About
This page is for XRI TC members to collaborate on drafting a white paper on Abstract Identifier Architecture as part of our ongoing dicussions with the W3C TAG (see XriTcW3cTag). Initially this page will be used to draft and discuss proposed sections of this document. As the document evolves it is expected to migrate to an independent document maintained in the TC's document repository.
Definitions
The following definitions are proposed:
Abstract and Concrete Identifiers
In the context of a given communications protocol:
An abstract identifier is an identifier (arc) of a target resource (node) that, using the given protocol, MUST NOT resolve directly to a representation of that resource, but MAY resolve to a descriptor of that resource.
A concrete identifier is an identifier of a target resource that, using the given protocol, MAY resolve directly to a representation of that resource, but MUST NOT resolve to a descriptor of that resource.
- The same target resource MAY, in the context of the given protocol, have zero-or-more abstract identifiers and zero-or-more concrete identifiers.
- By these definitions, the sets of abstract identifiers and concrete identifiers for a target resource, in the context of the given protocol, MUST be disjoint.
Descriptors
In the context of a given communications protocol:
A descriptor is a resource (node) that describes another resource (node).
- A descriptor MAY contain zero-or-more abstract identifiers for the target resource and zero-or-more concrete identifiers for the target resource.
- To be resolved in the context of the given communications protocol, a descriptor MUST have one-or-more concrete identifiers of itself as a resource. However these concrete identifiers for the descriptor MUST NOT be misinterpreted as either abstract or concrete identifiers of the target resource described by the descriptor.
Synonyms
In the context of a given communications protocol:
- Two identifiers (arcs) are synonyms if they are not character-for-character equivalent after normalization but they identify the same target resource (node).
- Two abstract identifiers MAY be synonyms, and synonymity MAY be verifiable using the semantics of the associated descriptor(s).
- Two concrete identifiers MAY be synonyms, and synonymity MAY be verifiable using the semantics of the communications protocol.
- An abstract and a concrete identifier MAY be synonyms, and synonymity MAY be verifiable, however verification MUST require using both the semantics of the descriptor (for the abstract identifier) and semantics of the communication protocol (for the concrete identifier). To prove synonymity in this case:
- A descriptor retrieved via the communications protocol for the abstract identifier MUST assert the concrete identifier as a synonym, AND
- A response received via the communication protocol for the concrete identifier MUST assert the abstract identifier as a synonym.
Illustration
Following is a conceptual diagram showing how a layer of abstract identifiers is constructed over a layer of concrete identifiers.
Note that in order to resolve abstract identifiers of abstract resources into concrete identifiers that can be used to retrieve resource representations, a special class of concrete resources called resource descriptors is required. Resource descriptors also have their own concrete identifiers.
Terminology note: The terms resolve or discover are often applied to requesting a descriptor while the terms retrieve or access are often applied to requesting a representation.
Examples
The following tables provide examples of this architectural model.
DNS
Layer |
Identifier |
Example |
Comment |
Abstraction |
Domain name |
www.example.com |
Delegates from right to left |
Description |
Nameserver Address + Domain Name + Record Type |
206.194.13.5 + "www" + A |
UDP ==> DNS Resource Record |
Representation |
IP Address |
196.120.45.32 |
Access via TCP/IP |
DOI (Handle System)
Layer |
Identifier |
Example |
Comment |
Abstraction |
10.1000/182 |
Delegates from left to right |
|
Description |
DOI proxy URI |
http://nascent.nature.com/openhandle/handle?id=10.1000/182&format=rdf&mimetype=application/xml |
HTTP ==> DOI Resource Metadata Declaration |
Representation |
URI + others |
Access via URI-identified protocol |
XRI
Layer |
Identifier |
Example |
Comment |
Abstraction |
XRI |
=drummond |
Delegates from left to right |
Description |
XRI proxy URI |
HTTP ==> XRDS |
|
Representation |
URI + others |
Access via URI-identified protocol |
Conclusions
This is only a placeholder – additional conclusions will be added as work on the paper progresses.
In the context of the same communications protocol, the same identifier cannot serve as both an abstract and concrete identifier. To support abstract identification and metadata discovery in addition to representation retrieval requires either:
- Using the same identifier in the context of two different protocols – a metadata resolution protocol and a representation retrieval protocol.
- Using the same protocol with two different identifiers, and creating a mapping between the abstract and concrete identifiers.
XRI Wiki