Sharebar?

IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook

IMS Logo IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook

Version 1.0 Final Handbook

Copyright © 2001 IMS Global Learning Consortium, Inc. All Rights Reserved.

The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name:
IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook
Revision: 24 April 2001

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

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.



Table of Contents

1. Introduction
 

1.1 Issues
 
1.2 Scope of Work Proposal

2. Technical Proposal
 
2.1 Existing Schemes for GUIDs
 
2.2 Proposed UID Scheme
 
2.3 URN Use for Learning Resources
 
2.4 IMS Registry/URN Namespace and NSS

3. IMS NSS Information Model

4. Examples

Appendix A - Additional Resources

Appendix B - List of Contributors

About This Document

Revision History

Index

1. Introduction

There is a need for persistent, location-independent, resource identifiers across multiple IMS specifications. A persistent, location-independent, resource identifier is defined as an instance of a data type or data format associated with an item which provides a persistent, immutable label with global scope and indefinite lifetime, and comprises the following:

  • Globally Unique Identifiers (GUIDs)
  • Universally Unique Identifiers (UUIDs)

1.1 Issues

A common IMS solution has not yet been identified. The current lack of a consensual solution is perceived as an obstacle. Some reasons for the lack of common consent are listed as follows:

Organizations have established practices of associating an organization-specific permanent identifying label with individual learning objects, such as elements of content, resources, questions, learners, etc.

Organizations wish to share and exchange objects or communicate information and object attributes with other organizations, and thus need a mechanism for all organizations to uniquely identify the commonality of identification of the shared objects. For example, organization X has a course which includes element a, which it moves to organization Y and Z. If organization Y produces a new course which also includes element a, and then moves that course to organization Z, organization Z may desire to know that the element a it receives from Y is the same as what had already received from X, without attempting to semantically match the two instances of a.

Organizations within the learning community do not have an agreed upon common practice for describing how to identify objects outside of their own organization.

Different IMS specifications have taken a variety approaches to providing unique IDs.

  • The IEEE Learning Object Meta-data (LOM) Specification has placeholders to store pan-organizational identifiers, and notes a problem with the lack of an appropriate labeling mechanism for LOM instances and resources within relationships: "1.1 Identifier: A globally unique label that identifies this resource. This data element is and shall not be used, because there is no specified method for the creation of a globally unique identifier."
  • IMS Content Packaging has identifier fields which are recommended to be unique across all organizations.
  • The IMS Competency Working Group intends to use unique identifiers as the fundamental identification mechanism for reusable competency definitions. The purpose of the Competency specification is to enable the exchange and referencing of definitions so as to reach a common human understanding in learning-related contexts. There are numerous existing and proposed repositories for competency, skills, and outcomes definitions. If this specification is to have any practical effect, it will be necessary to reference these definitions in a unique and machine-retrievable way. The proposed Competency definition data model includes a unique identifier field, currently modeled after the LOM identifier.
  • Uniqueness of elements has been identified as a need within the IMS Question and Test Interoberability (QTI) Working Group. Section 7.6.1 of the QTI Best Practice Guide recommends labels for assessments, sections, and items. Associated is a request that organizations requiring IDs register an organization code with the IMS. Section 7.7.1 also discusses the need for ID scoping and the need for unique identifiers.

According to the SCORM CSF data model, a unique label will:

  • better position the SCORM community for true content interoperability at the "learning object" level (instead of just interoperating at the course level),
  • eliminate the need for the "developer" label, as a content element would be uniquely identified for all systems at all times,
  • likely reduce the number of lookup tables or linked lists that a runtime system would need to maintain to track content element relationships,
  • enable content to easily report values at runtime for any content element that it recognizes by referencing the unique identifier (for instance, in a block testing scenario where content has an internal representation of the mapping between assessment items contained within a content presentation resource for a presentation resource that is separate from the assessment resource).

The proposed specification for the IMS Content Communication Model includes a description of extensions which require addressing a "unique content module identifier".

None of the IMS specifications identify an adequate scheme to define the data type or representation for such a unique identifier.

Conceptually, a globally unique or persistent, location-independent identifier is the generic agreed upon mechanism to identify and label resources which addresses these issues.

1.2 Scope of Work Proposal

The scope of this document is to develop a common approach to providing persistent, location-independent, resource identifiers which can be used across all IMS Specifications. This may include:

  • developing a detailed definition and scheme for unique identifiers
  • initiating harmonization of the existing specifications
  • developing necessary practice guides

The scope also inculdes the creation of any essential infrastructure needed to enable users to create and use unique identifiers. This may include:

  • establishing a registration or registry process
  • developing a prototype implementation

2. Technical Proposal

Build upon established practice of using global identifiers in different communities. Leverage specifications from other communities which define persistent identifiers.

2.1 Existing Schemes for GUIDs

Various schemes are used within different communities to identify their items, both for digital and physical assets (e.g., ISBN, DOI). Certain schemes require central registration authorities, while others do not.

  • Registration-based schemes may involve registering each identifier individually (e.g., DUNS), registering blocks of identifiers (e.g., MAC [ethernet hardware adapter] addresses), or registering a prefix or namespace (e.g., URN).
  • Schemes without registration involve a computational process to produce an ID. A detailed discussion of different models for automatic generation of UIDs is in [UUID/GUID]. The described process is designed to produce IDs with uniqueness over a long time period [1582CE to circa 3400CE] via use of system clock and MAC addresses, or IDs with very low probability of overlap via random generation.

There is a variety of practice in defining and using GUIDs. Each of the different schemes has a different model for allocating or computing part of the ID within an overall framework. Reliance upon registration authorities, especially for creating each ID, is perceived as unreliable or unscalable. In general, there is no agreed upon single approach or universal schema for GUIDs.

The remainder of this document is a strawman base proposal. Technical work is needed to validate this approach and complete the details or develop a viable alternative.

2.2 Proposed UID Scheme

The IETF Uniform Resource Name (URN) is proposed as a candidate for the IMS UID scheme.

"Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc." (RFC 2141: URN Syntax, Introduction)

The URN syntax is: URN:<nid>:<nss> where <nid> is the Namespace Identifier and <nss> is the Namespace Specific String. The namespace is a collection of uniquely-assigned identifiers. A URN NID is used to ensure global uniqueness of URNs and possibly provide a mechanism to decode the structure of the identifier. An organization may apply for a (formal or informal) NID from the IANA. The namespace string is the unique, persistent object ID within a namespace.

The URN is an appropriate candidate:

  • existing, recognized international specification,
  • minimum reliance on registration authorities,
  • respected registration authority (Internet Assigned Numbers Authority, IANA),
  • operates in a managed namespace,
  • permits other UIDs (e.g., ISBN) to be encoded into the URN syntax [RFC2288] (e.g., URN:ISBN:0-395-36341-1, URN:SICI:1046-8188(199501)13:1%3C69:FTTHBI%3E2.0.TX;2-4),
  • provides a mechanism for each namespace to define the syntax, semantics, and process to create UIDs within the namespace,
  • provides a mechanism for encoding URNs for data storage and transmission.

2.3 URN Use for Learning Resources

URN use for learning resources should be governed by a set of common principals.

  • Existing URN schemes should be used for all objects which have a formal URN scheme.
  • Large organizations should obtain their own NID. In such URNs, the NSS is opaque. If the organization does not have a formal scheme for generating the NSS, the approach outlined below should be used.
  • IMS should obtain an NID and develop an NSS scheme for organizations that do not want to obtain their own NID and/or use their own NSS scheme.
  • Any organization may use the experimental URN namespace for testing purposes, but items with such IDs cannot be deemed unique during exchange.
  • An organization receiving an object with a URN will determine if it trusts the uniqueness of the URN (e.g., an experimental URN would not be trusted for recording objects in a repository).
  • An organization which receives an object with a trusted URN must preserve the URN and upon export or transmission, it must label the object with the original URN. If the receiver does not trust the URN, it may either replace it or preserve it.
  • If an organization receives two objects from different sources with the same trusted URN, the receiver should assume the objects are identical.
  • Lexical equivalence of URNs is based on their encoding scheme.
  • Multiplicity of URNs for a single object are currently out of scope for this proposal.

2.4 IMS Registry/URN Namespace and NSS

IMS should apply for a URN Namespace and develop a single best-practice model for Namespace Specific Strings. RFC 2611 defines the formal process needed to obtain a NID.

In lieu of the IMS formal namespace, use the experimental namespace: URN:X-IMS-PLIRID-V0. (Syntax of the NID is open for discussion.)

The namespace string within the IMS NID should be structured, but not require a further formal registration process. For process of exchange and matching equivalence of objects, the NSS and URN may be treated as opaque.

If a formal UID scheme exists for the resource, but the scheme is not a URN, the formal scheme should be used within the IMS namespace (e.g., URN:X-IMS-PLIRID-V0:ISBN:0-201-83599-1).

If a formal UID scheme does not exist for the resource, use the IMS scheme for the namespace string.

3. IMS NSS Information Model

An IMS NSS consists of the following parts:

  • A set of control flags which can be used to decode the NSS:
    • Is the scheme a formal scheme (e.g., an ISBN number)?
    • Should the URN be trusted?
    • ...
  • If the NSS is part of some formal scheme, the NSS consists of two additional parts:
    • The label for the formal scheme (e.g., ISBN). A mechanism for resolving the formal scheme is not defined.
    • The identifier in the formal scheme (e.g., the ISBN number).
  • If the NSS uses the IMS scheme, there are two options, a sourced UID and an unsourced UID. In an unsourced UID, the owner or creator of the NSS is not encoded within the NSS. In a sourced UID, the owner or creator of the NSS is encoded within the NSS.
  • An IMS unsourced UID NSS consists of two parts:
    • An empty label.
    • A 128-bit string (16 octets) identifier, generated as described in the IETF and DCE UUID/GUID specification. The octets are encoded as 32-byte ASCII string (e.g., 6ba7b8149dad11d180b400c04fd430c8).
  • An IMS sourced UID NSS consists of four parts:
    • The label for the source (e.g., DUNS, DNS). A mechanism for resolving the formal scheme is not defined.
    • The identifier for the source (e.g., the DUNS number). The sourced value is assumed to be formally registered via the registration mechanism associated with the source. The process of registration is outside the scope of the URN and NSS.
    • The label identifying the scheme for the ID within the NSS. It may be empty, or may be a formal scheme.
    • The identifier within the scheme.

Modified BNF syntax for the URN

 

<GUID>
::= <3rd Party URN> | <Experimental URN> | <IMS URN>
<3rd Party URN> 
::= "URN:" <registered nid> ":" <registered nss>
<registered nid> 
::= formal registered NID as defined in RFC 2611
<registered nss> 
::= NSS which corresponds to scheme registered for NID
<Experimental URN> 
::= "URN:" <Experimental nid> ":" <nss>
<Experimental NID> 
::= "X-"<NID>
<NID> 
::= <NID> as defined in RFC 2141
<NSS> 
::= <NSS> as defined in RFC 2141
<IMS URN> 
::= "URN:" <IMS NID> ":" <IMS NIS>
<IMS NID> 
::= formal registed NID as defined in RFC 2611, <NID> syntax as defined RFC 2141
<IMS NIS>
::= <Formal NIS Scheme> | <IMS NIS Scheme>
<Formal NIS Scheme>
::= <Scheme label> <delimiter> <Scheme identifier>
<IMS NIS Scheme>
::= <IMS Unsourced Scheme> | <IMS Sourced Scheme>
<IMS Unsourced Scheme>
::= <delimiter> <DCE UUID/GUID>
<DCE UUID/GUID>
::= string generated by DCE UUID/GUID algorithm
<IMS Sourced Scheme>
::= <Source> <delimiter> <Scheme>
<Source>
::= <Source label> <delimiter> <Source identifier>
<Scheme>
::= <Scheme label> <delimiter> <Scheme identifier>
<Source label>
::= string which conforms to <NSS> as defined in RFC 2141
<Source identifier> 
::= string which conforms to <NSS> as defined in RFC 2141
<Scheme label> 
::= string which conforms to <NSS> as defined in RFC 2141
<Scheme identifier> 
::= string which conforms to <NSS> as defined in RFC 2141
<delimiter> 
::= single character to be selected

 

The exact encoding of the NSS into a linear syntax as a set of bytes or octets is to be developed. The mechanism of encoding an URN for data transmission is based on the formal URN syntax.

An encoded URN may be placed within a field in an XML field data instance. Other specifications should refer to such an item as the IMS GUID data type.

4. Examples

The examples are theoretical, not based on real data or registration of NIDs.

  • URNs based on registered organizational NIDs:
    • URN:NETG:12345678901234567890
    • URN:CMU:(12-411-2.0)\homework\incometax\deprec\topic\question\Module12-v02-0010v1.1

URN within the IMS NID using a formal NIS scheme:

  • URN:IMS-PLIRID-V0:ISBN:0-201-83599-1
  • URN within the IMS NID using a the IMS NIS scheme:
    • URN:IMS-PLIRID-V0::6ba7b8149dad11d180b400c04fd430c8)
  • URN within the IMS NID using a sourced NSS without a scheme:
    • URN:IMS-PLIRID-VO:DUNS:05-218-4116::6ba7b8149dad11d180b400c04fd430c8

Appendix A - Additional Resources

IEEE Learning Object Meta-data (LOM)

The IEEE Learning Object Meta-data (LOM) Draft Standard http://ltsc.ieee.org/doc/wg12/

IMS Documents

IMS Question & Test Interoperability Best Practice and Implementation Guide http://www.imsglobal.org/question/

IETF Documents

RFC 2141 URN Syntax. R. Moats. May 1997. (Format: TXT=14077 bytes) (Status: PROPOSED STANDARD) http://www.ietf.org/rfc/rfc2141.txt

RFC 2168 Resolution of Uniform Resource Identifiers using the Domain Name System. R. Danie1, M. Mealling. June 1997. (Format: TXT=46528 bytes) (Status: EXPERIMENTAL) http://www.ietf.org/rfc/rfc2168.txt

RFC 2288 Using Existing Bibliographic Identifiers as Uniform Resource Names. C. Lynch, C. Preston, R. Daniel. February 1998. (Format: TXT=21628 bytes) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc2288.txt

RFC 2611 URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. June 1999. (Format: TXT=26916 bytes) (Also BCP0033) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2611.txt

UUIDs and GUIDs, INTERNET-DRAFT, Network Working Group, Paul J. Leach, Rich Salz, February, 1998 (http://www.ics.uci.edu/~ejw/authoring/uuid-guid/draft-leach-uuids-guids-01.txt)

Appendix B - List of Contributors

The following individuals contributed to the development of this specification:

 

 

Bill Blackmon

Carnegie Mellon University

 Daniel Rehak

Carnegie Mellon University

Boyd Nielsen

NETg

 Robby Robson

Saba

Claude Ostyn

Click2Learn, Inc.

 Tom Wason

IMS

 

About This Document

 

 

Title

IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook

Editor

Mark McKell

Version

1.0

Version Date

April 2001

Status

Final Handbook

Summary

This document describes the Best Practice for implementing IMS Persistent, Location-Independent, Resource Identifiers.

Revision Information

24 April 2000

Document Location

http://www.imsglobal.org/implementationhandbook/imsrid_handv1p0.html

 

Revision History

 

 
Version No. Release Date Comments

Handbook 1.0

24 April 2001

Based on second draft of scope document from 3 November 2000.

 

Index

B
BNF 1

C
Contributors 1

E
Examples 1

G
GUIDs 1, 2

I
IANA 1
IETF 1, 2
issues 1

L
LOM 1, 2

N
Namespace Specific Strings 1
NID 1
NIDs 1
NSS 1, 2

O
opaque 1

P
Proposal 1

S
scope 1
SCORM 1
syntax 1

U
UID 1, 2
URN 1, 2
UUIDs 1

 

 

 

 

IMS Global Learning Consortium, Inc. (“IMS”) is publishing the information contained in this IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook (“Handbook”) for purposes of scientific, experimental, and scholarly collaboration only.

IMS makes no warranty or representation regarding the accuracy or completeness of the Handbook.
This material is provided on an “As Is” and “As Available” basis.

The Handbook 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 Handbook as it relates to you.

IMS would appreciate receiving your comments and suggestions.

Please contact IMS through our website at http://www.imsglobal.org

Please refer to Document Name:
IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook Revision: 24 April 2001