imslogoIAL-300dpi-small

IMS GLC Learning Object Discovery and Exchange (LODE)

 

Base Document Version 1.0

 

 

 

Date Issued:            2 March 2010
Latest version:        
http://www.imsglobal.org/lode/index.html

 

IMS Learning Object Discovery & Exchange (LODE) copyright 2010 by IMS Global Learning Consortium is licensed under conditions equivalent to a Creative Commons Attribution-Share Alike 3.0 United States License with an additional condition that derivative works that are publically distributed must be shared back with the IMS LODE community. This is accomplished by posting your derivative works to the public LODE web site. Instructions for posting are found on the web site at the following page: http://www.imsglobal.org/lode/shared_works.html . Additional derivative works may also be found there.

If you wish to create and distribute a derived work from this document, you are hereby granted permission to copy, display and distribute the contents of the derived work in any medium for any purpose without fee or royalty provided that you include this IPR, License and Distribution notice in its entirety on ALL copies, or portions thereof,. IMS GLC provides free resources for developing profiles of IMS GLC specifications and machine readable bindings. Those creating derivative works are encouraged to use these tools. To do so, follow the instructions on the IMS GLC web site: http://www.imsglobal.org/profile/

This document originated from the IMS Learning Object Discovery & Exchange by IMS Global Learning Consortium.  

THE IMS LODE SPECIFICATION OR DERIVATIVE WORK THEREOF IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER’S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by the contents of this document. Please notify IMS GLC: http://www.imsglobal.org/contactus.cfm

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS’s procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf .

Join the discussion and post comments on the LODE Forum: http://www.imsglobal.org/community/forum/index.cfm?forumid=9

Table of Contents

1               Introduction.. 4

1.1           Scope and Context. 6

1.2           Structure of this Document. 7

1.3           Nomenclature. 7

1.4           References. 7

2               Use Cases. 10

3               LODE Registry Data Model.. 13

3.1           Introduction to the Registry Data Model. 13

3.1.1        LODE Registry Data Model Overview.. 13

3.1.2        Scope and Context13

3.2           Definitions: Core Entities. 13

3.3           Definitions: Federation and Collection Discovery.. 15

3.3.1        Federation. 15

3.3.2        Collection Discovery. 16

3.4           Data Types. 16

3.5           UML Diagram.. 16

3.6           Collection Attributes. 17

3.6.1        Content Collection. 17

3.6.2        Metadata Collection. 18

3.6.3        Party. 19

3.7           Service Attributes. 19

3.7.1        Target19

3.7.2        Protocol Implementation Description. 19

3.7.3        Protocol19

3.7.4        Access Policy. 20

3.8           Relations. 20

3.9           Profiling and Extending.. 21

3.10         LODE Registry Summary.. 21

3.10.1      Protocol Root21

3.10.2      Target Root22

3.10.3      Content Collection Root25

3.10.4      Metadata Collection Root32

4               Information for Learning Object eXchange (ILOX) Data Model.. 38

4.1           Introduction to the ILOX Data Model. 38

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

4.3           ILOX: General Principles. 40

4.3.1        Basic Data Types. 41

4.3.2        Description Type. 42

4.4           Work.. 42

4.5           Expression.. 42

4.5.1        Dimension. 43

4.6           Manifestation.. 43

4.6.1        Name. 43

4.6.2        Parameter. 44

4.7           Item.. 45

4.8           Profiling and Extending.. 45

4.9           ILOX Summary.. 46

5               LODE Search Data Model.. 53

5.1           Introduction.. 53

5.2           Definitions. 53

5.3           Profiling and Extending.. 55

Appendix A: Use Cases. 56

Appendix A.1 – Use Cases Out of Scope. 69

About This Document .. 74

List of Contributors. 74

 

List of Figures

 

Figure 1.1 - IMS LODE at work.5

Figure 2.1 - Overview of the LODE use cases.10

Figure 3.1 – ISO 2146 reference model [ISO, 09].14

Figure 3.2 – Relationships between the LODE Registry entities.15

Figure 3.3 - LODE Registry class diagram.17

Figure 4.1 - A learning object can have multiple copies.39

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

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

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

 

1         Introduction

The Learning Object Discovery & Exchange (LODE) specification aims to facilitate the discovery and retrieval of learning objects stored across more than one collection.

In the context of this work, a learning object can be anything digital used for teaching, learning, or training. Learning objects can consist of simple assets (e.g., text, images, short videos) that can generally be directly rendered in a web browser,or more complex resources that usually consist of multiple components (e.g., text, images, simulations, videos, assessment exercises, etc.) that need to be combined in a precise way in order to provide end-users with a meaningful learning experience. Learning content specifications such as IMS Content Package and IMS Common Cartridge make it possible for such learning objects to be reused in different learning systems. This is achieved by packaging all the required components in a zip file together with a manifest describing how these components have to be rendered. As a result of this process where specifications have been applied, the content becomes more ‘interoperable’ and can be more easily exchanged and reused in learning platforms from different commercial vendors, or in open source learning (content) management systems,that comply with the relevant content packaging specifications.

Although the use of learning platforms is becoming common in most educational organizations, and the number of learning objects available online, for free or by subscription, is huge, most of these learning objects are not globally discoverable, which hampers their potential use and reuse. Improving access to these learning objects would have a significant impact on learning.

Over the last few years, IMS has produced specifications that make it easier to exchange and reuse general-purpose learning objects:

·         QTI

·         Common Cartridge

·         Content Packaging

·         Simple Sequencing

·         Learning Design

All of these specifications allow specific types of learning objects to be transferred between systems and reused but do not address the issue of how this content can be found. IMS has also produced specifications such as Learning Resource Metadata and VDEX that aid discovery by unifying the descriptions of this content. The missing piece in this collection of specifications is a protocol to support the discovery and exchange of all this interoperable content.

LODE is based on the following assumptions:

·         Learning objects are described by metadata such as IEEE LOM or Dublin Core.

·         Multiple metadata instances might be necessary in order to adequately describe all the aspect of a learning object (i.e., in order to provide the information necessary to support the LODE use cases).

·         Metadata can be gathered to create searchable catalogues of learning objects.

·         Consulting such metadata catalogues is the main way to obtain the information necessary to search for learning objects, assess their usefulness, and retrieve them.

·         Metadata catalogues are stored in repositories.

·         Repositories can be searched programmatically using a standard Application Programming Interface (API) such as the Simple Query Interface (SQI) or Search/Retrieve with URL (SRU).

·         Large catalogues can be created by harvesting (i.e., mirroring) metadata stored in repositories using protocols such as the Open Archives Initiative – Protocol for Metadata Harvesting (OAI-PMH).

IMS LODE can be seen as a glue specification that profiles existing general-purpose protocols in order to take into account requirements specific to the educational domain, rather than creating new protocols. It proposes three main data models:

 

Figure 1.1 - IMS LODE at work.

The diagram of Figure 1.1 illustrates how the IMS LODE specification can be combined with other specifications to permit to a LODE Client (i.e., a system that relies on the IMS LODE specification to discover and access learning objects) to actually obtain such learning objects.

Learning objects are described by metadata stored in repositories. The latter use different search and/or harvesting protocols (e.g., SQI, SPI, OAI-PMH) to expose metadata. In order to get access to this metadata, the first step is to discover the repositories in which it is stored.

The IMS LODE Registry Data Model provides a consistent way to describe repositories, their collections of learning objects and metadata, and the protocols they support. This enables the registration of repositories in a central registry that can be accessed by LODE clients. When consulting a LODE Registry, a LODE Client obtains repository descriptions that contain all the information needed to automatically connect to the repositories and get access to their metadata collections.

For those repositories that support search protocols such as SQI or SRU, the LODE Context Set for CQL (LODE CQL) enables LODE Clients to express queries in terms of learning object attributes.

Finally, whatever the protocol used by a LODE client to obtain metadata (search or harvesting), using LODE ILOX to organize the different metadata instances returned by this protocol ensures that all the information necessary to get access to learning objects is present and well-organized, without confusing the kinds of learning object described, and can be handled easily.

1.1       Scope and Context

The LODE activity in IMS is tasked with facilitating the discovery and retrieval of learning content stored in repositories. The “exchange” requirement centers on the fact that, while learning content repositories already cater for their local users, there are no agreed profiles that address the needs of the learning domain, and no established practices for combining existing specifications into complete solutions. Individual organizations are creating their own solutions, with quite different technical strategies, policy apparatus, and metadata schemes, and an opportunity to establish broader interoperability is being missed. There is also no way of measuring or testing the compatibility and conformance of specific solutions.

The following are considered in scope for the activity:

·         Search protocol, search query, and search results (i.e., metadata)

·         Metadata harvesting

·         Application of identifiers

·         Collection and service description

The following areas are considered out of scope of this activity:

·         Authentication, authorization, access (unless it is part of a specific protocol)

·         Digital Rights Management

·         Identity management

·         Metadata application profiling

Most stakeholders should benefit from agreed profiles and established practices that combine existing specifications into complete solutions addressing the needs of the learning domain for learning object discovery and exchange.

·         Educators will have an easy way to discover learning content that addresses the needs of their students, making their jobs easier, and maximizing re-use and minimizing the cost of re-invention of materials.

·         Students will have the benefit of access to the highest-quality learning resources available, making a significant impact on the quality of their learning experience and their learning outcomes.

·         Content providers will be able to advertise their products by making them globally discoverable.

·         System vendors will have a limited, well-defined set of specifications to support to make their systems compliant with major federations of learning resources.

·         Finally, federation builders will secure their investment by developing infrastructures based on standard specifications.

Interoperability will be demonstrated when a system (e.g., a LMS) end user is able to discover a compatible learning object (e.g., a common cartridge) hosted on a separate system (e.g., a learning object repository) using a LODE-compliant discovery service. Demonstrations will focus on federated discovery (through either federated search or harvest-driven centralized search), as these present the greater interoperability challenge. The federations should be based on LODE search and LODE registry specifications. However LODE does not require federation for compliance. “Federated” is used in a loose sense to refer to a group of distributed, independently managed and potentially heterogeneous repositories, whether or not any agreements, trust relationships etc. exist between them.

The IMS Global Learning Consortium has entered into a memorandum of understanding (MOU) with European Schoolnet to foster collaboration across Europe on the LODE specification in the framework of the European Commission funded ASPECT project. See the official announcement here: http://www.imsglobal.org/pressreleases/pr090212.html. Through this partnership, IMS GLC and European Schoolnet encourage the use of open standards and specifications for learning technology in schools throughout Europe.

1.2       Structure of this Document

The structure of this document is:

1. Introduction

Overview of the complete LODE information model

2. Use Cases

Use cases addressed by LODE information model

3. LODE Registry Data Model

Data model for description of collections of learning data objects

4. Information for Learning Object eXchange (ILOX) Data Model

Data model for structuring sets of learning object metadata

5. LODE Search Data Model

Data model for search query parameters for learning objects

Appendix: Use Cases (Full)

Full details of use cases addressed by LODE information model

 

1.3       Nomenclature

API                         Application Programming Interface

a-API                     Abstract Application Programming Interface

IAF                         IMS/GLC Abstract Framework

IMS GLC              IMS Global Learning Consortium Inc.

LODE                     Learning Object Discovery & Exchange

LOM                      Learning Object Metadata

OAI-PMH             Open Archives Initiative – Protocol for Metadata Harvesting

PIM                        Platform Independent Model

PMS                       Person Management Service

PSM                       Platform Specific Model

RFC                        Request For Comment

SDN                        Specification Development Note

SQI                         Simple Query Interface

SRU                        Search/Retrieve via URL

UML                      Unified Modelling Language

URI                        Uniform Resource Identifier

URL                       Uniform Resource Locator

WSDL                    Web Services Description Language

 

1.4       References

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

[APG, 05b]            IMS GLC Application Profile Guidelines White Paper: Part 2 Technical Manual, S.Wilson and K.Riley, Version 1.0, IMS Global Learning Consortium, October 2005. http://www.imsglobal.org/ap/index.html.

[ASP, 09]               Design of Data Model and Architecture for a Registry of Learning Object Repositories and Application Profiles, D. Massart, N. Smith & R. Tice, ASPECT Project, March 2009. http://aspect.eun.org/sites/default/files/docs/ASPECT_D2p2.pdf

[CANCORE, 04]  CanCore Guidelines for the Implementation of Learning Object Metadata (IEEE 1484.12.1-2002), N. Friesen, S. Fisher, & A. Roberts, April 2004. http://www.cancore.ca/en/guidelines.html

[CCR, 08]              Creative Commons Rights Expression Language, H. Abelson, B, Adida, M. Kinsvayer & N. Yergler, March 2008. http://wiki.creativecommons.org/CcREL

[CQL, 08]              CQL: Contextual Query Language (SRU Version 1.2 Specifications), Library of Congress. http://www.loc.gov/standards/sru/specs/cql.html

[CQLBIB, 09]      CQL Profile for Bibliographic Searching, Library of Congress. Version 1.0. July 2009.   http://www.loc.gov/standards/sru/resources/cql-bibliographic-profile.html

[DCCAP, 07]        Dublin core collections application profile, Dublin Core Collection Description Task Group, March 2007. http://dublincore.org/groups/collections/collection-application-profile/

[DCME, 08]          Dublin Core Metadata Element Set, Dublin Core Metadata Initiative, Version 1.1, January 2008. http://dublincore.org/documents/dces/

[FRBR, 98]           Functional Requirements for Bibliographic Records: Final Report, IFLA Study Group on the Functional Requirements for Bibliographic Records, 1998. http://archive.ifla.org/VII/s13/frbr/

 [GWS, 05]            IMS GLC General Web Services WSDL Binding Guidelines v1.0 Final Specification, C.Schroeder, J.Smon and C.Smythe, IMS Global Learning Consortium, December 2005.

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

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

[IAF, 03c]              IMS GLC Abstract Framework: White Paper v1.0, Ed. C.Smythe, IMS Global Learning Consortium, July 2003.

[IANA, 07]            MIME Media Types, IANA, March 2007. http://www.iana.org/assignments/media-types/

[ISO, 05]                Information technology—Learning, education and training -- Quality management, assurance and metrics—Part 1: General approach. JTC 1/SC 36. http://www.iso.org/iso/catalogue_detail?csnumber=33934

[ISO, 09]                Information and documentation—Registry Services for Libraries and Related Organisations. ISO TC 46/SC 4. http://www.iso.org/iso/catalogue_detail.htm?csnumber=44936

[ISO8601, 04]      Data elements and interchange formats—Information interchange—Representation of dates and times. ISO 8601:2004. International Organization for Standardization. December 2004. http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetch&nodeid=4021199

[LOC, 08]              ISO 639-2 Registration Authority , Library of Congress, 2008. http://www.loc.gov/standards/iso639-2/

[LODE, 07]           Charter for IMS Learning Object Discovery and Exchange (LODE), D. Massart, M. Morrey, C. Smythe, IMS Global Learning Consortium, 2007. Online version: http://members.imsglobal.org/forum/ims/dispatch.cgi/f.federatedar/showFile/100146/d20071009182840/Yes/lodeCharter.pdf

[LOM, 02]             Standard for Information Technology—Education and Training Systems—Learning Objects and Metadata, W. Hodgins et al., IEEE Learning technology Standards Committee, December 2002. http://ltsc.ieee.org/wg12/materials.html

[MARC, 03]          Source Codes for Classification, Library of Congress, Network Development and MARC Standards Office, August 2003. http://www.loc.gov/marc/sourcecode/classification/classificationsource.html

[MATER, 94]       Materialization: a powerful and ubiquitous abstraction pattern, A. Pirotte, E. Zimányi, D. Massart, and T. Yakusheva. In J. Bocca, M. Jarke, and C. Zaniolo, editors, Proc. of the 20th Int. Conf. on Very Large Data Bases, VLDB’94, pages 630–641, Santiago, Chile, 1994. Morgan Kaufmann.

[MYLOPOULOS, 98] Information modeling in the time of the revolution, J. Mylopoulos,  Information Systems, 23(3– 4):127–155, 1998.

[NSDL, 07]            Metadata Guidelines: Access Rights, The National Science Digital Library, October 2007. http://nsdl.org/collection/accessRights.php

[OAI, 04]               The open archives initiative protocol for metadata harvesting version 2.0, Document Version 2004/10/12T15:31:00Z, C. Lagoze, H. Van de Sompel, M. Nelson, & S. Warner. Also available as http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm, 2002.

[PRI, 09]                Publishing Requirements for Industry Standard Metadata, IDEAlliance, May 2009. http://www.prismstandard.org

[RDCEO, 02]        IMS Reusable Definition of Competency or Educational Objective—Information Model, IMS Global Learning Consortium, October 2002. http://www.imsglobal.org/competencies/rdceov1p0/imsrdceo_infov1p0.html

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

[SDN11, 06]          IMS GLC Specification Note 11: Vocabulary Definition, Registration & Maintenance Procedures, C.Smythe, IMS Global Learning Consortium, October 2006.

[SIL, 09]                ISO 639-3 Registration Authority , SIL International, 2009. http://www.sil.org/iso639-3/

[SPI, 08]                A simple publishing interface for learning object repositories, S. Ternier, D. Massart, F. Van Assche, N. Smith, B. Simon, & E. Duval. Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2008 (Vienna, Austria), AACE, June 2008, pp. 1840–1845. http://www.editlib.org/p/28625

[SQI, 05]               A simple query interface specification for learning repositories, CEN Workshop Agreement (CWA 15454). B. Simon, D. Massart, F. Van Assche, S. Ternier, & E. Duval. Also available from ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/WS-LT/CWA15454-00-2005-Nov.pdf, November 2005.

[SRU, 08]              SRU Version 1.2 Specifications, Library of Congress. http://www.loc.gov/standards/sru

[SWO, 08]             SWORD: Simple Web-service Offering Repository Deposit,J. Allinson, S. François & S. Lewis. Ariadne 54, January 2008. http://www.ariadne.ac.uk/issue54/allinson-et-al/

[VCARD, 98]       vCard MIME Directory Profile, F. Dawson & T. Howes, Internet Engineering Task Force., RFC 2426. http://tools.ietf.org/html/rfc2426

[VDEX, 04]           IMS Vocabulary Definition Exchange Best Practice and Implementation Guide, Version 1.0 Final Specification, A. Cooper, IMS Global Learning Consortium, 2005. Online version:  http://www.imsglobal.org/vdex/vdexv1p0/imsvdex_bestv1p0.html

[W3C, 06]             Web Services Policy 1.5—Primer, W3C Web Services Policy Working Group, October 2006. http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/

[XML, 04]             XML Schema Part 2: Datatypes Second Edition,World Wide Web Consortium, October 2004. http://www.w3.org/TR/xmlschema-2/  

2         Use Cases

The IMS LODE specification consists of 3 main data models:

  1. The IMS LODE Information for Learning Object eXchange (ILOX) data model,
  2. The IMS LODE Registry data model (Registry), and
  3. The IMS LODE Search data model (CQL).

Each of these data models addresses different use cases. The mind map of Figure 2.1 recaps all the use cases that were considered within the scope of the IMS LODE specifications. Each category of use cases is followed by the identifiers of the use cases belonging to this category. The data model addressing these use cases is indicated between parentheses. The complete list of use cases considered during the chartering of the LODE activity [LODE, 07] are listed in Table XX, ordered by use case identifier. Use cases out of scope have been kept for completeness (they are struck through to avoid confusion). The uses cases themselves are given in full in the Appendix.

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:

The Registry data model permits discovery of learning object repositories based on the properties of the learning object and metadata collections managed by these repositories, and on the protocols supported by these repositories to expose their collections. The registry data model provides enough information to allow automated configuration of search and harvest clients wishing to access a repository.

Finally, the search data model permits expressing the various queries covered by the query expression use cases.

3         LODE Registry Data Model

3.1       Introduction to the Registry Data Model

3.1.1           LODE Registry Data Model Overview

The Learning Object Discovery & Exchange (LODE) Learning Object Registry Data Model provides a scheme of describing collections of learning data objects, the persons responsible for those collections, and the available mechanisms for interacting with those collections.

Descriptions following this model are intended to facilitate exchange of learning content between different collections. The model provides a consistent framework, independent of local registry configuration, for:

3.1.2           Scope and Context

In order to access collections within repositories, the participants need a common metadata description of their respective collections, including who is responsible for the collections (and will be involved in negotiating the exchange of learning content), how to establish access to the collections, and what are the constraints on access to the collections. Having such metadata in machine-readable form allows content exchange to be substantially automated. This model provides a framework for such metadata.

LODE has emphasized reuse of existing specifications related to digital libraries, generic repositories, and learning repositories. To that end, the framework described here is substantially based on the ISO 2146 model for registry description [ISO, 09], which offers a generic model for registries of content, not bound to any particular protocol or platform. (The ISO 2146 model is not specific to machine readable collections.)  The framework outlined uses the ASPECT project’s profile of the ISO 2146 model in its own description of learning content registries [ASP, 09]. ASPECT has already successfully tested this framework, aggregating disparate e-learning collections in the European Union.

The LODE registry framework makes it possible for collections to form federations of learning content registries, both on a formal and an ad hoc basis. The common metadata for collection description and access reduces the barriers to content exchange across a federation, and enables ad hoc federation. This broadens the range of learning content that federation members have access to, and promotes content reuse.

 

3.2       Definitions: Core Entities

A learning object is anything (usually a digital object) that can be used for teaching or learning. Learning objects can range from simple learning assets (for example, an image that can be used to illustrate a lesson), to complex learning resources, such as a complex multi-media course with multiple components.

Learning objects are described by metadata in a machine-readable format. Metadata makes learning objects easier to find and to access. Metadata are themselves digital objects.

A well-managed grouping of objects is a collection. Collections are managed to conform to a common set of policies, which include policies on access and on what can be included in the collection. The objects in a collection usually have common subject matter, purpose, and provenance. In e-learning, this takes the form of:

·    subject matter: what courses may be supported by the learning objects in the collection (e.g. secondary school mathematics)

·    purpose: support for a particular cohort of learners (e.g. students in public schools in Wales)

·    provenance: authoring or dissemination from a particular institution (e.g. an education ministry, or a content vendor)

Collections may be content collections, i.e. collections of learning objects and their associated metadata. They may also be metadata collections, containing only metadata descriptions of learning content objects; those learning content objects themselves may be available in different collections. A metadata collection may be restricted to learning objects in particular content collections. The metadata in a metadata collection may be distinct from the metadata accompanying an item in a content collection; for example the metadata collection may include third-party reviews of the content collection items.

Collections may include other collections, or may be derived from other collections. These relations are constrained to the same type of collection: metadata collections cannot include or be included by content collections, and cannot derive or be derived from content collections.

Learning object repositories are specialized software systems used to manage collections. A repository need not be coterminous with a collection: a collection may be spread out over several repositories, and a repository may host multiple collections.

Partiesinteract with collections, in order to realize particular activities. Parties include both the end users of the collections (consumers), and those responsible for making the collections available (providers). Providers include the parties who generate the collection items; the parties who maintain the repository software system; and the parties who manage the collection as a whole. The latter responsibility includes contributing metadata, procuring content, performing quality control on content, and setting and enforcing collection policies.

Repositories support services allowing parties to access items in the collections they host. Users, including both humans and machines, interact with services through targets, which are the network addresses of the services (service endpoints). Those services follow one or more protocols, and are subject to access policies on who may use the services, and when. Services of interest in the e-learning domain include: the Open Archive Initiative Protocol for Metadata Harvesting  (OAI-PMH) [OAI, 04], the Simple Query Interface (SQI) [SQI, 05], Search/Retrieval via URL(SRU) [SRU, 08], and the Simple Publishing Interface (SPI) [SPI, 08].

Under the ISO 2146 model [ISO, 09], a registry is an aggregation of collections, parties, services and activities which together support the business of a given community. Our use of repository above corresponds to the ISO 2146 use of “registry”. ISO models the relation between registry objects as follows.

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

3.3.1           Federation

A federation is a grouping of repositories, which allow their users to access content from any participating repository. A federation has infrastructure to enable such access, which takes the form of a central registry of the participating repositories. The collection descriptions outlined here support federation through descriptions of the participating repositories. The descriptions are framed in terms of the collections that the repositories publish; those descriptions can be stored and added to in the central registry.

There are two models of federation, depending on how content in the repositories is discovered. Under federated search, requests for discovery of items are carried out separately on each participating repository: the results are aggregated by a search tool and presented to the user as they become available. Because the requests are separate for each repository, and the registry’s role is only to aggregate search results, repositories can remain autonomous in their policy and even their metadata profiles: the searches can be transformed as required by the central registry hub into a consistent format.

Under centralized search, searchable descriptions of items are copied from participating repositories into a central repository. This is typically realized through harvesting; it can also be achieved if indexes from participating repositories are periodically imported into the central repository, or if a push protocol such as SPI [SQI, 05] or SWORD [SWO, 08] is used by participating repositories to initiate the copying. Requests for discovery of items are carried out on the central repository, which mediates user access to federation content.

The LODE registry model supports both types of repository federation. The federated search model assumes that search will be the main service for interacting with participating repositories; the centralized search model assumes it is harvest or push. Either type of interaction can be documented through the service descriptions included in the collection descriptions; and those service descriptions can be used to configure federations automatically.

The two types of federation motivate the use of collection descriptions. The metadata about the collections themselves can be used in the processes described, to narrow the range of repositories over which discovery is attempted.

3.3.2           Collection Discovery

Outside federation, the other use case motivating the collection descriptions is collection discovery in its own right, without being coupled directly to item discovery. Collection descriptions make collections discoverable: they allow users to identify relevant collections in e-learning, and the parties responsible for arranging access to those collections. In the absence of a federation structure, the actual access needs to be arranged off-band, on a one-on-one basis. The descriptions also allow users to navigate the references of collections to other collections, either through description (metadata collection describes content collection), or inclusion (collection contains collection).

If the collections being described are open access, ad hoc federations can be put together, enabling content discovery across a range of repositories without explicit negotiation. However, discovery across those repositories is constrained to the extent that they use the same metadata for describing their items.

Machine readable collection descriptions also allow collections to be discovered automatically by a registry, so long as the collections are available in a location the registry is already aware of. While this still presupposes some negotiation, such dynamic discovery of collections allows registries to be more flexible in the range of federations they can support.

3.4       Data Types

The model uses the following data types from IEEE LOM [LOM, 02]:

Many properties of collections are derived from the properties of their items (e.g. subject, purpose). Because collections are not homogeneous, such collection properties often only apply to a subset of all items. To reflect this, this model uses the Property data type, which allows for relative strengths of properties in a collection. A Property type has a Source and Value, with the same meaning as for VocabularyTerm, and a Strength quantifier, which can take one of the values “some”, “most”, and “all”: this means that the property applies to some, most, or all of the items in the collection. The quantifier is optional, and the assumed default value is “some”.

The model also uses Integer and anyURI, both with their accepted meaning in XMLSchema. [XML, 04]

3.5       UML Diagram

The following UML diagram summarizes the overall realization of the model; refer to the XML Binding of the model for further information. The semantics of the model is discussed below.

LODE Registry Binding

Figure 3.3 - LODE Registry class diagram.

3.6       Collection Attributes

Collections are modelled using the Dublin Core Collections Application Profile (DCCAP) [DCCAP, 07] with contributions from ISO 2146 and IEEE LOM.

While content collections and metadata collections are both collections, their attributes are modelled differently, to account for contextual differences between the two.

3.6.1           Content Collection

The following attributes describe content collections as a whole:

Identifier

An identifier of the content collection.

Identifier

Mandatory

Description

A description of the collection.

LangString

Mandatory

Collection Rights

A description of the rights that apply to the collection as a whole.

LangString

Optional

Keywords

A list of keywords for describing the collection as a whole.

LangString

Optional

Average Annual Increase

The average annual increase in the number of learning objects in the collection. This can be a negative number.

Integer

Optional

Accrual Periodicity

An attribute using a controlled vocabulary from DCCAP [DCCAP, 07] to describe how often new learning objects are added to (or removed from) the collection.

VocabularyTerm

Optional

 

The following attributes describe collection-level properties of the items (i.e., learning objects) in a content collection. For that reason, they all have the Property data type. Because of the potentially incomplete coverage of any one collection-level property, all collection-level properties can occur zero or more times. For instance, a collection may contain items in seven different languages, in which case it has seven different Language properties, each of which may have its own Strength attribute.

Quality Procedure

The quality procedure(s) applied to the items in the collection.

Property

Optional

Subject

The subject(s) covered by the learning objects in the collection.

Property

Optional

Language

The language(s) of the learning objects in the collection.

Property

Optional

Type

The learning resource type(s) (cf. LOM 5.2) of the learning objects in the collection. For example: “assessment”.

Property

Optional

Representation

The representation(s) in which the learning objects in the collection are available. For example: “QTIv2.1”.

Property

Optional

Format

The technical format(s) of the learning objects in the collection. For example: “application/swf”.

Property

Optional

Intended User Role

The intended role(s) of the user of the learning objects in the collection.

Property

Optional

Context

The context(s) of use of the learning objects in the collection.

Property

Optional

Typical Age Range

The age range(s) of the typical users of the learning objects in the collection.

Property

Optional

Item Rights

The rights that apply to the learning objects in the collection. This is independent of Collection-level Rights, which govern access to collection metadata.

Property

Optional

Cost

Do the learning objects in the collection havea cost?

Property

Optional

 

3.6.2           Metadata Collection

The following attributes are used to describe a metadata collection as a whole:

Identifier

An identifier of the metadata collection.

Identifier

Mandatory

Description

A description of the metadata collection.

LangString

Mandatory

Collection Rights

A description of the rights that apply to the metadata collection as a whole.

LangString

Optional

Keywords

A list of keywords for describing the collection as a whole.

LangString

Optional

Average Annual Increase

The average annual increase in the number of metadata instances in the collection. This can be a negative number.

Integer

Optional

Accrual Periodicity

An attribute using a controlled vocabulary from DCCAP [DCCAP, 07] to describe how often metadata instances are added to (or removed from) the collection.

VocabularyTerm

Optional

 

The following attributes describe properties of the metadata instances that compose the collection:

Quality Procedure

The quality procedure(s) applied to the metadata in the collection.

Property

Optional

Language

The language(s) of the metadata in the collection.

Property

Optional

Format

The format(s) of the metadata in the collection. For example: “IEEE LOM XML binding”.

Property

Optional

Item Rights

The rights that apply to the metadata in the collection.

Property

Optional

 

3.6.3           Party

Parties are modeled as a combination of a Responsibility and Contact Details. Parties are responsible for collections or service targets. The following attributes describe parties:

Responsibility

The responsibility the party has with regard to the collection or target. E.g. “administrative contact”, “technical contact”.

VocabularyTerm

Mandatory

Contact Details

A VCARD [VCARD, 98] description of the party.

CharacterString

Mandatory

 

3.7       Service Attributes

3.7.1           Target

Targets serve as end-points for services offered by repositories to access collections. They are described with the following attributes:

Target Identifier

A unique identifier of the target.

Identifier

Mandatory

Protocol Identifier

The identifier of the protocol supported by the target.

Identifier

Mandatory

Location

The location of the target.

URI

Optional

<extension>

An XML description of the protocol parameters supported by the target end-point. This description is a valid instance of the XSD referenced at the Protocol Description Binding Location of the protocol identified by the <Protocol Identifier>.  (See Section 3.7.2)

XML

Mandatory

 

3.7.2           Protocol Implementation Description

This is a description of the properties of a specific implementation of the protocol, supported by the target. This description should provide all information necessary to configure a client to access the given target. The description is specific to the protocol, and the implementation description should be a valid instance of the XSD referred to in the “Protocol Description Binding Location” attribute of the corresponding protocol. Choices made in implementation of the protocol, such as asynchronous vs. synchronous SQI, choice of query language, and so forth should also be explicit in the Protocol Implementation Description.

3.7.3           Protocol

The protocol describes the service interface for interacting with the target. One or more targets can have the same protocol. The protocol description must include a pointer to a protocol implementation description.  Protocols are described with the following attributes:

Identifier

A unique identifier of the protocol.

Identifier

Mandatory

Name

The name of the protocol. For example, “Simple Query Interface”.

CharacterString

Mandatory

Version

The version of the protocol. For example, “1.0”.

CharacterString

Optional

Protocol Description Binding Name Space

The namespace of an XSD used to describe a particular implementation of the protocol.

URI

Mandatory

Protocol Description Binding Location

The location of this XSD.

URI

Mandatory

 

3.7.4           Access Policy

Access policies are described with two attributes:

Identifier

A unique identifier of the policy.

Identifier

Mandatory

Description

A description of the access policy.

LangString

Mandatory

 

3.8       Relations

Content and metadata collections are associated with one or more targets. The relation is navigable in both directions.

A target is associated with a unique access policy, though an access policy may apply to several targets.

A target contains a unique protocol implementation description, since a target is defined to be accessed through only one protocol. (A distinct protocol means a distinct target.)

A collection may contain or be contained by zero or more collections of the same type (metadata to metadata, content to content). The relation is navigable in both directions.

A content collection may be described by zero or more metadata collections, and a metadata collection may describe zero or more content collections. The relation is navigable in both directions.

For all the relations given above, the referring object may refer to the related object by value, embedding the description of the related object in its own description. Alternatively the referring object may refer to the related object by reference, supplying the identifier of the related object. For example: a target may identify its access policy by value, meaning it includes the access policy description in the target description. On the other hand, the target may only identify its access policy by reference, supplying the identifier for the policy. Identification by reference presupposes that the identifier can be dereferenced by users.

 


3.9       Profiling and Extending

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

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 3rd 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 3rd 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

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:

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

“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.

SimpleMaterLO.png

 

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 IMS Content Package and an IMS Common Cartridge. Each of these different embodiments of an expression of a work is referred to as a FRBR “manifestation”. Finally, copies of the IMS 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.

 

FromLO2Files3.png

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

 

FRBR_lo_line.png

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

4.3       ILOX: General Principles

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

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

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:

4.6       Manifestation

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

IMS Content Packaging Version 1.0

imscp_v1p1

IMS Content Packaging Version 1.1

imscp_v1p1p1

IMS Content Packaging Version 1.1.1

imscp_v1p1p2

IMS Content Packaging Version 1.1.2

imscp_v1p1p3

IMS Content Packaging Version 1.1.3

imscp_v1p1p4

IMS Content Packaging Version 1.1.4

imscc_v1p0

IMS Common Cartridge Version 1.0

imscc_v1p1

IMS 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

IMS Question & Test Interoperability Version 1.2 Lite

imsqti_v1p2

IMS Question & Test Interoperability Version 1.2

imsqti_v1p2p1

IMS Question & Test Interoperability Version 1.2.1

imsqti_v2p0

IMS Question & Test Interoperability Version 2.0

imsqti_v2p1

IMS Question & Test Interoperability Version 2.1

4.7       Item

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

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

IMS 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

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

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 IMS 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 (IMS 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., IMS 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

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.

IMS Global 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 cou