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

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 © 2004 IMS Global Learning Consortium. All Rights Reserved.

If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.

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

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 sourceSchema

4.7.2.1 Attributes

The sourceSchema attributes are described in Table 4.24.

4.7.3 MetadataStringDType

4.7.3.1 Attributes

The MetadataStringDType Class attributes are described in Table 4.25.

4.7.3.2 Associations

The set of associations for the MetadataStringDType are summarized in Table 4.26.

4.7.4 MetadataLangStringDType

4.7.4.1 Attributes

The MetadataLangStringDType Class attributes are described in Table 4.27.

4.7.4.2 Associations

The set of associations for the MetadataLangStringDType are summarized in Table 4.28.

4.7.5 MetadataDateDType

4.7.5.1 Attributes

The MetadataDateDType Class attributes are described in Table 4.29.

4.7.5.2 Associations

The set of associations for the MetadataDateType are summarized in Table 4.30.

4.7.6 MetadataTokenDType

4.7.6.1 Attributes

The MetadataTokenDType Class attributes are described in Table 4.31.

4.7.6.2 Associations

The set of associations for the MetadataTokenDType are summarized in Table 4.32.

4.8 OCL Definitions

package ResourceListManagementService

context ResourceList

inv: edition.size <= 1024

inv: description.size <= 8192

context ResourceListMetadata

inv: creator.size <= 4096

inv: owner.size <= 4096

inv: created.size <= 128

inv: title.size <= 4096

inv: kind.size <= 128

inv: rightsDescription.size <= 4096

inv: language.size <= 128

context Annotation

inv: annotator.size <= 4096

inv: date.size <= 128

inv: annotationNote.size <=4096

context Location

inv: locationType.size <= 256

inv: locatior.size <= 1024

context ResourceListIdPair

inv: sourcedId <= 2048

context Resource

inv: indexid.size <= 256

inv: type.size <= 128

context ResourceMetadata

inv: description.size <= 4096

inv: language.size <= 4096

inv: format.size <= 512

inv: genre.size <= 256

inv: structure.size <= 256

inv: mode.size <= 128

inv: totalPagesCovered <=128

context Citation

inv: title.size <= 4096

inv: creator.size <= 4096

inv: relatedTitle.size <= 256

inv: edition.size <= 1024

inv: publicationDate.size <= 128

inv: publicationPlace.size <= 512

inv: publisher.size <= 4096

inv: volumeDesignation.size <= 128

inv: partDesignation.size <= 128

inv: articleNumber.size <= 128

inv: startingPageNumber.size <= 64

inv: endingPageNumber.size<= 64

context RelatedTitle

inv: title.size <= 4096

inv: creator.size <= 4096

inv: edition.size <= 1024

inv: publicationDate.size <= 128

inv: publicationPlace.size <= 512

inv: publisher.size <= 256

inv: volumeDesignation.size <= 128

inv: partDesignation.size <= 128

context StandardIdentifier

inv: standardIdentifierType <= 128

inv: identifierString <= 2048

context ItemConstraints

inv: indexId.size <= 256

inv: required.size <= 128

inv: isvisible.size <= 128

context Rights

inv: rightsDescription.size <=4096

5. Extending the Service

5.1 Proprietary Extensions

The proprietary extensions of the specification are based upon two approaches:

1. The extension of the data models being manipulated by the current set of operations;
2. The inclusion of new operations to support new proprietary functionality.

It is NOT permitted to change the behavior of the current set of operations. Such changes MUST be supported by the creation of new operations.

5.1.1 Proprietary Operations

The definition of new operations should follow the same format as adopted herein. The new operations should be defined using a new interface type. Every operation must have a returned status code that is the returned value of the operation.

An example of creating such an extension is given in the Resource List Interoperability Best Practice and Implementation Guide [RLI 04c].

5.1.2 Proprietary Data Elements

The addition of proprietary data elements is only permitted directly under the resourceList class. This extension must use the IMSextension class. The format of the extension is limited to a repeated name/value tuple.

An example of creating such an extension is given in the Resource List Interoperability Best Practice and Implementation Guide [RLI, 04c].

5.2 Further Work

The resourceList Management Services Specification and is based on the composition of other clearly defined and functionally discrete operations. This means that the addition of new operations can be achieved without compatibility problems. The areas of work that will be addressed in new versions of the resourceList Management Services are:

1. Inclusion of operations that provide more definitive control over the full set of 'resourceList' records e.g., 'readAllResources()', 'deleteAllResources()', etc.
2. Inclusion of the 'queryResource()' operation. This will enable the service to be queried to supply details of the objects that conform to the set of search criteria;
3. Inclusion of discovery operations that allow a system to discover what resourceList records exist e.g. 'discoverResourceLists()'. This would return the list of the sourceIds of all of the existing resourceList objects;
4. Inclusion of operations that support direct manipulation of some of the sub-objects within the main services e.g., the ability to add/delete/read/change an individual resource or add an annotation to a resource without recourse to the manipulation of the full resourceList object. The corresponding operations for all aggregated parts of the resourceList data model will be considered.

Appendix A - Common Components

The set of common classes that are used throughout this specification are listed in Table A.1. The definitions of these classes can be found in the IMS Common Classes specification.

Appendix B - Service Status Codes

B1 - Summary List of Codes

The summary list of status codes that can be returned by the different operations through the StatusInfo object is given in Table B.1 (a detailed description of these codes is given in Section B2). The key to the entries is: 'Y' denotes the code may be returned by that operation. A blank entry means that the code cannot be returned by that operation.

B2 - Explanation of Operation Specific Codes

B2.1 - 'create' Operation

B2.2 - 'createByProxy' Operation

B2.3 - 'read' Operation

B2.4 - 'readResourceListsForGroup' Operation

B2.5 - 'replace' Operation

B2.6 - 'delete' Operation

B2.7 - 'assign' Operation

B2.8 - 'deassign' Operation

Appendix C - Sources of Input

In addition to the Use Cases (see the RLI Best Practices Document), the Project Team studied existing applications that currently address or fulfill user needs in the Resource List domain. Below is a sample list of products that enable the creation of Resource Lists at either the course or personal level. More importantly, the Project Team still needs to develop a methodology for reviewing, evaluating and incorporating existing specifications and standards in the schema definition work.

Course Resource List Management System

e.g., Sentient Learning's DISCOVER product, http://www.sentientlearning.com/home

Personal Bibliographic Search and Management Tools (Desktop Clients)

ISI ResearchSoft's EndNOTE, http://endnote.com/

ISI ResearchSoft's ProCite, http://www.procite.com/

Personal Bibliographic Search and Management Tools (ASP)

ExLibris Group's MetaLib, http://www.exlibrisgroup.com/metalib.htm

MuseGlobal Inc.'s Muse products, http://www.museglobal.com/index.html

Fretwell Downing's ZPortal, http://www.fdusa.com/products/zportal.html

Endeavor Information System's ENCompass, http://encompass.endinfosys.com/

WebFeat Inc.'s WebFeat products, http://www.webfeat.org/webfeat_products.html

RefWork's RefWork product, http://www.refworks.com/refworks.shtml

Item Level Meta-data Description

IMS-LOM, IEEE 1484.12.1-2002, Standard for Learning Object Metadata, http://www.ieee.org/

USMARC XML, http://www.loc.gov/standards/marcxml/

Dublin Core, ANSI/NISO Z39.85 - Dublin Core Metadata Element Set - 2001 http://dublincore.org/groups/citation/

MODS, Metadata Object Description Standard, http://www.loc.gov/standards/mods/

ONIX for Books, http://www.editeur.org/onixfiles2.1/prodinf%202.1.html and http://www.loc.gov/marc/onix2marc.html

Packaging and Transfer Protocols

IMS Content Packaging, Version 1.1.3, Final Specification, 2003-June-12, http://www.imsglobal.org/content/packaging/index.cfm

METS, Metadata Encoding and Transmission Standard, Version 1.3, http://www.loc.gov/standards/mets/

Locator schemas

OpenURL, ANSI/NISO Z39.88-200x - The OpenURL Framework for Context-Sensitive Services http://xml.coverpages.org/ni2001-03-13-b.html

URl, Uniform Resource Locators, http://www.faqs.org/rfcs/rfc1738.html

PURL, Persistent Uniform Resource Locators, http://purl.oclc.org/

DOI, ANSI/NISO Z39.84 - Syntax for the Digital Object Identifier - 2000, http://www.niso.org/standards/standard_detail.cfm?std_id=480

Standard ID Schemes/Categories

Common standard numbering schemes of interest in digital content management include those standardized by ISO:

ISBN: ISO 2108:1992 International Standard Book Numbering (ISBN)

ISSN: ISO 3297:1998 International Standard Serial Number (ISSN)

ISRC: ISO 3901:2001 International Standard Recording Code (ISRC)

ISRN: ISO 10444:1997 International Standard Technical Report Number (ISRN)

ISMN: ISO 10957:1993 International Standard Music Number (ISMN)

ISWC: ISO 15707:2001 International Standard Musical Work Code (ISWC)

ISAN: Draft ISO 15706: International Standard Audiovisual Number (ISAN)

V-ISAN: Draft ISO 20925: Version Identifier for audiovisual works (V-ISAN)

ISTC: Draft ISO 21047: International Standard Text Code (ISTC)

Note: While these ISO TC46 identifiers were originally simple numbering schemes, of late they have also begun to adopt the notion of associating some minimal structured descriptive meta-data with the identifier. Also relevant are the ISO- affiliated NISO standards including:

DOI, ANSI/NISO Z39.84 - Syntax for the Digital Object Identifier - 2000, http://www.niso.org/standards/standard_detail.cfm?std_id=480

SICI, ANSI/NISO Z39.56 - Serial Item and Contribution Identifier (SICI) -1996 (R2002), http://www.niso.org/standards/standard_detail.cfm?std_id=530

URI, Uniform Resource Identifier, http://www.w3.org/TR/uri-clarification

Appendix D - Comparison of Descriptive Meta-data Schemes for Citation and Resolution

About This Document

List of Contributors

The following individuals contributed to the development of this document:

Revision History

Index

A
Attributes
     StatusInfo

description 1

B
Behavior 1, 2, 3, 4, 5, 6
Bibliographic 1, 2, 3, 4, 5
Binding 1, 2, 3, 4

C
Citation 1, 2, 3, 4, 5
Classes
     Person 1, 2
Conformance 1, 2
Course
     environment 1

D
Dublin Core 1

E
Extension 1, 2

I
IEEE 1, 2, 3, 4
IMS Specifications
     Content Packaging 1, 2, 3
     Learner Information Package 1
     Resource List Interoperability 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     Resources List Interoperability 1
Interoperability 1, 2, 3
ISO 1, 2, 3, 4, 5, 6

L
Learning 1, 2, 3, 4
Learning Object 1, 2
Libraries 1
LOM 1, 2, 3, 4, 5
LTSC 1

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

N
Normative 1, 2, 3

O
OpenURL 1, 2, 3, 4, 5, 6
Operations
     Person

readPersonsForGroup 1, 2

P
Profile 1

R
Records 1, 2, 3, 4, 5
Resource 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Resource list 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21
Resources 1, 2, 3, 4, 5, 6, 7
Resources list 1
RFC 1

S
Schema 1, 2, 3, 4, 5, 6, 7
SCORM 1
Services 1, 2, 3, 4, 5, 6
Standards 1, 2, 3, 4, 5
Structure 1, 2, 3, 4, 5, 6, 7

U
URI 1, 2, 3

V
Vocabulary 1, 2

W
W3C 1

X
XML 1, 2, 3, 4, 5