References and SourcesOur project website: http://www.ilumina-dlib.orgProject papers on the site:JERIC: Towards a Sharable Digital Library of Reusable Teaching Resources: Roles for Rich Metadata. Journal on Education Resources in Computing (JERIC).JCDL: Developing Recommendation Services for a Digital Library with Uncertain and Changing Data. Joint Conference on Digital Libraries (JCDL)JLibAdmin: Library Services Today and Tomorrow: Lessons from iLumina, a Digital Library for Creating and Sharing Teaching Resources. Journal of Library Administration. Recent and upcoming presentations:IMS, Redwood Shores (11/15/01): Demonstration of iLumina and IMS metadata at Members ExchangeCLIR, New Orleans (1/24/02): Invitational Meeting on Courseware Systems, Integrated Library Systems, Content Strategies. Council on Library and Information Resources, Academic Library Advisory Council NLII, San Diego (1/27/02): Featured panel session on learning object repositoriesAERA, New Orleans (4/02): Interactive symposium: The National Science Digital Library for Science, Mathematics, and Technology Education: A technology demonstration and discussion
This presentation provides an overview of the iLumina project, which is developing a digital library of sharable resources created for and by higher education instructors. After a brief introduction to the goals of the project and the library interfaces and functionality, we focus on several aspects of our project, concerning:The use of IMS metadata, and how weve adapted the specificationelements and vocabulariesto suit the purposes of digital librariesThe construction and management of metadata in ways that increase its flexibility and reduce the costs of creation.How metadata is used to underpin a variety of library services, helping to offset their creation costs.How iLumina provides supports for all phases of the sharing of resources.What were planning to do in the near-term future to work with NSDL and to further our own project goals in that context.The basic premise behind iLumina is that a lot of learning, certainly in higher education and corporate training will be online, or have online components in the future; in short there will be a growing demand for e-learning. Of course, a lot of this demand will be met by traditional publishers, such as McGraw-Hill, or new entrants that develop ebooks for courses.But ebooks alone will not be enough, just as books are not. Faculty and instructors have always wanted to tailor formal content in books and supplement these materials with their own, informal often home-grown or created and shared by peers.These personalizations have always been important but limited, primarily because in the past instructors could only share resources on a local basis. But we believe that the Internet can scale this kind of peer-centric creation and sharing of informal resources, so that it becomes a much more vital part of building high-quality educational content. In general, iLumina wants to prove that thesis and build such a sharable library.This slide emphasizes the main themes of the iLumina research approach, at a very high-level. To begin with, we want to enable instructors (and other informal educational resource developers) to create and share their materials, which are often small or granular in size. To promote such sharing iLumina not only provides services that facilitate the creation and acquisition of resources, but also for the end-user, offers tools that will enable them to find and make use of the digital objects.One related theme is that IMS metadata can underpin tools that enable such sharing. iLumina uses IMS metadata tools to create rich and standardized descriptions of the learning objects that it manages. However, for this to work effectively, the costs of creating such rich metadata must be (relatively) low, in comparison to its benefits. Many have argued that minimalist metadata (such as Dublin Core), is not only easier to create than IMS/IEEE descriptions, but also more cost-effective. One question the iLumina project is addressing is whether this is true. An architectural theme is that the iLumina is both distributed (content) and centralized (metadata). That is, we encourage content providers to maintain their own materials, but we gather and manage their metadata so that end-users can come to a single sitethe iLumina portalto find collections from all over the Internet.This is a high-level view of what weve done in the last year.First, weve implemented the full IMS metadata information model (including recent updates), using SQL Server. Building on this we have developed a set of tools to create, manage, search and view the metadata, and the iLumina resources which they describe. This has enabled us to catalog a lot of library resources, now over 700 and growing all the time. Many of these are actually collections embedded in the larger iLumina collection. We provide tools to describe and view (with metadata) not only individual resources but the collections themselves.Metadata has provided a foundation for a number of core library services that are already in place, including basic (and advanced) search, browsing, and a contribution form that allows new content providers to catalog their materials for iLumina (although, they must also undergo review before being finally admitted to the library).Weve also moved ahead on an extended set of services, although most of these are still in the development stage. Some of them will be briefly highlighted below (and in accompanying demos).Finally one thing were also doing with metadata is participating in federated searches with other digital libraries, notably the SMETE Open Federation (SOF). Because all the libraries adhere to a common metadata standard, we are now able to search metadata across repositories and libraries and to access their content.This is a very brief overview of the iLumina architecture. See papers referenced at the end of this presentation for more details. A lot of iLumina is devoted to acquisition services that bring resources and metadata into iLumina. Note that there are several migration paths for materials into iLumina: Resources from existing repositories are mapped, meaning that the catalog entry for a resource from, say, CSTC, is simply translated into iLuminas catalog format. iLumina, in other words, relies on the fact that these resources have been reviewed, edited and cataloged. iLumina does not need to replicate these value-added services.However, informal collections and individual materials do not come with all of this, so we need to provide the services and tools for cataloging and reviewing, depicted in routes on the right. For individual resources, we will often need to provide an extra service, namely to provide a home for the resource (the iLumina Open repository), since the contributing faculty member may not have a server on which it can be published, maintained, and supported over time.Note that iLumina is partly federated and partly centralized. Resources are actually made up of two parts: the metadata (description) and the digital content itself. However, iLumina is actually a library of only the metadata, and the resources themselves stay in their separate repositories (even the iLumina Open database).This briefly explains how iLumina supports re-use in terms of a model of reuse weve adapted from Sumner. Of course, tools alone wont guarantee reuse; there are many less tangible motivational and community-based factors that a full model of reuse needs to consider. However, the supports and tools we provide do help, tactically, to reduce the costs and disincentives to use and reuse.The iLumina database tables include the full set of IMS v 1.2 elements, so we can parse all compliant records that are imported and store them in our repository. We can also export such records (as well as the records we create from scratch), for example, in response to federated search or harvesting requests), with no loss of information.However, although our database tables implement the full IMS information model, neither our metadata creation tools (the Submission form) nor search tools (the Advanced Search page) support all the elements uniformly (see previous charts for details of the supported elements). This also applies to other services that enables users to view and understand resources, such as Detailed Search Results pages and Browse. There are several (tentative) reasons for this selective support. First, several of the IMS Educational elements are not included. Many, such as SemanticDensity, simply have no pedigree and the cost of creating the description, at this time, exceeds any potential benefits. Furthermore, although other elements are used, they are clearly inadequate for the purposes that their names suggest. Rights.CopyrightandOtherRestrictions, for example, just provides an opportunity to say there are such constraints this is by no means the basis for services well obviously need in digital libraries to do digital rights management (DRM). For the same reasons, Annotations, especially dynamic ones created by users and reviewers, should probably also be put in separate records. Technical.MediaType and General.Thumbnail were the only elements added, beyond the IMS spec, although at several times we were tempted to extend the spec in other directions. In some of these cases we deferred because we realized the information was best not put in IMS (cataloging) metadata records at all (see below).Finally, although we made relatively few changes to IMS metadata elements, we have revised extensively several of the (recommended) vocabularies. At this time we have adopted less than half of those defaults without change. It is not surprising, in general, that weve made more changes to vocabularies than elements primarily because vocabularies are less standardized than elements in learning object classification, and in other areas as well. The fact that vocabularies are not very standardized, however, means that different communities and repositories are unlikely to use similar ones which will pose substantial problems for federated search and other NSDL services (see below).Metadata is used to help provide a number of services in iLumina beginning with search and extending to other purposes, well beyond discovery, including Browsing and Collection-level descriptions. This really isnt a new point, of course. A lot of folks in the digital library community and others that are using the standards are pushing metadata into other service areas as well. In general, theres no real reason to stop at using metadata for discovery, in spite of what some metadata cataloging experts think. But the question is: how far can metadata be pushed before youre doing inappropriate things with it? Were still testing the limits of metadata and considering its use for even more services. In spite of the fact that we can demonstrate benefits of the IMS metadata, in terms of multiple service uses, its still true that the costs of creating such rich metadata are high; and it will be essential to find ways of reducing them. iLumina not only uses efficient metadata tools to break this bottleneck, but also several other strategies, including automating some elements, cataloging collections rather than individual items (or using the collection description as a template for items), and distributing metadata creation among different contributors (e.g., author, cataloger, editor, reviewer). Other approaches are possible and will be critical in the future.Metadata tools will also need to be flexible, not just efficient, because different communities, like iLumina, will need different metadata elements, and certainly vocabularies. A good tool will need to adapt to each repositories needs. And, it will also need to support mapping from one set of schemas to another, otherwise cross-repository federated services will be virtually impossible.Finally, as we noted above, there is always the concern that, to get more out of metadata, you have to put more in some of which may not belong there. Weve decided to pull several kinds of information into separate modular records that others may be putting into the basic metadata records. This includes: (i) anything that smacks of digital rights management (DRM); (ii) annotations, ratings and reviews and other pieces of dynamic description; and (iii) contributor descriptions. iLumina supports the IMS spec in the sense that when we export records, we provide vcard-formatted strings for the appropriate contributor elements. But internally, we use, separate records that encode information about contributors, or more generally, agents known to iLumina. In other words, we dont embed contributor (vcard) information, but rather factor it out of metadata into modular representations, and reference those descriptions in metadata records as well as to provide other services. In general, modularizing in this way should improve library functionality and cut description costs.
iLuminas goal is to provide science, math, engineering and technology resources for undergraduate teaching and learning. iLumina also provides tools to use, and re-use, resources and services that facilitate resource discovery and community interaction. Some of the services provided on iLuminas home page include: 1) an overview of library contents that note the number of resources contained within each discipline; 2) a dynamically generated list of the most recent resources submitted to iLumina; 3) access to technical documents describing iLuminas architecture and detailing development processes; 4) links to articles about work on all aspects of digital libraries.iLumina is a repository of metadata, which is acquired in three ways: mapping metadata, importing metadata in batches and cataloging metadata from individuals. While mapping and importing yield high amounts of metadata, those processes do not invite users to participate in the library environment. The Contribution Form was designed for users to play an active role in contributing a resource and its metadata into iLumina for several reasons: 1) Less chance for error when the expert is describing his or her resource; 2) Lower iLuminas acquisition costs by not having to hire catalogers; 3) Testing the IMS schema, which is one of the objectives of our grant.To aid our audience in describing and finding resources, we used metadata with non-standard vocabularies in addition to IMS metadata with standardized vocabularies. For example, content experts and librarians developed vocabularies for subjects and topics to collect non-standard metadata vocabulary within Discipline.To minimize cataloging errors, we collect metadata by using a combination of drop-down lists containing controlled vocabularies and fill-in-the-blank fields. To guide users through the process of cataloging their resource(s), we designed an interface with the goal of reducing or removing barriers to authors completing the form.One of the challenges of acquiring metadata is to minimize the cost of metadata creation for the authors. Some solutions include: 1) Require that a limited number of elements be completed (Title, Discipline); 2) Automate completion of some elements (Contributor); 3) Design efficient interfaces; 4) Educate users through point-of-need help screens.iLumina provides multiple perspectives and various means of accessing resources in the library. Advanced Search allows users to limit items in a known search. Browse gives users an overview of iLumina. iLumina also makes collections of resources accessible via a collection-level metadata record. The schema used for this record is RSLP (Research Support Libraries Programme); however, the elements are similar to the point of providing seamless service from Browse through to the collection-level record.Collection-level metadata records are used to record information common to a set of resources, where commonalities can be based on a number of features, such as authorship, topic or format. Although we have currently cataloged only a small number of collections in iLumina, we are now aware that the repository embeds a larger number of them, and are capturing them on a post-hoc basis.Describing resources at the collection-level provides users a different view of resources by showing relationships between and within collections of all sizes. Collection-level description also supports comprehension of collections in a way different from item-level metadata by associating content or themes. Furthermore, we suspect that collection-level descriptions are likely to be even more relevant to digital libraries than to traditional ones. With new web-based and desktop production tools, many faculty are now quite capable of authoring substantial sets of resources for their classes. Digital libraries need to capture this in collection-level metadata.These points represent our main project plans at this time. Note that while the areas target goals that are critical to the success and growth of our own project project, they are also informed and support the goals of NSDL as a whole, as we see them. For example, not only are we planning to increase the size of our own (metadata cataloged) collections and extend iLumina services. But we also want to work with NSDL groups, and members of the SMETE Open Federation (SOF), to create general versions of the tools and services we are using ones that other NSDL projects could also adopt. Similarly, we are planning to participate in federated search and metadata harvesting activities that will involve several other projects and research teams.
This presentation has provided a fairly high-level overview of iLuminas goals, architecture, current progress and future plans. But it omits most of the details. Additional information on the project as a whole can be found in our project site at www.ilumina-dlib.org. The site provides timely news about what the project is doing, as well as information of general interest to the digital library community. This is also where we make our papers and presentations publicly available. A couple that we have referenced in this presentation are noted here; many more are accessible through the iLumina site.