IMS Resource List Interoperability Best Practice and Implementation Guide 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 Best Practice and Implementation Guide
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 behavior 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 primarily map to subsets of the IEEE-LOM (Learning Object Metadata) and ISO 690-2 bibliographic citation standards 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 (please see Information Model for a fuller description).

1.2 IMS RLI Specification Components

This document is the IMS RLI Best Practice and Implementation Guide. As such it should be used in conjunction with:

• IMS Resource List Interoperability Information Model;
• IMS Resource List Interoperability XML/WSDL Binding;
• IMS Resource List Interoperability Conformance Requirements.

1.3 Structure of this Document

The structure of this document is:

1.4 Nomenclature

1.5 References

2. Relationship to Other Specifications and Standards

2.1 Meta-data

The RLI specification structures the description of resources and resource lists for the purpose of easily sharing them between the meta-data and content repositories (OPACs, electronic journals, etc.), of libraries, publishers and their vendors, and the course management systems and learning object repositories of the e-learning domain. To better ensure close interoperability with the IMS community's meta-data specification for describing learning objects and because the RLI specification has been generated within that community, the IEEE-LOM data model standard forms the foundation of the RLI data model.

The IEEE-LOM alone, however, is insufficient to describe the reading list resources typical of the library and publishing communities that the RLI specification addresses in particular. This situation is complicated by the fact that libraries and publishers themselves employ no basic, universal bibliographic meta-data standard that describes the full range of textual content they provide. The IMS RLI specification consequently uses meta-data elements from a number of standards to describe a resource list and its component resources. The following sections briefly treat each of the meta-data schemas that contributed elements to represent the RLI data model. It should be emphasized that the RLI element set is not intended to be the missing universal bibliographic meta-data standard alluded to above; but RLI does define a core set of elements sufficient to support a full range of basic bibliographic citation types and standard locator schemas.

Finally, it should also be noted that there is a very close relationship between the emerging OpenURL resource locator standard and RLI (see details in sub-section 2.2.1). Growing compliance with OpenURL will ensure that the kind of structured meta-data standard citations required will be readily available to those applications intending to use them.

2.1.1 IEEE Learning Object Metadata Standard

The IEEE LOM data model has been developed to describe complex digital "learning objects", e.g., an interactive simulation; yet, it is also fairly general in its scope. Because of the LOM's broad purview, many of the RLI meta-data elements within the RLI Information Model map fairly readily to the LOM. Despite the relative ease in mapping to RLI meta-data elements, the LOM is not fully suited to describe a fundamental requirement of RLI, a bibliographic citation; nor does it provide a means for describing all the meta-data needed to support standard locator schemas, another requirement.

For a bibliographic citation, the LOM lacks adequate semantic specificity and structure. In addition, it does not provide for the sequencing of elements which is important for certain citation types, i.e., part of a whole such as a volume in a multi-volume set, a chapter of a book, or an article in a particular issue and volume of a journal series.

Structurally, the meta-data within the LOM for several key components of a bibliographic citation is stored in a single element, 7.2.2:Resource.Description. This concatenation of elements makes it much more difficult to parse and display the information in a typical bibliographic citation format, as recommended by as ISO 690-2 (see sub-section 2.1.2).

Ironically, the element concatenation of the LOM matches the treatment of citation meta-data by many of the content vendors whose resources the RLI specification targets. To date there has been virtually no compliance with the ISO standard or adoption of any other consistent format across the vendor community. To accommodate this fact, desktop bibliographic management software such as ISI's EndNote and ProCite come packaged with multiple filters to parse and regularize the various ways that the different vendors structure citations. The lack of a consistent format has prevented the standardization of a method to import and export the meta-data necessary to aggregate discrete resources into resource lists. This makes it necessary to customize solutions for any implementation, resulting in aggregations that are very difficult to share; (and hence the value of an RLI specification).

Finally, the IEEE-LOM element 2.3.2:Lifecycle.Contribute.Entity does not contain a value for "owner" that is required by the RLI data model. This element was considered necessary for purposes of documenting, at the resource list level, the entity having the authority to decide about the permissions and constraints related to re-use of the resource list.

Please see sub-section 2.2.1 for implementation recommendations and the itemized list of elements that map directly to the LOM. See also RLI Data Model (section 4 of Information Model) for the semantics of each element.

2.1.2 ISO 690-2 Citation Format

The first release of the IMS RLI specification expressly addresses traditional lists of resources, i.e., reading lists. Thus, the descriptive elements for the resources within this type of resource list are closely aligned to typical bibliographic citations, as described by the ISO 690-2 standard for bibliographic citations of electronic materials.

Another RLI element that does not appear either in the IEEE-LOM, or in the OpenURL specifications, but is included in the ISO 690-2 requirements is "Publication Place". It could be argued that from an electronic resources point of view, the place of publication is less relevant than in the print world. Instead, it is once again, the reliable locator of the resource that is most important. For this reason, the RLI specification does not require the "Publication Place" element, but does include it since many content providers provide the information as part of the meta-data that accompanies the display of the resource.

Please see sub-section 2.2.1 for implementation recommendations and the itemized list of elements that maps directly to the ISO 690-2 standard. See also RLI Data model (section 4 of Information Model) for the semantics of each element.

2.1.3 Dublin Core

The "Resource Type" element within the RLI specification for which the value is "bibliographic citation" does not exist, per se, in the IEEE-LOM. The dc:type element from the Dublin Core schema is used for describing these semantics. Also note that the value "bibliographic citation" is not included in the DC Type Vocabulary although a proposal to include such a phrase has been made and withdrawn in the past few years. The Learning Resource Type Vocabularies identified in the CanCore Guidelines for the Implementation of Learning Object Metadata 1.9 do not have a similar term either. Hopefully, one of the results of the successful adoption of the RLI specification will be the inclusion of an appropriate term either within one of the Learning Resource Type Vocabularies or the DC Type Vocabulary.

Future specifications will include implementation recommendations and the itemized list of elements that map directly to the Dublin Core. See also RLI Data Model (section 4 of Information Model) for the semantics of each element.

2.2 Locators

The RLI data model provides a "locator" element to store any locator information as part of the meta-data associated with a given resource and/or resource list. As well, the model contains other meta-data elements necessary for an application to construct OpenURLs and DOIs, if desired.

2.2.1 Resolvable Locators - OpenURL

NISO's OpenURL locator standard enables the context-sensitive resolution of user requests for digital library objects. Requests are fulfilled by the transmission of meta-data for the objects, including standard identifiers, to a resolution service, which in turn provides additional services available to the requesting user (e.g., full text for an article, an inter-library loan request form, etc.), depending on the user's institutional affiliations and authorizations or "context".

It is the San Antonio Profile Level 1 (SAP1) for journal or book of the OpenURL v 1.0 specification which provides a means to describe resources in citation format. In addition, SAP1 allows a citation to be further described by denoting the context in which a particular resource resides, such as the whole document of which a subpart is being cited. SAP1 encourages the parsing of citation meta-data so that it can be constructed as part of the locator string. For this reason, the RLI specification recommends that applications using RLI meta-data import and order the descriptive elements as discrete elements that correspond to those needed to construct an OpenURL, or use/leverage existing OpenURL locators in the resource records, when available.

Here is an example of a v1.0 OpenURL:

url_ver=Z39.88-2003
&url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx
&rfr_id=info:ofi/rfr:db:mimas.ac.uk:zetoc
&rft_val_fmt=info:ofi/fmt:kev:mtx:journal
&rft.genre=article
&rft.atitle=Phase compositions...
&rft.jtitle=Scripta Materialia&rft.issn=1359-6462
&rft.aulast=Apps&rft.auinit=P.J.&rft.date=2003
&rft.volume=48&rft.issue=5&rft.spage=475&rft.epage=48

[From PowerPoint presentation of Ann Apps at NISO workshop on OpenURL, October 29, 2003, http://www.niso.org/standards/resources/appsopenurl-using.ppt]

OpenURL is not yet a universal standard, but its adoption is growing rapidly. It represents the current best chance for a widely accepted, relatively simple, but sufficiently broad meta-data structure for bibliographic data that will actually be implemented by vendors who have previously relied on proprietary solutions. Because RLI conforms to the San Antonio profile, Level 1, it should be relatively straightforward for OpenURL-compliant vendors to provide equally rich meta-data in the RLI format.

Future specifications will include implementation recommendations and an itemized list of elements that map directly to OpenURL. See also RLI Data Model (section 4 of Information Model) for the semantics of each element.

2.2.2 Other Locators

See the RLI Data Model (section 4 of Information Model) for the semantics of each element.

2.3 Behavior Services

2.3.1 IMS Enterprise Services Specification

The RLI abstract interface defines fairly generic Create/Read/Delete operations that are paralleled in the IMS Enterprise Services Specification. One element critical to the practical implementation of RLI is establishing a relationship between a resource list and a "class" or group of users within a course management system. The IMS Enterprise concept of Group can define a class to which a resource list is assigned or associated through the Resource List Assignment operation. The association between resource list and class is created at runtime and subsequently managed within the target system. Both the sending and target systems will need a common understanding of a Group (although this might not include membership data).

2.4 Content Packaging

2.4.1 IMS Content Packaging Specification

IMS Content Packaging is a specification for packaging learning resources (for example resource lists) for easier transport from one system to another, facilitating easier delivery, reuse, and sharing of materials. IMS Content Packages enable the export of content from one virtual learning environment, content management system, or digital repository, and import into another while retaining information describing the learning resources and their organization (such as a table of contents). The use of the IMS Content Packaging specification to package instances of other IMS specifications such as IMS RLI is described in the IMS implementation handbook "Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications" [IMSBUND]. In the context of IMS RLI an IMS Content Package contains a resource list manifest that may include individual Resources and/or other Resource Lists. The Package Interchange File can be a ZIP, JAR, or a TAR file. The manifest is an XML file that describes what the Package contains and how the content is organized. The manifest XML file contains three main sections:

• a Meta-data section that describes the whole IMS Content Package;
• a Resources section that lists the resources in the IMS Content Package and any meta-data that describes them;
• an Organizations section that describes the structure of the resources within the IMS Content Package.

For a Content Package containing a resource that is an XML-bound instance of a resource list conforming to this specification, the Resources section should specify that the resource is of type imsrli_xmlv1p0.

2.5 Digital Repositories

2.5.1 IMS Digital Repositories Interoperability Specification

There is a strong relationship with the IMS Digital Repositories Interoperability (DRI) specification in that DRI and RLI are focused on interoperability within environments that span both online information services and e-learning provision. Both specifications are also focused on managing assets and meta-data as well as collections of information objects and learning objects.

In providing a broad interoperability context the IMS DRI Information Model also presents a functional architecture that focuses on the most common repository functions (search/expose, gather/expose, submit/store, request/deliver, and alert/expose). These functions clearly have a role in managing resource lists.

The IMS DRI Best Practice Guide details operational recommendations that have been adopted within RLI, in particular Web Services. The RLI abstract interface is expressed as a WSDL file, with SOAP specified for messaging and transport. Other recommendations have relevance for the searching and gathering of individual resources as well as resource lists per se.

3. Creating, Managing, and Using Resource Lists

While there has not been a great deal of published discussion about the practices of creating, managing, and using Resource Lists, per se, there has been related work going on in the Dublin Core Metadata Initiative. The Dublin Core Citation Working Group is in the process of writing guidelines for encoding bibliographic citation information in Dublin Core Metadata which may have some impact upon the practices associated with creating, managing, and using Resource Lists, and consequently upon the RLI specification, thus requiring future revisions of this specification.

4. Implementation Recommendations

Until there are reference implementations of the RLI specification, it is difficult to anticipate what would be the best practices associated with implementing it in any of the several repository or learning environments in which they might be found. Therefore, this section of the RLI specification will undoubtedly be expanded in the future.

5. Stakeholders

There are a number of stakeholders who stand to benefit from this specification. These stakeholders have been grouped into the following categories (a brief example use case is illustrated in the subsequent paragraphs; many of the use cases are applicable to multiple stakeholders and should not be considered exclusive to or exhaustive of a particular domain):

• Learners:
  Learners will be able to easily access selected resources and/or specific resource lists, made available to them within the context of a specific learning environment.
• Faculty:
  Faculty will be able to log in to their course environment, and from there, search/browse for relevant library and other resources, build a resource list, and incorporate the resource list into the course environment, where it would become available to learners.
• Instructional designers:
  Instructional designers working with an authoring tool will be able to easily access resource lists and incorporate resources from them into structured course content in the fashion of other learning objects.
• Librarians:
  Librarians using a combination of library services will be able to select resources or use instructor-selected resources to build resource lists for specific courses or subject areas. Librarians would publish specific resource lists associated with particular courses or send them to a digital repository with the meta-data necessary for ready incorporation into a course management system.
• Course management system vendors:
  Course management system vendors will be able to integrate course management systems with library systems, content repositories and digital libraries that maintain reading lists through the exchange of resource list meta-data.
• Learning content management system vendors:
  Learning content management system vendors will be able to integrate learning content management systems with library systems, other content repositories and digital libraries that maintain reading lists through the exchange of resource list meta-data.
• Library system vendors:
  Library system vendors will be able to integrate library systems with course management systems through the exchange of resource list meta-data. Integrated Library Systems (ILS) that support course reserves, federated searching of catalog and article databases and bibliographic management facilities already provide services for the creation of personal reading lists. The definition of these lists as RLI meta-data will enable their ready transport into the course context.
• Content repositories:
  Content Repositories will be able to incorporate resource lists from other systems and store them as searchable digital objects. Content Repositories will also be able to receive resource list updates from the originating systems.
• Content publishers:
  Content publishers will be able to build resource lists in particular subject areas and publish them into searchable repositories for distribution to customers. Customers may acquire and deploy resource lists as learning objects for incorporation into course content.

6. Application Scenarios

These application scenarios comprise the functional requirements that were used to determine the scope and structure of the Information Model. They are included to help readers gain an understanding of the range of uses to which RLI may be put and to provide the initial ideas to help people apply RLI to their problems. The scenarios are not meant to imply any degree of constraint.

6.1 Use Case 1

Title: Resource List Is Created Based on Federated Search of Library and Third Party Licensed Databases

Goal: Instructor wants to create a new Resource List within a course that may include any of the following:

• Citations to print only articles within journals that the institution's library owns, with links to journal record and specific volume/copy information within the Online Public Access Catalog.
• Citations to print only books that the institution's library owns, with links to monograph record and volume/copy information within the Online Public Access Catalog.
• Citations to electronic books and journal articles, with links to the full text.

Scenario:

• Instructor searches library catalog and third-party licensed databases for desired resources.
• Instructor selects desired resources among search results to add to the Resource List.
• Instructor saves Resource List.
• Instructor exposes Resource List within the course environment.

6.2 Use Case 2

Title: Online Public Access Catalog Records of Printed Materials in a Resource List Are Prepared for Course Reserves

Goal: An instructor designates printed materials for course reserves in a Resource List.

Scenario:

• Instructor selects records for printed materials from an existing Resource List.
• Instructor submits records to Online Public Access Catalog's course reserves module.
• Reserves module flags corresponding records in the OPAC for course reserves processing.
• Library staff modify appropriate records to activate course reserves list.

Alternate Scenarios:

The two previous use cases assume that instructors are the primary actors in the resource list creation process. Depending on institutional preferences, other staff, including library personnel, could be assigned and authorized to first create and then expose a resource list within the course environment.

6.3 Use Case 3

Title: Resource List Is Shared Between Courses and/or Course Management System (CMS) Environments

Goal: Instructor wants to move a resource list from one course or course management system to another.

Scenario:

• Instructor selects from a Course or CMS a resource list to share.
• Selected resource list is exported from a Course or CMS.
• Created resource list is imported into another Course and/or CMS.

6.4 Use Case 4

Title: Supplying the Learner with a Course Reading List

Goal: A learner within a CMS wants to access a resource list to locate readings and cite them in a bibliography.

Scenario:

• Learner chooses to view the resource list within a course.
• Learner chooses to view a resource from the resource list that is described within the Library Online Public Access Catalog.
• Learner is taken to the Library system which displays selected resource, either as a catalog record for an item in printed format or as a link to the item itself if in electronic format.
• Learner selects resource from the resource list.
• Learner exports resource meta-data.

6.5 Use Case 5

Title: Resource List is Created from Harvested Meta-data in a Personal Database

Goal: Instructor wants to create a new resource list using previously retrieved and stored citations from various information sources.

Scenario:

• Instructor opens personal database and selects resource records for inclusion in the resource list.
• Instructor exports selected records in IMS RLI format.
• Instructor uploads list of records into CMS or resource list creation tool.
• Instructor exposes resource list within the course or virtual learning / learning management environment.

6.6 Use Case 6

Title: Resource List is Modified by the Instructor to Include Local Content

Goal: Instructor wants to edit an existing resource list to include locally created content, e.g., an unpublished manuscript.

Scenario:

• Instructor opens existing resource list.
• Instructor adds meta-data into IMS RLI fields for file previously uploaded into course management system.
• Instructor saves modified resource list.

This showcases that resource lists when they arrive in a system should allow editing.

6.7 Use Case 7

Title: Extensibility for Vendor Specific Needs

Goal: Allow vendors (and other parties creating or managing learning resources) to extend the specification and incorporate proprietary extensions to the meta-data elements needed.

Scenario:

Vendor extends to resources specification to include proprietary information necessary to use or manage the resource list within the vendor's system.

6.8 Use Case 8

Title: Propagate Resource and Resource List changes to the system in which it is being managed Goal

Goal: Allows propagation of changes in the individual resources and entire resource lists to the management system. It assumes that the individual resource or resource list has been already created.

Scenario:

• New version of a resource list has become available, e.g., a new edition of a book that has just been received by the Library Acquisitions Department is included on the Course Reserve List managed by the campus Library ILS vendor.
• Faculty members using that resource list are notified of changes made to the resource list, and are given the option of accepting or rejecting it's inclusion in the environments in which it is currently being used. (Optionally, this behavior could have been set during create and/or deploy action for particular Course Resource or resource list; this would be an example of two way communication between Library and CMS Systems.)
• If Faculty decides to accept new version of Resource List, subsequent Learners accessing the Course Resource or resource list are presented with a new version.

6.9 Use Case 9

Title: Harvesting and Reusing of Resource and Resource List Meta-data

Goals:

• Allows reuse of resource meta-data, coming from different systems and following different schemas, for resource.
• Allows creation of resource list meta-data.
• Provides tracking of administrative actions in the resource and resource list meta-data.

Scenario:

• Meta-data imported from various content providers maps into required and desired meta-data for newly created resources and resource lists.
• Resource and resource list meta-data is edited and modified, if necessary or desired upon inclusion into the learning environment.
• Administrative information (edit log, versions) is associated automatically in the resource and resource list meta-data.

6.10 Use Case 10

Title: Facilitating Reuse of Resources and Resource Lists by means of Annotations (References)

Goals:

• Allows faculty to create multiple pedagogic annotations for each resource and resource list.
• Provides contextual information about the individual resource or resource list. Facilitates more granular referencing and use of discrete resources within a resource list, thus allowing more flexible reuse of resources within a learning environment.

Scenario:

• Faculty creates new Annotation(s) for a desired resource or resource listing.
• Thereafter, Annotations become a part of resource or resource list (in case of Resource export, and then import, annotation would also export and import).

6.11 Use Case 11

Goal: A library's digital repository is used to archive selected resource lists that have been used and within a VLE. The resource list and its meta-data are retained in the digital repository separately, but include contextual information about where the resource list has previously been used in the VLE. The VLE deactivates and archives courses that are not currently being taught. These courses may be reactivated in future terms, and instructors can then access the resource list and use it in the reactivated course, or in other courses. Changes to the resource list are added to the resource list archive as a newer version of the original resource list.

Scenario:

• A previously instantiated course is reactivated for the current term, thus making the resource list associated with the course visible to the current instructor.
• Instructor chooses to keep as part of the new version of the course the resource list used previously.
• The Instructor modifies the list.
• The modified resource list is archived with the course once the course is completed, and also separately within the digital repository.

6.12 Use Case 12

Goal: Resource list managers wish to create a list containing zero items. Empty resource lists may also be created automatically as part of the initial set up of a course environment.

Scenario:

• The instructor instantiates a list within the resource list manager.
• The instructor exits the system without entering an item in the resource list.
• Teaching Assistant adds resources to the list at a later dateTime.

About This Document

List of Contributors

The following individuals contributed to the development of this document:

Revision History

Index

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

C
CanCore 1
Catalog 1, 2, 3
Citation 1, 2, 3, 4
Content Package 1
Course
     content 1
     environment 1, 2, 3

D
Dublin Core 1, 2

I
IEEE 1, 2, 3, 4
IMS Specifications
     Content Packaging 1, 2, 3
     Digital Repositories Interoperability 1
     Learner Information Package 1, 2
     Resource List Interoperability 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     Vocabulary Definition Exchange 1
Interoperability 1, 2
ISO 1, 2, 3, 4

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

M
Meta-data 1, 2, 3, 4, 5, 6, 7, 8, 9

N
Normative 1

O
OpenURL 1, 2, 3

P
Preferences 1
Profile 1

R
Records 1, 2, 3
Repositories 1, 2
Resource 1, 2, 3, 4, 5, 6
Resource list 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Resource list meta-data 1, 2
Resources 1, 2, 3, 4, 5, 6, 7, 8, 9
RFC 1

S
Schema 1
SCORM 1
Services 1, 2, 3, 4
Standards 1, 2
Structure 1, 2, 3

W
W3C 1

X
XML 1, 2, 3