IMS GLC Learning Object Discovery and Exchange (LODE)
Base Document Version 1.0
Date
Issued: 2 March 2010
Latest version: http://www.imsglobal.org/lode/index.html
IMS Learning Object Discovery & Exchange (LODE) copyright 2010 by IMS Global Learning Consortium is licensed under conditions equivalent to a Creative Commons Attribution-Share Alike 3.0 United States License with an additional condition that derivative works that are publically distributed must be shared back with the IMS LODE community. This is accomplished by posting your derivative works to the public LODE web site. Instructions for posting are found on the web site at the following page: http://www.imsglobal.org/lode/shared_works.html . Additional derivative works may also be found there.
If you wish to create and distribute a derived work from this document, you are hereby granted permission to copy, display and distribute the contents of the derived work in any medium for any purpose without fee or royalty provided that you include this IPR, License and Distribution notice in its entirety on ALL copies, or portions thereof,. IMS GLC provides free resources for developing profiles of IMS GLC specifications and machine readable bindings. Those creating derivative works are encouraged to use these tools. To do so, follow the instructions on the IMS GLC web site: http://www.imsglobal.org/profile/
This document originated from the IMS Learning Object Discovery & Exchange by IMS Global Learning Consortium.
THE IMS LODE SPECIFICATION OR DERIVATIVE WORK THEREOF IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER’S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by the contents of this document. Please notify IMS GLC: http://www.imsglobal.org/contactus.cfm
IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS’s procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf .
Join the discussion and post comments on the LODE Forum: http://www.imsglobal.org/community/forum/index.cfm?forumid=9
Table of Contents
1.2 Structure of this Document
3.1 Introduction to the Registry Data Model
3.1.1 LODE Registry Data Model Overview
3.2 Definitions: Core Entities
3.3 Definitions: Federation and Collection Discovery
3.7.2 Protocol Implementation Description
3.10.3 Content Collection Root
3.10.4 Metadata Collection Root
4 Information for Learning Object eXchange (ILOX) Data Model
4.1 Introduction to the ILOX Data Model
4.2 Conceptual Model: Learning Objects, Versions, Formats, and Copies
Appendix A.1 – Use Cases Out of Scope
List of Figures
Figure 1.1 - IMS LODE at work.
Figure 2.1 - Overview of the LODE use cases.
Figure 3.1 – ISO 2146 reference model [ISO, 09].
Figure 3.2 – Relationships between the LODE Registry entities.
Figure 3.3 - LODE Registry class diagram.
Figure 4.1 - A learning object can have multiple copies.
Figure 4.4 - Pattern for describing the different FRBR aspect of a learning object.
1 Introduction
The Learning Object Discovery & Exchange (LODE) specification aims to facilitate the discovery and retrieval of learning objects stored across more than one collection.
In the context of this work, a learning object can be anything digital used for teaching, learning, or training. Learning objects can consist of simple assets (e.g., text, images, short videos) that can generally be directly rendered in a web browser,or more complex resources that usually consist of multiple components (e.g., text, images, simulations, videos, assessment exercises, etc.) that need to be combined in a precise way in order to provide end-users with a meaningful learning experience. Learning content specifications such as IMS Content Package and IMS Common Cartridge make it possible for such learning objects to be reused in different learning systems. This is achieved by packaging all the required components in a zip file together with a manifest describing how these components have to be rendered. As a result of this process where specifications have been applied, the content becomes more ‘interoperable’ and can be more easily exchanged and reused in learning platforms from different commercial vendors, or in open source learning (content) management systems,that comply with the relevant content packaging specifications.
Although the use of learning platforms is becoming common in most educational organizations, and the number of learning objects available online, for free or by subscription, is huge, most of these learning objects are not globally discoverable, which hampers their potential use and reuse. Improving access to these learning objects would have a significant impact on learning.
Over the last few years, IMS has produced specifications that make it easier to exchange and reuse general-purpose learning objects:
· QTI
· Common Cartridge
· Content Packaging
· Simple Sequencing
· Learning Design
All of these specifications allow specific types of learning objects to be transferred between systems and reused but do not address the issue of how this content can be found. IMS has also produced specifications such as Learning Resource Metadata and VDEX that aid discovery by unifying the descriptions of this content. The missing piece in this collection of specifications is a protocol to support the discovery and exchange of all this interoperable content.
LODE is based on the following assumptions:
· Learning objects are described by metadata such as IEEE LOM or Dublin Core.
· Multiple metadata instances might be necessary in order to adequately describe all the aspect of a learning object (i.e., in order to provide the information necessary to support the LODE use cases).
· Metadata can be gathered to create searchable catalogues of learning objects.
· Consulting such metadata catalogues is the main way to obtain the information necessary to search for learning objects, assess their usefulness, and retrieve them.
· Metadata catalogues are stored in repositories.
· Repositories can be searched programmatically using a standard Application Programming Interface (API) such as the Simple Query Interface (SQI) or Search/Retrieve with URL (SRU).
· Large catalogues can be created by harvesting (i.e., mirroring) metadata stored in repositories using protocols such as the Open Archives Initiative – Protocol for Metadata Harvesting (OAI-PMH).
IMS LODE can be seen as a glue specification that profiles existing general-purpose protocols in order to take into account requirements specific to the educational domain, rather than creating new protocols. It proposes three main data models:
- A LODE Context Set for the Contextual Query Language (CQL): a data model for the attributes of learning objects, which can be used for search by expressing educationally meaningful queries;
- A data model, named Information for Learning Object eXchange (ILOX), that organizes sets of metadata on learning objects to be used in data exchange; and
- A data model, named Learning Object Repository Registry Data Model, for learning object collections, to be used in discovering and configuring access to those collections.
Figure 1.1 - IMS LODE at work.
The diagram of Figure 1.1 illustrates how the IMS LODE specification can be combined with other specifications to permit to a LODE Client (i.e., a system that relies on the IMS LODE specification to discover and access learning objects) to actually obtain such learning objects.
Learning objects are described by metadata stored in repositories. The latter use different search and/or harvesting protocols (e.g., SQI, SPI, OAI-PMH) to expose metadata. In order to get access to this metadata, the first step is to discover the repositories in which it is stored.
The IMS LODE Registry Data Model provides a consistent way to describe repositories, their collections of learning objects and metadata, and the protocols they support. This enables the registration of repositories in a central registry that can be accessed by LODE clients. When consulting a LODE Registry, a LODE Client obtains repository descriptions that contain all the information needed to automatically connect to the repositories and get access to their metadata collections.
For those repositories that support search protocols such as SQI or SRU, the LODE Context Set for CQL (LODE CQL) enables LODE Clients to express queries in terms of learning object attributes.
Finally, whatever the protocol used by a LODE client to obtain metadata (search or harvesting), using LODE ILOX to organize the different metadata instances returned by this protocol ensures that all the information necessary to get access to learning objects is present and well-organized, without confusing the kinds of learning object described, and can be handled easily.
1.1 Scope and Context
The LODE activity in IMS is tasked with facilitating the discovery and retrieval of learning content stored in repositories. The “exchange” requirement centers on the fact that, while learning content repositories already cater for their local users, there are no agreed profiles that address the needs of the learning domain, and no established practices for combining existing specifications into complete solutions. Individual organizations are creating their own solutions, with quite different technical strategies, policy apparatus, and metadata schemes, and an opportunity to establish broader interoperability is being missed. There is also no way of measuring or testing the compatibility and conformance of specific solutions.
The following are considered in scope for the activity:
· Search protocol, search query, and search results (i.e., metadata)
· Metadata harvesting
· Application of identifiers
· Collection and service description
The following areas are considered out of scope of this activity:
· Authentication, authorization, access (unless it is part of a specific protocol)
· Digital Rights Management
· Identity management
· Metadata application profiling
Most stakeholders should benefit from agreed profiles and established practices that combine existing specifications into complete solutions addressing the needs of the learning domain for learning object discovery and exchange.
· Educators will have an easy way to discover learning content that addresses the needs of their students, making their jobs easier, and maximizing re-use and minimizing the cost of re-invention of materials.
· Students will have the benefit of access to the highest-quality learning resources available, making a significant impact on the quality of their learning experience and their learning outcomes.
· Content providers will be able to advertise their products by making them globally discoverable.
· System vendors will have a limited, well-defined set of specifications to support to make their systems compliant with major federations of learning resources.
· Finally, federation builders will secure their investment by developing infrastructures based on standard specifications.
Interoperability will be demonstrated when a system (e.g., a LMS) end user is able to discover a compatible learning object (e.g., a common cartridge) hosted on a separate system (e.g., a learning object repository) using a LODE-compliant discovery service. Demonstrations will focus on federated discovery (through either federated search or harvest-driven centralized search), as these present the greater interoperability challenge. The federations should be based on LODE search and LODE registry specifications. However LODE does not require federation for compliance. “Federated” is used in a loose sense to refer to a group of distributed, independently managed and potentially heterogeneous repositories, whether or not any agreements, trust relationships etc. exist between them.
The IMS Global Learning Consortium has entered into a memorandum of understanding (MOU) with European Schoolnet to foster collaboration across Europe on the LODE specification in the framework of the European Commission funded ASPECT project. See the official announcement here: http://www.imsglobal.org/pressreleases/pr090212.html. Through this partnership, IMS GLC and European Schoolnet encourage the use of open standards and specifications for learning technology in schools throughout Europe.
1.2 Structure of this Document
The structure of this document is:
|
1. Introduction |
Overview of the complete LODE information model |
|
2. Use Cases |
Use cases addressed by LODE information model |
|
3. LODE Registry Data Model |
Data model for description of collections of learning data objects |
|
4. Information for Learning Object eXchange (ILOX) Data Model |
Data model for structuring sets of learning object metadata |
|
5. LODE Search Data Model |
Data model for search query parameters for learning objects |
|
Appendix: Use Cases (Full) |
Full details of use cases addressed by LODE information model |
1.3 Nomenclature
API Application Programming Interface
a-API Abstract Application Programming Interface
IAF IMS/GLC Abstract Framework
IMS GLC IMS Global Learning Consortium Inc.
LODE Learning Object Discovery & Exchange
LOM Learning Object Metadata
OAI-PMH Open Archives Initiative – Protocol for Metadata Harvesting
PIM Platform Independent Model
PMS Person Management Service
PSM Platform Specific Model
RFC Request For Comment
SDN Specification Development Note
SQI Simple Query Interface
SRU Search/Retrieve via URL
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
WSDL Web Services Description Language
1.4 References
[APG, 05a] IMS GLC Application Profile Guidelines Overview: Part 1 – Management Overview v1.0, K.Riley, IMS Global Learning Consortium, October 2005. http://www.imsglobal.org/ap/index.html.
[APG, 05b] IMS GLC Application Profile Guidelines White Paper: Part 2 Technical Manual, S.Wilson and K.Riley, Version 1.0, IMS Global Learning Consortium, October 2005. http://www.imsglobal.org/ap/index.html.
[ASP, 09] Design of Data Model and Architecture for a Registry of Learning Object Repositories and Application Profiles, D. Massart, N. Smith & R. Tice, ASPECT Project, March 2009. http://aspect.eun.org/sites/default/files/docs/ASPECT_D2p2.pdf
[CANCORE, 04] CanCore Guidelines for the Implementation of Learning Object Metadata (IEEE 1484.12.1-2002), N. Friesen, S. Fisher, & A. Roberts, April 2004. http://www.cancore.ca/en/guidelines.html
[CCR, 08] Creative Commons Rights Expression Language, H. Abelson, B, Adida, M. Kinsvayer & N. Yergler, March 2008. http://wiki.creativecommons.org/CcREL
[CQL, 08] CQL: Contextual Query Language (SRU Version 1.2 Specifications), Library of Congress. http://www.loc.gov/standards/sru/specs/cql.html
[CQLBIB, 09] CQL Profile for Bibliographic Searching, Library of Congress. Version 1.0. July 2009. http://www.loc.gov/standards/sru/resources/cql-bibliographic-profile.html
[DCCAP, 07] Dublin core collections application profile, Dublin Core Collection Description Task Group, March 2007. http://dublincore.org/groups/collections/collection-application-profile/
[DCME, 08] Dublin Core Metadata Element Set, Dublin Core Metadata Initiative, Version 1.1, January 2008. http://dublincore.org/documents/dces/
[FRBR, 98] Functional Requirements for Bibliographic Records: Final Report, IFLA Study Group on the Functional Requirements for Bibliographic Records, 1998. http://archive.ifla.org/VII/s13/frbr/
[GWS, 05] IMS GLC General Web Services WSDL Binding Guidelines v1.0 Final Specification, C.Schroeder, J.Smon and C.Smythe, IMS Global Learning Consortium, December 2005.
[IAF, 03a] IMS GLC Abstract Framework: Applications, Services & Components v1.0, Ed. C.Smythe, IMS Global Learning Consortium, July 2003.
[IAF, 03b] IMS GLC Abstract Framework: Glossary v1.0, Ed. C.Smythe, IMS Global Learning Consortium, July 2003.
[IAF, 03c] IMS GLC Abstract Framework: White Paper v1.0, Ed. C.Smythe, IMS Global Learning Consortium, July 2003.
[IANA, 07] MIME Media Types, IANA, March 2007. http://www.iana.org/assignments/media-types/
[ISO, 05] Information technology—Learning, education and training -- Quality management, assurance and metrics—Part 1: General approach. JTC 1/SC 36. http://www.iso.org/iso/catalogue_detail?csnumber=33934
[ISO, 09] Information and documentation—Registry Services for Libraries and Related Organisations. ISO TC 46/SC 4. http://www.iso.org/iso/catalogue_detail.htm?csnumber=44936
[ISO8601, 04] Data elements and interchange formats—Information interchange—Representation of dates and times. ISO 8601:2004. International Organization for Standardization. December 2004. http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetch&nodeid=4021199
[LOC, 08] ISO 639-2 Registration Authority , Library of Congress, 2008. http://www.loc.gov/standards/iso639-2/
[LODE, 07] Charter for IMS Learning Object Discovery and Exchange (LODE), D. Massart, M. Morrey, C. Smythe, IMS Global Learning Consortium, 2007. Online version: http://members.imsglobal.org/forum/ims/dispatch.cgi/f.federatedar/showFile/100146/d20071009182840/Yes/lodeCharter.pdf
[LOM, 02] Standard for Information Technology—Education and Training Systems—Learning Objects and Metadata, W. Hodgins et al., IEEE Learning technology Standards Committee, December 2002. http://ltsc.ieee.org/wg12/materials.html
[MARC, 03] Source Codes for Classification, Library of Congress, Network Development and MARC Standards Office, August 2003. http://www.loc.gov/marc/sourcecode/classification/classificationsource.html
[MATER, 94] Materialization: a powerful and ubiquitous abstraction pattern, A. Pirotte, E. Zimányi, D. Massart, and T. Yakusheva. In J. Bocca, M. Jarke, and C. Zaniolo, editors, Proc. of the 20th Int. Conf. on Very Large Data Bases, VLDB’94, pages 630–641, Santiago, Chile, 1994. Morgan Kaufmann.
[MYLOPOULOS, 98] Information modeling in the time of the revolution, J. Mylopoulos, Information Systems, 23(3– 4):127–155, 1998.
[NSDL, 07] Metadata Guidelines: Access Rights, The National Science Digital Library, October 2007. http://nsdl.org/collection/accessRights.php
[OAI, 04] The open archives initiative protocol for metadata harvesting version 2.0, Document Version 2004/10/12T15:31:00Z, C. Lagoze, H. Van de Sompel, M. Nelson, & S. Warner. Also available as http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm, 2002.
[PRI, 09] Publishing Requirements for Industry Standard Metadata, IDEAlliance, May 2009. http://www.prismstandard.org
[RDCEO, 02] IMS Reusable Definition of Competency or Educational Objective—Information Model, IMS Global Learning Consortium, October 2002. http://www.imsglobal.org/competencies/rdceov1p0/imsrdceo_infov1p0.html
[SDN07, 06] IMS GLC Specification Note 7: UML Profile for Platform Independent Model Descriptions of Specifications for Data Models v1.0, C.Smythe, IMS Global Learning Consortium, October 2006.
[SDN11, 06] IMS GLC Specification Note 11: Vocabulary Definition, Registration & Maintenance Procedures, C.Smythe, IMS Global Learning Consortium, October 2006.
[SIL, 09] ISO 639-3 Registration Authority , SIL International, 2009. http://www.sil.org/iso639-3/
[SPI, 08] A simple publishing interface for learning object repositories, S. Ternier, D. Massart, F. Van Assche, N. Smith, B. Simon, & E. Duval. Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2008 (Vienna, Austria), AACE, June 2008, pp. 1840–1845. http://www.editlib.org/p/28625
[SQI, 05] A simple query interface specification for learning repositories, CEN Workshop Agreement (CWA 15454). B. Simon, D. Massart, F. Van Assche, S. Ternier, & E. Duval. Also available from ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/CWA15454-00-2005-Nov.pdf, November 2005.
[SRU, 08] SRU Version 1.2 Specifications, Library of Congress. http://www.loc.gov/standards/sru
[SWO, 08] SWORD: Simple Web-service Offering Repository Deposit,J. Allinson, S. François & S. Lewis. Ariadne 54, January 2008. http://www.ariadne.ac.uk/issue54/allinson-et-al/
[VCARD, 98] vCard MIME Directory Profile, F. Dawson & T. Howes, Internet Engineering Task Force., RFC 2426. http://tools.ietf.org/html/rfc2426
[VDEX, 04] IMS Vocabulary Definition Exchange Best Practice and Implementation Guide, Version 1.0 Final Specification, A. Cooper, IMS Global Learning Consortium, 2005. Online version: http://www.imsglobal.org/vdex/vdexv1p0/imsvdex_bestv1p0.html
[W3C, 06] Web Services Policy 1.5—Primer, W3C Web Services Policy Working Group, October 2006. http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/
[XML, 04] XML Schema Part 2: Datatypes Second Edition,World Wide Web Consortium, October 2004. http://www.w3.org/TR/xmlschema-2/
2 Use Cases
The IMS LODE specification consists of 3 main data models:
- The IMS LODE Information for Learning Object eXchange (ILOX) data model,
- The IMS LODE Registry data model (Registry), and
- The IMS LODE Search data model (CQL).
Each of these data models addresses different use cases. The mind map of Figure 2.1 recaps all the use cases that were considered within the scope of the IMS LODE specifications. Each category of use cases is followed by the identifiers of the use cases belonging to this category. The data model addressing these use cases is indicated between parentheses. The complete list of use cases considered during the chartering of the LODE activity [LODE, 07] are listed in Table XX, ordered by use case identifier. Use cases out of scope have been kept for completeness (they are struck through to avoid confusion). The uses cases themselves are given in full in the Appendix.
Figure 2.1 - Overview
of the LODE use cases.
|
Identifier |
Title |
|
1** |
Professor searches for colleagues' resources |
|
2** |
Register Repository Metadata with Registry |
|
3** |
Pull Metadata of Item into Registry |
|
4** |
Update Metadata of Item in Registry |
|
5** |
Discover item through registry (Search) |
|
6** |
Add Repository to Directory Roster |
|
7** |
Discover item through roster (Full text Federated Search) |
|
8** |
Searching remote repositories through a European Digital Library web service |
|
9** |
Harvesting and indexing repositories with a European Digital Library harvesting and indexing service |
|
10** |
Federated Search |
|
11** |
Harvesting Search |
|
|
|
|
13** |
Instructor conducts search by metadata value |
|
14** |
Alocom powerpoint plug searches a learning object repository |
|
15** |
ARIADNE federated search |
|
16** |
VLE searches a Learning Object Repository |
|
17** |
Disclosure and Social Contribution: Organization level |
|
18** |
Sharing and reuse of digital learning resources: Faculty and Teachers level |
|
|
|
|
20** |
Resource detail information browsing |
|
21** |
Basic search |
|
22** |
Advanced search |
|
23** |
Federated Search |
|
24** |
Search/Browse for Finding |
|
25** |
Previewing for Use |
|
26** |
Selecting, Assembling, and Annotating for Use |
|
27** |
Choosing, Rendering, and Buying content |
|
28** |
Learning resource exchange federated search |
|
29** |
Federated discovery of repositories |
|
30** |
Federated harvesting |
|
31** |
Search LORs to get results sorted by relevance |
|
|
|
|
33** |
Tutor refines their search criteria using properties exposed by the target repositories |
|
34** |
Tutor browses repositories by subject classification |
|
35** |
Tutor selects content objects for inclusion in course |
|
36** |
Student is shown latest version of a content object |
|
37** |
LMS downloads copy of a content package from LOR |
|
|
|
|
39** |
Tutor previews content stored in a LOR |
|
40** |
Tutor reads full catalogue record |
|
41** |
Tutor in an LMS comments on an object in a LOR |
|
|
|
|
|
|
|
|
|
|
|
|
|
46** |
Resource access |
|
|
|
|
48** |
Annotate item |
|
49** |
Recommend item |
|
50** |
Rate item |
|
|
|
|
52** |
Display Objects |
|
|
|
|
|
|
|
55** |
Tutor chooses specific version of a content object to use in a course |
|
56** |
Querying learning resources based on a rating or other annotation |
The ILOX data model permits structuring metadata (for example metadata that is harvested or present in search results) in a way that allows for:
- Exposing and combining metadata of different origin (e.g., LOM produced by publishers and Web 2.0-like annotations by end-users, or accessibility metadata).
- Making explicit different content uses.
The Registry data model permits discovery of learning object repositories based on the properties of the learning object and metadata collections managed by these repositories, and on the protocols supported by these repositories to expose their collections. The registry data model provides enough information to allow automated configuration of search and harvest clients wishing to access a repository.
Finally, the search data model permits expressing the various queries covered by the query expression use cases.
3 LODE Registry Data Model
3.1 Introduction to the Registry Data Model
3.1.1 LODE Registry Data Model Overview
The Learning Object Discovery & Exchange (LODE) Learning Object Registry Data Model provides a scheme of describing collections of learning data objects, the persons responsible for those collections, and the available mechanisms for interacting with those collections.
Descriptions following this model are intended to facilitate exchange of learning content between different collections. The model provides a consistent framework, independent of local registry configuration, for:
- collection discovery
- evaluation and vetting of collections
- access to collections (e.g., harvesting or searching)
- automated configuration of access to collections
3.1.2 Scope and Context
In order to access collections within repositories, the participants need a common metadata description of their respective collections, including who is responsible for the collections (and will be involved in negotiating the exchange of learning content), how to establish access to the collections, and what are the constraints on access to the collections. Having such metadata in machine-readable form allows content exchange to be substantially automated. This model provides a framework for such metadata.
LODE has emphasized reuse of existing specifications related to digital libraries, generic repositories, and learning repositories. To that end, the framework described here is substantially based on the ISO 2146 model for registry description [ISO, 09], which offers a generic model for registries of content, not bound to any particular protocol or platform. (The ISO 2146 model is not specific to machine readable collections.) The framework outlined uses the ASPECT project’s profile of the ISO 2146 model in its own description of learning content registries [ASP, 09]. ASPECT has already successfully tested this framework, aggregating disparate e-learning collections in the European Union.
The LODE registry framework makes it possible for collections to form federations of learning content registries, both on a formal and an ad hoc basis. The common metadata for collection description and access reduces the barriers to content exchange across a federation, and enables ad hoc federation. This broadens the range of learning content that federation members have access to, and promotes content reuse.
3.2 Definitions: Core Entities
A learning object is anything (usually a digital object) that can be used for teaching or learning. Learning objects can range from simple learning assets (for example, an image that can be used to illustrate a lesson), to complex learning resources, such as a complex multi-media course with multiple components.
Learning objects are described by metadata in a machine-readable format. Metadata makes learning objects easier to find and to access. Metadata are themselves digital objects.
A well-managed grouping of objects is a collection. Collections are managed to conform to a common set of policies, which include policies on access and on what can be included in the collection. The objects in a collection usually have common subject matter, purpose, and provenance. In e-learning, this takes the form of:
· subject matter: what courses may be supported by the learning objects in the collection (e.g. secondary school mathematics)
· purpose: support for a particular cohort of learners (e.g. students in public schools in Wales)
· provenance: authoring or dissemination from a particular institution (e.g. an education ministry, or a content vendor)
Collections may be content collections, i.e. collections of learning objects and their associated metadata. They may also be metadata collections, containing only metadata descriptions of learning content objects; those learning content objects themselves may be available in different collections. A metadata collection may be restricted to learning objects in particular content collections. The metadata in a metadata collection may be distinct from the metadata accompanying an item in a content collection; for example the metadata collection may include third-party reviews of the content collection items.
Collections may include other collections, or may be derived from other collections. These relations are constrained to the same type of collection: metadata collections cannot include or be included by content collections, and cannot derive or be derived from content collections.
Learning object repositories are specialized software systems used to manage collections. A repository need not be coterminous with a collection: a collection may be spread out over several repositories, and a repository may host multiple collections.
Partiesinteract with collections, in order to realize particular activities. Parties include both the end users of the collections (consumers), and those responsible for making the collections available (providers). Providers include the parties who generate the collection items; the parties who maintain the repository software system; and the parties who manage the collection as a whole. The latter responsibility includes contributing metadata, procuring content, performing quality control on content, and setting and enforcing collection policies.
Repositories support services allowing parties to access items in the collections they host. Users, including both humans and machines, interact with services through targets, which are the network addresses of the services (service endpoints). Those services follow one or more protocols, and are subject to access policies on who may use the services, and when. Services of interest in the e-learning domain include: the Open Archive Initiative Protocol for Metadata Harvesting (OAI-PMH) [OAI, 04], the Simple Query Interface (SQI) [SQI, 05], Search/Retrieval via URL(SRU) [SRU, 08], and the Simple Publishing Interface (SPI) [SPI, 08].
Under the ISO 2146 model [ISO, 09], a registry is an aggregation of collections, parties, services and activities which together support the business of a given community. Our use of repository above corresponds to the ISO 2146 use of “registry”. ISO models the relation between registry objects as follows.
Figure 3.1 – ISO 2146 reference model [ISO, 09].
The collection descriptions modelled here present metadata on the collection itself; on core parties responsible for the collection; and on services which interact with the collection. Since the descriptions are used to configure machine-to-machine interaction with collections, services are modelled as targets, so that two different network locations of the same service are modelled as distinct entities. The description of services includes both protocol information and access policy metadata. Details of configuration for individual targets are modelled as protocol implementation descriptions, and are idiosyncratic to the particular protocol. Two targets may use the same protocol, but have different configurations for that protocol.
The entities modelled here are related as follows:
Figure 3.2 – Relationships between the LODE Registry entities.
Descriptions of ISO 2146 activities are out of scope of this model. The parties and services that the descriptions represent presuppose core activities: creating items in a collection (both learning objects and metadata); managing a collection and repository services for the collection; and discovering and accessing items in a collection, and the collections themselves.
Likewise items and their descriptions are out of scope of this model. The goal of all activities is to interact with the items, but models for describing learning content items are already defined elsewhere, e.g. see LOM and ILOX. It is important to differentiate metadata describing collections of items, and metadata describing the items they contain: the metadata overlap, but are not identical.
3.3 Definitions: Federation and Collection Discovery
3.3.1 Federation
A federation is a grouping of repositories, which allow their users to access content from any participating repository. A federation has infrastructure to enable such access, which takes the form of a central registry of the participating repositories. The collection descriptions outlined here support federation through descriptions of the participating repositories. The descriptions are framed in terms of the collections that the repositories publish; those descriptions can be stored and added to in the central registry.
There are two models of federation, depending on how content in the repositories is discovered. Under federated search, requests for discovery of items are carried out separately on each participating repository: the results are aggregated by a search tool and presented to the user as they become available. Because the requests are separate for each repository, and the registry’s role is only to aggregate search results, repositories can remain autonomous in their policy and even their metadata profiles: the searches can be transformed as required by the central registry hub into a consistent format.
Under centralized search, searchable descriptions of items are copied from participating repositories into a central repository. This is typically realized through harvesting; it can also be achieved if indexes from participating repositories are periodically imported into the central repository, or if a push protocol such as SPI [SQI, 05] or SWORD [SWO, 08] is used by participating repositories to initiate the copying. Requests for discovery of items are carried out on the central repository, which mediates user access to federation content.
The LODE registry model supports both types of repository federation. The federated search model assumes that search will be the main service for interacting with participating repositories; the centralized search model assumes it is harvest or push. Either type of interaction can be documented through the service descriptions included in the collection descriptions; and those service descriptions can be used to configure federations automatically.
The two types of federation motivate the use of collection descriptions. The metadata about the collections themselves can be used in the processes described, to narrow the range of repositories over which discovery is attempted.
3.3.2 Collection Discovery
Outside federation, the other use case motivating the collection descriptions is collection discovery in its own right, without being coupled directly to item discovery. Collection descriptions make collections discoverable: they allow users to identify relevant collections in e-learning, and the parties responsible for arranging access to those collections. In the absence of a federation structure, the actual access needs to be arranged off-band, on a one-on-one basis. The descriptions also allow users to navigate the references of collections to other collections, either through description (metadata collection describes content collection), or inclusion (collection contains collection).
If the collections being described are open access, ad hoc federations can be put together, enabling content discovery across a range of repositories without explicit negotiation. However, discovery across those repositories is constrained to the extent that they use the same metadata for describing their items.
Machine readable collection descriptions also allow collections to be discovered automatically by a registry, so long as the collections are available in a location the registry is already aware of. While this still presupposes some negotiation, such dynamic discovery of collections allows registries to be more flexible in the range of federations they can support.
3.4 Data Types
The model uses the following data types from IEEE LOM [LOM, 02]:
- CharacterString: text; may have a maximum number of characters defined
- LangString: one or more CharacterString with indication of the language each CharacterString is in.
- Identifier: a generic type under IEEE LOM. In this model it takes the form of a pair of an Entry (CharacterString), which is the identifier string itself, and a Catalog (CharacterString) indicating the identifier namespace.
- VocabularyTerm: a pair of a Value (CharacterString) giving a term taken from a fixed vocabulary, and a Source (CharacterString) identifying the fixed vocabulary.
- DateTime: a date specified according to ISO8601 [ISO8601, 04]
Many properties of collections are derived from the properties of their items (e.g. subject, purpose). Because collections are not homogeneous, such collection properties often only apply to a subset of all items. To reflect this, this model uses the Property data type, which allows for relative strengths of properties in a collection. A Property type has a Source and Value, with the same meaning as for VocabularyTerm, and a Strength quantifier, which can take one of the values “some”, “most”, and “all”: this means that the property applies to some, most, or all of the items in the collection. The quantifier is optional, and the assumed default value is “some”.
The model also uses Integer and anyURI, both with their accepted meaning in XMLSchema. [XML, 04]
3.5 UML Diagram
The following UML diagram summarizes the overall realization of the model; refer to the XML Binding of the model for further information. The semantics of the model is discussed below.
Figure 3.3 - LODE Registry class diagram.
3.6 Collection Attributes
Collections are modelled using the Dublin Core Collections Application Profile (DCCAP) [DCCAP, 07] with contributions from ISO 2146 and IEEE LOM.
While content collections and metadata collections are both collections, their attributes are modelled differently, to account for contextual differences between the two.
3.6.1 Content Collection
The following attributes describe content collections as a whole:
|
Identifier |
An identifier of the content collection. |
Identifier |
Mandatory |
|
Description |
A description of the collection. |
LangString |
Mandatory |
|
Collection Rights |
A description of the rights that apply to the collection as a whole. |
LangString |
Optional |
|
Keywords |
A list of keywords for describing the collection as a whole. |
LangString |
Optional |
|
Average Annual Increase |
The average annual increase in the number of learning objects in the collection. This can be a negative number. |
Integer |
Optional |
|
Accrual Periodicity |
An attribute using a controlled vocabulary from DCCAP [DCCAP, 07] to describe how often new learning objects are added to (or removed from) the collection. |
VocabularyTerm |
Optional |
The following attributes describe collection-level properties of the items (i.e., learning objects) in a content collection. For that reason, they all have the Property data type. Because of the potentially incomplete coverage of any one collection-level property, all collection-level properties can occur zero or more times. For instance, a collection may contain items in seven different languages, in which case it has seven different Language properties, each of which may have its own Strength attribute.
|
Quality Procedure |
The quality procedure(s) applied to the items in the collection. |
Property |
Optional |
|
Subject |
The subject(s) covered by the learning objects in the collection. |
Property |
Optional |
|
Language |
The language(s) of the learning objects in the collection. |
Property |
Optional |
|
Type |
The learning resource type(s) (cf. LOM 5.2) of the learning objects in the collection. For example: “assessment”. |
Property |
Optional |
|
Representation |
The representation(s) in which the learning objects in the collection are available. For example: “QTIv2.1”. |
Property |
Optional |
|
Format |
The technical format(s) of the learning objects in the collection. For example: “application/swf”. |
Property |
Optional |
|
Intended User Role |
The intended role(s) of the user of the learning objects in the collection. |
Property |
Optional |
|
Context |
The context(s) of use of the learning objects in the collection. |
Property |
Optional |
|
Typical Age Range |
The age range(s) of the typical users of the learning objects in the collection. |
Property |
Optional |
|
Item Rights |
The rights that apply to the learning objects in the collection. This is independent of Collection-level Rights, which govern access to collection metadata. |
Property |
Optional |
|
Cost |
Do the learning objects in the collection havea cost? |
Property |
Optional |
3.6.2 Metadata Collection
The following attributes are used to describe a metadata collection as a whole:
|
Identifier |
An identifier of the metadata collection. |
Identifier |
Mandatory |
|
Description |
A description of the metadata collection. |
LangString |
Mandatory |
|
Collection Rights |
A description of the rights that apply to the metadata collection as a whole. |
LangString |
Optional |
|
Keywords |
A list of keywords for describing the collection as a whole. |
LangString |
Optional |
|
Average Annual Increase |
The average annual increase in the number of metadata instances in the collection. This can be a negative number. |
Integer |
Optional |
|
Accrual Periodicity |
An attribute using a controlled vocabulary from DCCAP [DCCAP, 07] to describe how often metadata instances are added to (or removed from) the collection. |
VocabularyTerm |
Optional |
The following attributes describe properties of the metadata instances that compose the collection:
|
Quality Procedure |
The quality procedure(s) applied to the metadata in the collection. |
Property |
Optional |
|
Language |
The language(s) of the metadata in the collection. |
Property |
Optional |
|
Format |
The format(s) of the metadata in the collection. For example: “IEEE LOM XML binding”. |
Property |
Optional |
|
Item Rights |
The rights that apply to the metadata in the collection. |
Property |
Optional |
3.6.3 Party
Parties are modeled as a combination of a Responsibility and Contact Details. Parties are responsible for collections or service targets. The following attributes describe parties:
|
Responsibility |
The responsibility the party has with regard to the collection or target. E.g. “administrative contact”, “technical contact”. |
VocabularyTerm |
Mandatory |
|
Contact Details |
A VCARD [VCARD, 98] description of the party. |
CharacterString |
Mandatory |
3.7 Service Attributes
3.7.1 Target
Targets serve as end-points for services offered by repositories to access collections. They are described with the following attributes:
|
Target Identifier |
A unique identifier of the target. |
Identifier |
Mandatory |
|
Protocol Identifier |
The identifier of the protocol supported by the target. |
Identifier |
Mandatory |
|
Location |
The location of the target. |
URI |
Optional |
|
<extension> |
An XML description of the protocol parameters supported by the target end-point. This description is a valid instance of the XSD referenced at the Protocol Description Binding Location of the protocol identified by the <Protocol Identifier>. (See Section 3.7.2) |
XML |
Mandatory |
3.7.2 Protocol Implementation Description
This is a description of the properties of a specific implementation of the protocol, supported by the target. This description should provide all information necessary to configure a client to access the given target. The description is specific to the protocol, and the implementation description should be a valid instance of the XSD referred to in the “Protocol Description Binding Location” attribute of the corresponding protocol. Choices made in implementation of the protocol, such as asynchronous vs. synchronous SQI, choice of query language, and so forth should also be explicit in the Protocol Implementation Description.
3.7.3 Protocol
The protocol describes the service interface for interacting with the target. One or more targets can have the same protocol. The protocol description must include a pointer to a protocol implementation description. Protocols are described with the following attributes:
|
Identifier |
A unique identifier of the protocol. |
Identifier |
Mandatory |
|
Name |
The name of the protocol. For example, “Simple Query Interface”. |
CharacterString |
Mandatory |
|
Version |
The version of the protocol. For example, “1.0”. |
CharacterString |
Optional |
|
Protocol Description Binding Name Space |
The namespace of an XSD used to describe a particular implementation of the protocol. |
URI |
Mandatory |
|
Protocol Description Binding Location |
The location of this XSD. |
URI |
Mandatory |
3.7.4 Access Policy
Access policies are described with two attributes:
|
Identifier |
A unique identifier of the policy. |
Identifier |
Mandatory |
|
Description |
A description of the access policy. |
LangString |
Mandatory |
3.8 Relations
Content and metadata collections are associated with one or more targets. The relation is navigable in both directions.
A target is associated with a unique access policy, though an access policy may apply to several targets.
A target contains a unique protocol implementation description, since a target is defined to be accessed through only one protocol. (A distinct protocol means a distinct target.)
A collection may contain or be contained by zero or more collections of the same type (metadata to metadata, content to content). The relation is navigable in both directions.
A content collection may be described by zero or more metadata collections, and a metadata collection may describe zero or more content collections. The relation is navigable in both directions.
For all the relations given above, the referring object may refer to the related object by value, embedding the description of the related object in its own description. Alternatively the referring object may refer to the related object by reference, supplying the identifier of the related object. For example: a target may identify its access policy by value, meaning it includes the access policy description in the target description. On the other hand, the target may only identify its access policy by reference, supplying the identifier for the policy. Identification by reference presupposes that the identifier can be dereferenced by users.