RE: Perisistence (was RE: [XRI] Private naming conventions and hypermedia)

Hello Drummond,

________________________________
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: 21 August 2008 20:24
To: Williams, Stuart (HP Labs, Bristol); 'John Bradley'
Cc: 'Mark Baker'; 'Henry S. Thompson'; www-tag@w3.org
Subject: RE: Perisistence (was RE: [XRI] Private naming conventions and hypermedia)

This thread has grown long and somewhat difficult to follow. However because it's important to the XRI discussion, I offer the following as a summary of some of the key points (and then will start a separate thread on a related topic):

1) A persistent XRI (an XRI consisting entirely of persistent subsegments, often called an i-number) is defined in XRI Syntax 2.0 [1] as meeting the functional requirements of a URN as specified in RFC 1737 [2].

2) That means that a persistent XRI is a claim by the identifier authority assigning it that the identification relationship (graph arc) between the persistent XRI and the resource it identifies (graph node) will never be reassigned, i.e., the arc will never be changed to point at a different node. For example, if the XRI is assigned to identify a specific person, the claim is that it will always identify that specific person (even after they die). If it is assigned to identify a specific organization, the claim is that it will always represent that specific organization (even after it is merged into another). If it is assigned to represent a specific document, the claim will always represent that specific document (even if it is subsequently renamed, moved, or becomes unavailable on the network).
Ok... modulo my comment in the other thread about lack of clarity about what is persistent... this is clear.

3) In URN architecture, a resolvable URN is resolved to a descriptor of the target resource called a URC (Uniform Resource Characteristics) (see section 1 of [1]). The URC contains metadata describing the target resource, which typically includes (but is not required to include) concrete identifiers or "locators" of the resource.

4) In XRI architecture, the URC is an XRDS document. XRDS documents enable mapping of an XRI (either a persistent XRI or a reassignable XRI) to concrete identifiers or "locators" called service endpoints. A service endpoint (very similar to an endpoint reference or EPR in web services architecture) can be either typed or untyped, and can contain zero or more concrete URIs for the target resource. In addition to service endpoints, XRDS documents also support synonym assertions (such as CanonicalID). These are assertions by the identifier authority of other identifiers that identify the same target resource as the original XRI.

5) While the XRDS document may itself be considered a first-class resource on the Web, by definition it is NOT the resource being identified by the XRI, just as a URC is not the resource identified by the URN. (More about this below.)
Ok... in that case an http GET on such an identifier should not directly give a 200 response with along with a representation of the XRDS document. Some form of redirection should be involved. [I'm not saying whether or not this is the case for XRI resolution - only that what is stated in 5 has that as a consequence].

6) The last and most subtle point about the relationship between XRIs, XRDS documents, and XRI authorities (which again is directly analogous to the relationship between URNs, URCs, and URN assignment authorities) is that in the authority component of an XRI, delegation between authorities is supported just like it is in DNS. This uses XRI subsegment architecture, which operates from left-to-right (vs. right-to-left delegation in DNS names). For example, in the theoretical XRI xri://@!1!2!3, the identifier authority for XRI @ registry assigns the persistent subsegment !1 to identifier authority #1; identifier authority #1 assigns the persistent subsegment !2 to identifier authority #2, and so on.

In such delegations, the target resource (node) being identified _is by definition the identifier authority for any additional delegations_. For persistent XRIs, _it is this delegation relationship (arc) that is persistent_. For example, in the theoretical XRI xri://@!1!2!3, the XRI @ identifier authority (which is a registry) is asserting that the subsegment !1 has been assigned once to a registrant and will not be reassigned to another registrant. That registrant, who is now the adminstrative authority for xri://@!1, is in turn asserting that the subsegment !2 has been assigned once to whatever type of resource may be identified in its scope, and will not be reassigned to another resource. If that resource is a registry for other identifier authorites, the identifier authority chain continues. If however any point in the chain you can reach an identifier for a resource that is NOT an identifier authority, such as a document, you've reached the end of the delegation chain. For example, if @!1!2 represented a document management system for persistent documents, then @!1!2!3 identifies a specific document in this registry. This XRI represents an assertion by the @!1!2 identifier authority that !3 has been assigned to one specific document and will not be reassigned to another document.

In all cases, however, the XRDS documents resolved in the process of traversing that resolution chain are _not_ the resources being identified.

Ok... that's been said enough times now that I'll not question it again - though I may pick up on inconsistent/ambiguous expressions.
I can understand the source of the confusion, however, because XRDS documents are a defined media type retreived from an http: or https: URI, so by AWWW guidelines they are first-class resources on the Web. I don't believe that is a problem, however; indeed, one might say that the whole premise of abstract identifier architecture is that an abstract identifier can be resolved to a resource that describes another resource, and this set of relationships is known a priori from the abstract identifier architecture. This, in a nutshell, is why it is essential to know, a priori, that an identifier is abstract, just as any application can know, a priori, that a URN is abstract just by looking at the urn: scheme prefix.

Hmm... I guess we could have a deeper discussion on what is meant by an identifier being abstract... not sure that it would help right now.

Which leads me to my next point, for which I'll start a new thread.

=Drummond

[1] http://docs.oasis-open.org/xri/xri-syntax/2.0/specs/cs01/xri-syntax-V2.0-cs.html
[2] http://www.w3.org/Addressing/rfc1737.txt

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England