 |
1EdTech Resource List Interoperability Version 1.0 Final Specification |
Copyright © 2004 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech 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.
1EdTech 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 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2004 1EdTech 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 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech 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 Specification Overview
1.1.1 Rationale
1.1.2 Background and History
1.2 Components of the Specification
1.2.1 RLI Information Model
1.2.2 RLI Binding
1.2.3 RLI Best Practice and Implementation Guide
1.2.4 RLI Conformance Requirements
1.3 Scope
1.4 Structure of this Document
1.5 Nomenclature
1.6 References
2. Resource List Manager Service Description
2.1 An Abstract Representation
2.2 Resource List Manager Service Architecture Model
2.3 Resource List Objects
2.4 Synchronous Services
3. Behavioral Model
3.1 Service Definition - Resource List Manager Interface Class
Description
3.1.1 Structure
3.1.2 Operations
3.2 Permitted State Sequence
4. RLI Data Model
4.1 resourceList
4.1.1 Attributes
4.1.2 Associations
4.1.3 resourceListIDPair
4.2 resource
4.2.1 Associations
4.3 annotation
4.4 location
4.5 resourceListSet
4.5.1 Description
4.5.2 Attributes
4.5.3 Associations
4.6 constraints
4.6.1 Description
4.6.2 Attributes
4.6.3 Associations
4.6.4 itemConstraints
4.7 Data Types
4.7.1 Description
4.7.2 sourceSchema
4.7.3 MetadataStringDType
4.7.4 MetadataLangStringDType
4.7.5 MetadataDateDType
4.7.6 MetadataTokenDType
4.8 OCL Definitions
5. Extending the Service
5.1 Proprietary Extensions
5.1.1 Proprietary Operations
5.1.2 Proprietary Data Elements
5.2 Further Work
Appendix A - Common Components
Appendix B - Service Status Codes
B1 - Summary List of Codes
B2 - Explanation of Operation Specific Codes
Appendix C - Sources of Input
Appendix D - Comparison of Descriptive Meta-data Schemes for Citation
and Resolution
About This Document
List of Contributors
Revision History
Index
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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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
| [RLI, 04b] | 1EdTech Resource List Interoperability XML/WSDL Binding v1.0, A.Jackl, 1EdTech Consortium, Inc., July 2004. |
| [RLI, 04c] | 1EdTech Resources List Interoperability Best Practice and Implementation Guide v1.0, A.Jackl, 1EdTech Consortium, Inc., July 2004. |
| [RLI, 04d] | 1EdTech Resources List Interoperability Conformance v1.0, M.Maljkovic, 1EdTech Consortium, Inc., July 2004. |
| [DOI] | ANSI/NISO Z39.84 - Syntax for the Digital Object Identifier |
| [IEEE LOM] | IEEE 1484-12:2002, Standard for Learning Object Metadata, http://ltsc.ieee.org |
| [IMSBUND] | Using 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech Specifications, v1.0, B.Olivier, M.McKell, 1EdTech Consortium, Inc., August 2001. |
| [IMSCP] | 1EdTech Content Packaging, v1.1.3, 1EdTech Consortium, Inc., June 2003. |
| [IMSES, 04] | 1EdTech Enterprise Services v1.0, 1EdTech Consortium, Inc., June 2004. |
| [IMSPLID] | 1EdTech Persistent, Location-Independent, Resource Identifier Implementation Handbook v1.0, 1EdTech Consortium, Inc., April 2001. |
| [ISO 690-2] | ISO 690-2 Standard Information and documentation -- Bibliographic references -- Part 2: Electronic documents or parts thereof |
| [METS] | Metadata Encoding and Transmission Standard, Version 1.3 |
| [OpenURL] | ANSI/NISO Z39.88-200x - The OpenURL Framework for Context-Sensitive Services |
| [PRISM] | PRISM v 1.2 Specifications (Publishing Requirements for Industry Standard Metadata |
| [RFC 1766] | Tags for the Identification of Languages, http://www.ietf.org/rfc/rfc1766.txt |
| [RFC 2119] | Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt |
| [RFC 2396] | Uniform Resource Identifiers (URI): Generic Syntax, http://www.ietf.org/rfc/rfc2396.txt |
| [ISO 639-2, part 2] | ISO 639 part 2, Codes for the representation of names of languages -- Part 2: Alpha-3 code, http://www.loc.gov/standards/iso639-2/langhome.html |
| [ISO 11404] | ISO 11404, Language-independent Datatypes, http://www.iso.ch/cate/d19346.html |
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 1EdTech 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 1EdTech 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 1EdTech 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.
| Name | Description |
|---|---|
| sourcedID | An identifier for a Resource List that is unique among the systems being integrated. |
4.1.3.1 Associations
The set of associations for the Resource List ID Pair Class are summarized in Table 4.6.
| Association Class Name | Mult | Description |
|---|---|---|
| resourceList | 1 | The details of the resource list |
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.
The set of associations for the resourceMetadata Class are summarized in Table 4.10.
The citation Class attributes are described in Table 4.11.
The set of associations for the citation Class are summarized in Table 4.12.
The standardIdentifier Class attributes are described in Table 4.13.
The relatedTitle Class attributes are described in Table 4.14.
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
4.5.3 Associations
The set of associations for the resourceListSet are summarized in Table 4.18.
| Association Class Name | Mult | Description |
|---|---|---|
| resourceListGroupAssociation | 1..* | A resource list and the constraints apply for the association of this resource list with this group. |
4.5.3.1 resourceListGroupAssociation
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. 1EdTech 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
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.
| Name | Type | Mult | Description |
|---|---|---|---|
| rightsDescription | MetadataLangStringDType | 1..* | Simple, human readable statement about rights related to Resource List |
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.
| Name | Type | Mult | Description |
|---|---|---|---|
| metadataString | String | 1 | Contains the element data for type string. |
4.7.3.2 Associations
The set of associations for the MetadataStringDType are summarized in Table 4.26.
| Association Class Name | Mult | Description |
|---|---|---|
| sourceSchema | 0..1 | The schema from which the data was sourced. |
4.7.4 MetadataLangStringDType
4.7.4.1 Attributes
The MetadataLangStringDType Class attributes are described in Table 4.27.
| Name | Type | Mult | Description |
|---|---|---|---|
| metadataString | SeqLangString | 1 | Contains a sequence of one or more language versions of the element data. |
4.7.4.2 Associations
The set of associations for the MetadataLangStringDType are summarized in Table 4.28.
| Association Class Name | Mult | Description |
|---|---|---|
| sourceSchema | 0..1 | The schema from which the data was sourced. |
4.7.5 MetadataDateDType
4.7.5.1 Attributes
The MetadataDateDType Class attributes are described in Table 4.29.
| Name | Type | Mult | Description |
|---|---|---|---|
| metadataString | date | Contains the element data for type date. |
4.7.5.2 Associations
The set of associations for the MetadataDateType are summarized in Table 4.30.
| Association Class Name | Mult | Description |
|---|---|---|
| sourceSchema | 0..1 | The schema from which the data was sourced. |
4.7.6 MetadataTokenDType
4.7.6.1 Attributes
The MetadataTokenDType Class attributes are described in Table 4.31.
| Name | Type | Mult | Description |
|---|---|---|---|
| metadataString | String | 1 | Contains the element data where a string is intended to represent a token such as a controlled vocabulary, enumeration etc. |
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
context ResourceListMetadata
inv: rightsDescription.size <= 4096
context Annotation
inv: annotationNote.size <=4096
context Location
context ResourceListIdPair
context Resource
context ResourceMetadata
context Citation
inv: publicationDate.size <= 128
inv: publicationPlace.size <= 512
inv: volumeDesignation.size <= 128
inv: partDesignation.size <= 128
inv: articleNumber.size <= 128
inv: startingPageNumber.size <= 64
inv: endingPageNumber.size<= 64
context RelatedTitle
inv: publicationDate.size <= 128
inv: publicationPlace.size <= 512
inv: volumeDesignation.size <= 128
inv: partDesignation.size <= 128
context StandardIdentifier
inv: standardIdentifierType <= 128
context ItemConstraints
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:
- The extension of the data models being manipulated by the current set of operations;
- 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:
- Inclusion of operations that provide more definitive control over the full set of 'resourceList' records e.g., 'readAllResources()', 'deleteAllResources()', etc.
- 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;
- 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;
- 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 1EdTech 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
1EdTech-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
1EdTech 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
| Title | 1EdTech Resource List Interoperability Information Model |
| Editor | Alex Jackl (1EdTech) |
| Team Co-Leads | Oliver Heyer (UC Berkeley), Mladen Maljkovic (WebCT) |
| Version | 1.0 |
| Version Date | 08 July 2004 |
| Status | Final Specification |
| Summary | This document describes the Resource List Interoperability Information Model |
| Revision Information | July 2004 |
| Purpose | This document has been approved by the 1EdTech Technical Board and is made available for adoption. |
| Document Location | http://www.imsglobal.org/rli/rliv1p0/imsrli_infov1p0.html |
| To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=22 |
List of Contributors
The following individuals contributed to the development of this document:
Revision History
Index
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
I
IEEE 1, 2, 3, 4
1EdTech 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
O
OpenURL 1, 2, 3, 4, 5, 6
Operations
Person
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
W
W3C 1
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Resource List Interoperability Information Model ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech 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.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Resource List Interoperability Information Model Revision: 08 July 2004
