IMS Digital Repositories Interoperability - Core Functions Information Model
Version 1.0 Final Specification
Copyright © 2003 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Digital Repositories Interoperability - Core Functions Information Model
Revision: 13 January 2003
IPR and Distribution Notices
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 any implementation of the specification set forth in this document, and to provide supporting documentation.
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.
Copyright © 2003 IMS Global Learning Consortium. All Rights Reserved.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.
THIS SPECIFICATION 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.
2. Functional Architecture
3. Reference Model
3.1.1 Recommendations for Query Language
3.2.1 Recommendations for "Pull" Gather
3.2.2 Recommendations for "Push" Gather
3.5.1 Exclusions from Scope
3.5.2 Request/Deliver Mechanism
4. General Messaging Model
4.1 Open Issues
5. High Level Overview of Use Cases for a Learning Repository
5.2 Use Cases
5.2.1 Create and Modify Resources
5.2.2 Discover Resources
5.2.3 Notification of Modification of Resources
About This Document
List of Contributors
This document constitutes the Information Model for Phase 1 of the IMS Digital Repositories Interoperability (DRI) Specification. The purpose of this specification is to provide recommendations for the interoperation of the most common repository functions. These recommendations should be implementable across services to enable them to present a common interface. This specification is intended to utilize schemas already defined elsewhere (e.g., IMS Meta-Data and Content Packaging), rather than attempt to introduce any new schema.
On the broadest level, this specification defines digital repositories as being any collection of resources that are accessible via a network without prior knowledge of the structure of the collection. Repositories may hold actual assets or the meta-data that describe assets. The assets and their meta-data do not need to be held in the same repository.
This document begins by describing the scope that the IMS DRI Project Group agreed upon for Phase 1 of the specification. Section 2 specifies the core functional interactions between the Mediation and Provision layers of the DRI Functional Architecture. These core functions are:
This specification acknowledges that a wide range of content formats, implemented systems, technologies, and established practices already exist in the area of digital repositories. Consequently, its recommendations consistently acknowledge two generalized implementation scenarios, or two different repository types:
- Systems reflecting established practice (e.g., that utilize Z39.50) for repository interoperability.
- Repositories that are able to implement the XQuery and SOAP-based recommendations as put forward in this specification.
The second repository type or scenario defines repository interoperability very specifically in terms of the full implementation of the core functions and functional architecture, as outlined in this specification. In concise terms, it is an implementation of a collection of resources capable of exposing meta-data to resource utilizers for the purposes of searching, gathering, storing, and delivering assets.
- A user searching a repository directly.
- A user conducting a search across repositories via a Search Gateway intermediary (acting as a translator).
- A user conducting a search across repositories via a Harvest intermediary (acting as an aggregator).
While Z39.50 is assumed for searching systems such as digital libraries, XQuery is recommended as the preferred query mechanism for XML-based learning object repositories. SOAP with attachments is proposed as the protocol for messaging associated with core function implementation.
The diagram in Figure 2.1 below depicts the DRI functional architecture. The interactions are shown by the red (solid) lines. The diagram maps out three entity types that define the space where e-learning, digital repositories, and Information Services interact, and which provide a context for exploration of the problem space.
- Roles (e.g., Learner, Creator, Infoseeker, Agent)
- Functional Components for Resource Utilizers, Repositories, Access Management, and Procurement Services
- Services, such as Registries and Directories (not part of the DRI Phase 1 scope)
The diagram in Figure 3.1 provides a simplified systems view of the digital repository domain with the components embodying the core functions identified in Figure 2.2. There are two types of repositories represented in Figure 3.1:
- Systems reflecting established practice (e.g., utilizing Z39.50) for repository interoperability.
- Repositories that are able to implement the XQuery and SOAP-based recommendations, as put forward in this specification.
Section 2 (Functional Architecture) described four roles played by users of a digital repository: Creator, Learner, Infoseeker, and Agent. Figure 3.1 illustrates users playing the first three of these roles and the typical software applications with which they interact. The Agent, LMS, LCMS, and Search Portal applications play the role of Access Components.
The goal of this specification is to enable widespread access to content in repositories of both types in the context of e-learning by applications such as Learning Management Systems (LMS), Learning Content Management Systems (LCMS), and Search Portals (e.g., in library search systems) as shown in the reference model in Figure 3.1. These software applications are used as common examples from the e-learning industry and there may be other applications.
Finding content, when there are multiple repositories of content to be searched, is a complex problem. The problem is further aggravated when the repositories have heterogeneous representations of meta-data and heterogeneous access methods. The reference model introduces an optional intermediary component which can fulfill one of three functions that simplify this problem:
- A Translator function is able to translate one search format into another and is understood by multiple IMS and existing repositories.
- An Aggregator function that gathers IMS and/or other meta-data from multiple repositories and makes this meta-data available for searching.
- A Federator function that passes a search query to multiple repositories and manages the responses.
There are two dominant characteristics of the Search reference model. First, it supports a diverse range of configurations for conducting search. These will offer both broad technology-based and community-focused experiences for searching the digital content universe. Second, it provides an optional mediation layer to allow the querying of distributed, heterogeneous meta-data sources.
- XQuery for searching IMS (XML) meta-data format. XQuery is being developed by a W3C working group. It has a well-developed grammar, and several commercial implementations are emerging from the community. Its strengths are query-by-example and structured searches of XML documents and repositories containing IMS meta-data. The most recent working drafts of the specification are dated November 2002.
- Z39.50 for searching library information. This search provides a grammar for searching Z39.50 repositories either directly or through an intermediate search engine.
- RPC (known arguments to well-known methods)
- Messaging (generic arguments to well-known methods)
- Session (generic arguments with context)
The Gather reference model defines the soliciting of meta-data exposed by repositories and the aggregation of the meta-data for use in subsequent searches, and the aggregations of the meta-data to create a new meta-data repository. The aggregated repository becomes another repository available for Search/Expose Alert/Expose functions. The reference model is represented in Figure 3.3 below.
The Gather component may interact with repositories in one of two ways. It either actively solicits meta-data (newly created, updated, or deleted) from a repository (pull), or subscribes to a meta-data notification service (newly created, updated, or deleted) provided by the repository or by an adapter external to a repository that enables messaging between the repository and other users (push).
The Open Archive Initiative (OAI) provides a simple model for Pull Gather. OAI meta-data aggregators perform a periodic search of target repositories and retrieve meta-data based on a range of dates. Date is the primary criterion used in this model and it requires a meta-data element that contains the date on which the meta-data was added or updated. Qualification by sets is also possible. This has the advantage of being very simple and can be effective in providing completeness in harvesting meta-data.
It is expected that the OAI model will be sufficient for the IMS repositories context. OAI mandates that repositories supply Dublin Core as a minimal lingua franca for OAI compliance, but repositories are free to support any additional XML meta-data format, such as MARC XML or ONIX.
To use the OAI model in the IMS context, an element within the IMS Meta-Data Specification will have to be defined to provide the date information required to allow the Gather Engine to determine which meta-data has been added or updated since the last time the spider harvested from that repository. Note that the Gather Engine is responsible for keeping the date information stating when it last harvested from a particular repository. There are issues with the OAI model working with meta-data structures that do not contain the required date element.
OAI currently uses XML messages over HTTP. OAI Protocol 1.1 Documentation is available at: http://www.openarchives.org/OAI/openarchivesprotocol.html
Another option for Pull Gather is to periodically gather all meta-data records from all target repositories. This ranks very high on completeness, but is an inefficient utilization of resources as potentially millions of records would repeatedly be pulled over the network.
Push Gather is a special, basic case of Alert. Whenever a new meta-data record is added or updated, repositories could send an alert to subscribing aggregators. This could be a simple message saying that new meta-data exists at this repository, or could be the complete meta-data, which could then be incorporated into the meta-data repository and would then be available for search.
The mechanism for Push Gather could also be provided by an adapter external to a particular repository. This adapter could forward meta-data to the intermediate aggregators simultaneously as new content is added to the repository. This adapter could also manage message translation between the network and the repository's native capabilities.
The DRI Project Group regards the Alert function as a possible component of a digital repository or an intermediary aggregator service and envisions that e-mail/SMTP (Simple Mail Transfer Protocol) could provide this functionality. However, the Alert function is regarded as out of scope for Phase 1 of the DRI specification. For more detail about how the Alert function might work, see the Appendix in the DRI Best Practice Guide.
Submit/Store functionality refers to the way an object is moved to a repository from a given network-accessible location, and how the object will then be represented in that repository for access. The location from which an object is moved can be another repository, a learning management system, a developer's hard-drive, or any other networked location. It is anticipated that existing repository systems may already have established means for achieving Submit/Store functions (typically FTP). This specification provides no particular recommendations for legacy repository systems, but wishes to draw attention to the following weaknesses of FTP as a transport mechanism for learning objects or other assets:
- Plain FTP provides no encryption capabilities, making it unsuitable for the transport of copyright controlled assets.
- Providing FTP server access to a networked location presents widely-recognized security risks.
- FTP does not provide means of confirming the successful delivery of assets from one networked location to another.
In the case of more recently developed repositories that deal specifically with learning objects, this specification makes significant reference to the IMS Content Packaging Specification. The Content Packaging Specification defines "interoperability between systems that wish to import, export, aggregate, and disaggregate packages of content." A Content Package comprises a compressed file package (preferably a zip file) that contains the learning object, its meta-data record, and a manifest describing the contents of the package.
In the case of a learning object repository that is compliant with the DRI specification, the Submit function shall be satisfied through the transmission of an IMS-compliant Content Package using SOAP Messages with attachments. SOAP with attachments refers to a W3C specification that "defines a binding for a SOAP 1.1 message" in such a way that the "MIME multipart mechanism for encapsulation of compound documents can be used to bundle entities related to the SOAP 1.1 message such as attachments." In the case of the Submit function, these attachments shall take the form of one or more IMS-compliant Content Packages.
The Request functional component allows a resource utilizer that has located a meta-data record via the Search (and possibly via the Alert) function to request access to the learning object or other resource described by the meta-data. Deliver refers to the response from the repository which provides access to the resource.
In a hybrid environment, the resources discovered via a cross-domain search potentially include resources that are not learning objects and/or are not available online. Version 1.0 of the DRI Specification deals only with the case of requesting and delivering online resources from object repositories.
Digital Rights Management, including verification that the resource utilizer is authorized to access a resource, and resolution of an object identifier to locate the most appropriate copy are not covered here. These functions are carried out within the functional model by the Access Management Service. Recommendations on location services and technologies, including DOIs and OpenURLs, are included in the DRI Best Practice Guide.
The starting point for the Request/Deliver function is a pointer to a location of a resource. If the meta-data record has been located via the Search function on IMS-compliant meta-data, then this pointer will be contained in element 4.3 <location> of the meta-data record. If the resource utilizer is not authorized to access the resource, then the access management services should prevent access to the resource. Implementation of Access Management / Rights Management services are outside the scope of specification. Implementation mechanisms may include blocking the presentation of the <location> data element to the user or refusing access to the resource on receipt of the Request.
The meta-data element may consist of a list of locations or a method which resolves to a location or list of locations. The latter may be a DOI or an OpenURL. The resolver functional component is responsible for returning the list of locations. The location returned should resolve to a URL. Linking to this URL shall initiate the Request. The protocol used to Deliver the learning object will vary depending on the format of the object but will include:
The Messaging model is used to provide general communication between the components defined by the DRI Information Model. The basic messaging model is stateless, consisting of a single request message from source to destination followed by a single response message from destination to source. Additional messaging models may be supported in the future.
message header body
header message type destination address message authentication
body payload(s) audit element(s)
'Audit' elements allow the addition of relevant audit information to any message. This could include information relating to payment, usage, performance, and so on. 'Audit' elements typically accumulate as a message moves through the system. In particular, when a response is returned, it includes all the 'audit' elements from the corresponding request.
Excepting the message-level authentication identified in the message header element described above, no explicit security mechanism is identified in the current model. Some level of message-level security may be provided externally to the basic message itself. For instance, HTTPS may be used to provide message encryption when HTTP is used as a transport binding (see the Messaging section in the DRI XML Binding).
The following DRI use cases describe scenarios where certain actors assume specific roles within a learning repository. Before exploring the use cases, carefully read the section below on actors to better understand the roles that these actors assume.
1. Creator Roles 1.1 Single Repository Use Cases
Actor 1: Training course creator in a corporate setting (perhaps a defense contractor or pharmaceutical company) who is using a single repository to develop courses or reference materials related to a particular product for use in either in-house training materials or for training materials for customers.
1.2 Multiple Repositories Use Cases
Actor 2: Someone working in a publishing company context where there are several different subsidiary publishing arms and the person is trying to pull materials from the different subsidiaries' repositories to develop new cross-disciplinary materials to sell.
2. Learner Roles 2.1 Single Repository Use Cases
Actor 3: Employee or customer in a corporate setting who is using the single repository to find a training course or reference materials needed to raise the individual's competency with respect to a particular product.
Actor 4: Training coordinator in a corporate setting who associates competencies with the courses or learning objects in a repository.
2.2 Multiple Repositories Use Cases
Actor 5: Someone who has purchased the cross-disciplinary training material created by Actor 2 and would like to receive periodic updates to the training material whenever the publishing company changes the material.
3. Infoseeker Roles 3.1 Single Repository Use Cases
Actor 6: Employee who is searching via a portal for information related to a particular subject.
3.2 Multiple Repositories Use Cases
Actor 7: Someone who is searching for information related to a subject that may be contained in multiple repositories.
|Use Case 1||Creator authors a course and submits it to a repository|
|Primary Actor||Actor 1 or 2|
to the repository.
requests a discovered resource.
populates its own repository.
|Use Case 7|
|Primary Actor||Actor 1, 3, 4, or 6|
|Preconditions||User is part of the community of subscribers to the learning repository|
to the meta-data in a repository.
to the meta-data in multiple repositories.
|Title||IMS Digital Repositories Interoperability - Core Functions Information Model|
|Editors||Kevin Riley (IMS), Mark McKell (IMS)|
|Team Co-Lead||Jon Mason (IMS Australia - DEST)|
|Version Date||13 January 2003|
|Summary||This document describes the Information Model for the IMS Digital Repositories Interoperability Specification.|
|Revision Information||13 January 2003|
IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Digital Repositories Interoperability - Core Functions Information Model ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS would appreciate receiving your comments and suggestions.
Please contact IMS through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Digital Repositories Interoperability - Core Functions Information Model Revision: 13 January 2003