Internet-Draft Herbert Van de Sompel
Document: draft-vandesompel-info-uri-01.txt LANL
Expires: June 2004 Tony Hammond
Elsevier
Eamonn Neylon
Manifest Solutions
Stuart L. Weibel
OCLC
December 2003
The "info" URI Scheme for Information Assets
with Identifiers in Public Namespaces
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines the "info" Uniform Resource Identifier (URI)
scheme for information assets with identifiers in public namespaces.
Namespaces participating in the "info" URI scheme are regulated by an
"info" Registry mechanism.
Table of Contents
1 Introduction...................................................2
2 Terminology....................................................3
3 Application of the "info" URI Scheme...........................3
4 The "info" Registry............................................4
5 The "info" URI Scheme..........................................5
6 Normalization and Comparison of "info" URIs....................9
Van de Sompel Expires û June 2004 [Page 1]
The "info" URI Scheme December 2003
7 Rationale.....................................................11
8 Security Considerations.......................................12
9 Acknowledgements..............................................12
10 Normative References.......................................13
11 Non-Normative References...................................13
12 Authors' Addresses.........................................14
13 Full Copyright Statement...................................15
1 Introduction
This document defines the "info" Uniform Resource Identifier (URI)
scheme for information assets that have identifiers in public
namespaces that are not part of the URI allocation. By information
asset this document intends any information construct û i.e. any
abstraction, manifestation or performance, whether digital or
physical - that has identity within a public namespace.
There exist many information assets with identifiers in public
namespaces that are not referenceable by URI schemes. Examples of
such namespaces include Dewey Decimal Classifications [DEWEY],
Library of Congress Control Numbers [LCCN], NISO Serial Item and
Contribution Identifiers [SICI], NASA Astrophysics Data System
Bibcodes [BIBCODE], and National Library of Medicine PubMed
identifiers [PMID]. Other candidate namespaces include Publisher Item
Identifiers [PII], Online Computer Library Center OCLC Numbers
[OCLCNUM], and NISO OpenURL Framework identifiers [OFI] amongst
others.
The "info" URI scheme facilitates the referencing of information
assets that have identifiers in such public namespaces by means of
URIs. When referencing an information asset by means of its "info"
URI, the asset SHALL be considered a "resource" as defined in RFC
2396 [RFC2396] and SHALL enjoy the same common syntactic, semantic
and shared language benefits that the URI presentation confers. As
such, the "info" URI scheme enables public namespaces that are not
part of the URI allocation to be represented within the allocation.
The "info" URI scheme thus provides a bridging mechanism to allow
public namespaces to become part of the URI allocation.
Namespaces declared under the "info" URI scheme are regulated by an
"info" Registry mechanism. The "info" Registry allows a public
namespace that is not part of the URI allocation to be declared in a
registration process by the organization that manages it (the
Namespace Authority). The "info" Registry supports the declaration of
public namespaces that are not part of the URI allocation in a manner
that facilitates the construction of URIs for information assets
without imposing the burdens of independent URI registration and
maintenance of resource representations on the Namespace Authority.
Information assets identified within a registered namespace SHALL be
Van de Sompel Expires - June 2004 [Page 2]
The "info" URI Scheme December 2003
added or deleted according to the business processes of the Namespace
Authority, and yet MAY be referenced within network applications via
the "info" URI in an open, standardized way without additional action
on the part of the Namespace Authority.
The "info" URI scheme exists for identification purposes alone.
Implementations MUST NOT assume that an "info" URI can be
dereferenced to a representation of the resource identified by the
URI. Applications of the "info" URI scheme are limited to the
identification of information assets and the declaration of rules for
comparing identity of such information assets regardless of whether
any services relating to such information assets are accessible on
the Internet.
2 Terminology
In this document the key words "MUST", "MUST NOT", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "MAY", and "MAY NOT" are to be
interpreted as described in RFC 2119 [RFC2119] and indicate
requirement levels for compliant implementations.
3 Application of the "info" URI Scheme
Public namespaces that are used for the identification of information
assets, and that are not part of the URI allocation, MAY be
registered as namespaces within the "info" Registry. Namespace
Authorities MAY register these namespaces in the "info" Registry,
thereby making these namespaces available to applications that need
to reference information assets by means of a URI. Registrations of
public namespaces that are not part of the URI allocation by parties
other than the Namespace Authority SHALL NOT be permitted, thereby
insuring against hostile usurpation or inappropriate usage of
registered service marks or the public namespaces of others.
Registration under the "info" Registry of a public namespace that is
not part of the URI allocation implies no particular functionalities
of the identifiers from the registered namespace other than the
identification of information assets. No resolution mechanisms are
associated with the "info" URI scheme, though for any particular
namespace there MAY exist mechanisms for resolving identifiers to
network services. The definition of such services falls outside the
scope of the "info" URI scheme. Registration does not define
namespace-specific semantics for identifiers within a registered
namespace, though allowable character sets and normalization rules
are specified in sections 5 and 6 so as to ensure that the URIs
created using such identifiers are compliant with applications that
use URIs.
Van de Sompel Expires - June 2004 [Page 3]
The "info" URI Scheme December 2003
The registration of a public namespace in the "info" Registry SHALL
NOT preclude further development of services associated with that
namespace which MAY qualify the namespace for additional publication
elsewhere within the URI allocation.
4 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 part of the URI allocation.
NISO [NISO], the National Information Standards Organization, will
act as the Maintenance Agency for the "info" Registry, and will
delegate the day-to-day operation of the "info" Registry to a
Registry Operator. As the Maintenance Agency, NISO will ensure that
the Registry Operator operates the "info" Registry in accordance with
a publicly articulated policy document established under NISO
governance and made available on the "info" website . The "info" Registry policy defines a review process for
candidate namespaces and provides measures of quality control and
suitability for entry of namespaces.
4.1 Management Characteristics of the "info" Registry
The "info" Registry will be managed according to policies established
under the auspices of NISO. All such policies, as well as the
namespace declarations in the "info" Registry, will be public.
4.2 Functional Characteristics of the "info" Registry
The "info" Registry will be publicly accessible and will support
discovery (by both humans and machines) of:
. string literals identifying the namespaces
. names and contact information of Namespace Authorities
. syntax requirements for identifiers maintained in such
namespaces
. normalization methodology for identifiers maintained in such
namespaces
. ancillary documentation
where the Registry entries refer to the corresponding "namespace" and
"identifier" components which are defined in the ABNF given in
section 5.1 of this document.
4.3 Maintenance of the "info" Registry
The public namespaces that MAY be registered in the "info" Registry
will be those of interest to the communities served by NISO and
Van de Sompel Expires - June 2004 [Page 4]
The "info" URI Scheme December 2003
therefore NISO is committed to act as Maintenance Authority for the
"info" Registry, and to assign a Registry Operator to operate it on a
day-to-day basis.
NISO, a non-profit association accredited by the American National
Standards Institute (ANSI), identifies, develops, maintains, and
publishes technical standards to manage information in the digital
environment. NISO standards apply technologies to the full range of
information-related needs, including retrieval, re-purposing,
storage, metadata, and preservation.
Founded in 1939, incorporated as a not-for-profit education
association in 1983, and assuming its current name the following
year, NISO draws its support from the communities it serves. The
leaders of over 70 organizations in the fields of publishing,
libraries, IT and media serve as its voting members. Hundreds of
experts and practitioners serve on NISO committees and as officers of
the association.
NISO has been designated by ANSI to represent US interests to the
International Organization for Standardization's (ISO) Technical
Committee 46 on Information and Documentation.
The NISO headquarters office is located at: 4733 Bethesda Ave.,
Bethesda, MD 20814, USA. (For further information, see the NISO
website .)
5 The "info" URI Scheme
5.1 Definition of "info" URI Syntax
Note: RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax"
[RFC2396] is being revised [2396BIS] at the time of this writing. The
syntax used in this document follows the revisions made to the
generic URI syntax defined in RFC 2396 [2396BIS].
The "info" URI syntax presented in this document is generally
conformant with the generic URI syntax defined in RFC 2396 [RFC2396].
The only point of departure is to make use of the new "segment"
production as generalized in the revision to RFC 2396 [2396BIS]. This
specification uses the Augmented Backus-Naur Form (ABNF) notation of
RFC 2234 [RFC2234] to define the URI. The following core ABNF
productions are used by this specification as defined by Section 6.1
of RFC 2234: ALPHA, DIGIT, HEXDIG.
The "info" URI syntax is presented in two parts. Part A contains
productions specific to the "info" URI scheme, while Part B contains
generic productions from the RFC 2396 revision [2396BIS] which are
Van de Sompel Expires - June 2004 [Page 5]
The "info" URI Scheme December 2003
repeated here both for completeness and for reference. (Although the
work on revising RFC 2396 is currently ongoing we expect that the
productions presented here will coincide with the final outcome of
that work. Nevertheless this BNF is complete in itself.) The
following set of productions (Part A) are specific to the "info" URI
scheme:
; Part A:
; productions specific to the "info" URI scheme
info-URI = info-scheme ":" info-identifier [ "#" fragment ]
info-scheme = "info"
info-identifier = namespace "/" identifier
namespace = scheme
identifier = path-segments
Note that the "info-identifier" production is a restriction on the
"rel-path" branch of the "hier-part" production in the RFC 2396
revision [2396BIS]. Further note that relative URI forms for "info"
URIs SHOULD NOT be allowed.
This next set of productions (Part B) are generic productions
reproduced from the RFC 2396 revision [2396BIS]:
; Part B:
; generic productions from the RFC 2396 revision [2396BIS]
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
path-segments = segment *( "/" segment )
segment = *pchar
fragment = *( pchar / "/" / "?" )
pchar = unreserved / escaped / ";" /
":" / "@" / "&" / "=" / "+" / "$" / ","
unreserved = ALPHA / DIGIT / mark
escaped = "%" HEXDIG HEXDIG
mark = "-" / "_" / "." / "!" / "~" / "*" / "'" /
"(" / ")"
Van de Sompel Expires - June 2004 [Page 6]
The "info" URI Scheme December 2003
An "info" URI has an "info-identifier" as its scheme-specific part
and MAY take an optional "fragment" component. An "info-identifier"
is constructed by appending an "identifier" component to a
"namespace" component separated by a slash "/" character. The "info"
URI scheme supports hierarchy as indicated by the presence of the
slash "/" character. The intent of any slash "/" character within the
"identifier" component SHALL be construed as representing a hierarchy
delimiter, regardless of the intent of that character in the original
namespace.
Values for the "namespace" component of the "info" URI are name
tokens composed of URI scheme characters only (cf. the "scheme"
production). They identify the public namespace in which the
(unescaped) value for the "identifier" component originates, and are
registered in the "info" Registry, which guarantees their uniqueness.
Although the "namespace" component is case-insensitive, the canonical
form is lowercase and documents that specify values for the
"namespace" component MUST do so using lowercase letters. An
implementation SHOULD accept uppercase letters as equivalent to
lowercase in "namespace" names, for the sake of robustness, but
SHOULD only generate lowercase "namespace" names, for consistency.
Values for the "identifier" component of the "info" URI are
hierarchical strings composed of path segments of path segment
characters (cf. the "pchar" production), the segments being separated
by slash "/" characters. In their originating public namespace, the
(unescaped) values for the "identifier" component identify
information assets. The values for the "identifier" component MUST be
%-escaped as required by this syntax. The "identifier" component MUST
be treated as case-sensitive, although the "info" Registry MAY record
the case-sensitivity of identifiers from within particular registered
public namespaces. The "info" Registry MAY also disclose additional
normalization rules regarding the treatment of punctuation characters
and the like.
Values for the "fragment" component of the "info" URI are strings
composed of path segment characters (cf. the "pchar" production) plus
the slash "/" character and the question-mark "?" character. No
semantic role is assigned to the the slash "/" character and the
question-mark "?" character within the "fragment" component. The
(unescaped) values for the "fragment" component identify secondary
information assets with respect to the primary information asset
which is referenced by the "info-identifier". The values for the
"fragment" component MUST be %-escaped as required by this syntax.
The "fragment" component MUST be treated as case-sensitive.
5.2 Allowed Characters Under the "info" URI Scheme
Van de Sompel Expires - June 2004 [Page 7]
The "info" URI Scheme December 2003
The "info" URI syntax uses the same set of allowed US-ASCII
characters as specified in RFC 2396 [RFC2396] for a generic URI. An
"info" URI string SHOULD be represented as a UNICODE [UNICODE] string
and be encoded in UTF-8 [RFC2279] form. Reserved characters as well
as excluded US-ASCII characters and non-US-ASCII characters MUST be
%-escaped before forming the URI. Details of the %-escape encoding
can be found in RFC 2396, section 2.4.
5.3 Examples of "info" URIs
Some examples of syntactically valid "info" URIs are given below:
a) info:ddc/22/eng//004.678
where "ddc" is the "namespace" component for a Dewey Decimal
Classification [DEWEY] namespace and "22/eng//004.678" is the
"identifier" component for an identifier of an information asset
within that namespace.
The information asset identified by the identifier "22/eng//004.678"
in the namespace for (22nd Ed.) English-language Dewey Decimal
Classifications is the classification
"Internet"
b) info:lccn/2002022641
where "lccn" is the "namespace" component for a Library of Congress
Control Number [LCCN] namespace and "2002022641" is the "identifier"
component for an identifier of an information asset within that
namespace.
The information asset identified by the identifier "2002022641" in
the namespace for Library of Congress Control Numbers is the book
"Newcomer, Eric. Understanding Web services: XML, WSDL,
SOAP, and UDDI. Boston: Addison-Wesley, 2002."
c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V
where "sici" is the "namespace" component for a of Serial Item and
Contribution Identifier [SICI] 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".
Van de Sompel Expires - June 2004 [Page 8]
The "info" URI Scheme December 2003
The information asset identified by the identifier "0363-
0277(19950315)120:5<>1.0.TX;2-V" in the namespace for Serial Item and
Contribution Identifiers is the journal issue
"Library Journal, Vol. 120, no. 5. March 15, 1995."
d)
where "bibcode" is the "namespace" component for a NASA ADS Bibcode
[BIBCODE] namespace and "2003Icar..163..263Z " is the "identifier"
component for an identifier of an information asset within that
namespace. This example further shows an application of an "info" URI
as the subject of an RDF statement.
The information asset identified by the identifier
"2003Icar..163..263Z" in the namespace for NASA ADS Bibcodes is the
abstract of the 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) info:pmid/12376099
where "pmid" is the "namespace" component for a PubMed Identifier
[PMID] namespace and "12376099" is the "identifier" component for an
identifier of an information asset in that namespace.
The information asset identified by the identifier "12376099" in the
namespace for PubMed Identifiers is the abstract of the 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."
6 Normalization and Comparison of "info" URIs
In order to facilitate comparison of "info" URIs, a sequence of
normalization steps SHOULD be applied.
Since the "info" URI is case-sensitive, a canonical form MAY only be
arrived at by consulting the "info" Registry for possible information
on the case-sensitivity for identifiers from a registered public
namespace, and any case normalization step to apply. The "info"
Registry MAY also disclose additional normalization rules regarding
the treatment of punctuation characters and the like.
The following generic normalization steps SHOULD be applied:
Van de Sompel Expires - June 2004 [Page 9]
The "info" URI Scheme December 2003
a) Normalize the case of the "scheme" component to be
lowercase
b) Normalize the case of the "namespace" component to be
lowercase
c) Unescape all unreserved %-escaped characters in the
"namespace" and "identifier" components
d) 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:
e) Normalize the case of the "identifier" component as
per any rules that may be recorded in the Registry
f) Normalize any punctuation characters in the "identifier"
component as per any rules that may be recorded in the
Registry
Note that the "info" URI scheme provides a relative path only for its
hierarchical part, and as such any path normalization of dot segments
("/./" and "/../") MUST NOT be applied.
The following unnormalized forms of an "info" URI
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
are normalized to the following respective 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
If the "info" Registry records the case-sensitivity for identifiers
from the "pii" registered public namespace as being case-insensitive
and normalized to an uppercase form, then the above URI forms can be
reduced to the following forms
N1,N3. info:pii/S0888-7543(02)96852-7
N2. info:pii/S0888754302968527
If the "info" Registry further records the treatment of punctuation
characters for identifiers from the "pii" registered public namespace
as being optional and normalized to a punctuation free form, then the
above URI forms can be reduced to the following unique canonical form
Van de Sompel Expires - June 2004 [Page 10]
The "info" URI Scheme December 2003
N2. info:pii/S0888754302968527
If the "info" URI includes a "fragment" component, namespace-specific
normalization steps MUST NOT be applied to the "fragment". This would
result in being unable to reconcile the following two URI forms
N2a. info:pii/S0888754302968527#sec4
N2b. info:pii/S0888754302968527#SEC4
7 Rationale
7.1 Why Create a New URI Scheme for Identifiers from Public
Namespaces?
Under RFC 2718, "Guidelines for new URL Schemes" [RFC2718], it is
stated that a URI scheme SHOULD have a "demonstrated utility", and in
particular SHOULD be applied to "things that cannot be referred to in
any other way". The "info" URI scheme allows identifiers within
public namespaces, used for the identification of information assets,
to be referred to within the URI allocation. Once a namespace is
registered in the "info" Registry, the "info" URI scheme enables an
information asset with an identifier in that namespace to be
referenced by means of a URI. As a result, the information asset
SHALL be considered a resource as defined in RFC 2396 [RFC2396] and
SHALL enjoy the same common syntactic, semantic and shared language
benefits that the URI presentation confers.
7.2 Why Not Use an existing URI Scheme for Identifiers from Public
Namespaces?
Existing URI schemes are not suitable for employment as the "info"
URI scheme expressly disallows dereference. While examples of
resource identifiers minted under other URI schemes may not always be
dereferenceable, nevertheless there is a common expectation that such
URIs can be dereferenced by various resolution mechanisms, whether
they be location-dependent or location-independent resource
identifiers. The "info" URI scheme applies to a class of resource
identifiers which share a set of common properties including the
property of non-dereference.
7.3 Why Not Create a New URN Namespace ID for Identifiers from Public
Namespaces?
RFC 2141 [RFC2141] states that "Uniform Resource Names (URNs) are
intended to serve as persistent, location-independent, resource
identifiers." The "info" URI scheme, on the other hand, asserts
neither the persistence of the identifiers created under this scheme
nor of the public namespaces grandfathered under this scheme. Rather
Van de Sompel Expires - June 2004 [Page 11]
The "info" URI Scheme December 2003
it exists purely to disclose the identity of information assets and
to facilitate a lightweight registration mechanism for public
namespaces of identifiers managed according to the policies and
business models of the Namespace Authorities. The "info" URI scheme
is neutral with respect to identifier persistence. Moreover, for
"info" to operate as a URN NID would require that "info" be
constituted as a delegated naming authority. It is not clear that a
URN NID would be an appropriate choice for naming authority
delegation.
Further, the "info" URI scheme is not dereferenceable in contrast to
the specific recommendation given in RFC 1737, "Functional
Requirements for Uniform Resource Names" [RFC1737] that "It is
strongly recommended that there be a mapping between the names
generated by each naming authority and URLs.". It would therefore be
inappropriate to create a URN Namespace ID for the "info" namespaces.
An extra consideration is that the "urn" URI syntax excludes
hierarchy by reserving the slash "/" character. An "info" URI, on the
other hand, admits of general hierarchy by allowing the slash "/"
character (as well as more liberally allowing the ampersand "&" and
tilde "~" characters) and therefore represents a lower barrier to
entry in keeping with its intention of acting as a bridging mechanism
to allow public namespaces to become part of the URI allocation. That
is, an "info" URI is more widely supportive of "human
transcribability" as discussed in RFC 2396 [RFC2396] than is a "urn"
URI.
Additionally the "urn" URI syntax does not support "fragment"
components as does the "info" URI syntax for indirect identification
of secondary resources.
8 Security Considerations
The "info" URI scheme syntax is subject to the same security
considerations as the generic URI syntax described in RFC 2396
[RFC2396].
An "info" URI is not dereferenceable and hence no resolution
mechanisms are available to a URI processor. Therefore security
considerations regarding the use of "info" URIs MUST be limited
solely to the nature of the identifier string itself.
9 Acknowledgements
The authors acknowledge the contributions of Michael Mealling,
Verisign, and Patrick Hochstenbach, Los Alamos National Laboratory.
Van de Sompel Expires - June 2004 [Page 12]
The "info" URI Scheme December 2003
10 Normative References
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Retrieved September 20, 2003 from
.
[RFC2234] Crocker, D.H. and Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Retrieved
September 20, 2003 from
.
[RFC2279] Yergeau, F., "UTF-8, A Transformation Format for Unicode
and ISO10646", RFC 2279, October 1996. Retrieved September
20, 2003 from .
[RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. Retrieved September 20, 2003 from
.
[RFC2718] Masinter, L., H. Alvestrand, D. Zigmond and P. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
Retrieved September 20, 2003 from
.
[UNICODE] The Unicode Consortium. The Unicode Standard, Version
4.0.0, defined by: The Unicode Standard, Version 4.0
(Reading, MA, Addison-Wesley, 2003). ISBN 0-321-18578-1.
11 Non-Normative References
[2396BIS] Berners-Lee, T., R. Fielding and L. Manister, "Uniform
Resource Identifiers (URI): Generic Syntax", Internet-
Draft (work in progress), June 2003. Retrieved November
25, 2003 from .
[BIBCODE] "NASA Astrophysics Data System Bibliographic Code".
Retrieved August 1, 2003 from
.
[DEWEY] "Dewey Decimal Classification". Retrieved September 20,
2003 from .
[LCCN] "Library of Congress Control Number". Retrieved August 1,
2003 from .
Van de Sompel Expires - June 2004 [Page 13]
The "info" URI Scheme December 2003
[NISO] National Information Standards Organization. Retrieved
August 1, 2003 from .
[OCLCNUM] "Online Computer Library Center OCLC Control Number".
Retrieved November 25, 2003 from
.
[OFI] Draft Standard for Trial Use ANSI/NISO Z39.88, "The OpenURL
Framework for Context-Sensitive Services". Retrieved
September 20, 2003 from
[PII] "Publisher Item Identifier as a means of document
identification". Retrieved September 25, 2003 from
.
[PMID] "PubMed Overview", National Library of Medicine. Retrieved
September 25, 2003 from
.
[SICI] ANSI/NISO Z39.56-1996 (R2002), "Serial Item and
Contribution Identifier (SICI)", ISBN 1-880124-28-9.
Retrieved September 25, 2003 from
12 Authors' Addresses
Herbert Van de Sompel
Los Alamos National Laboratory,
Research Library, MS-P362,
PO Box 1663,
Los Alamos, NM 87545-1362, USA
Tony Hammond
Elsevier Ltd
32 Jamestown Road
London, NW1 7BY, UK
Eamonn Neylon
Manifest Solutions
Bicester
Oxfordshire, OX26 2HX, UK
Stuart L. Weibel
OCLC Online Computer Library Center, Inc.
Van de Sompel Expires - June 2004 [Page 14]
The "info" URI Scheme December 2003
6565 Frantz Road
Dublin, OH 43017-3395, USA
13 Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process MUST be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Van de Sompel Expires - June 2004 [Page 15]