IMS Logo

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.


Table of Contents


1. Introduction
     1.1 Nomenclature
     1.2 References

2. Functional Architecture

3. Reference Model
     3.1 Search/Expose
           3.1.1 Recommendations for Query Language
     3.2 Gather/Expose
           3.2.1 Recommendations for "Pull" Gather
           3.2.2 Recommendations for "Push" Gather
     3.3 Alert/Expose
     3.4 Submit/Store
           3.4.1 Submit
           3.4.2 Store
     3.5 Request/Deliver
           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.1 Actors
     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

Revision History

Index

1. Introduction

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:

Note: Alert/Expose is identified as a key function that will need to be addressed in a later DRI specification.

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:

  1. Systems reflecting established practice (e.g., that utilize Z39.50) for repository interoperability.
  2. 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.

Section 3 defines a general reference model, which captures all instances of possible implementations, such as:

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.

Section 4 outlines the message structure for each of the core functions addressed.

Section 5 outlines the use cases which have informed the discussion and development of this specification.

1.1 Nomenclature

DC
Dublin Core
DOI
Digital Object Identifier
DRI
Digital Repositories Interoperability
FTP
File Transfer Protocol
GUID
Globally Unique Identifier
HTTP
Hypertext Transfer Protocol
LCMS
Learning Content Management System
LMS
Learning Management System
MIME
Multipurpose Internet Mail Extensions
OAI
Open Archive Initiative
SMTP
Simple Mail Transfer Protocol
SOAP
Simple Object Access Protocol
W3C
World Wide Web Consortium
XQuery
XML Query

1.2 References

[DRI, 03b]
IMS Digital Repositories Interoperability - Core Functions XML Binding, K.Riley and M.McKell, Version 1.0, IMS, January 2003.
[DRI, 03c]
IMS Digital Repositories Interoperability - Core Functions Best Practice Guide, K.Riley and M.McKell, Version 1.0, IMS, January 2003.
[MD, 01a]
IMS Learning Resource Meta-Data Information Model, T.Anderson and M.McKell, Version 1.2.1, IMS, October 2001.
[MD, 01b]
IMS Learning Resource Meta-Data XML Binding, T.Anderson and M.McKell, Version 1.2.1, IMS, October 2001.
[MD, 01c]
IMS Learning Meta-Data Best Practice and Implementation Guide, T.Anderson and M.McKell, Version 1.2.1, IMS, October 2001.

2. Functional Architecture

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.

The three entities are:

Functional Architecture

Figure 2.1  Functional Architecture.

The solid red lines, between a number of functions between Resource Utilizers and Repositories, indicate the interactions between core functional components that support interoperability, including:

Note: ALERT is a core function, but is not addressed within this version of the DRI specification.

The DRI Project Group is focusing on these core interoperability functions within the functional architecture (see Figure 2.2).

Core Functionality

Figure 2.2  Core Functionality.

3. Reference Model

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:

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.

General reference model diagram with roles

Figure 3.1  General reference model diagram with roles.

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:

3.1 Search/Expose

The Search reference model defines the searching of the meta-data associated with content exposed by repositories. The reference model is illustrated in Figure 3.2 below.

Distributed, cross-domain search

Figure 3.2  Distributed, cross-domain search.

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.

3.1.1 Recommendations for Query Language

  1. 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.
  2. Z39.50 for searching library information. This search provides a grammar for searching Z39.50 repositories either directly or through an intermediate search engine.

There are three types of SOAP messaging with or without attachments:

3.2 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. 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 Gather reference model for soliciting meta-data

Figure 3.3  The Gather reference model for soliciting meta-data.

3.2.1 Recommendations for "Pull" Gather

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.

3.2.2 Recommendations for "Push" Gather

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.

3.3 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. For more detail about how the Alert function might work, see the Appendix in the DRI Best Practice Guide.

3.4 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). 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:

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.

3.4.1 Submit

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.

3.4.2 Store

The Store function is understood simply as the ability of the repository to present an IMS Content Package at some level of its operation.

Figure 3.5 indicates how the Submit/Store functionality would accommodate both digital repositories that use or do not use the IMS DRI recommendations.

Diagram of the Submit/Store functionality

Figure 3.5  Diagram of the Submit/Store functionality.

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

3.5.1 Exclusions from Scope

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.

Verification of the delivery of materials is not covered in this version of the specification. E-commerce and payment processing is handled by another functional component.

3.5.2 Request/Deliver Mechanism

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:

http:       for online materials including html, java, and pdf
http:       for streaming access to materials (audio, video, etc.)
ftp:         for access to documents, executables, etc.

4. General Messaging Model

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.

The basic message has two parts: a message header and a message body.

message
   header
   body


Message Header

The message header contains addressing and minimal security information.

No provision for routing, alternate returns addresses, time-to-live, messaging sequencing, and so on is made in the initial model. These are all anticipated in subsequent versions.

Message-level authentication is provided by an extensible 'security' element.

header
   message type
   destination address
   message authentication

The destination address is specified as a URI.


Message Body

The message body consists of zero or more payloads, with zero or more 'audit' elements.

body
   payload(s)
   audit element(s)

Arbitrary payloads may be used, as long as they meet the requirements of the relevant message and transport bindings.

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


Message Security

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

4.1 Open Issues

This section records issues that have been identified but not addressed. The appropriate standards communities should address many of these, as they represent common problems.

Message Security

Message integrity and non-repudiation
Message-level encryption

Cascaded Messages

A model that supports cascaded messages is needed to handle alerts, transactions, hooks to other systems, and so on.

Failures

Where possible, failure messages are handled at the application level, generally as a return message. Within the SOAP/HTTP binding, 'out-of-band' failures will use the SOAP failure message mechanism.

Canceling a Query

The SOAP/HTTP message binding does not provide a way to directly cancel a message once issued, in particular, cancellation of a currently executing (distributed) query.

Incomplete Query

In the case when a query doesn't complete for some reason, the use of a time-out mechanism at both ends of the message is recommended.

5. High Level Overview of Use Cases for a Learning Repository

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.

5.1 Actors

Each actor in the use cases described below will be acting in one of the following roles described earlier: Creator, Learner, Infoseeker, or Software Agent.

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.

4.   Software Agent Roles Actor 8: LMS software application
Actor 9: LCMS software application
Actor 10: Portal software application
Actor 11: Aggregator Repository

5.2 Use Cases

5.2.1 Create and Modify Resources

Use Case 1 Creator authors a course and submits it to a repository
Description

Primary Actor Actor 1 or 2
Flow Detail
  1. User logs into an LCMS
  2. User is authenticated
  3. User submits an IMS Content Package containing meta-data and the resource to the repository
  4. Repository returns a unique ID that can be used to request the Content Package at a later time
Preconditions

User is part of the community of subscribers to the learning repository

Postconditions

Comments

If there are multiple repositories, the user must identify the correct repository and submit the Content Package to that repository

Creator authors a course and submits it to a repository

Figure 5.1  Creator authors a course and submits it to a repository.

Use Case 2 Creator requests a course from a repository, modifies it, and submits the modified course to the repository
Description

Primary Actor Actor 1 or 2
Flow Detail
  1. User logs into an LCMS
  2. User is authenticated
  3. User initiates a search on the meta-data in the repository with a set of search restriction parameters
  4. Repository returns the set of meta-data records that meet the search criteria
  5. User reviews the meta-data records and requests one learning object from the repository using the unique ID of the learning object
  6. Repository returns the learning object in the form of an IMS Content Package
  7. User modifies the learning object
  8. User submits the modified learning object to the repository
Preconditions User is part of the community of subscribers to the learning repository
Postconditions

Comments Versioning of resources in a repository will be specified in a later release

Creator requests a course from a repository, modifies it, and submits the modified course to the repository

Figure 5.2  Creator requests a course from a repository, modifies it, and submits the modified course
to the repository.

5.2.2 Discover Resources

Use Case 3 Creator/Learner/Infoseeker searches the meta-data in a repository and requests a discovered resource
Primary Actor Actor 1, 3, 4, or 6
Description

Flow Detail
  1. User logs into an LCMS, LMS, or Search Portal
  2. User is authenticated
  3. User initiates a search on the meta-data in the repository with a set of search restriction parameters
  4. Repository returns the set of meta-data records that meet the search criteria
  5. User reviews the meta-data records and requests one object from the repository using the unique ID of the object
  6. Repository returns the object in the form of an IMS Content Package
Preconditions User is part of the community of subscribers to the object repository
Postconditions

Comments

Creator/Learner/Infoseeker searches the meta-data in a repository and requests a discovered resource

Figure 5.3  Creator/Learner/Infoseeker searches the meta-data in a repository and requests a discovered resource.

Use Case 4 Creator/Learner/Infoseeker searches the meta-data in multiple repositories and requests a discovered resource
Primary Actor Actor 2, 5, or 7
Description

Flow Detail
  1. User logs into an LCMS, LMS, or Search Portal
  2. User is authenticated
  3. User initiates a search on the meta-data in multiple repositories with a set of search restriction parameters
  4. Federated Search Intermediary software module translates the search into multiple searches of multiple repressurizes
  5. Each of the multiple repositories returns the set of meta-data records that meet the search criteria
  6. Federated Search Intermediary software module receives the meta-data records from all of the repositories and returns all of the meta-data records
  7. User reviews the meta-data records and requests one object from one of the repositories using the unique ID of the object
  8. Repository returns the object in the form of an IMS Content Package
Preconditions User is part of the community of subscribers to the object repository
Postconditions

Comments

Creator/Learner/Infoseeker searches the meta-data in multiple repositories and requests a discovered resource

Figure 5.4  Creator/Learner/Infoseeker searches the meta-data in multiple repositories and
requests a discovered resource.

Use Case 5 Software Agent searches the meta-data in a repository and requests a discovered resource
Primary Actor Actor 8, 9, or 10
Description

Flow Detail
  1. User logs into an LCMS, LMS, or Search Portal
  2. User is authenticated
  3. User begins to interact with a training course on a particular topic
  4. Software Agent develops search parameters for dynamic selection of the next learning object. The search parameters may be predefined by the instructor or dynamically determined based on criteria such as the results of assessment
  5. Software Agent initiates a search on the meta-data in a repository with a set of search restriction parameters
  6. The repository returns a set of meta-data records that meet the search criteria
  7. Software Agent reviews the meta-data records and requests one object from one of the repositories using the unique ID of the object
  8. Repository returns the object in the form of an IMS Content Package
Preconditions

Postconditions

Comments

Software Agent searches the meta-data in a repository and requests a discovered resource

Figure 5.5  Software Agent searches the meta-data in a repository and requests a discovered resource.

Use Case 6 Aggregator Repository gathers meta-data from multiple repositories and populates its own repository
Primary Actor Actor 11
Description

Flow Detail
  1. Software Agent identifies candidate repositories from which to gather meta-data
  2. Software Agent initiates a search on the meta-data in multiple repositories using a set of restriction parameters that select only new meta-data records; the Agent is able to identify which of the meta-data records are "new"
  3. Each of the multiple repositories returns the set of meta-data records that meet the search criteria
  4. Software Agent stores the meta-data records to its own local repository
Preconditions

Postconditions

Comments

Aggregator Repository gathers meta-data from multiple repositories and populates its own repository

Figure 5.6  Aggregator Repository gathers meta-data from multiple repositories and
populates its own repository.

5.2.3 Notification of Modification of Resources

Use Case 7

Creator/Learner/Infoseeker subscribes to be alerted when a specified change occurs to the meta-data in a repository

Primary Actor Actor 1, 3, 4, or 6
Description

Flow Detail
  1. User logs into an LCMS, LMS, or Portal
  2. User is authenticated
  3. User subscribes to be alerted when a specified change occurs to the meta-data in a repository
  4. User logs off of the LCMS, LMS, or Portal
  5. When the specified change later occurs, the user is notified via an email message
Preconditions User is part of the community of subscribers to the learning repository
Postconditions

Comments

Creator/Learner/Infoseeker subscribes to be alerted when a specified change occurs to the meta-data in a repository

Figure 5.7  Creator/Learner/Infoseeker subscribes to be alerted when a specified change occurs
to the meta-data in a repository.

Use Case 8 Creator/Learner/Infoseeker subscribes to be alerted when a specified change occurs to the meta-data in multiple repositories
Primary Actor Actor 2, 5, or 7
Description

Flow Detail
  1. User logs into an LCMS, LMS, or Portal
  2. User is authenticated
  3. User subscribes to be alerted when a specified change occurs to the meta-data in a repository
  4. Alert Intermediary software module translates the subscribe into multiple subscribes to multiple repositories
  5. User logs off of the LCMS, LMS, or Portal
  6. When the specified change later occurs, the user is notified via an email message
Preconditions User is part of the community of subscribers to the learning repository
Postconditions

Comments

Creator/Learner/Infoseeker subscribes to be alerted when a specified change occurs to the meta-data in multiple repositories

Figure 5.8  Creator/Learner/Infoseeker subscribes to be alerted when a specified change occurs
to the meta-data in multiple repositories.

About This Document

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
1.0
Version Date
13 January 2003
Status
Final Specification
Summary
This document describes the Information Model for the IMS Digital Repositories Interoperability Specification.
Revision Information
13 January 2003
Document Location
http://www.imsglobal.org/digitalrepositories/driv1p0/imsdri_infov1p0.html

List of Contributors

The following individuals contributed to the development of this specification:

Name Organization
Tom Barefoot
Learning Objects Network
Fred M. Beshears
UC Berkeley
Kerry Blinco
IMS Australia - DEST
Dipto Chakravarty
Artesia Technologies
Tracy Flynn
Learning Objects Network
Norm Friesen
Industry Canada

Niccolo' Giaccone

Giunti Labs

Renato Iannella

IMS Australia - DEST

Kirk Johnson

ADL

Paul Lefrere

Open University
Ralph LeVan
OCLC

Esko Liimatta

R5 Vision

Aki Salakka

R5 Vision

Rick Scurfield
Artesia Technologies
Neil Smith
FDI
Colin Smythe
IMS

Mats Svensson

Luvit
Kim Voltero
WebCT
Darrell Woelk
Docent

Revision History

Version No. Release Date Comments
Base 1.0
05 February 2002
The first formally released version of the full IMS Digital Repositories Interoperability Specification.
Public Draft 1.0
16 July 2002
Expanded several sections and edited for consistency.
Final 1.0
13 January 2003
Made minor edits to clarify meaning and provide better textual description in various sections. Corrections to minor typographic errors were also included.

Index

A
agent 1, 2, 3
aggregator 1, 2, 3
Architecture 1
architecture 1, 2
asset 1, 2

C
Content Packaging 1, 2
core functions 1, 2
creator 1, 2, 3

D
DOI 1, 2
Dublin Core 1, 2

F
federator 1
FTP 1

I
infoseeker 1, 2, 3

L
LCMS 1, 2
learner 1, 2, 3
LMS 1, 2

M
Meta-data
     Version 1
meta-data 1, 2, 3, 4, 5, 6

O
OAI 1, 2

Q
query 1, 2, 3, 4

R
roles 1, 2, 3

S
Scope 1
scope 1, 2, 3
SMTP 1
SOAP 1, 2, 3, 4, 5, 6

T
translator 1, 2

W
W3C 1, 2, 3

X
XML 1
XQuery 1, 2, 3, 4

Z
Z39.50 1, 2, 3

 

 

 

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