imslogoIAL-300dpi-small

1EdTech 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

1EdTech Learning Object Discovery & Exchange (LODE) copyright 2010 by 1EdTech 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 1EdTech 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,. 1EdTech GLC provides free resources for developing profiles of 1EdTech GLC specifications and machine readable bindings. Those creating derivative works are encouraged to use these tools. To do so, follow the instructions on the 1EdTech GLC web site: http://www.imsglobal.org/profile/

This document originated from the 1EdTech Learning Object Discovery & Exchange by 1EdTech Consortium.

THE 1EdTech 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 1EdTech GLC: http://www.imsglobal.org/contactus.cfm

1EdTech 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 1EdTech’s procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech 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

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 1EdTech Content Package and 1EdTech 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, 1EdTech 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. 1EdTech 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).

1EdTech 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 - 1EdTech LODE at work.

The diagram of Figure 1.1 illustrates how the 1EdTech LODE specification can be combined with other specifications to permit to a LODE Client (i.e., a system that relies on the 1EdTech 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 1EdTech 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

Move to top

The LODE activity in 1EdTech 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 1EdTech 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, 1EdTech 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

Move to top

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

Move to top

API Application Programming Interface

a-API Abstract Application Programming Interface

IAF 1EdTech/GLC Abstract Framework

1EdTech GLC 1EdTech 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

Move to top

[APG, 05a] 1EdTech GLC Application Profile Guidelines Overview: Part 1 – Management Overview v1.0, K.Riley, 1EdTech Consortium, October 2005. http://www.imsglobal.org/ap/index.html.

[APG, 05b] 1EdTech GLC Application Profile Guidelines White Paper: Part 2 Technical Manual, S.Wilson and K.Riley, Version 1.0, 1EdTech 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] 1EdTech GLC General Web Services WSDL Binding Guidelines v1.0 Final Specification, C.Schroeder, J.Smon and C.Smythe, 1EdTech Consortium, December 2005.

[IAF, 03a] 1EdTech GLC Abstract Framework: Applications, Services & Components v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[IAF, 03b] 1EdTech GLC Abstract Framework: Glossary v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[IAF, 03c] 1EdTech GLC Abstract Framework: White Paper v1.0, Ed. C.Smythe, 1EdTech 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 1EdTech Learning Object Discovery and Exchange (LODE), D. Massart, M. Morrey, C. Smythe, 1EdTech 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] 1EdTech Reusable Definition of Competency or Educational Objective—Information Model, 1EdTech Consortium, October 2002. http://www.imsglobal.org/competencies/rdceov1p0/imsrdceo_infov1p0.html

[SDN07, 06] 1EdTech GLC Specification Note 7: UML Profile for Platform Independent Model Descriptions of Specifications for Data Models v1.0, C.Smythe, 1EdTech Consortium, October 2006.

[SDN11, 06] 1EdTech GLC Specification Note 11: Vocabulary Definition, Registration & Maintenance Procedures, C.Smythe, 1EdTech 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] 1EdTech Vocabulary Definition Exchange Best Practice and Implementation Guide, Version 1.0 Final Specification, A. Cooper, 1EdTech 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 1EdTech LODE specification consists of 3 main data models:

The 1EdTech LODE Information for Learning Object eXchange (ILOX) data model,
The 1EdTech LODE Registry data model (Registry), and
The 1EdTech 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 1EdTech 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.

ims LODE UC
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
12	~~Peer-to-peer distributed 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
19	~~Lifelong learning in international contexts; Learners 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
32	~~LMS tutor sorts search results in order of last modification date~~
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
38	~~Search portal adds copy of a content package into a course in an LMS~~
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
42	~~LMS system checks for (is alerted to) modifications to a learning object~~
43	~~Course page includes a lists of newly published learning objects on relevant topics~~
44	~~Feeds from LORs combined in a news agregator~~
45	~~Tutor is automatically alerted to new content relevant to their course(s)~~
46**	Resource access
47	~~Classify item~~
48**	Annotate item
49**	Recommend item
50**	Rate item
51	~~Syndicate Items~~
52**	Display Objects
53	~~Choosing, Rendering, And Buying Student Development Resources~~
54	~~Buy~~
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

Move to top

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

Move to top

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.

ISO Registry

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:

ISO2LODE Registry

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

Move to top

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

Move to top

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

Move to top

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.

LODE Registry Binding

Figure 3.3 - LODE Registry class diagram.

3.6 Collection Attributes

Move to top

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

Move to top

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

Move to top

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.

3.9 Profiling and Extending

Move to top

This specification is generic and needs to be profiled before it can be used. Profiling the

specification includes:

· Selecting an Identifier Type

· Selecting mandatory attributes (a priori, all attributes are optional).

· Selecting controlled vocabularies for the different property attributes.

· Agreeing on XSD bindings for the different protocol descriptions

3.10 LODE Registry Summary

Move to top

3.10.1 Protocol Root

Nr	Name	Description	Multiplicity	Order	Value space	Data type	Note	Example
P.1	Identifier	A unique identifier of the protocol.	1..1	-	-	-	Mandatory data element.	-
P.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this entry. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
P.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this protocol. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
P.2	Name	The name of the protocol.	1..*	Unordered	A valid protocol name.	CharacterString	Mandatory data element.	“Simple Query Interface”
P.3	Version	The version of the protocol.	0..1	-	A valid protocol version.	CharacterString	Optional data element.	“1.0”
P.4	Protocol Description Binding Namespace	The namespace of an XSD used to describe a particular implementation of the protocol.	1..1	-	A valid XML namespace.	URI	Mandatory data element.	“http://explain.z3950.org/dtd/”, “http://www.imsglobal.org/services/lode/imslosqi-1p0_v1p0”
P.5	Protocol Description Binding Location	The location of an XSD used to describe a particular implementation of the protocol.	1..1	-	A valid URL.	URL	Mandatory data element.	“http://fire.eun.org/xsd/registry/imslosqi-1p0_v1p0.xsd”

3.10.2 Target Root

Nr	Name	Description	Multiplicity	Order	Value space	Data type	Note	Example
T.1	Identifier	A globally unique label that identifies the target of a collection	1..1	-	-	-	Mandatory data element. (Is referred to by C.12.1 Target Identifier)	-
T.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this target. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "URI"
T.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this target. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“101.1021323”, “http://foo.org/1234”
T.2	Protocol Identifier	The identifier of the protocol supported by the target.	1..1	-	-	-	Mandatory data element. Refers to protocol identified by P.1 Protocol.Identifier	-
T.2.1	Catalog	The name or designator of the identification or cataloguing scheme for this protocol. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "URI"
T.2.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this protocol. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“101.1021323”, “http://foo.org/1234”
T.3	Location	The location of the target	0..*	Unordered	A valid URL.	URL	Optional data element	“http://foo.org/1234”
T.4	Protocol Implementation Description	An XML description of the protocol parameters supported by the target end-point.	1..1	-	A valid metadata instance	A valid instance of the XSD referenced at the Protocol Description Binding Location P.5 of the protocol identified by the Protocol Identifier T.2.	Mandatory data element	A ZeeRex instance, an OAI-PMH description instance
T.5	Responsible	Parties responsible for the service target	0..*	Unordered	-	-	Optional data element	-
T.5.1	Responsibility	The responsibility the party has with regard to the target	1..1	-	No controlled vocabulary provided	VocabularyTerm	Mandatory child data element	“administrative contact”, “technical contact”
T.5.2	Contact Details	A description of the party	1..1	-	A VCARD [VCARD, 98] description.	CharacterString	Mandatory child data element	BEGIN:VCARD VERSION:2.1 N:kapukod;Hétszin FN:4758 ORG:Bubba Gump Shrimp Co. TITLE:Shrimp Man TEL;CELL;VOICE:2536 END:VCARD
T.6	Access Policy	Access policy applicable to the collection	0..1	-	-	-	Optional data element	-
T.6.1	Access Policy Identifier (option 1)	A unique identifier of the policy	1..1	-	-	-	Mandatory child data element (Mutually exclusive with T.6.2 Access Policy Description)	-
T.6.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this access policy. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "URI"
T.6.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this access policy. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“101.1021323”, “http://foo.org/1234”
T.6.2	Access Policy (option 2)	A description of the policy	1..1	-	-	-	Mandatory child data element (Mutually exclusive with T.6.1 Access Policy Identifier)	-
T.6.2.1	Access Policy Identifier	A unique identifier of the policy	1..1	-	-	-	Mandatory child data element. (Is referred to by T.6.1 Access Policy Identifier)	-
T.6.2.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this access policy. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "URI"
T.6.2.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this access policy. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“101.1021323”, “http://foo.org/1234”
T.6.2.2	Description	A description of the access policy	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	(“en”, “This target is behind a firewall. Access can be obtained on request by sending an email to our technical contact. ”)
T.7	Collection	Collection exposed by the target	0..1	-	-	-	Optional data element
T.7.1	Content Collection (option 1)	Content collection exposed by the target	1..1	-			Mandatory child data element (Mutually exclusive with T.7.2 Metadata Collection)
T.7.1.1	Content Collection Identifier	Identifier of Content collection exposed by the target	1..1	-			Mandatory child data element. Refers to identifier of C.1
T.7.1.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this content collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
T.7.1.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this content collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
T.7.2	Metadata Collection (option 2)	Metadata collection exposed by the target	1..1	-			Mandatory child data element (Mutually exclusive with T.7.1 Content Collection)
T.7.2.1	Metadata Collection Identifier	Identifier of Metadata collection exposed by the target	1..1	-			Mandatory child data element. Refers to identifier of M.1
T.7.2.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this metadata collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
T.7.2.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this metadata collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”

3.10.3 Content Collection Root

Nr	Name	Description	Multiplicity	Order	Value space	Data type	Note	Example
C.1	Identifier	A globally unique label that identifies this collection of learning objects.	1..1	-	-	-	Mandatory data element.	-
C.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this entry. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
C.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this learning object collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
C.2	Description	A description of the collection.	1..1	-	-	LangString	Mandatory data element.	(“en”, “Collection of Algebra Assessments for 3^rd grade”)
C.3	Collection Rights	A description of the rights that apply to the collection as a whole.	0..1	-	-	LangString	Optional data element.	(“en”, ”Creative Commons Attribution Share-Alike 3.0”)
C.4	Keywords	A list of keywords for describing the collection as a whole.	0..*	Unordered	-	LangString	Optional data element.	(“en”, “assessment”), (“en”, “mathematics”)
C.5	Average Annual Increase	The average annual increase in the number of learning objects in the collection. This can be a negative number.	0..1	-	-	Integer	Optional data element.	“100”, “-50”
C.6	Accrual Periodicity	How often new learning objects are added to (or removed from) the collection.	0..1	-	No controlled vocabulary provided	VocabularyTerm	Optional data element. Possible controlled vocabulary is DCCAP [DCCAP, 07]: http://dublincore.org/groups/collections/frequency/2007-03-09/	“freq:annual”, “freq:threeTimesAMonth”, “freq:semiweekly”
C.7	Quality Procedure	The quality procedure(s) applied to the items in the collection.	0..*	Unordered.	No controlled vocabulary provided.	Property	Optional data element.	(“no quality procedure”, “all”) (“peer-reviewed”, “some”)
C.8	Language	The language(s) of the learning objects in the collection.	0..*	Unordered	ISO-639.	Property	Optional data element.	(“en”, “all”), (“fr”, “some”)
C.9	Format	The technical format(s) of the learning objects in the collection.	0..*	Unordered	A valid MIME type.	Property	Optional data element.	“application/swf”.
C.10	Item Rights	The rights that apply to the learning objects in the collection.	0..*	Unordered	No vocabulary provided.	Property	Optional data element. This is independent of Collection-level Rights, which govern access to collection.	(“All rights reserved, copyright big money limited 2010”, “some”)
C.11	Responsible	Parties responsible for the collection	0..*	Unordered	-	-	Optional data element.	-
C.11.1	Responsibility	The responsibility the party has with regard to the collection.	1..1	-	No vocabulary provided.	VocabularyTerm	Mandatory child data element.	“administrative contact”, “technical contact”
C.11.2	Contact Details	A VCARD description of the party.	1..1	-	A valid VCARD [VCARD, 98]	CharacterString	Mandatory child data element.	BEGIN:VCARD VERSION:2.1 N:kapukod;Hétszin FN:4758 ORG:Bubba Gump Shrimp Co. TITLE:Shrimp Man TEL;CELL;VOICE:2536 END:VCARD
C.12	Target	Service end-point for the collection	0..*	Unordered	-	-	Optional data element	-
C.12.1 (option 1)	Target Identifier	A globally unique label that identifies a target of the collection (end-point for services offered)	1..1	-	-	-	Mandatory data element. (Mutually exclusive with C12.2 Target Description)	-
C.12.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this target. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "URI"
C.12.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this target. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“101.1021323”, “http://foo.org/1234”
C12.2 (option 2)	Target Description	A description of a target of the collection (end-point for services offered)	1..1	-	-	-	Mandatory child data element. (Mutually exclusive with C12.1 Target Identifier) (For further expansion, see T)
C.13	Subject	The subject(s) covered by the learning objects in the collection	0..*	Unordered	No controlled vocabulary provided.	Property	Optional data element.	(“Algebra”, “most”)
C.14	Type	The learning resource type(s) (cf. LOM 5.2) of the learning objects in the collection	0..*	Unordered	No controlled vocabulary provided.	Property	Optional data element.	(“Assessment”, “most”)
C.15	Representation	The representation of the learning objects of the collection (cf. ILOX Manifestation Names and Parameters).	0..*	Unordered	No controlled vocabulary provided.	Property	Optional data element.	(“imscp_v1p0”, “some”)
C.16	Intended User Role	The intended end-user role for the learning objects in the collection.	0..*	Unordered	No controlled vocabulary provided.	Property	Optional data element.	(“Learner”, “most”)
C.17	Context	The context of use of the learning objects in the collection.	0..*	Unordered	No controlled vocabulary provided.	Property	Optional data element.	(“Compulsory education”, “all”)
C.18	Typical Age Range	The typical age range of the users of the objects in the collection.	0..*	Unordered	No controlled vocabulary provided.	Property	Optional data element.	(“10-14”, “some”)
C.19	Cost		0..*	Unordered	No controlled vocabulary provided.	Property	Optional data element.	(“no”, “most”)
C.20	To Metadata Collection	Related metadata collections	0..*	Unordered
C.20.1	Metadata Collection Identifier (option 1)	Identifier of related metadata collection	1..1	-			Mandatory child data element (Mutually exclusive with C.20.2 Metadata Collection) (Refers to identifier of M.1)
C.20.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this metadata collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
C.20.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this metadata collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
C.20.2	Metadata Collection (option 2)	Description of related metadata collection	1..1	-			Mandatory child data element. For further expansion, see M
C.21	Contains	Content collections that this content collection contains	0..*	Unordered
C.21.1	Content Collection Identifier (option 1)	Identifier of contained content collection	1..1	-			Mandatory child data element (Mutually exclusive with C.21.2 Content Collection) (Refers to identifier of C.1)
C.21.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this content collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
C.21.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this content collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
C.21.2	Content Collection (option 2)	Description of contained content collection	1..1	-	-	-	Mandatory child data element. For further expansion, see C	-
C.22	Is Contained	Content collections that this content collection is contained by	0..*	Unordered
C.22.1	Content Collection Identifier (option 1)	Identifier of containing content collection	1..1	-			Mandatory child data element (Mutually exclusive with C.22.2 Content Collection) (Refers to identifier of C.1)
C.22.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this content collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
C.22.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this content collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
C.22.2	Content Collection (option 2)	Description of containing content collection	1..1	-	-	-	Mandatory child data element. For further expansion, see C	-

3.10.4 Metadata Collection Root

Nr	Name	Description	Multiplicity	Order	Value space	Data type	Note	Example
M.1	Identifier	A globally unique label that identifies this collection of metadata.	1..1	-	-	-	Mandatory data element.	-
M.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this entry. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
M.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this metadata collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
M.2	Description	A description of the collection.	1..1	-	-	LangString	Mandatory data element.	(“en”, “Collection of Algebra Assessments for 3^rd grade”)
M.3	Collection Rights	A description of the rights that apply to the collection as a whole.	0..1	-	-	LangString	Optional data element.	(“en”, ”Creative Commons Attribution Share-Alike 3.0”)
M.4	Keywords	A list of keywords for describing the collection as a whole.	0..*	Unordered	-	LangString	Optional data element.	(“en”, “assessment”), (“en”, “mathematics”)
M.5	Average Annual Increase	The average annual increase in the number of metadata objects in the collection. This can be a negative number.	0..1	-	-	Integer	Optional data element.	“100”, “-50”
M.6	Accrual Periodicity	How often new metadata objects are added to (or removed from) the collection.	0..1	-	No controlled vocabulary provided.	VocabularyTerm	Optional data element. A possible vocabulary for this element is DCCAP [DCCAP, 07] http://dublincore.org/groups/collections/frequency/2007-03-09/	“freq:annual”, “freq:threeTimesAMonth”, “freq:semiweekly”
M.7	Quality Procedure	The quality procedure(s) applied to the items in the collection.	0..*	Unordered.	No controlled vocabulary provided.	Property	Optional data element.	(“no quality procedure”, “all”) (“peer-reviewed”, “some”)
M.8	Language	The language(s) of the learning objects in the collection.	0..*	Unordered	ISO 639	Property	Optional data element.	(“en”, “all”), (“fr”, “some”)
M.9	Format	The technical format(s) of the metadata objects in the collection.	0..*	Unordered	A valid MIME type.	Property	Optional data element.	“application/swf”.
M.10	Item Rights	The rights that apply to the metadata objects in the collection.	0..*	Unordered	No vocabulary provided.	Property	Optional data element. This is independent of Collection-level Rights, which govern access to collection.	(“All rights reserved, copyright big money limited 2010”, “some”)
M.11	Responsible	Parties responsible for the collection	0..*	Unordered	-	-	Optional data element.	-
M.11.1	Responsibility	The responsibility the party has with regard to the collection.	1..1	-	No vocabulary provided.	VocabularyTerm	Mandatory child data element.	“administrative contact”, “technical contact”
M.11.2	Contact Details	A VCARD description of the party.	1..1	-	A valid VCARD [VCARD, 98]	CharacterString	Mandatory child data element.	BEGIN:VCARD VERSION:2.1 N:kapukod;Hétszin FN:4758 ORG:Bubba Gump Shrimp Co. TITLE:Shrimp Man TEL;CELL;VOICE:2536 END:VCARD
M.12	Target	Service end-point for the collection	0..*	Unordered	-	-	Optional data element	-
M.12.1 (option 1)	Target Identifier	A globally unique label that identifies a target of the collection (end-point for services offered)	1..1	-	-	-	Mandatory data element . (Mutually exclusive with M.12.2 Target Description)	-
M.12.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this target. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "URI"
M.12.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this target. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“101.1021323”, “http://foo.org/1234”
M.12.2 (option 2)	Target Description	A description of a target of the collection (end-point for services offered)	1..1	-	-	-	Mandatory child data element. (Mutually exclusive with M.12.1 Target Identifier) (For further expansion, see T)	-
M.13	To Content Collection	Related content collections	0..*	Unordered	-	-	Optional element.	-
M.13.1	Content Collection Identifier (option 1)	Identifier of related content collection	1..1	-	-	-	Mandatory child data element (Mutually exclusive with M.20.2 Content Collection) (Refers to identifier of C.1)	-
M.13.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this content collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
M.13.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this content collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
M.13.2	Content Collection (option 2)	Description of related content collection	1..1	-	-	-	Mandatory child data element. For further expansion, see C	-
M.14	Contains	Metadata collections that this metadata collection contains	0..*	Unordered	-	-	Optional data element.	-
M.14.1	Metadata Collection Identifier (option 1)	Identifier of contained metadata collection	1..1	-	-	-	Mandatory child data element (Mutually exclusive with M.21.2 Metadata Collection) (Refers to identifier of M.1)	-
M.14.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this metadata collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
M.14.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this content collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
M.14.2	Metadata Collection (option 2)	Description of contained metadata collection	1..1	-	-	-	Mandatory child data element. For further expansion, see M	-
M.15	Is Contained	Metadata collections that this content collection is contained by	0..*	Unordered	-	-	-	-
M.15.1	Metadata Collection Identifier (option 1)	Identifier of containing metadata collection	1..1	-	-	-	Mandatory child data element (Mutually exclusive with M.22.2 Metadata Collection) (Refers to identifier of M.1)	-
M.15.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this metadata collection. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“hdl”, "ISBN", "lre", "URI",”doi”
M.15.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this metadata collection. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
M.15.2	Metadata Collection (option 2)	Description of containing metadata collection	1..1	-	-	-	Mandatory child data element. For further expansion, see M	-

4 Information for Learning Object eXchange (ILOX) Data Model

4.1 Introduction to the ILOX Data Model

Move to top

Metadata consist of machine-readable descriptions of learning objects. Metadata specifications and standards such as Dublin Core [DCME, 08] and IEEE LOM [LOM, 02] have been widely used to describe learning objects. Thanks to these specifications, metadata records are now interoperable, and can be easily exchanged to create searchable catalogs that facilitate learning object discovery and allow learning object users to evaluate whether an object meets their specific needs.

The LODE specification focuses on supporting what users may wish to do after they have discovered a learning object. Looking at the LODE use cases, a user, who finds a learning object potentially interesting based on its catalog description, might want to:

· Preview the object,

· Annotate, rate, recommend, or tag it,

· See its full metadata description,

· Play it remotely,

· Import it into a learning environment, or

· Select a particular version of it.

Supporting these use cases involves describing aspects of learning objects such as their different versions, the different formats in which they are available, their previews, etc. Existing metadata standards such as Dublin Core and LOM do not distinguish between all of these aspects within a single metadata record.

Existing standards also do not straightforwardly allow two different metadata records, describing different aspects of the same learning object, to be considered together. This is necessary in cases like the following:

A user searches across a range of repositories, and discovers several instances of the same object: they should not have to access the different copies individually, to work out the differences between them.
A repository federation is aware of duplicate objects in its repositories, and can use this information to plan which copy is best to deliver to which user (appropriate copy delivery).
A repository compares its holdings with another registry, to fill in gaps in coverage or to supplement its metadata.

Whether two instances are considered to be the same learning object depends on the business process: some contexts require the objects to be bytewise identical (a testing module configured to a specific operating environment must be in exactly the same format), while others require only a “family resemblance” (a Word document of Version 1.0 and a PDF document of Version 3.0 of the object might be equally suitable in a repository content audit).

The solution proposed below, Information for Learning Object eXchange (ILOX), allows each aspect of a learning object to be described with distinct metadata records using existing standards such as Dublin Core and LOM. It provides a mechanism to identify which aspect of a learning object is being described and to describe relationships between those descriptions. It also permits deduplication of learning resources described in multiple records.

ILOX is not a new metadata specification and is not intended to replace existing metadata standards. It consists of a framework for organizing existing metadata standards (such as Dublin Core and LOM) in a semantically sound way.

The conceptual modelling underlying ILOX is introduced in Section 4.2. The data model itself is fully described in Section 4.3. Finally, Section 4.4 discusses how the specification can be profiled and extended.

4.2 Conceptual Model: Learning Objects, Versions, Formats, and Copies

Move to top

“Information modeling is concerned with the construction of computer-based symbol structures which capture the meaning of information and organize it in ways that make it understandable and useful to people.” [MYLOPOULOS, 98]

Materialization is an abstraction mechanism used in information modeling to represent the relationship between a class of categories (e.g., learning objects) and a class of more concrete items (e.g., learning object copies) [MATER, 94].

Figure 4.1 presents an example of materialization. It relates a more abstract class: Learning Object to a more concrete one: LO Copy. Class Learning Object represents the information about learning objects (e.g., their titles, their descriptions) whereas class LO Copy represents the information about concrete copies of these learning objects (e.g., the file names and path of these LO copies). Materialization is noted as a straight line with a * at its more concrete class end.

Figure 4.1 - A learning object can have multiple copies.

The attributes of abstract classes are inherited by the classes materializing them. So if a Learning Object has the title “Hamlet”, then all LO Copies materializing it also have the title “Hamlet”. This allows us to express metadata economically: we need only define title once for a Learning Object, rather than repeating it for each LO Copy.

The Functional Requirements for Bibliographic Records or FRBR [FRBR, 98]contains a materialization hierarchy that is useful for distinguishing between aspects of learning objects relevant to different contexts. The FRBR concepts of “work”, “expression”, “manifestation”, and “item” as they relate to learning objects are illustrated in Figure 4.2.

A FRBR “work” is a distinct (intellectual or artistic) creation, such as the learning object about nutrition shown on the example of Figure 4.2. Different versions of this learning object can exist: for example, an English and a French version. These versions are different FRBR “expressions” of the work. Each version of the learning object can take different forms. For example, the English version of the learning object about nutrition can be available as a preview, an 1EdTech Content Package and an 1EdTech Common Cartridge. Each of these different embodiments of an expression of a work is referred to as a FRBR “manifestation”. Finally, copies of the 1EdTech Common Cartridge of the English version of the learning object may exist in a number of locations. Each of these copies is a FRBR “item”.

As depicted on the class diagram of Figure 4.3, materialization can be used to model the relationships between the different FRBR aspects of learning objects.

Class LO Copy models the item aspect of learning objects. Class LO Copy is the materialization of class LO Package, which models their manifestation aspects. In turn, class LO Package is the materialization of class LO Version, which models the expression aspects of learning objects. Class LO Version finally is the materialization of class Learning Object, which models the work aspect of learning objects. To save space, each of these four classes in the example is shown with only two example attributes typical of the aspect that it models.

Figure 4.2 - Example of different FRBR expressions, manifestations, and items of a learning object work.

Figure 4.3 - Class diagram modelling the relationships between the different FRBR aspects of learning objects as materializations.

4.3 ILOX: General Principles

Move to top

The ILOX data model structures a learning object description as a materialization hierarchy such as the one presented in Figure 4.3. The FRBR materialization levels are used as follows:

· Work is abstract view of a learning object that captures the commonalities between all the possible variations of this learning object such as, for example, the pedagogical content that is common across all the variations of the learning object.

· Expressions are used to capture information specific to the different versions, drafts, translations, and localizations of learning objects such as, for example, the language of the aspect of the learning object.

· Manifestations are used to capture information specific to the way a given expression of a learning object is encoded and presented such as, for example, the file formats of different aspects of the learning object.

· Items are used to capture information specific to the concrete copies of learning objects, such as, for example, the URI where they can be accessed.

Users can use this information to decide which learning object copies to treat as the same for their purposes.

Some types of information will typically be specific to one FRBR materialization level. For instance, the language of an object is typically characteristic of an Expression: an object may be translated into a different language without becoming a different Work, but different Manifestations of the same Expression are all expected to be in the same language. However, other types of information may appear at multiple materialization levels: access rights may apply to all copies of a Work, or may be specific to a particular Manifestation (e.g. a preview of the learning object vs. the runtime object). The same information at a lower materialization level overrides information appearing at a higher level. (So access rights can be set for the Work as a whole, but access rights for a specific Manifestation can be treated as an exception.)

An ILOX instance can be rooted at any level of the hierarchy depending on how abstract or concrete one needs to be. Handling learning object descriptions at the:

· Work level permits one entry per learning object (LO) with no immediate distinction between LO versions;

· Expression level permits one entry per LO version with no immediate distinction between the different formats of a given LO version, and without having to decide which Work different Expressions belong to;

· Manifestation level permits one entry per LO format with no immediate distinction between the different copies of an LO, and without having to decide which Work or Expression the Manifestations belong to;

Item level permits one entry per LO copy, without having to decide which Work, Expression or Manifestation the Items belong to.

Figure 4.4 - Pattern for describing the different FRBR aspect of a learning object.

At each level of the hierarchy, a common pattern is used to model the corresponding FRBR aspect of the learning object. This pattern is shown on the class diagram of Figure 4.4 where a given FRBR level (modelled by class “LO at FRBR level #n” is described by:

· Optional identifiers (modelled by attribute “Identifier”),

· Descriptions consisting of level-specific metadata (modelled by class “Description”),

· Additional level-specific information (modelled by attribute “Level specific features”), and

· Information about the immediate lower FRBR level (modelled by class “LO at FRBR level #n-1”).

4.3.1 Basic Data Types

The ILOX data model is based on two primitive XML types: normalizedString and anyURI that are used to build the three basic data types of ILOX: the Identifier, ValueFromVocab, and Metadata types.

The Identifier Type is the type of identifier elements. It is equivalent to the type of IEEE LOM [LOM, 02] identifier elements and consists of two sub-elements:

· catalog that indicates the identifier namespace (normalizedString) and

· entry that is the identifier string itself (normalizedString).

The ValueFromVocab Type is used by elements that contain a controlled vocabulary entry. It consists of two sub-elements:

· vocabularyID that identifies a controlled vocabulary (normalizedString) and

· value that contains a term taken from the controlled vocabulary (normalizedString).

The Metadata Type provides extension points for embedding XML metadata records (such as IEEE LOM instances) into the ILOX structure. It consists of two sub-elements:

· schema that identifies the metadata schema for the embedded XML record. The schema is identified by its namespace (anyURI) and

· the metadata itself.

4.3.2 Description Type

The “description” elements are used to describe each FRBR level of a learning object with level-specific metadata. They are of type “Description Type” that consists of two sub-elements:

· facet indicates what “facet” of the given FRBR aspect of the learning object in question is described (ValueFromVocab) (see below) and

· metadata contains a metadata description of the given FRBR aspect of the learning object in question (Metadata).

Each level can have multiple metadata descriptions, each with its own facet to differentiate between them. ILOX does not define a controlled vocabulary for facets. Instead, application profiles of LODE are expected to select controlled vocabularies for the facet elements. These vocabularies will probably differ from one application profile to another and from one FRBR level to another. Possible uses of element facet include:

· Making a distinction between the providers of metadata, for example, user-generated information, providers’ metadata, etc.

· Indicating the purpose of the embedded metadata record, such as “general description”, “rights description”, “accessibility profile”.

Note that the quantity of information attached to an ILOX description element may vary depending on the scenario under consideration. For example, when harvesting metadata, one might want to exchange learning object descriptions that are as complete as possible whereas, when searching, one might prefer to limit the amount of information transported to what needs to be displayed to end users. Such scenarios are further discussed in Section 4.6.

Because of the importance of rights metadata, licenses constitute their own facet, licenseType, including an identifier for the License as well as the metadata description. The license facet can apply at any level, and applies to all materialization at lower levels, unless overridden by a different license facet. More than one license can apply to the same object.

4.4 Work

Move to top

ILOX Work is one of the four possible root elements of an ILOX instance. It consists of an abstract view of a learning object used to capture the commonalities between its versions such as, for example, its pedagogical content as described by the LOM Educational elements.

The ILOX Work Data Type follows the pattern proposed in Figure 4.4. It consists of

· One (or more) optional identifiers (Identifier Type),

· One (or more) optional descriptions (Description Type), and

· At least one ILOX expression.

A work identifier uniquely identifies a learning object work itself and not one particular version, format, or copy of this learning object.

Similarly, the description should be used to describe the different facets of a learning object work. Information specific to a particular version, format, or copy of this object should not be present at the work level.

Finally, since ILOX is intended to provide the information necessary to support the exchange of concrete learning objects, a work must always contain at least one expression.

4.5 Expression

Move to top

An ILOX expression can be either the root element of an ILOX instance or a work sub-element. Expressions are used to capture information specific to the different versions, drafts, translations, and localizations of learning objects.

The ILOX Expression Data Type follows the pattern proposed in Figure 4.4. It consists of:

· One (or more) optional identifiers (Identifier Type),

· One (or more) optional descriptions (Description Type),

· At least one ILOX expression, and

· One (or more) optional dimension (Dimension Type) that makes explicit how the expressions of a work differ. Dimension is optional when the expression is used as a root element of an ILOX. It is mandatory when the expression is a work sub-element.

When used, an expression identifier uniquely identifies a learning object expression itself (e.g., a given version of a learning object). Each identifier will differ from the identifiers of the other expressions of the learning object and will also differ from the learning object work identifier.

The description should be used to describe the different facets of a learning object expression. In addition, if the expression is the ILOX root element (i.e., if the expression is not a sub-element of a work), information belonging to the work aspect of the learning object is also expressed at the expression level.

Finally, since ILOX is intended to provide the information necessary to support the exchange of concrete learning objects, an expression must always contain at least one manifestation.

4.5.1 Dimension

This element provides the dimension of an expression, making explicit the criteria according to which it differs from the other expressions of the same work. Dimension is of type Dimension Type which consists of two sub-elements:

name indicates the name of the expression dimension (ValueFromVocab). For example, the dimension name can be “language”, indicating that the different expressions of this learning object are expressed in different languages.
parameter defines the actual position of an expression in the dimension being considered (ValueFromVocab). For example the actual language value of an expression.

4.6 Manifestation

Move to top

An ILOX manifestation can be either the root element of an ILOX instance or an expression sub-element. Manifestations are used to capture information specific to the way a given expression of a learning object is encoded and presented (i.e., the learning object file formats and presentation formats).

The ILOX Manifestation Data Type follows the pattern proposed in Figure 4.4. It consists of:

· One (or more) optional identifiers (Identifier Type),

· One (or more) optional descriptions (Description Type), and

· At least one ILOX Item.

· An optional name that indicates the type of manifestation (ValueFromVocab)

· An optional parameter that provides further information on the type of manifestation (ValueFromVocab)

When used, a manifestation identifier uniquely identifies a learning object manifestation (e.g., a given format of a given version of a learning object). Each identifier will differ from the identifiers of the other manifestations in which the learning object is available and will also differ from the learning object expression and learning object work identifiers.

The description should be used to describe the different facets of a learning object manifestation. In addition, if the manifestation is the ILOX root element (i.e., if the manifestation is not a sub-element of an expression), information belonging to the work and expression aspects of the learning object is also expressed at the manifestation level.

Again, since ILOX is intended to provide the information necessary to support the exchange of concrete learning objects, a manifestation must always contain at least one item.

4.6.1 Name

This element provides the “name" of a learning object manifestation. It is optional when manifestation is used as the ILOX root element. It is mandatory when manifestation is an expression sub-element. Possible manifestation names are:

· preview: A preview of the learning object expression.

· thumbnail: A thumbnail of the learning object expression.

· metadata in: A full metadata description of the learning object (a repository might choose to only put a subset of the available metadata in ILOX, this manifestation provides access to the full metadata)

· experience: A manifestation of the learning object that is available online and can be rendered in a web browser (possibly equipped with appropriate plugins).

· package in: A manifestation of the learning object that is packaged according to a given content packaging format.

Each name + parameter combination is unique. That is, it is only possible to have different manifestations of the same learning object expression with the same name if they have different parameter values.

4.6.2 Parameter

A manifestation name might be too broad to convey how to handle such a manifestation. For example, “package in” indicates that the learning object is packaged, but does not say what the package format is. Element “parameter” further refines a given type of manifestation. A manifestation can only have one parameter. Possible values for this element depend on the name of the manifestation:

4.6.2.1 Parameter values for Name = ‘preview’

Not defined.

4.6.2.2 Parameter values for Name = ‘thumbnail’

Allowed values include all image MIME types [IANA, 07] (i.e., all the MIME types prefixed by “image/”). Example: “image/png” for a PNG file thumbnail.

4.6.2.3 Parameter values for Name = ‘metadata in’

Allowed values include all valid namespaces of metadata schema used in a full metadata record. Example: “http://ltsc.ieee.org/xsd/LOM” for an IEEE LOM metadata record.

4.6.2.4 Parameter values for Name = ‘experience’

With this manifestation name, element parameter is optional. When used, it must contain the MIME type of the file(s) referred to in element “item.location.uri” (see Section Item).

Potentially, all the MIME types based on IANA registration [IANA, 07] (see RFC2048:1996) are acceptable. See also Appendix B for further detail.

4.6.2.5 Parameter values for Name = ‘package in’

The controlled vocabulary used to describe the different package formats is described in the table below.

Term	Description
imscp_v1p0	1EdTech Content Packaging Version 1.0
imscp_v1p1	1EdTech Content Packaging Version 1.1
imscp_v1p1p1	1EdTech Content Packaging Version 1.1.1
imscp_v1p1p2	1EdTech Content Packaging Version 1.1.2
imscp_v1p1p3	1EdTech Content Packaging Version 1.1.3
imscp_v1p1p4	1EdTech Content Packaging Version 1.1.4
imscc_v1p0	1EdTech Common Cartridge Version 1.0
imscc_v1p1	1EdTech Common Cartridge Version 1.1
scorm_v1p0	SCORM Version 1.0
scorm_v1p1	SCORM Version 1.1
scorm_v1p2	SCORM Version 1.2
scorm_v2004	SCORM 2004
imsqti_v1p2lite	1EdTech Question & Test Interoperability Version 1.2 Lite
imsqti_v1p2	1EdTech Question & Test Interoperability Version 1.2
imsqti_v1p2p1	1EdTech Question & Test Interoperability Version 1.2.1
imsqti_v2p0	1EdTech Question & Test Interoperability Version 2.0
imsqti_v2p1	1EdTech Question & Test Interoperability Version 2.1

4.7 Item

Move to top

An ILOX item can be either the root element of an ILOX instance or a manifestation sub-element. Items are used to capture information specific to the concrete copies of learning objects.

The ILOX Item Data Type consists of

· One (or more) optional identifiers (Identifier Type),

· One (or more) optional descriptions (Description Type), and

· An item-specific feature named location (Location Type).

Item being the lowest (i.e., most concrete) level of the ILOX hierarchy, it has no need for an element modelling a lower level.

An item identifier uniquely identifies a learning object item (e.g., a learning object copy). Such an identifier will differ from the identifiers of the other copies of the learning object and will also differ from the learning object manifestation, expression and work identifiers.

The description should be used to describe the different facets of a learning object item (if any). In addition, if the item is the ILOX root element (i.e., if the item is not a sub-element of an manifestation), information belonging to the work, expression, and manifestation aspects of the learning object is also expressed at the item level.

The location is used to provide information about the actual location of the item. It is of type Location Type that consists of two elements:

· URI of type anyURL and

· Metadata of type Metadata Type.

Element URI should contain a resolvable location such as a URL, a persistent URL or anything else that can be resolved to a location.

When the (resolvable) location contained in element URI is the location of the item itself, the element Metadata cannot be used. Therefore, the absence of element Metadata indicates that the item can be obtained at the location provided in element URI.

In some cases, element URI does not contain the location of the learning object. This is the case, for example, for commercial learning objects to which the access is controlled by an access control system. In such a case, element Metadata should be used to describe the distribution models supported by the learning object provider (i.e., how to obtain the actual location of the learning object item.) The URI element is still mandatory, and should refer to information on how to gain access to the resource, such as an authentication page, or information on the distribution model.

4.8 Profiling and Extending

Move to top

Profiling ILOX consists of:

1. Selecting the ILOX root element (Work, Expression, Manifestation, or Item);

2. Making mandatory one or more optional ILOX elements;

3. Selecting controlled vocabularies for facet and description elements; and

4. Selecting the metadata schema allowed by the different metadata extension points of the ILOX schema.

The LRE Metadata Application Profile version 4.0 (http://fire.eun.org/LREMAPv4p0.pdf) is an example of ILOX profile using expression as root element.

4.9 ILOX Summary

Move to top

1EdTech LODE Information for Learning Object Exchange (ILOX) v1.0
Root	Work	An abstract view of a learning object that captures the commonalities between all the possible variations of this object.	-	-	-	-	With expression, manifestation, and item, work is one of the four possible root elements for an ILOX instance.	-
1	Identifier	A globally unique label that identifies the learning object work.	0..*	Unordered	-	-	Optional data element.	-
1.1	Catalog	The name or designator of the identification or cataloguing scheme for this entry. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“hdl”, "ISBN", "lre", "URI",”doi”
1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this learning object work. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
2	Description	A multi-faceted description of the LO work under consideration.	0..*	Unordered	-	-	Optional data element.	-
2.1	Facet	The name of the facet of the LO work that is described.	0..1	-	No vocabulary defined.	ValueFromVocab	Optional data element. If absent, it is recommended to provide a default value.	“default”, “accessibility”, “rights”
2.2	Metadata	A metadata instance describing the facet defined in element 2.1 Description.Facet.	1..1	-	-	-	Mandatory child data element.	-
2.2.1	Schema	The namespace of the schema used for the description.	0..1	-	A valid URI.	URI.	Optional data element. When used, this URI is the namespace of the schema used to define the metadata at the extension point 2.2.2.	“http://ltsc.ieee.org/xsd/LOM”
2.2.2	<extension>	The metadata instance containing the description.	1..1	-	A valid metadata instance.	A metadata instance used to describe the LO work facet defined in element 2.1 Description.Facet. This should be a valid instance of the schema identified by the namespace provided in element 2.2.1 Description.Metadata.Schema.	Mandatory child data element.	A LOM instance, a Dublin Core instance,
Root / 3	Expression	The expressions (versions) of the LO work.	1..*	Unordered	-	-	Can either be a mandatory data element of Work or the ILOX root element.	-
3.1	Identifier	A globally unique label that identifies this learning object expression.	0..*	Unordered	-	-	Optional data element.	-
3.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this entry. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“hdl”, "ISBN", "lre", "URI",”doi”
3.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this LO expression. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
3.2	Dimension	The criteria (e.g., language, version, accessibility) used to distinguish between the different expressions of a learning object work.	0..*	unordered	-	-	Dimension is optional when Expression is the ILOX root element and mandatory otherwise.	-
3.2.1	Name	The name of the dimension (or criteria) according to which the different expressions of the work differ.	1..1	-	No vocabulary defined.	ValueFromVocab	Mandatory child data element.	“language”, “version”
3.2.2	Parameter	The actual value of the dimension criteria for this expression.	0..1	-	No vocabulary defined.	ValueFromVocab	Mandatory child data element.	“en”, “fr”, “1.0”, “beta 6”
3.3	Description	A multi-faceted description of the LO expression under consideration.	0..*	Unordered	-	-	Optional data element.	-
3.3.1	Facet	The name of the facet of the LO expression that is described.	0..1	-	No vocabulary defined.	ValueFromVocab	Optional data element. If absent, it is recommended to provide a default value.	“default”, “rights”
3.3.2	Metadata	A metadata instance describing the facet defined in element 3.3.1 Description.Facet.	1..1	-	-	-	Mandatory child data element.	-
3.3.2.1	Schema	The namespace of the schema used for the LO expression description.	0..1	-	A valid URI.	URI.	Optional data element. When used, this URI is the namespace of the schema used to define the metadata at the extension point 3.3.2.2.	“http://ltsc.ieee.org/xsd/LOM”
3.3.2.2	<extension>	The metadata instance containing the description.	1..1	-	-	A metadata instance used to describe the LO manifestation facet defined in element 3.3.1 Expression.Description.Facet. This should be a valid instance of the schema identified by the namespace provided in element 3.3.2.1 Expression.Description.Metadata.Schema.	Mandatory child data element.	A valid LOM instance
Root / 3.4	Manifestation	The manifestations (embodiements) of the LO expression.	1..*	Unordered	-	-	Can either be a mandatory data element of Expression or the ILOX root element.	-
3.4.1	Identifier	A globally unique label that identifies this learning object manifestation.	0..*	Unordered	-	-	Optional data element.	-
3.4.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this entry. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“hdl”, "ISBN", "lre", "URI",”doi”
3.4.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this LO manifestation. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
3.4.2	Name	The name of the LO manifestation.	1..1	-	A controlled vocabulary including at least the values provided in Section 4.6.1.	ValueFromVocab	Dimension is optional when Manifestation is the ILOX root element and mandatory otherwise.	“package in”, “experience”
3.4.3	Parameter	A parameter further defining the manifestation.	0..1	-	The value space of this element depends on the value of element 3.4.2 Manifestation.Name. See section 5 for details.	ValueFromVocab	Usage depends on the value of element 3.4.2 (Manifestation.Name)	Value depends on the value of element 3.4.2 (see Section 4.6.2).
3.4.4	Description	A multi-faceted description of the LO manifestation under consideration.	0..*	Unordered	-	-	Optional data element.	-
3.4.4.1	Facet	The name of the facet of the LO manifestation that is described.	0..1	-	No vocabulary defined.	ValueFromVocab	Optional data element.	“default”, “rights”
3.4.4.2	Metadata	A metadata instance describing the facet defined in element 3.4.1 Description.Facet.	1..1	-	-	-	Mandatory child data element.	-
3.4.4.2.1	Schema	The namespace of the schema used for the LO manifestation description.	0..1	-	A valid URI.	URI.	Optional data element. When used, this URI is the namespace of the schema used to define the metadata at the extension point 3.4.2.2.	“http://ltsc.ieee.org/xsd/LOM”
3.4.4.2.2	<extension>	The metadata instance containing the description.	1..1	-	-	A metadata instance used to describe the LO manifestation facet defined in element 3.4.1 Manifestation.Description.Facet. This should be a valid instance of the schema identified by the namespace provided in element 3.4.2.1 Manifestation.Description.Metadata.Schema.	Mandatory child data element.	A valid LOM element.
Root/3.4.5	Item	The items (copies) of an LO manifestation.	1..*	Unordered	-	-	Can either be a mandatory data element of Manifestation or the ILOX root element.	-
3.4.5.1	Identifier	A globally unique label that identifies this learning object item.	0..*	Unordered	-	-	Optional data element.	-
3.4.5.1.1	Catalog	The name or designator of the identification or cataloguing scheme for this entry. A namespace scheme.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“hdl”, "ISBN", "lre", "URI",”doi”
3.4.5.1.2	Entry	The value of the identifier within the identification or cataloguing scheme that designates or identifies this learning object item. A namespace specific string.	1..1	-	Repertoire of ISO/IEC 10646-1:2000	normalizedString	Mandatory child data element.	“DB123456”, "2-7342-0318", "LEAO875", “http://foo.org/1234”
3.4.5.2	Location	The location of the LO item.	1..1	-	-	-	Mandatory data element.	-
3.4.5.2.1	URI	The URL of the LO item or of a resolution service that can provide it.	1..1	-	A valid URL	URI	Mandatory data element.	“http://fire.eun.org/LREMAPv4p0.pdf”
3.4.5.2.2	Metadata	A piece of metadata further describing the LO item location.	0..1	-	-	-	Optional data element.	-
3.4.5.2.2.1	Schema	The namespace of the schema used for the description of the LO item location.	0..1	-	A valid URI.	URI.	Optional data element. When used, this URI is the namespace of the schema used to define the metadata at the extension point 3.4.5.2.2.2.	“http://ltsc.ieee.org/xsd/LOM”
3.4.5.2.2.2	<extension>	The metadata instance that actually contains the description.	1..1	-	-	This element can only be used when A metadata instance used to describe the location. This should be a valid instance of the schema identified by the namespace provided in element 3.4.5.2.2.1 Item.Location.Description.Schema.	Mandatory child data element.	A DREL expression instance.
3.4.5.3	Description	A multi-faceted description of the copy (item) of the LO item under consideration.	0..*	Unordered	-	-	Optional data element.	-
3.4.5.3.1	Facet	The name of the facet of the LO item that is described.	0..1	-	No vocabulary defined.	ValueFromVocab	Optional child data element.
3.4.5.3.2	Metadata	A metadata instance describing the facet defined in element 3.4.5.3.1 Description.Facet.	1..1	-	-	-	Mandatory child data element.	-
3.4.5.3.2.1	Schema	The namespace of the schema used for the description.	0..1	-	A valid URI.	URI.	Recommended data element. When used, this URI is the namespace of the schema used to define the metadata at the extension point 3.4.5.3.2.2.	“http://ltsc.ieee.org/xsd/LOM”
3.4.5.3.2.2	<extension>	The metadata instance containing the description.	1..1	-			Mandatory data element.	A LOM instance.

5 LODE Search Data Model

5.1 Introduction

Move to top

Searches for learning objects use certain attributes of the objects as search terms. We model search for learning objects here following the information model of CQL [CQL, 08], under which the attributes of a learning object are available for search through an abstract access point corresponding to a distinct attribute. For example, “competency” is an access point for discovering learning content based on the competencies supported by the content. Search queries can be constructed by combining searches across one or more access points, all of which need to be successful for a particular object in order for that object to match the search.

The information model also defines modifiers for certain access points. These allow more specific queries for certain access points, in case those access points can contain multiple values. For example, the Language modifier can be used in conjunction with the Title access point to construct a search for only French language Titles. (This presupposes that the Title attribute of an object can have multiple values, each corresponding to a distinct language, and that a search can differentiate between those values.)

The information model does not constrain access points to having a single value for an object, as just seen. If a modifier is not specified, all values in the access point are searched for a match.

The information model also defines sort criteria that can be used to indicate how to sort the result set generated by the search.

The realization of access points through search indexes binds access points to an existing search protocol and the data model can be bound to other search protocols. The CQL binding binds the access points to indexes from four separate context sets: there is no expectation that they all be drawn from a single CQL context set.

5.2 Definitions

Move to top

The semantics of the access points and modifiers are defined according to the information model of LOM [LOM, 02]. This means that LOM is used for reference semantics, but this profile does not presume that the data being searched is necessarily stored as LOM. The sources of definitions follow the hierarchy: Dublin Core [DCME, 08], where applicable; LOM semantics, where Dublin Core is not specific enough; CanCore [CANCORE, 04] or 1EdTech RDCEO [RDCEO, 02], where LOM is not definitive (e.g. in some of its vocabularies).

Some of the access points correspond to LOM fields that are constrained to a vocabulary; e.g. learning resource type, intended end user role. These vocabularies are not included in the base model described here, although they would be the default in any profile.

Access point	Definition	Definition Source
full record	Full text index of the metadata for the resource	—
title	Name given to the resource	DC
author	An entity primarily responsible for making the resource.	DC
publisher	An entity responsible for making the resource available.	DC
contributor	An entity responsible for making contributions to the resource.	DC
keywords	The topic of this learning object	DC
discipline	Classification of a learning object according to its use by disciplinary departments, faculties, or units in an organization	LOM (CanCore): 9. Classification where purpose = discipline
competency	Classification of a resource according to its use to develop skills, knowledge, tasks, and learning outcomes	LOM (1EdTech RDCEO): 9. Classification where purpose = competency
language	A language of the resource	DC
cost	Whether this resource requires payment	LOM: 6.1 Cost
license	Identifier for a license under which the resource is available (e.g. URI, Creative Commons abbreviation)	—
learning resource type	The specific kind of learning object	LOM: 5.2 Learning Resource Type
intended end user role	Principal user(s) for which this learning object was designed	LOM: 5.5 Intended End User Role
context	The principal environment within which the learning and use of this learning object is intended to take place	LOM: 5.6 Context
typical age	Age of the typical end user	LOM: 5.7 Typical Age Range
date	Date of publication (e.g., give me the latest version)	DC
version	Version of the learning object	LODE: ILOX Expression dimension parameter where dimension name = version
manifestation name	Name of the manifestation (e.g., package in, experience)	LODE: ILOX Manifestation name
manifestation parameter	Parameter of the manifestation (e.g., 1EdTech Common Cartridge 1.0)	LODE: ILOX Manifestation parameter

Modifier	Definition	Definition Source
language	Restrict the search to values from the specified language.	LOM
source	Restrict the search to values from the specified controlled vocabulary	e.g. bib.classAuthority [CQLBIB, 09]. NOTE: bib.classAuthority restriction constrains controlled vocabularies to bibliographic classification authorities as listed in [MARC, 03]. It is used here to illustrate restrictions to controlled vocabulary sources, rather than to prescribe that particular list of sources.

Sort criteria	Definition	Definition Source
Modification date	Sort in reverse order of date/time of last modification	—
Rating	Sort in reverse order of average user rating	—
Relevance	Sort in order of relevance to the specified search criteria	—

5.3 Profiling and Extending

Move to top

While the semantics of the access points are mostly derived from LOM, there is no requirement that the metadata of learning objects actually be coded in LOM: any metadata schema that can be transformed so as to match the access point semantics is permissible.

The data model is intended for use through CQL [CQL, 08], and its access points and modifiers correspond to CQL indexes and relation modifiers, through a default CQL binding. Other bindings are permissible.

The metadata underlying the access points can be profiled so as to constrain values to particular vocabularies. The identifier used for the License access point needs to be profiled to a particular scheme.

Appendix A: Use Cases

Use Case Title:	Professor searches for colleagues’ resources within Lionshare
Use Case Local ID:	LODE001
Brief Description:	Professors in the astronomy department often do searches on the Internet for such items as images of galaxies, papers on astronomy that they can refer to in class, and charts of the solar system. The professors mentioned at a meeting how frustrating it was to try to find astronomy-related items online, as often the search results are cluttered with things such as astrology sites, company names that are astronomy-related, etc. Sorting through such results to find useful items can be a problem for professors with limited time. Along with this, several professors mentioned that they often spend a lot of time searching for something, and then find out after the fact that a colleague has what they are looking for on their computer. It would be great, the professors conclude, if they had something like a Web site where they could search for each other’s resources. However, they have limited computer expertise and little time for such an involved project.
Level:	Summary
Actors:	Professors

Use Case Title:	Register repository metadata with the FRED registry ()Federated Repositories for Education)
Use Case Local ID:	LODE002
Brief Description:	New repository is registered with registry, and thereby joins the federation. Accountability and access metadata is registered for repository.
Level:	Summary
Actors:	Primary: Local Repository Manager, Registry Manager

Use Case Title:	Pull metadata of item into the FRED registry
Use Case Local ID:	LODE003
Brief Description:	Metadata for an item is pulled from repository into registry, and exposed by registry to end users for discovery.
Level:	Summary
Actors:	Primary: Repository Manager, Registry Manager, End User

Use Case Title:	Update metadata of item in the FRED registry
Use Case Local ID:	LODE004
Brief Description:	The metadata record for an item is updated; it sits alongside the old metadata record as a new version.
Level:	Summary
Actors:	Primary: Registry, Metadata Manager (~ Repository Manager)

Use Case Title:	Discover item through the FRED registry (Search)
Use Case Local ID:	LODE005
Brief Description:	Item registered in registry is discovered by end user through full-text search of meta- data or specific metadata fields
Level:	Summary
Actors:	Primary: End User, Registry

Use Case Title:	Add repository to the FRED directory roster
Use Case Local ID:	LODE006
Brief Description:	The directory manager adds a local repository to their roster of repositories
Level:	Summary
Actors:	Primary: Directory Manager

Use Case Title:	Discover item through the FRED roster (Full text Federated Search)
Use Case Local ID:	LODE007
Brief Description:	Item in an (ad hoc) federated repository is discovered by end user through full-text search of local repository content
Level:	Summary
Actors:	Primary: End User

Use Case Title:	Searching remote LODE repositories through a European Digital Library web service
Use Case Local ID:	LODE008
Brief Description:	LODE repositories are described within a European Digital Library web service as collections. These descriptions allow end-users to select them for searching. Search results are retrieved from LODE repositories and displayed in the web service interface. The descriptions should contain information about how repositories are accessed (protocols like SRU, Z39.50, etc.) and which formats the received metadata is in.
Level:	Summary
Actors:	Primary: European Digital Library web service Secondary: LODE repositories, end users
Stakeholders & Interest:	Stakeholder: LODE Interest: Repositories exposed through different platforms reaching a broader audience
Stakeholders & Interest:	Stakeholder: European Digital Library Interest: Provide European Digital Library users with searchable content

Use Case Title:	Harvesting and indexing LODE repositories with a European Digital Library harvesting and indexing service
Use Case Local ID:	LODE009
Brief Description:	A European Digital Library harvesting service retrieves LODE repositories metadata and index them into a central index. Metadata are harvested in a format compliant for search within a European Digital Library web service.
Level:	Summary
Actors:	Primary: European Digital Library harvesting and indexing service Secondary: LODE repositories
Stakeholders & Interest:	Stakeholder: LODE Interest: >From within a central index the LODE repositories are part of a fast search and retrieve system giving convenient access to end users.
Stakeholders & Interest:	Stakeholder: European Digital Library Interest: Provide European Digital Library users fast and convenient access to new content

Use Case Title:	Federated search within Lornet
Use Case Local ID:	LODE010
Brief Description:	This use case details the process through which a Federator interacts within eduSource to search a network of Metadata repositories and to locate a set of LOM records. The goal is to create a service for an Infoseeker (teacher, student, course developer or software agent) to search for a learning object/resource across multiple repositories, providing an aggregated result list of metadata records in return. The Infoseeker must have access to the Internet. The Federator possesses a (possibly empty) result list of learning objects from a variety of repositories, which meet the search criterion provided by the Infoseeker.
Level:	Summary
Actors:	Primary: Federator: a software agent responsible for providing the interaction between the Infoseeker and the Federated Search System (FSS). Secondary: Infoseeker: a person (or a software application) wanting to search a network of metadata repositories. Most often the Infoseekers will be a person, but it may very well be software running as part of an LMS or an agent launching a scheduled Intelligent Search Agent on behalf a human user. Federated Search System (FSS): a software interface that can access a set of metadata repositories, search each one according to their conditions and return a set of Metadata Records.

Use Case Title:	Harvested search within Lornet
Use Case Local ID:	LODE011
Brief Description:	A Harvester is operated by a service provider as a means of collecting metadata from repositories, here defined as network accessible servers that can process the 6 OAI-PMH requests (GetRecord, Identify, ListIdentifiers, ListMetadatFormats, ListRecords, ListSets). An acceptable alternative to OAI-PMH is to use D-Space repositories. To provide Infoseekers with a way to use a Harvester as a search service and enable resource Providers (commercial and non-commercial) with a simple way to make their resources available for use through the eduSource network. The Infoseeker has access to a Harvester on his/her workstation. At least one learning resource Publisher has created at least one metadata repository and a corresponding resource repository available to Harvesters in a Registry that list all such repositories available for harvesting. The Infoseeker has located a resource through a Harvester from at least one learning resource Provider.
Level:	Summary
Actors:	Primary: Harvester: a client application that issues OAI-PMH compliant requests and makes metadata available to the Infoseeker. Secondary: Resource Publisher: a person (or a software agent) creating repositories for the harvesting system. Registry service:a service making available a list of metadata and resource repositories.

Use Case Title:	Instructor conducts search by metadata value
Use Case Local ID:	LODE013
Brief Description:	Instructor searches a digital repository for content by a specific value of a metadata field. A successful result returns a list of objects that met search criteria
Level:	Primary task
Actors:	Primary: Instructor Secondary: Digital repository, metadata indexer, SME (subject matter expert), instructional designer, web content developer
Stakeholders & Interest:	Stakeholder: Institution the provides content Interest: Discoverability of and reuse of their content
	Stakeholder: Instructor Interest: Finding existing content to use as part of their offering
	Stakeholder: SME and/or metadata indexer Interest: Providing metadata information that supports discovery by instructors

Use Case Title:	Alocom powerpoint plugin searches a learning object repository
Use Case Local ID:	LODE014
Brief Description:	A plugin for MS powerpoint (and similar applications) enables authors to reuse fragments of presentations available in a repository. 1. Alocom sends a query to a repository. This query contains keywords and the type of learning object the author is interested in (examples, images, definitions, ...) 2. The repository returns a list of learning objects that match the query. 3. The author selects an object and adds it to her/his presentation
Level:	Summary
Actors:	Primary: The author is in the process of creating a powerpoint presentation, reusing existing learning objects. Secondary: The learning object repository that hosts reusable assets. These can be images, single slides, definitions, examples, animations, etc.
Stakeholders & Interest:	Stakeholder: ARIADNE Interest: making reuse of small LO possible.

Use Case Title:	ARIADNE federated search engine
Use Case Local ID:	LODE015
Brief Description:	The ARIADNE federated search engine federates search requests through standards such as SQI and LOM to learning object repositories such as the repositories available in ProLearn and GLOBE. 1. A client tool sends a query (synchronously or asynchronously) to the federated search engine. This tool can additionally limit the search to a subset of the repositories available. 2. The federated search engine forwards the query (preferably asynchronously) to the repositories that support the query language. 3. The repository return results to the federated search engine. 4. The federated search engine ranks the results according to a ranking algorithm. 5. The federated search responds to the client tool.
Level:	Summary
Actors:	Primary: A client tool issuing a search. Secondary: The federated search engine, responsible for federating a query Secondary: A repository that is part of federation. Such a repository can implement a native interface to a repository or host metadata, harvested from several repositories. Secondary: A registry documenting repositories (Search interface, harvest interface, publish interface, etc.)
Stakeholders & Interest:	Stakeholder: ARIADNE/GLOBE Interest: Enabling search engines to reach a broader mass of educational content, unlocking the deep web.

Use Case Title:	VLE (Virtual Learning Environment) searches a learning object repository
Use Case Local ID:	LODE016
Brief Description:	Loosely couple search and obtain LO’s from repositories. 1. A client tool sends a query (synchronously or asynchronously) to the federated search engine. This tool can additionally limit the search to a subset of the repositories available. 2. The federated search engine forwards the query (preferably asynchronously) to the repositories that support the query language. 3. The repository return results to the federated search engine. 4. The federated search engine ranks the results according to a ranking algorithm. 5. The federated search responds to the client tool.
Level:	Summary
Actors:	Primary: A VLE issuing a search or trying to obtain content Secondary: A repository or federated search engine responding to the search.
Stakeholders & Interest:	Stakeholder: ARIADNE Interest: Enable content to be open, reachable beyond the borders of a repository. Avoid content to be locked up inside a single VLE. Making coupling with other VLEs easy.

Use Case Title:	Disclosure and social contribution: Organization level (NIME)
Use Case Local ID:	LODE017
Brief Description:	Many Japanese universities and colleges have some traditions to share their knowledge with their regional community as a “social contribution”. They provide their face-to- face lectures and/or on-line course materials for the community. For example, the member universities of Japanese Opencourseware Consortium also understand their significance of their movement in the similar contexts. Japanese government promotes the new “e-Japan Strategic Plan II”, and one of the objectives is to contribute to the global knowledge-based society by providing Japanese content (open or profit) to overseas. Nowadays, the Japanese universities and colleges should promote their social contributions in more international and global fashions. Even if they provide their content in English or in other foreign languages, it is very difficult for overseas potential users to find their homepages. So, they register their metadata at NIME-glad gateway, and give more search opportunities from overseas using GLOBE federated search functions. At the moment, the five organizations, ARIADNE in EU, education.au limited-EdNA in Australia, LORNET in Canada, MERLOT in the United States and NIME in Japan, join the GLOBE. The users in each organization can search the other overseas databases cross-organizationally using the federated search services.
Level:	Summary

Use Case Title:	Resource detail information browsing (Institute for Information Industry)
Use Case Local ID:	LODE020
Brief Description:	Users get full descriptions of the resource, which was chosen in search result pages, in learning object metadata (LOM) format.
Level:	Primary Task
Actors:	Primary: public user Secondary: teacher, student, learning object author or provider
Stakeholders & Interest:	Stakeholder: National Science & Technology Program Office for e-Learning Government departments, ex. National Palace Museum, Overseas Compatriot Affairs Commission, R.O.C (Taiwan), Ministry of Education ... Interest: National Science & Technology Program Office for e-Learning

Use Case Title:	Basic search (Institute for Information Industry)
Use Case Local ID:	LODE021
Brief Description:	The basic function of the search.
Level:	Primary Task
Actors:	Primary: public user Secondary: teacher, student, learning object author or provider
Stakeholders & Interest:	Stakeholder: 1. National Science & Technology Program Office for e-Learning 2. Government departments, ex. National Palace Museum, Overseas Compatriot Affairs Commission, R.O.C (Taiwan), Ministry of Education ... Interest: National Science & Technology Program Office for e-Learning

Use Case Title:	Advanced search (Institute for Information Industry)
Use Case Local ID:	LODE022
Brief Description:	Users can specify more restrictive conditions to make a more accurate query.
Level:	Sub-function

Use Case Title:

Advanced search (Institute for Information Industry)

Actors:

Primary: public user

Secondary: teacher, student, learning object author or provider

Stakeholders & Interest:

Stakeholder:

1. National Science & Technology Program Office for e-Learning

2. Government departments, ex. National Palace Museum, Overseas Compatriot Affairs Commission, R.O.C (Taiwan), Ministry of Education ...

Interest: National Science & Technology Program Office for e-Learning

Use Case Title:	Federated search within EdNA
Use Case Local ID:	LODE023
Brief Description:	This use case describes at a high level, the tasks used to perform federated search across a number of repositories and present the results of that search to an end user. The use case is based on an existing federated search. There is a distinction drawn between distributed search and federated search. In this case, distributed search refers to a search across multiple repositories where there may be no agreement on how that search is performed. In this ‘federated search’, there is a collection of repository owners that have agreed to provide a search across their collection of repositories and have agreed to a common set of behaviors/guidelines. The use case describes a federated search request as distinct from harvesting metadata for searching. However, any or all of the repositories in this federation may contain harvested metadata from other repositories.
Level:	Primary task
Actors:	Primary: Searcher. The primary actor is typically a person wishing to query multiple repositories within a single search request. The searcher usually generates the search request from a web-form. It is possible that the search request can be generated from another program. Secondary: Repository. Repositories will have an API that can be queried as part of the search request. Federated Search Provider (FSP): The federated search provider is typically a software program that is called to process search requests. The federated search provider also performs administrative and operational functions related to federated search. Access Provider (AP): An access provider provides access to federated search functions. There may be multiple access providers for a federation. Each repository owner may provide access to the federated search function. Other website/portal owners that do not have a repository may also act as access providers. Each provider may configure their access point differently (e.g., limiting the number of repositories, using different performance policies, presenting results differently etc.).
Stakeholders & Interest:	Stakeholder: Federation: A collection of repository owners that have agreed to allow their repositories to be searched collectively according to an agreed set of rules/ guidelines. Repository Provider: Owners of a repository. In addition to agreeing to a common set of guidelines for the federation, an individual repository may have additional constraints that they need to abide by.

1EdTech Learning

Use Case Title:	Discovery within Digital Marketplace
Use Case Local ID:	LODE024
Brief Description:	Search/Browse for Finding – What materials are available that could satisfy my needs in teaching the course and my students’ needs in learning? On demand search and browse services will provide users hitlists of materials for them to evaluate if the material(s) satisfy their “finding” requirements. >From an initial request, the search/browse functionality must allow the user to easily navigate to the item level and the item-level metadata should allow the user to have a 70% confidence level that the materials will satisfy their requirement that the material can satisfy their teaching needs and their students’ learning needs. Professor Plum logs into his RLS during the summer to begin to build the collection of resources he will want his students to use in the Biology 101 course he’s teaching in the fall (1). It’s been 3 years since he taught the introductory level course so he’s interested in reviewing what’s available in the field. Within the LMS website, he goes to the page for building his resource list and clicks on “Search for Resources”. He types in a key concept he’ll be covering in the course and a hit list of materials from 6 different publishers is generated along with free materials from MERLOT. The descriptions of the materials includes title, author, abstract, publisher collateral, type of resource (book, article, multimedia, etc.), indication of its ability to be rendered in an accessible (section 508 compliant) format, and the different delivery formats and prices (hard copy text book, custom book, eBook to own, eBook to rent).
Level:	Summary
Actors:	Primary: Faculty

Use Case Title:	Preview within Digital Marketplace
Use Case Local ID:	LODE025
Brief Description:	Previewing for Use – Of the materials I’ve discovered, which ones do I want to evaluate more deeply for selection in my course? Once users have created a limited collection of prospective course content, they will evaluate the resources in more detail. Previewing the content in preparation for the final selection is an important service for faculty. At the completion of previewing the materials, faculty will have information about the resource and about their own needs to support a confident decision to select materials and label them as “my materials for my course” – personalizing the materials in the process of reusing materials. Professor Plum selects 10 different resources to review in more detail. He clicks on the PREVIEW button and a window pops ups indicating that since he is a faculty in good standing at CSULB, he will have full electronic access to the eBook for a 72-hour period, starting whenever he wishes. After previewing 10 materials, he selects 5 for his course, a textbook, and a chapter from another book, a tutorial on using EXCEL, and 2 multimedia simulations. He also gets to preview the net-generation handbook as well.
Level:	Summary
Actors:	Primary: Faculty

Use Case Title:	Selection, assembly, and annotation within Digital Marketplace
Use Case Local ID:	LODE026
Brief Description:	Professor Plum saves his selections of materials for his students and writes notes (annotations) about the resources he’s selected to use. With the textbook, Professor Plum decides that only 8 of the 14 chapters will be used in the course so he chooses the custom publishing option to create a book that’s more relevant to the course learning. He also adds the chapter from another book to create the custom course “textbook”. As Professor Plum views the resource list he remembers that he created some content when last taught the course that students found especially useful. By using the Digital Marketplace Authoring / Assembly service, he adds this content to the CSU repository and then adds it to his resource list. He also allows other CSU faculty to view and use this content. He notices that the custom textbook, and tutorial can be rendered in an accessible format but the 2 multimedia simulations are only 80% accessible. Professor Plum contacts the campus Center for Students with Disabilities to learn what he needs to do to provide alternative curriculum to the visually impaired student he’ll have in his class. Finally Professor Plum examines the “student view” of the resource list and sees that the textbook is offered in an eBook-to-own version for 50% of the hard copy text and the eBook-to-rent is only $15.99 for the semester. With all these options for access to the materials, he’s hoping all his students will use the materials.
Level:	Summary
Actors:	Primary: Faculty

Use Case Title:	Choosing, rendering, and buying content within Digital Marketplace
Use Case Local ID:	LODE027
Brief Description:	When Jane Student gets access to the RLS for her Biology 101 course, she navigates to the Resource List to check out what she’ll need to buy. As a student with a vision disability, she has had a challenge of getting the materials in a format she can use in a timely manner. She reviews the resource list and sees that the textbook and tutorial are in an accessible format and is pleased. She then reviews the different types of style sheets CSULB has certified has rendering the content in an accessible manner. She likes the choices and decides on the size, contrast, colors, and layout that suits her needs. Jane is considering becoming a biology major so she decides to put the eBook-to-buy in her shopping cart and the tutorial in her shopping cart. She buys the resources online with her credit card and stores the resources in her campus ePortfolio. For the two multimedia resources, there’s a note for her stating that the CSULB Center for Students with Disabilities will provide an aid to work with Jane on the portions of these resource that are not accessible to her. In the 4th week of the semester, Jane realizes she’s having trouble with one of the key concepts in biology. She goes to the Digital Marketplace in her RLS and searches for additional materials that might do a better job in helping her learn the concept. She finds a student workbook that has the background information she needs and it can be rendered in the accessible format she prefers. Jane buys it online.
Level:	Summary
Actors:	Primary: Student

Use Case Title:	Federated search within the Learning Resource Exchange
Use Case Local ID:	LODE028
Brief Description:	A user sends a query to the Learning Resource Exchange and gets results 1. The user enters search criteria in its system 2. User’s system transforms user input into a valid query 3. User’s system sends the query to the BS 4. The BS propagates the query to all the repositories participating in the LRE 5. Each repository that supports the query language used, processes the query and sends the results back to the BS asynchronously 6. The BS routes the results to User’s system 7. The user gets the results
Level:	Summary
Actors:	A system connected to the Learning Resource Exchange A user of the system The Learning Resource Exchange (LRE) The Brokerage System (BS). All the repositories participating in the LRE

Use Case Title:	Federated discovery of repositories within the Learning Resource Exchange
Use Case Local ID:	LODE029
Brief Description:	A harvester sends an Identify query to the Learning Resource Exchange and gets the description of the participating repositories: 1. The harvester sends the Identify query to the BS 2. The BS propagates the query to the repositories participating in the LRE 3. Each repository receives the query and sends its description to the BS 4. The BS routes the repository descriptions to the harvester 5. The harvester receives the descriptions of the participating repositories
Level:	Summary
Actors:	The Learning Resource Exchange (LRE) The Brokerage System (BS) All the repositories participating in the LRE A harvester connected to the Learning Resource Exchange

Use Case Title:	Federated harvesting within the Learning Resource Exchange
Use Case Local ID:	LODE030
Brief Description:	The harvester sends a ListRecords query to the Learning Resource Exchange and gets metadata updates: 1. The harvester sends the ListRecords, which contains a timestamp query to the BS 2. The BS propagates the query to the repositories participating in the LRE 3. Each repository receives the query and returns metadata updates 4. Metadata that have been updated after the timestamp 5. Ids of Metadata that have been removed after the timestamp 6. The BS routes the metadata to the harvester 7. The harvester receives metadata updates
Level:	Summary
Actors:	The Learning Resource Exchange (LRE) The Brokerage System (BS) All the repositories participating in the LRE A harvester connected to the Learning Resource Exchange

Use Case Title:	Search LORs to get results sorted by relevance
Use Case Local ID:	LODE031
Brief Description:	Tutor searches one or more LORs, and gets back results sorted in order of relevance to their search criteria
Level:	Summary
Actors:	Primary: Tutor Secondary: search client (e.g. part of LMS system), repository system(s), search gateway
Stakeholders & Interest:	Stakeholder: Tutor Interest: looking for packages of learning content suitable for a lesson for their students

Use Case Title:	Tutor refines their search criteria using properties exposed by the target repositories
Use Case Local ID:	LODE033
Brief Description:	The target repositories support a common set of metadata fields and vocabularies, such as educational level, which are made available to the tutor as possible search constraints within the search interface of the LMS. The tutor restricts the search to a specific educational level, and sees a more relevant list of results.
Level:	Summary
Actors:	Primary: Course Tutor
Stakeholders & Interest:	Stakeholder: Course Tutor

Use Case Title:	Tutor browses repositories by subject classification
Use Case Local ID:	LODE034
Brief Description:	Repository system(s) expose the classification system(s) used to categorize the collections they hold. A searching system reads these classifications systems, and offers up to a course tutor to explore the content available.
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	Tutor selects content objects for inclusion in course
Use Case Local ID:	LODE035
Brief Description:	From a list of search results the tutor selects one or more content objects for inclusion in their course.
Level:	Sub-function
Actors:	Primary: Tutor Secondary: search client (e.g. part of LMS system), repository system(s), search gateway
Stakeholders & Interest:	Stakeholder: Tutor Interest: looking for packages of learning content suitable for a lesson for their students

Use Case Title:	Students is shown latest version of a content object
Use Case Local ID:	LODE036
Brief Description:	Students accessing the lesson in the LMS see the latest versions of the selected content objects, requested from the host repository and parsed/played by the LMS
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	LMS downloads copy of a content package from LOR
Use Case Local ID:	LODE037
Brief Description:	From inside their LMS, a tutor selects one or more content objects for inclusion in a course. These are downloaded from the relevant repository by the LMS, and imported into the course.
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	Tutor previews content stored in an LOR
Use Case Local ID:	LODE039
Brief Description:	From a list of search results, a tutor chooses to preview each content object they are interested in.
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	Tutor reads full catalogue record
Use Case Local ID:	LODE040
Brief Description:	From a list of search results, a tutor chooses to view more information (metadata) about the content object.
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	Resource access
Use Case Local ID:	LODE046
Brief Description:	Users can access the resource they chose in three kinds of way: 1. link to the original website of the resource 2. access the resource immediately 3. download the resource to users’ local hard drive space.
Level:	Sub-function
Actors:	Primary: public user Secondary: teacher, student, learning object author or provider
Stakeholders & Interest:	Stakeholder: 1. National Science & Technology Program Office for e-Learning 2. Government departments, ex. National Palace Museum, Overseas Compatriot Affairs Commission, R.O.C (Taiwan), Ministry of Education .. Interest: National Science & Technology Program Office for e-Learning

Use Case Title:	Display Objects
Use Case Local ID:	LODE052
Brief Description:	This use case details the process through which a Launcher interacts with a network of Metadata and Learning Object repositories and displays the items in a content package, or simple un-packaged objects. The goal is to create a service for an Infoseeker (teacher, student, course developer or software agent) to display the objects/resources referenced by a metadata record. The Infoseeker must have access to some LORs, both physically and logically through attaining appropriate rights according to the DRM infrastructure. The Launcher has displayed items in a content package, or a single object, corresponding to the Infoseeker’s request.
Level:	Summary
Actors:	Primary: Launcher: an agent that can decompose an 1EdTech-LD or SCORM package and display any of its items or launch an un-packaged object/resource. Secondary: Infoseeker: a person (or a software application) wanting to search a network of metadata repositories.

Use Case Title:	Tutor chooses specific version of a content object to use in a course
Use Case Local ID:	LODE055
Brief Description:	Content objects in a repository are subject to regular updates. When they select one of these content objects for use in the course, a tutor is given the choice to always use the latest version of the content object, or to apply a specific version of the content object.
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	Querying learning resources based on a rating or other annotation
Use Case Local ID:	LODE056
Brief Description:	A user is interested in all the learning objects that are rated at 4 and higher in all the repositories of the federation. This could be one of the criteria in the advanced search. Ratings information could additionally be used to rank results.
Level:	Summary
Actors:	Primary: End-users Secondary: Repository owners who are interested in filtering resources that are of a certain rating.
Stakeholders & Interest:	Stakeholder: Repositories who have implemented ratings or review criteria for learning resources. Interest: Ratings can be binary votes, on a scale or multi-attribute. Moreover, in some repositories they are done by expert and in some by end-users.

Appendix A.1 – Use Cases Out of Scope

Move to top

Use Case Title:	Peer-to-peer distributed search
Use Case Local ID:	LODE012
Brief Description:	The user (Infoseeker) issues a search request to P2P network, directly or through the Search Result Display tool. The query is transformed and sent to the repository (-ies) that can be reached through the eduSource gateway. The results from the repository are received by the gateway and after transformation are propagated via P2P network to the user. The Infoseeker receives metadata results from eduSource reachable repositories on peers and LO Provider’s servers. The peer is connected to P2P network. The gateway between P2P network and eduSource is configured and running Some eduSource repositories are open for search requests. The metadata records from the eduSource reachable repositories are received by the peer and displayed to the user.
Level:	Summary
Actors:	Primary: Distributor: a P2P distributed search agent on the client computer. Secondary: Infoseeker: a person (or a software application) wanting to search a network of metadata repositories. Most of the time the Infoseeker will be a person, but it may very well be software running as part of an LMS or an agent launching a scheduled Intelligent Search Agent on behalf a human user.

Use Case Title:	Sharing and reuse of digital learning resources :
Use Case Local ID	LODE018
Brief Description:	Faculty and Teachers level. In order to improve their teaching and pedagogical activities, professors and teachers need various “materials” for their classes, that is, learning objects. As, in higher education, the subjects and academic fields are diversified and the learning resources are scattered, it is very difficult to find in a content repository all of what they want. They have to visit many databases, to search by keywords, and to compare the search results. By utilizing the *GLOBE federated search* services, they need not repeat the same operations in different databases. Each professor is also a researcher in the specific academic field(s) and she/he has very original research materials and findings. Such research materials can be remixed into quality educational materials. Some professors hope to contribute to the global knowledge-based society by providing their materials as an “open content”; others hope to sell commercially for the sustainability. In Japan, both the university and the professor sometimes share the copyright on the educational materials, and it also make the situation more complicated. In such case, they need some copyright clearance services in addition to the global federated search. NIME is developing a prototype system for the copyright clearance, called “*EE-CARD (Educational and Electronic Copyright Agreement for Reuse and Derivative)î*.
Level:	Summary

Use Case Title:	Lifelong learning in international contexts: Learners level (NIME)
Use Case Local ID:	LODE019
Brief Description:	Many Japanese students are looking for the opportunities of studying abroad and for those of joining overseas distance education. When they compare the content from many similar programs provided by different organization, they have to use their huge time to find the homepages introducing the actual content. By the *GLOBE federated search* services, they can find the similar programs and compare their content much more easily.
Level:	Summary

Use Case Title:	LMS Tutor sorts search results in order of last modification date
Use Case Local ID:	LODE032
Brief Description:	The tutor re-orders the list, according to the last modification-date of the content objects.
Level:	Summary
Actors:	Primary: Course Tutor Secondary: LMS system, repository system
Stakeholders & Interest:	Stakeholder: Course Tutor

Use Case Title:	Search portal adds copy of a content package into a course in an LMS
Use Case Local ID:	LODE038
Brief Description:	From a list of search results in a repository/catalogue system, a tutor selects one or more content objects. They choose to include these content objects in one of their courses in a separate LMS system. The content objects are deposited in the LMS system by the repository system, and imported into the course by the LMS system.
Level:	Summary
Actors:	Primary: Course Tutor Secondary: Repository system, LMS

Use Case Title:	Tutor in an LMS comments on an object in a LOR
Use Case Local ID:	LODE041
Brief Description:	Tutor can make comments, star ratings etc. on a content object that are visible to other users of the repository network
Level:	Summary
Actors:	Primary: Course Tutor Secondary: LMS and Repository Systems

Use Case Title:	LMS system checks for (is alerted to) modifications to a learning object
Use Case Local ID:	LODE042
Brief Description:	A content object stored in a remote repository has been included in a course in an LMS. When the content object is modified, the LMS system notifies the course tutor that there is a new version of the content object.
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	Course page includes a lists of newly published learning objects on relevant topics
Use Case Local ID:	LODE043
Brief Description:	The home page for a course features a list of the latest learning objects available in external repositories which are relevant to that course. Could extend to most popular, most frequently used learning objects.
Level:	Summary
Actors:	Primary: Course Tutor

Use Case Title:	Feeds from LORs combined in a news aggregator
Use Case Local ID:	LODE044
Brief Description:	A tutor wants to be informed of new materials meeting the needs of their students in a particular subject area. On the tutor’s behalf an information specialist creates news feed for multiple repositories, constrained by the classification systems used in the individual repositories, and combine these feeds in a news aggregation service. The tutor is given a link to a single feed which will alert them to relevant materials published in any of the repositories.
Level:	Summary
Actors:	Primary: Information specialist Secondary: Feed aggregation service
Stakeholders & Interest:	Stakeholder: Course Tutor

Use Case Title:	Tutor is automatically alerted to new content relevant to their course(s)
Use Case Local ID:	LODE045
Brief Description:	A tutor searches a repository gateway for materials relevant to their course. They subscribe to an alert service which notifies them when any materials matching their original search query are published in any repositories in the network covered by the repository gateway.
Level:	Summary
Actors:	Primary: Course Tutor Secondary: Repository Gateway

Use Case Title:	Classify item
Use Case Local ID:	LODE047
Brief Description:	Registry adds its own classifications to metadata about items, as an augmentation of the metadata it has already registered.
Actors:	Registry Manager, Metadata Provider

Use Case Title:	Annotate item
Use Case Local ID:	LODE048
Brief Description:	Registry adds its own annotations to metadata about items, as an augmentation of the metadata it has already registered
Actors:	Registry Manager, Metadata Provider

Use Case Title:	Recommend item
Use Case Local ID:	LODE049
Brief Description:	Registry adds its own recommendations to metadata about items, as an augmentation of the metadata it has already registered
Actors:	Registry Manager, Metadata Provider

Use Case Title:	Rate item
Use Case Local ID:	LODE050
Brief Description:	Registry adds its own ratings to metadata about items, as an augmentation of the meta- data it has already registered
Actors:	Registry Manager, Metadata Provider

Use Case Title:	Syndicate items.
Use Case Local ID:	LODE051
Brief Description:	An end user subscribes to a notification service from the registry, informing them of any additions of content relevant to them.
Actors:	End User, Registry

Use Case Title:	Choosing, rendering, and buying student development resources
Use Case Local ID:	LODE053
Brief Description:	While Jane was looking for her course materials, she saw that the resource list also include a collection of online materials that could help her learn more about the different jobs you can get with a biology degree, expected salaries, and different types of professional opportunities. Being a CSULB student, she can preview the career development material for 3 hours. Jane likes to book and adds it to her shopping cart. She also sees an e-handbook on how to succeed in college without going broke. She also puts this in her shopping cart and buys the materials with her credit card.
Level:	Summary
Actors:	Primary: Student

Use Case Title:	Buy
Use Case Local ID:	LODE054
Brief Description:	While looking for instructional content, Professor Plum also examines some of the professional development resources also presented that he can use help prepare to teach successfully. He finds a number of handbooks on teaching the net-generation and he selects one for his summer reading, which CSULB gets a discount because of a bulk purchase. Professor Plum puts the net-gen book in his shopping cart and buys it with his credit card. He choose the e-book version and saves the book in his ePortfolio.
Level:	Summary
Actors:	Primary: Faculty

About This Document

Title: 1EdTech GLC Learning Object Discovery & Exchange (LODE)

Editors: David Massart (European Schoolnet), Nick Nicholas (DEEWR) and Nigel Ward (DEEWR)

Co-chairs: David Massart (European Schoolnet)
Susanne Lapointe (TELUQ)
Nigel Ward (DEEWR)

Version: 1.0

Version Date: 2 March 2010

Release: Draft 14

Status: Base Document

Summary: This document contains the 1EdTech GLC LODE Registry Data Model

Revision Information: N/A.

Purpose: This document is released for review by the 1EdTech LODE forum users. Join the discussion and post comments on the LODE Forum: http://www.imsglobal.org/community/forum/index.cfm?forumid=9

Document Location: http://www.imsglobal.org/lode/index.html

List of Contributors

Move to top

The following individuals contributed to the development of this document:

Frédéric Bergeron (TELUQ)

Suzanne Lapointe (TELUQ)

David Massart (European Schoolnet)

Nick Nicholas (DEEWR)

Colin Smythe (1EdTech GLC)

Nigel Ward (DEEWR)

1EdTech Consortium, Inc. (“1EdTech GLC”) is publishing the information contained in this document (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.

1EdTech GLC makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an “As Is” and “As Available” basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

1EdTech GLC would appreciate receiving your comments and suggestions.

Please contact 1EdTech GLC through our website at http://www.imsglobal.org

Please refer to Document Name: 1EdTech GLC Learning Object Discovery and Exchange Base Document v1.0

Date: 2 March 2010