IMS Resource List Interoperability Information Model Version 1.0 Final Specification

Copyright © 2004 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Resource List Interoperability Information Model
Revision: 8 July 2004

Table of Contents

1. Introduction

This section is not normative.

1.1 Specification Overview

The Resource List Interoperability (RLI) specification details how structured meta-data can be exchanged between systems that store and expose resources for the purpose of creating resource lists and those that gather and organize those resource lists for educational or training purposes. A typical example of such a resource list is a reading list.

The specification is based on an abstract service behaviors and data model that describes in generalized terms a resource at the item level, a collection of these resources (i.e., a list) and the behaviors associated with a resource list management service. The data model is then bound or expressed in XML, combining elements that map to subsets of key standards, including the IEEE-LOM (Learning Object Metadata), ISO 690-2 for bibliographic citations, and NISO's OpenURL to describe the resource items and aggregated resource list. The abstract service interface is bound to web services expressed as WSDL. The IMS Content Packaging specification wraps the resource list to enable transfer between systems. Because the data model is generalized, other bindings may be (and it is expected, will be) added to future releases of the specification.

The IMS Learning Resource Meta-data specification (now the IEEE-1484.12.1 LOM standard) was developed to provide item-level descriptions for the range of instructional materials that might be used in a virtual learning environment or course management system, from simple static HTML content to technically sophisticated simulations. While the LOM anticipates a broad economy of complex, self-contained e-learning objects, in the higher education realm much of the digital course "content" often categorized loosely as "course resources" parallels fairly traditional collections of supplementary course reading materials. These course resource lists frequently include links to freely available content on the Web and other materials that may not have been formally published, and may also include bibliographic records from OPACs (Online Public Access Catalog) and content licensed by academic libraries from publishers and aggregators.

Naturally, course reserves or course-specific collections of resources have long been and continue to be maintained and organized within academic libraries. The intersection of the library reserves function and the Web as a content distribution mechanism has given rise to the notion of "e-reserves." Integrated Library System (ILS) vendors have developed web-based software tool suites that integrate OPAC, e-reserves, federated searching and personal bibliographic management capabilities. At the same time, e-learning systems provide another logical context and dissemination point for course-specific collections of resources.

Course Resource Lists, then, may be maintained in both library and course management systems. Yet, while instructors are able to add citations and links to readings or post other supplementary resources directly into the course environment, they usually do so in an ad hoc fashion not much different from the manner one would post readings to any free form website. Furthermore, multiple segregated systems create a variety of unnecessarily disparate institutional work flows, ranging from the creation and publication of lists culled from library and other sources by the instructor (as just described), to the complete processing of a course reserves list by the library based on skeletal information the instructor has provided. The variety of ways in which Resource Lists can be created make it difficult for the various systems or tools that harvest, associate and store the Resource Lists to exchange and consolidate these heterogeneous aggregations. The RLI specification begins to address these integration issues by enabling the ready exchange of structured meta-data between e-learning tools and various related applications, including OPACs, reserves modules, or other third-party tools.

The Information Model defines the exchange and maintenance of resource lists among systems through an abstract service interface. The interface is divided between core (Create, Read, Replace, and Delete) and complex behaviors (Assign and De-assign). The latter enable the association of resource lists created in one system or application with groups or courses in another. Multiple implementations of the service interface are possible, although the RLI Binding document defines a WSDL binding.

The initial release of the RLI specification addresses the issue of how to organize, describe and exchange traditional lists of course resources (such as bibliographies). The data model comprises a minimal set of elements for citing print publications. Nevertheless, given the simplicity, generality and design of the RLI model, materials in other media can be adequately described and included within resource lists as currently defined. Just as importantly, the model is designed so that it may be easily extended to specify different resource types in subsequent iterations.

In the future, it is highly unlikely that any one standard will be adopted to describe bibliographic resources, much less digital resources in general. Appendix D includes a mapping of the relevant LOM elements to major bibliographic citation schemas used in the library and publishing worlds. While the RLI specification represents a first step towards a larger resource collections framework, the relatively simple abstract data model on which it is based should ensure interoperability with other emerging frameworks such as METS.

1.1.1 Rationale

This Resource List Interoperability (RLI) specification:

• Enables the creation of tools for the generation and exchange of resource lists according to a standard format.
• Allows for incorporation of resource list data into other e-learning tools, so that future efforts to integrate enterprise learning and library course reserves systems will not need to rely on proprietary solutions, reducing costs to vendors and customers.
• Leverages federated searching tools to capture records for resource lists. This raises the profile of costly and often underutilized library-licensed resources.
• Establishes the potential for a unified resource list creation workflow.

1.1.2 Background and History

The IMS Digital Libraries special interest group identified the organization of course resources as an existing intersection between the library and e-learning domains that had not, as of yet, been addressed in any standardized fashion. It was also recognized as an area that represented a potential quick win-through the development of an interoperability specification-for the broader effort to bring two related domains into closer harmony.

1.2 Components of the Specification

This specification consists of the documents listed below.

1.2.1 RLI Information Model

The RLI Information Model (this document) [RLI, 04a] - Describes the core aspects of the specification and contains parts that are normative for any binding claiming to use this Information Model. It contains details of: semantics, structure, data types, value spaces, multiplicity, and obligation (i.e., whether mandatory or optional).

1.2.2 RLI Binding

The XML/WSDL Binding [RLI, 04b] - Describes a binding of the Information Model using a Web Services infrastructure based upon XML and a SOAP/HTTP transport mechanism. There are many possible bindings of the Information Model but at the current time the only specified binding is based upon XML and WSDL.

1.2.3 RLI Best Practice and Implementation Guide

The Best Practice and Implementation Guide [RLI, 04c] - Provides non-normative guidance on application of the Information Model and WSDL Binding. This includes reference to existing practice in handling information that this specification seeks to support and guidance on practices that will promote interoperability and durability. It also includes examples to illustrate how the conceptual framework maps to practical uses and to identify the relationship between this specification and related IMS specifications. Implementers are encouraged, but not required, to follow guidance in this part of the specification.

1.2.4 RLI Conformance Requirements

The Conformance Requirements [RLI, 04d] - Defines the conformance criteria that must be followed by systems that wish to claim compliance to the Resource List Interoperability Information Model.

1.3 Scope

The following are out of scope for this specification:

• In this specification, the definition of persistent locators is out of scope and not addressed. The RLI specification does state, however, when locators are needed and what meta-data is required for the construction of known, standard resolver schemes such as OpenURL and the Digital Object Identifier.
• Authorization/Access Management. Ensuring authorized access to the resource list creation functionality and the items contained within a resource list is outside the scope of this specification. The RLI specification does provide a meta-data element in which access rights or other intellectual property declarations associated with the resource list can be stated in human readable form for display or other, non-machine actionable purposes.
• Association of Course Identifiers. Dynamically associating system course identifiers to resource lists is critical to the practical working of the RLI spec. The definition of course identifiers is out of scope.
• Update transactions. Lists already created that have been modified must in their entirety replace any previous versions (Destructive Update). Update functionality may be formalized in a later phase of specification development.

1.4 Structure of this Document

The structure of this document is:

1.5 Nomenclature

1.6 References

2. Resource List Manager Service Description

2.1 An Abstract Representation

It is important to remember that this document describes the underlying information model in terms of the abstract API. The manner in which this abstract representation is visualized is not intended to dictate the implementation form of a Resource List Management System. The breakdown of the service into its interface classes is a convenient way to document the set of behaviors. The internal organization of an implementation of the full abstract API is beyond the scope of this specification. The only constraint is that the external behavior of the abstract API complies with this specification. This means that a .NET, Java, etc. physical implementation of this abstract API does not have to represent the functionality using the same breakdown of operations/methods. This physical implementation is not subject to the conformance specification.

It is important to note that the UML representation of the interface is used to help develop and document the Resource List Management Services. It is not a requirement for an implementation to implement this interface as defined, i.e., to use the same parameters, etc. Conformance against this specification will be confirmed by inspecting the appropriate binding of the information model and ensuring that the relevant information is present and that different sequences of activity result in the predicted and mandated behavior. It is essential that the behaviors described by each of the operations are fully supported, and it is also essential that the behaviors described by different sequences are also maintained.

2.2 Resource List Manager Service Architecture Model

Online Public Access Catalog, Digital Library, Course Management and other third-party systems should facilitate the exchange of Resource Lists. This exchange will be achieved through Export/Import or integrated Send/Receive Actions as defined in the services of the Resource List Manager. Furthermore, updates to the Resource List made in the originating system should be updated in the other systems that have imported/received that particular Resource List.

The basic architectural model for the Resource List Manager Services specification is shown in Figure 2.1.

In this architecture the scope of the IMS Resource List Manager Services specification is shown as within the red box. The scope of the interoperability is the data and behavioral models of the objects being exchanged.

The IMS Resource List Manager Services specification contains a very simple abstract messaging model that is assumed to underlie the exchange of the data between the communicating Resource List Manager systems. The basic data exchange mechanism is shown in Figure 2.2 in which the 'source' and 'target' Resource List Manager systems exchange 'messages' using a 'Request/Response' transaction. This abstract messaging representation is adopted because the Resource List Manager System architecture is based upon a loosely coupled system and the primary IMS binding of this information model is based upon the exchange of XML documents/messages.

It is important to remember that the structure of the exchanged information has NO bearing on how the same information is contained within the 'source' and 'target' Enterprise systems. It is simply a representation of the data used to facilitate exchange with other parties (the information that crosses the dotted line in Figure 2.2).

The behavioral descriptions will describe:

• The data that is to be exchanged between the communicating Resource List Manager Systems;
• The operations that can be invoked to support the exchange of the data between the communicating Resource List Manager Systems;
• The permitted sequence of operations that can be used to support the exchange of data between the communicating Resource List Manager Systems.

2.3 Resource List Objects

It is important to note that this is an interoperability specification and as such it makes no statements about how information is stored within the exchanging end systems. The objects in the end-systems must be persistent otherwise sequences of operation on the same object will not be possible. Reference to these objects in the interface is through a 'sourcedId' however this identifier does not have to be the key stored within the end-systems. If different keys are used in the end-systems then it is the responsibility of the end-systems to maintain the mapping between that key and the 'sourcedId' i.e., the interface must never be exposed to the keys of the end-systems.

2.4 Synchronous Services

Within the context of the Resource List Manager Services, this specification only deals with synchronous services. Asynchronous services are out of scope for the specification.

Synchronous services are defined as services in which the source service is blocked until the final response from the target service is received.

The abstract-API does not differentiate between synchronous and asynchronous services.

3. Behavioral Model

3.1 Service Definition - Resource List Manager Interface Class Description

3.1.1 Structure

The ResourceListManager interface class is used to model the service responsible for manipulating information about resource lists and describes the operations that are permitted on a single 'resourceList' object as shown in Figure 3.1.

These operations are based upon the classic Create/Read/Update/Delete (CRUD) model with variations defined to differentiate subtleties of functionality. The interface stereotype indicates that there are no attributes for this class.

Resource List Manager operations use the following data types and common classes:

• resourceList - the data structure for the resourceList.
• identifier - the container for the unique identifier of the 'resourceList' object.
• constraints - the container for data that defines the association between a course and a resources list.
• resourceListSet - the container for the set of Resource Lists and constraints for a uniquely identified group.
• SeqLanString - the container for a set of language alternative versions of a string.
• StatusInfo - the container for the status information that describes the completion state of the operation.
• StatusInfoSet - the container for a set of status information that describes the completion state of the operation.

3.1.2 Operations

The core CRUD operations are summarized in Table 3.1.

3.1.2.1 createResourceList

The associated interaction sequence diagram is shown in Figure 3.2. The 'TriggerAction' results in the 'Source System' issuing the 'createResourceList ()' request. At some time later the 'Target System' responds.

3.1.2.2 createByProxyResourceList ()

The associated interaction sequence diagram is shown in Figure 3.3. The 'TriggerAction' results in the 'Source System' issuing the 'createByProxyResourceList ()' request. At some time later the 'Target System' responds.

3.1.2.3 readResourceList ()

The associated interaction sequence diagram is shown in Figure 3.4. The 'TriggerAction' results in the 'Source System' issuing the 'readResourceList ()' request. At some time later the 'Target System' responds.

3.1.2.4 readResourceListsForGroup ()

The associated interaction sequence diagram is shown in Figure 3.5. A set of 'TriggerAction' events results in the 'Source System' issuing the 'readResourceListsForGroup()' request. At some time later the 'Target System' responds.

3.1.2.5 replaceResourceList ()

The associated interaction sequence diagram is shown in Figure 3.6. The 'TriggerAction' results in the 'Source System' issuing the 'replaceResourceList ()' request. At some time later the 'Target System' responds.

3.1.2.6 deleteResourceList ()

The associated interaction sequence diagram is shown in Figure 3.7. The 'TriggerAction' results in the 'Source System' issuing the 'deleteResourceList ()' request. At some time later the 'Target System' responds.

3.1.2.7 assignResourceList ()

The associated interaction sequence diagram is shown in Figure 3.8. The 'TriggerAction' results in the 'Source System' issuing the 'assignResourceList ()' request. At some time later the 'Target System' responds.

3.1.2.8 deassignResourceList ()

The associated interaction sequence diagram is shown in Figure 3.9. The 'TriggerAction' results in the 'Source System' issuing the 'assignResourceList ()' request. At some time later the 'Target System' responds.

3.2 Permitted State Sequence

The permitted state activity on an object is shown in Figure 3.10. This state diagram has four states:

• 'No Object' state - no resourceList object exits with a particular id;
• 'Object with Target-created id' - a resourceList object exists with the id allocated by the Target system;
• 'Object with Source-created id' - a resourceList object exists with the id allocated by the Source system.
• 'Object with associations' - a resourceList object exists that has been assigned to a group.

The start state is 'No Object' i.e. the resourceList record has not yet been created. Only the 'createResourceList ()' and 'createByProxy()' operations are possible. Once the resourceList object has been created then it persists until a successful 'deleteResourceList ()' operation is completed. The 'createResourceList()' operation takes the system into the 'Object with Source-created id' state whereas the 'createByProxyResourceList ()' takes the system into the 'Object with Target-created id' state.

Once the system is in the 'Object with Source-created id' or the 'Object with Target-created id' states then the 'readResourceList()' and 'replaceResourceList ()' operations are now possible.

The 'assignResourceList()' operation takes the system into the 'Object with group associations' state. Once the system is in the 'Object with group associations' state, then the 'readResourceListsForGroup' operation is possible.

4. RLI Data Model

The Data Model in this specification is non-normative. It is an informative abstraction. Conformance and normalization is described in the Binding and Conformance components of this specification.

4.1 resourceList

The resource list and its associations are is shown in Figure 4.1. This representation describes the data model that must be supported by the end systems.

A resource list is an aggregation of content resources associated with one or more courses or learning objects.

Resource lists may be subsumed under other Resource Lists.

A resource list always exists in association with an identifier 'sourcedId', either in the input parameters to a service or, in the resource list ID Pair object. The identifier is unique among the systems being integrated.

4.1.1 Attributes

The set of attributes for the resourceList class is summarized in Table 4.1.

4.1.2 Associations

The set of associations for the Resource List Class are summarized in Table 4.2.

4.1.2.1 resourceListMetadata

The resourceListMetadata Class attributes are described in Table 4.3.

4.1.2.2 Associations

The set of associations for the resourceListMetadata Class are summarized in Table 4.4.

4.1.3 resourceListIDPair

The ResourceListIDPair Class attributes are described in Table 4.5.

4.1.3.1 Associations

The set of associations for the Resource List ID Pair Class are summarized in Table 4.6.

4.2 resource

The resource Class attributes are described in Table 4.7.

4.2.1 Associations

The set of associations for the resource Class are summarized in Table 4.8.

4.2.1.1 resourceMetadata

The resourceMetadata Class attributes are described in Table 4.9.

4.2.1.1.1 Associations

The set of associations for the resourceMetadata Class are summarized in Table 4.10.

Citation

The citation Class attributes are described in Table 4.11.

Associations

The set of associations for the citation Class are summarized in Table 4.12.

standardIdentifier

The standardIdentifier Class attributes are described in Table 4.13.

relatedTitle

The relatedTitle Class attributes are described in Table 4.14.

Associations

The set of associations for the relatedTitle Class are summarized in Table 4.15.

4.3 annotation

The annotation Class attributes are described in Table 4.16.

4.4 location

The location Class attributes are described in Table 4.17.

4.5 resourceListSet

4.5.1 Description

The resourceListSet and its associations are is shown in Figure 4.2.

4.5.2 Attributes

None.

4.5.3 Associations

The set of associations for the resourceListSet are summarized in Table 4.18.

4.5.3.1 resourceListGroupAssociation

4.5.3.1.1 Attributes

None.

4.5.3.1.2 Associations

4.6 constraints

4.6.1 Description

Constraints and its associations are is shown in Figure 4.3.

Constraints apply to the association between a course and a resources list and define any constraints temporal, conditional, etc. being placed on the association. IMS RLI Implementers are encouraged to leverage constraints available within the behavioral model, in situations where access to resource lists may be of a temporary or restricted nature. However, these constraints are not intended to replace access right management and digital rights management systems, and rules.

4.6.2 Attributes

None.

4.6.3 Associations

The set of associations for the constraints are summarized in Table 4.20.

4.6.3.1 rights

The rights Class attributes are described in Table 4.21.

4.6.4 itemConstraints

The itemConstraints Class attributes are described in Table 4.22.

4.6.4.1 Associations

The set of associations for the itemConstraints Class are summarized in Table 4.23.

4.7 Data Types

4.7.1 Description

The RLI Data Types are shown in Figure 4.4.

In the future, it is highly unlikely that any one standard will be adopted to describe bibliographic resources, much less digital resources in general. The Information Model Appendix D includes a mapping of the relevant LOM elements to major bibliographic citation schemas used in the library and publishing worlds. This specification has defined an origin neutral meta-data description of Resource Lists and the resources they describe. However it may be extremely useful for the system processing the Resource List to understand the original meta-data source for the meta-data. The RLI Data Types allow an optional description of the source schema to be associated with the attribute content.

4.7.2 sourceSche