About "INFO" URIs

Frequently Asked Questions

The Questions

1. Background (I)
2. Background (II)
3. INFO and Other URI Schemes
4. The INFO Registry
5. Syntax Considerations
6. Examples of Usage
7. Comparing INFO URIs
8. Historical Perspective

1. Background (I)  <<
   1. What is a URI scheme?
   2. Where is the specification for INFO?
   3. Why was it necessary to develop the INFO URI scheme?
   4. What was the motivation behind the INFO URI scheme?
   5. Does the INFO URI scheme compete with other URI schemes?
   6. Could the INFO URI scheme break Web applications?
   7. Who developed the INFO URI scheme?
   8. Why is the scheme called INFO?
   9. What is the status of the INFO URI scheme?

2. Background (II)  <<
   1. What is the value proposition of the INFO URI scheme?
   2. What is unique about the INFO URI scheme?
   3. And just what is a non-globally dereferenceable URI?
   4. So, why are INFO URIs not globally dereferenceable?
   5. Why identify information assets with URIs anyway?
   6. Can anyone use their namespaces under INFO?
   7. Who is entitled to register under INFO?
   8. Which namespaces are eligible for registration under INFO?
   9. Does registration under INFO limit any future URI registration?

3. INFO and Other URI Schemes  <<
   1. What considerations are there regarding URIs?
   2. Why not just use HTTP URIs?
   3. Well then, why not just use URN URIs?
   4. Are there any other URI schemes that might be considered?
   5. So, why not use DATA URIs?
   6. Or else, why not use TAG URIs?

4. The INFO Registry  <<
   1. What is the INFO Registry?
   2. Where is the INFO Registry located?
   3. Who maintains and operates the INFO Registry?
   4. What policies govern the INFO Registry?
   5. What is the registration procedure for an INFO namespace?
   6. What functionalities does the INFO Registry present?

5. Syntax Considerations  <<
   1. What are the syntax highlights for an INFO URI?
   2. What is the full syntax for an INFO URI?
   3. What does the fragment signify for an INFO URI?

6. Examples of Usage  <<
   1. What do INFO URIs look like?
   2. How are INFO URIs used in Web applications?

7. Comparing INFO URIs  <<
   1. Why is comparison of URIs important?
   2. What steps should be taken to compare two INFO URIs?
   3. Is there an example of comparing INFO URIs?

8. Historical Perspective  <<
   1. What is the historical background to INFO?
   2. What consultations preceded the development of INFO?
   3. What were the next steps in the development of INFO?
   4. What is the current position of INFO?

The Answers

A. Background (I)

1. What is a URI scheme?  <<

   A Uniform Resource Identifier (URI) provides a simple and extensible means for identifying a resource within the World Wide Web global information architecture. Each URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.

2. Where is the specification for INFO?  <<

   The final specification for INFO is RFC 4452. (The five Internet-Drafts that were published to support the INFO URI scheme application are available here on the INFO website.)

3. Why was it necessary to develop the INFO URI scheme?  <<

   The INFO URI scheme was developed from within the library and publishing communities to expedite the referencing by URIs of information assets that have identifiers in public namespaces but have no representation within the URI allocation.

   For various reasons (both cultural and technical) the creation and registration of a new URI scheme or URN namespace to support a given public namespace under the URI allocation may not have been attempted by the authority for that namespace. It is precisely to facilitate the representation of these public namespaces within the URI allocation that the INFO URI scheme was developed.

4. What was the motivation behind the INFO URI scheme?  <<

   The motivation behind developing the INFO URI scheme was to allow legacy identification systems to become part of the World Wide Web global information architecture so that the information assets they identify can be referenced by Web-based description technologies such as XLink, RDF or Topic Maps. Note that we are concerned with "information assets", not "digital assets" per se - the information assets may be variously digital, physical or conceptual.

5. Does the INFO URI scheme compete with other URI schemes?  <<

   No. The INFO URI scheme does not compete with independent URI registrations but rather cooperates with independent URI registrations by providing a lightweight early URI registration mechanism to support referencing of public information assets ahead of any possible subsequent URI scheme or URN namespace application. Note that in the majority of cases no subsequent URI scheme or URN namespace application will be made by a Namespace Authority as the INFO resource identifier alone will be sufficient in providing an identification service. Only if additional services are required would a Namespace Authority seek to register a URI scheme independently.

6. Could the INFO URI scheme break Web applications?  <<

   No. INFO URIs exist primarily to support the representation of identity and comparison with other INFO URIs, and therefore any Web applications that can recognize a URI within a URI usage context should not break with this additional URI scheme. INFO URIs are conformant to the general syntax requirements of URIs as laid out in RFC 3986 and as such are readily parseable and recognizable as legitimate URI strings. Any dereference capabilities associated with any particular INFO namespace are outside the scope of INFO itself.

7. Who developed the INFO URI scheme?  <<

   The INFO URI scheme was developed by members of the library and publishing communities working together under the auspices of ANSI/NISO.

   Representing the library communities are Herbert Van de Sompel of LANL (Los Alamos National Laboratory) Research Library and Stu Weibel of OCLC (Online Computer Library Center), while representing the publishing communities are Tony Hammond of Nature Publishing Group and Eamonn Neylon of Manifest Solutions, a publishing technology consultancy.

   NISO, the National Information Standards Organization, is a standards developing organization accredited to the International Organization for Standards (ISO) by the American National Standards Institute (ANSI), the sole US representative to ISO.

8. Why is the scheme called INFO?  <<

   The scheme is called INFO as a shorthand for the information asset that it references by means of a URI.

   Another reading of INFO is that INFO exists primarily to provide information about an information asset, the information disclosed being confined to identity alone. Richer sets of information, such as authority metadata, would require resolution services which are not directly supported by INFO and hence would require a corresponding independent URI scheme or URN namespace application.

9. What is the status of the INFO URI scheme?  <<

   An Internet-Draft for the INFO URI scheme was first announced September 30^th, 2003 (-00). Subsequent revisions to this draft are available here and were issued in December 2003 (-01), July 2004 (-02), January 2005 (-03), and August 2005 (-04). RFC 4452 was published in April 2006.

   The INFO URI scheme has already been fully embraced by a number of Web description technologies: the OpenURL Framework and the SRU/W information retrieval initiative.

B. Background (II)

1. What is the value proposition of the INFO URI scheme?  <<

   The value proposition of INFO URIs is to facilitate Namespace Authorities in representing identifiers from their namespaces in URI form and so to make those identifiers available for public use in Web-based description technologies independently of any Web infrastructure considerations on behalf of the Namespace Authorities.

   As such, INFO URIs are designed to be simple to deploy, both in terms of namespace registration and in the creation and general usage of these identifiers. These simplifications are fully in line with the INFO URI remit of providing a lightweight URI registration mechanism to facilitate the referencing of information assets under the URI allocation.

2. What is unique about the INFO URI scheme?  <<

   INFO URIs are not globally dereferenceable, nor is there any implication that they may be, although individual Namespace Authorities may register dereference methods on a per-namespace basis. The prime purpose of INFO is the disclosure of the identity of an information asset from a public namespace within the World Wide Web global information architecture.

3. And just what is a non-globally dereferenceable URI?  <<

   A non-globally dereferenceable URI is one that supports no global resolution method, although per-namespace methods may exist as declared by the relevant Namespace Authorities.

4. So, why are INFO URIs not globally dereferenceable?  <<

   INFO is focused exclusively on supporting identity. As such, this focus on the prime functionality of INFO URIs to supporting identity leads to the following considerations:

   • Dramatically simplifies INFO operational behaviours, and consequently the operational expectations of an INFO URI, which are primarily limited to URI string presentation and comparison.
   • Avoids overhead in new INFO namespace registrations by downplaying the possibility of resolution mechanisms.
     (Note that public namespaces may have functionality associated with them which is accessible on the Internet, but INFO does not support a global access route into these functionalities. Applications wishing to tap into this functionalitiesy must consult the INFO Registry on a per-namespace basis.)
   • Avoids overhead in the management of a global resolution infrastructure and maintenance of resolution targets for INFO URIs.
   • Does not run foul of the mantra "many URI schemes considered harmful" as this is primarily concerned with the need for applications to support global resolution mechanisms.

   Note that this stance on non-dereference is in contrast to other URI schemes which are generally dereferenceable (or otherwise actionable by applications), even if not all examples within a particular scheme are actually dereferenceable. This holds true for both location-dependent URIs (e.g. HTTP URIs) as well as for location-independent URIs (e.g. URN URIs).

5. Why identify information assets with URIs anyway?  <<

   The real need for presenting legacy identifiers in URI form is that many Web-based description technologies (e.g. XLink, RDF, Topic Maps, OpenURL, SRU/W) recognize URIs as the only form of globally unique identifier.

   Besides this, the URI naming architecture offers to identifiers a common base syntax, a common base semantics, and a common nomenclature for talking about identifier constructs (e.g. URIs reference "resources" while generally identifiers for information assets will reference diverse kinds of things - objects, records, etc.). The URI thus provides a uniform (and unifying) naming architecture for identifiers.

   The examples FAQ included here might afford some insight into the desirability of rendering identifiers as URIs, cf. the identifiers in their native form and as rendered in URI form.

6. Can anyone use their namespaces under INFO?  <<

   No. Namespaces used under INFO must be registered in the INFO Registry.

7. Who is entitled to register under INFO?  <<

   A Namespace Authority is entitled to register a recognized namespace after suitable review.

   A Namespace Authority is the body that owns and manages a public namespace.

8. Which namespaces are eligible for registration under INFO?  <<

   The namespaces eligible for registration under INFO will typically be those of interest to the publishing, library and media communities. These communities necessarily have a very wide purview. Candidate namespaces will be those that are for public use only and that are not part of the URI allocation. Non-public namespaces are not eligible for registration.

   For all registered namespaces the reader is advised to consult the INFO Registry. The following registered namespaces are typical:

   • bibcodes - NASA Astrophysics Data System Bibcodes (~3.5m)
   • doi - International DOI Foundation Digital Object Identifiers (~20m)
   • lccn - Library of Congress Control Numbers (~12m)
   • oclcnum - Online Computer Library Center (OCLC) Numbers (~52m)
   • ofi - NISO OpenURL Framework Identifiers (~40)
   • pmid - National Library of Medicine PubMed Identifiers (~10m)
   • sid - Source Identifiers (as used by the OpenURL Framework)
   (Note: To put those numbers into perspective, as of an earlier writing the accumulated totals represented some 2.6% of Google space.)

9. Does registration under INFO limit any future URI registration?  <<

   No. On the contrary, by occupying its own toplevel URI scheme, INFO does not restrict a Namespace Authority from proceeding with registration under any portion of the URI allocation either as a toplevel URI scheme or as a URN namespace. In particular, an independent INFO URI scheme does not interfere with any of the existing URI namespaces which have their own defined semantics.

C. Comparison with Other URI Schemes

1. What considerations are there regarding URIs?  <<

   Some general considerations regarding URIs are:

   • Generality - URI schemes are divided between generality and speciality as regards their reliance upon an Internet transport protocol.
   • Location dependence - URI schemes are variously categorized as location-dependent or location-independent with respect to whether the URI contains a network authority component.
   • Character set - The set of allowable characters within a URI is a subset of ASCII. Certain ASCII characters are excluded, while others are reserved within various contexts within the URI string according to the URI scheme in question. Excluded and reserved characters must be %-escaped as described in RFC 3986.
   The wider the character set that a given URI scheme supports, the more easily it can function as a substrate for legacy identifiers.
2. Why not just use HTTP URIs?  <<

   HTTP URIs (RFC 2616) are Internet protocol elements for referencing hypertext documents which can be retrieved from a network authority using the HTTP transfer protocol. There is a common expectation that HTTP URIs can be dereferenced.

   The following considerations hold in respect of HTTP URIs:

   • HTTP URIs are inappropriate for INFO namespaces because HTTP URIs provide:
     • network transport
     • network path (discovery obstacle)
     • strong dereference expectation
     • poor branding (network path overhead)
   • A transport mechanism adds meaningless semantic overhead to nondereferencable URIs.
   • Absolute HTTP URIs include a network path (comprised of an authority component and a hierarchical path component). INFO namespaces may not have (or may not make) any network authority available. A central network authority would also be inappropriate as this would introduce a dependency between a third party namespace and a central network authority.

     Further, were INFO namespaces to make a network authority available they would each have to publish the particular hierarchical path syntax employed by that network authority. A central network authority would mitigate this requirement by providing a single path syntax, although it would still need to publish that path syntax.

   • Use of HTTP URIs might only encourage the provisioning of resource representations (e.g. metadata descriptions) which could conflict with representations provided under any possible future URI registration on the part of the Namespace Authority. Further, if HTTP URIs were used to provide resource representations, it must be recognized that managing the namespace and infrastructure is a costly enterprise that may not be appropriate or cost effective in a given business context.
   • The network path of HTTP URIs adds unnecessary string overhead and consequent loss of branding for legacy identifiers.
3. Well then, why not just use URN URIs?  <<

   URN URIs (RFC 2141) are Internet protocol elements for referencing resources using persistent and location-independent identifiers, representations of which may be retrieved using various resolution mechanisms. There is a common expectation that URN URIs can be dereferenced, once suitable resolution mechanisms are defined (e.g. DDDS or other proprietary mechanisms). Indeed, RFC 1737 goes so far as to make a strong recommendation that "there be a mapping between the names generated by each naming authority and URLs".

   Use of URN URIs requires a URN namespace registration. An informal URN namespace is of limited utility because its numerical nature obliterates any branding or name recognition and effectively renders the namespace anonymous. A formal URN namespace, on the other hand, would require a more substantial review than a corresponding registration under the INFO Registry. Based on experience with the initial INFO namespace target group, it is unlikely that many Namespace Authorities will proceed with independent applications as the burden of registering a URN namespace is high, especially in the case of organizations that are not strongly steeped in technology.

   One particular impediment in applying for a URN namespace for INFO is that this would compromise any possible future URN namespace registration that a Namespace Authority might seek to make in respect of considerations of persistence, location independence and/or dereference to resource representations.

   The following considerations hold in respect of URN URIs:

   • URN URIs are inappropriate for INFO namespaces because URN URIs provide:
     • claims of persistence of resource identifiers
     • dereference expectation
     • no delegated naming responsibility
     • restricted syntax (no hierarchy)
     • no support for fragment identifiers
     • poor branding and extra semantic layer (additional namespace tier)
   • INFO URIs make no claims on persistence. INFO URIs may be location independent and in consequence may enjoy some degree of persistence, but INFO does not make these assertions. Instead INFO is neutral with respect to identifier persistence.
   • Use of URN URIs might only encourage the provisioning of resource representations (e.g. metadata descriptions) which could conflict with representations provided under any possible future URI registration on the part of the Namespace Authority. Further, if URN URIs were used to provide resource representations, it must be recognized that managing the namespace and infrastructure is a costly enterprise that may not be appropriate or cost effective in a given business context.
   • For INFO to operate as a URN namespace would require that INFO be constituted as a delegated naming authority. It is not clear that a URN namespace would be an appropriate choice for such naming authority delegation.
   • Syntactically, URN URIs do not support hierarchy (in URI syntax hierarchy proceeds through the "/" character) and are thus more difficult to use with legacy identifiers because of their restricted character set. Other characters reserved by URN URIs, but allowed by INFO URIs are "&" and "~".

     For a demonstration in the difficulty of mapping legacy identifiers the reader is referred to RFC 3151 which provides a set of complex transcriptions for mapping SGML formal public identifiers onto the URN URI syntax. Formal public identifiers would have been more readily presented under the more expressive INFO syntax.

   • Additionally, URN URIs do not support fragment identifiers thus not allowing the identification of secondary resources with respect to a primary resource. This is a pratical requirement that INFO supports.
   • With INFO as a URN namespace, the INFO namespaces would then become sub-sub-namespaces, with a consequent loss of branding. This would also introduce three tiers of semantic layers for an implementation to navigate.
4. Are there any other URI schemes that might be considered?  <<

   Two other generic URI schemes that might be considered are DATA URIs and TAG URIs.

5. So, why not use DATA URIs?  <<

   DATA URIs (RFC 2397) are Internet protocol elements for the referencing of inline resources, i.e. the reference is an immediate address.

   The following considerations hold in respect of DATA URIs:

   • DATA URIs are inappropriate for INFO namespaces because DATA URIs provide:
     • no authority mechanism (network authority or registry)
     • no globally unique identifiers
   • The DATA URI provides a data resource inline without reference to any network authority or registry. There is thus no record for the namespaces that would need to be supported.
   • Without an authority there can be no guarantee that DATA URIs are globally unique. This guarantee of uniqueness is the prime motivator for the INFO URI scheme.
6. Or else, why not use TAG URIs?  <<

   TAG URIs (RFC 4151) are Internet protocol elements for referencing resources that are globally unique across network space and time. The basic premise is that a specific identifier is prefixed with a TAG authority which is constructed from a fully qualified domain name (either used alone or embedded within an email address) and a date in ISO 8601 format. The TAG authority should thus guarantee that the TAG URI is globally unique. TAG URIs may or may not have resolution mechanisms, although those mechanisms are not specified.

   The following considerations hold in respect of TAG URIs:

   • TAG URIs are inappropriate for INFO namespaces because TAG URIs provide:
     • network authority (discovery obstacle)
     • redundant date component (requires adoption of a date convention)
     • dereference expectation
     • poor branding (string overhead from network authority and date components)
   • TAG URIs include a network authority component. INFO namespaces may not have (or may not make) any network authority available. A central network authority would also be inappropriate as this would introduce a dependency between a third party namespace and a central network authority. Further, the form of disclosing the network authority component (either as an independent string or embedded within an email address) would need to be published.
   • Another difficulty is that the TAG URI is designed for minting new identifiers whereas INFO is purely concerned with proxying legacy identifiers (i.e. already minted) onto the URI namespace. Since there is a date component in the TAG URI the only means of making this work as a basis for supporting legacy identifiers would be to adopt some convention whereby a known date would be used for all the identifiers (which obviously obviates the need for a date component).
   • Use of TAG URIs might only encourage the provisioning of resource representations (e.g. metadata descriptions) which could conflict with representations provided under any possible future URI registration on the part of the Namespace Authority. Further, if TAG URIs were used to provide resource representations, it must be recognized that managing the namespace and infrastructure is a costly enterprise that may not be appropriate or cost effective in a given business context.
   • The TAG authority of TAG URIs adds unnecessary string overhead and consequent loss of branding for legacy identifiers.

D. The INFO Registry

1. What is the INFO Registry?  <<

   The INFO Registry provides a mechanism for the registration of public namespaces that are used for the identification of information assets, and that are not referenceable within the URI allocation.

2. Where is the INFO Registry located?  <<

   The INFO Registry is located on the INFO website at: <http://info-uri.info/registry/>

3. Who maintains and operates the INFO Registry?  <<

   NISO is the Maintenance Agency for the INFO Registry and may delegate operational responsibility to an operating body, or Registry Operator.

4. What policies govern the INFO Registry?  <<

   A publicly articulated policy established under NISO governance will be made available on the INFO website <http://info-uri.info/>. The INFO Registry policy defines a review process for candidate namespaces and provides measures of quality control and suitability for entry of namespaces

5. What is the registration procedure for an INFO namespace?  <<

   The INFO Registry provides an online registration form which solicits the relevant fields. This information will then be made available to a public approval process. Subject to a favourable review the namespace will be added to the INFO Registry.

6. What functionalities does the INFO Registry present?  <<

   The INFO Registry is publicly accessible and supports discovery (by both humans and machines) of:

   • String literals identifying the namespaces.
   • Names and contact information of Namespace Authorities.
   • Syntax requirement for identifiers maintained in such namespaces.
   • Normalization methodology for identifiers maintained in such namespaces.
   • Ancillary documentation.
   Disclosure of Registry records will be both in a human presentational form as well as in structured markup form for machine automation. Currently the Registry records are presented as XHTML documents but are also available as "oai_dc" XML records and are harvestable using the OAI-PMH protocol. Other presentations, such as RSS, may subsequently be made available.

E. Syntax Considerations

1. What are the syntax highlights for an INFO URI?  <<

   The INFO URI syntax is very straightforward:

       "info:" namespace "/" identifier [ "#" fragment ]

   where namespace is a registered namespace token, identifier is a %-escaped identifier, and fragment is an optional %-escaped identifier to a secondary resource.

   The INFO URI syntax introduces certain restrictions on the generic URI syntax:

   • No network authority component allowed.
   • No query component allowed.
   • No absolute path allowed (although relative paths are admitted).
   • No relative URI references allowed.
2. What is the full syntax for an INFO URI?  <<

   The INFO URI syntax is fully conformant with the generic URI syntax defined in RFC 3986.

   This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC 4234 to define the URI. The following core ABNF productions are used by this specification as defined by Appendix B.1 of RFC 4234: ALPHA, DIGIT, HEXDIG.

   The INFO URI syntax is presented in two parts. Part A contains productions specific to the INFO URI scheme:

   info-URI = info-scheme ":" info-identifier [ "#" fragment ] info-scheme = "info" info-identifier = namespace "/" identifier namespace = scheme identifier = *( pchar / "/" )

   Part B contains generic productions from RFC 3986 which are repeated here both for completeness and for reference.

   scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) pchar = unreserved / pct-encoded / sub-delims / ":" / "@" fragment = *( pchar / "/" / "?" ) unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" pct-encoded = "%" HEXDIG HEXDIG sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

3. What does the fragment signify for an INFO URI?  <<

   The fragment on an INFO URI signifies a secondary resource with respect to the primary resource identified by an absolute INFO URI without a fragment.

F. Examples of Usage

1. What do INFO URIs look like?  <<

   Some examples of (syntactically) valid INFO URIs are given below together with the identifiers they reference in their native form and the information assets that they identify:

   1. Dewey Decimal Classification
   2. Library of Congress Control Number
   3. Serial Item and Contribution Identifier (SICI)
   4. Astrophysics Data System Bibcode
   5. PubMed Identifier

   a. Dewey Decimal Classification  <<
   Notes: ddc is the INFO namespace component for a Dewey Decimal Classification namespace and 22/eng//004.678 is the identifier component for an identifier of an information asset within that namespace.
   info:ddc/22/eng//004.678 22/eng//004.678 Information Asset: Vocabulary Term "Internet"

   b. Library of Congress Control Number  <<
   Notes: lccn is the INFO namespace component for a Library of Congress Control Number namespace and 2002022641 is the identifier component for an identifier of an information asset within that namespace.
   info:lccn/2002022641 2002022641 Information Asset: Metadata Record "Newcomer, Eric. Understanding Web services: XML, WSDL, SOAP, and UDDI. Boston: Addison-Wesley, 2002."

   c. Serial Item and Contribution Identifier (SICI)  <<
   Notes: sici is the INFO namespace component for a Serial Item and Contribution Identifier namespace and 0363-0277(19950315)120:5%3C%3E1.0.TX;2-V is the identifier component for an identifier of an information asset in that namespace in escaped form, or in unescaped form 0363-0277(19950315)120:5<>1.0.TX;2-V.
   info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V 0363-0277(19950315)120:5<>1.0.TX;2-V Information Asset: Journal Issue "Library Journal, Vol. 120, no. 5. March 15, 1995."

   d. Astrophysics Data System Bibcode  <<
   Notes: bibcode is the INFO namespace component for an Astrophysics Data System bibcode namespace and 2003Icar..163..263Z is the identifier component for an identifier of an information asset within that namespace.
   info:bibcode/2003Icar..163..263Z 2003Icar..163..263Z Information Asset: Abstract of Journal Article "K. Zahnle, P. Schenk, H. Levison and L. Dones, Cratering rates in the outer Solar System, Icarus, 163 (2003) pp. 263-289."

   e. PubMed Identifier  <<
   Notes: pmid is the INFO namespace component for a PubMed Identifier namespace and 12376099 is the identifier component for an identifier of an information asset within that namespace.
   info:pmid/12376099 12376099 Information Asset: Abstract of Journal Article "Wijesuriya SD, Bristow J, Miller WL. Localization and analysis of the principal promoter for human tenascin-X. Genomics. 2002 Oct;80(4):443-52."

2. How are INFO URIs used in Web applications?  <<

   Some examples of (syntactically) valid INFO URIs are given below as they would be used by applications:

   1. RDF Graph
   2. Topic Map
   3. Extended XLink
   4. RSS 1.0 Feed - ContextObject (1)
   5. OpenURL Link - ContextObject (2)
   6. SRU Record

   a. RDF Graph  <<
   Notes: This RDF graph asserts a set of statements about the resource referenced by the URI info:pii/S0888-7543(02)96852-7 (which identifies the Publisher Item Identifier S0888-7543(02)96852-7) using the Dublin Core vocabulary.
   <rdf:Description about="info:pii/S0888-7543(02)96852-7"> <dc:creator>Wijesuriya, S.D.</dc:creator> <dc:title>Localization and analysis of the principal promoter for human tenascin-X.</dc:title> <dc:identifier>info:doi/10.1006/geno.2002.6852</dc:identifier> </rdf:Description>

   b. Topic Map  <<
   Notes: This topic map entry defines the topic internet which has a public subject indicator as referenced by the URI info:ddc/22/eng//004.678 (which identifies the Dewey Decimal Classification Internet) and a base name string of Internet.
   <topic id="internet"> <subjectIdentity> <subjectIndicatorRef xlink:href="info:ddc/22/eng//004.678" /> </subjectIdentity> <baseName id="_id123"> <baseNameString>Internet<baseNameString> </baseName> </topic>

   c. Extended XLink  <<
   Notes:
   <ce:inter-refs> <ce:inter-refs-text id="interref8">Parts I and II</ce:inter-refs-text> <ce:inter-ref-end xlink:href="info:pii/S0167-8396(00)00009-1"> <ce:inter-ref-title>Part I</ce:inter-ref-title> </ce:inter-ref-end> <ce:inter-ref-end xlink:href="info:pii/S0167-8396(00)00010-8"> <ce:inter-ref-title>Part II</ce:inter-ref-title> </ce:inter-ref-end> <ce:inter-refs-link/> </ce:inter-refs>

   d. RSS 1.0 Feed - ContextObject (1)  <<
   Notes: The ContextObject shown here in an RSS feed is making use of the mod_context RSS 1.0 module. This is the same ContextObject as shown below in Example e) but with a different serialization.
   <channel rdf:about="http://rss.example.com/"> <title>My conetxt-sensitive RSS feed</title> <link>http://rss.example.com/"</link> <!-- ContextObject => { --> <ctx:ctx_ver>Z39.88-2004</ctx:ctx_ver> <ctx:rft_id> info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V </ctx:rft_id> <ctx:req_id> mailto:a.n.other@example.net </ctx:req_id> <!-- } --> <items> <rdf:Seq> <rdf:li rdf:resource="http://rss.example.com/resource/1" /> <rdf:li rdf:resource="http://rss.example.com/resource/2" /> </rdf:Seq> </items> </channel>

   e. OpenURL Link - ContextObject (2)  <<
   Notes: The ContextObject is shown here on an OpenURL which is requesting context-sensitive services from the link resolver <http://link.example.com/resolver> for the referent entity identified by the URI info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V (which identifies the SICI code 0363-0277(19950315)120:5<>1.0.TX;2-V) and the requester entity identified by the URI mailto:a.n.other@example.net. The example OpenURL is text wrapped with whitespace for readability.
   http://link.example.com/resolver?url_ver=Z39.88-2004 &rft_id=info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V &req_id=mailto:a.n.other@example.net

   f. SRU Record  <<
   Notes:
   <record> <recordSchema>info:srw/schema/1/dc-v1.1</recordSchema> <recordPacking>xml</recordPacking> <recordData> <srw_dc:dc> <dc:title>This is a Sample Record</dc:title> </srw_dc:dc> </recordData> <recordPosition>1</recordPosition> <extraRecordData> <rel:rank>0.965</rel:rank> </extraRecordData> </record>

G. Comparing INFO URIs

1. Why is comparison of URIs important?  <<

   A prime motivator for comparison of URIs is to improve performance in retrieval operations by using caching mechanisms. A secondary motivator is to equivalence resource identifiers in Web descriptions of information structures to allow those structures to be normalized or merged with other like structures, e.g. the merging of two RDF graphs or the merging of two Topic Maps.

   As far as INFO URIs are concerned there are no associated retrieval mechanisms, and the prime motivator for comparison of INFO URIs is to support the equivalencing of identifiers for information assets.

2. What steps should be taken to compare two INFO URIs?  <<

   INFO URIs only exist in absolute form - no relative URI forms are allowed. The normalization steps that should be applied are with respect to the three components of the URI: the "scheme" component, the "namespace" component and the "identifier" component.

   The following generic normalization steps should be applied:

   1. Normalize the case of the "scheme" component to be lowercase.
   2. Normalize the case of the "namespace" component to be lowercase.
   3. Unescape all unreserved %-escaped characters in the "namespace" and "identifier" components.
   4. Normalize the case of any %-escaped characters in the "namespace" and "identifier" components to be uppercase.

   The subsequent namespace-specific normalization steps may be applied:

   5. Normalize the case of the "identifier" component as per any rules that may be recorded in the Registry.
   6. Normalize any punctuation characters in the "identifier" component as per any rules that may be recorded in the Registry.
3. Is there an example of comparing INFO URIs?  <<

   Before comparing INFO URIs they should be normalized by applying the standard INFO normalization rules (lowercasing the "scheme" and "namespace" components, unescaping non-reserved characters and uppercasing any %-escaped characters that remain). In the example below four unnormalized forms (Step A), are reduced to normalized forms (Step B). (Subsequent normalization steps are not shown as they would be namespace specific.)

   The Registry may be consulted for namespace-specific rules on case normalization and punctuation normalization. If these namespace-specific rules are available INFO URIs may be reduced to a unique canonical form.

   Step A - Unnormalized Forms U1. INFO:PII/S0888-7543(02)96852-7 U2. info:PII/S0888754302968527 U3. info:pii/S0888%2D7543%2802%2996852%2D7 U4. info:pii/s0888-7543(02)96852-7 Step B - Normalized Forms N1. info:pii/S0888-7543(02)96852-7 N2. info:pii/S0888754302968527 N3. info:pii/S0888-7543(02)96852-7 N4. info:pii/s0888-7543(02)96852-7

H. Historical Perspective

1. What is the historical background to INFO?  <<

   The effort to create the INFO URI scheme emerged from the ANSI/NISO process to standardize the OpenURL Framework for Context-Sensitive Services (see the Part 1 and Part 2 ballot documents), which requires the ability to describe resources by means of globally unique identifiers. The Draft Standard for Trial Use released for Public Comment introduced a "proprietary" naming architecture which allowed information assets to be referenced by means of widely used non-URI identifiers (e.g. National Library of Medicine PubMed identifiers, International DOI Foundation Digital Object Identifiers, NASA Astrophysics Data System Bibcodes, and others) which would be registered under the OpenURL Framework.

   The Public Comment period started March 12^th, 2003, when the first document was released. Early public feedback led to the decision to fundamentally revise the naming architecture, and to base all resource identification requirements within the OpenURL Framework on URIs alone. Because it was deemed unrealistic to expect that all namespaces required in the OpenURL Framework would be registered within the URI allocation by the respective Namespace Authorities, the INFO URI effort was launched.

2. What consultations preceded the development of INFO?  <<

   Development of the INFO URI scheme is being conducted under the auspices of NISO, together with consultation from the IETF and the W3C. A consultation document "Bootstrapping the Web" was prepared to analyse the options available.

   On June 19^th 2003, representatives from NISO, NISO Committee AX on OpenURL Framework standardization, the IETF, and the W3C met to discuss the requirements with respect to the identification of resources in the OpenURL Framework. More specifically, this group discussed how to handle the ORI and XRI Naming Environments introduced in the OpenURL Framework Draft Standard for Trial Use as an integral part of the Internet's URI environment. There was a general consensus to proceed with registration of a toplevel URI scheme and follow on meetings with representatives from the various communities were scheduled.

3. What were the next steps in the development of INFO?  <<

   It was recognized that these resource identifiers would have a much wider applicability to many Web-based applications and it was decided to decouple this URI scheme from the OpenURL Framework and to name it INFO. An Internet-Draft was duly prepared and posted to the Internet-Drafts repository on September 30^th, 2003. This was also widely communicated to various mailing lists and there was much discussion of the new INFO URI scheme on the public uri@w3.org mailing list.

4. What is the current position of INFO?  <<

   The final specification of INFO RFC 4452 was published April 2006 which, together with this FAQ, will guide Web applications, such as OpenURL Framework implementations and others, in making use of the INFO URI scheme to deploy legacy identifiers within the World Wide Web global information architecture.

   Both the OpenURL Framework and INFO are now approved information standards and can be used securely in this capacity.

   The INFO Registry has been established and namespace registrations are currently being processed. A Registry policy document is available as a work in progress from the INFO website. An RSS feed (defunct) is also available to alert subscribers to newly registered INFO namespaces.

   NISO Committee AX completed its work on the OpenURL Framework standardization at its last face-to-face meeting on October 27^th/28^th, 2003 and handed over to NISO the final documents. The ANSI/NISO information standard Z39.88-2004 was duly balloted and approved for publication April 15^th, 2005.