IMS DRI - Summary

Terms of use
X Terms of use
These contents have been obtained from the IMS Global Learning Consortium official Web site and edited for presentation. Please refer to the IMS Global Learning Consortium official Web site for additional information on terms of use.
IMS DRI provides 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.

The specification defines the core functional interactions between the mediation and Provision layers of the Functional Architecture identified for Digital Repositories. These core functions are:
  • Search/Expose: The Search reference model defines the searching of the meta-data associated with content exposed by repositories. 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. Two protocols are supported: XQuery over SOAP (for learning object repositories) and Z39.50 (for information repositories).
  • Gather/Expose: 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. A Gather component may interact with repositories in one of two ways: i) it either actively solicits meta-data (newly created, updated, or deleted) from a repository (pull), using OAI-PMH, or ii) it 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).
  • Submit/Store: 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). The specification specification provides no particular recommendations for legacy repository systems but draws attention to the weaknesses of FTP as a transport mechanism for learning objects or other assets:
  • Request/Deliver: 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.
  • Alert/Expose: 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.
Image for 'Summary'
Functional Architecture
In an overall sense, there are three generalized scenarios considered for the core functions:

  1. Learning Object Repositories. Searching is performed using the XQuery protocol over XML meta-data, adhering to the IMS Meta-Data Schema. IMS Content Packaging is assumed as the format for Submit/Store.
  2. General Repositories (of resources not purposed specifically for learning). Assumes use of Z39.50 protocol for searching, with no provision for Submit/Store.
  3. Cross-Domain Search. Assumes simple keyword searching without internal truncation using the Boolean operators AND, OR, and ANDNOT over a flattened schema of IMS meta-data elements.
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text