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).



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.)



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. 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.



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



  _____

From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
Williams, Stuart (HP Labs, Bristol)
Sent: Thursday, August 21, 2008 6:30 AM
To: John Bradley
Cc: Mark Baker; Henry S. Thompson; www-tag@w3.org
Subject: RE: Perisistence (was RE: [XRI] Private naming conventions and
hypermedia)



Hello John,






  _____


From: John Bradley [mailto:john.bradley@wingaa.com]
Sent: 08 August 2008 00:48
To: Williams, Stuart (HP Labs, Bristol)
Cc: Mark Baker; Henry S. Thompson; www-tag@w3.org
Subject: Re: Perisistence (was RE: [XRI] Private naming conventions and
hypermedia)

Hi Stuart,



Reply inline.



On 7-Aug-08, at 2:57 AM, Williams, Stuart (HP Labs, Bristol) wrote:



 <snip/>

This must be an identifier for which the parent authority is the final
authority.



For any XRI other than a community root authority (DNS) the CID must consist
of the parent authorities CanonicalID plus one additional subsegment.



Once assigned, a parent authority SHOULD NEVER

a) change or reassign a CanonicalID value



Never change => only ever assign one CID to a given thing?



 <snip/>

Assuming that that's out of the way, back to what it is that is persistent.

Your response to my question on that was:




B)  is the closest.  It is the mapping assigned by the parent

authority to the relationship between and administrative

authority and  the identifier.


where B) was




b) The association between the identifier and whatever it refers to (a

resource?)?


I think this in part gets close to the heart of the matter. What I believe
you are saying is that what it is that is persistent is, as you say, the
relationship between an (persistent) identifier and the authority that
administers it.

Yes it is an administrative relationship.

! segments are used to specify persistent identifiers―identifiers that are
permanently assigned to a resource and will not be reassigned at a future
date.



In this context the resource is the XRD document.  The administrative
control of that XRD document must not be reassigned.



Ah... we're back into the data v metadata thing. In what I wrote I was
meaning the resource to be whatever the XRI was intended to be used to refer
to (denote), rather than metadata (an XRD document) about that thing. eg. in
the example I tried to construct earlier of an XRI for the "XRI 2.0
Resolution Spec" the resource would be just that, the spec, and not the XRD
document which (one presumes) would describe the spec. (or at least how to
obtain a copy of it).



>From your answer above, what is persistent is the relationship between and
XRD 'resolved' by the resolution protocol and the administrative authority
that controls that document. As the content of the XRD document itself can
change, and could presumably over time described different things (maybe)
then the relationship between a persistent XRI and the thing it denotes
could change by fiat of a change in an XRD... though that may be a violation
of XRI architecture which might demand a fresh persistent XRI CID in such a
circumstance - which then breaks the premise (because we have a new CID and
a new persistent relationship).



If =skw is assigned to you along with =!BF81.FD97.C81B.B4E5 and at some
point you stop paying for =skw and TBL wants to purchase it he can get =skw
but not =!BF81.FD97.C81B.B4E5,  a new CID would be created if he needed it.



As the openid.claimed_id is the CID and not the iName TBL would not be able
to get access to your resources.



It is always possible to reassign the administrative control of a XRD to
some other entity if the owner requests it.

That might be necessary if a company is sold or something like that.



This is largely a social matter wrt to administrative policy rather than a
technical one. The underlying social issue that this seeks to address is a
lack of stabilty in this relationship induced by the administrative policies
assoicated with the DNS - specifically, that the authority for a given
domain name can change over time. If DNS domains were not 'rented' on a 1-2
year renewal basis where an authority can 'accidentally' loose
administrative control over the name through inattention, or simply
relinquish control which is subsequently picked up by another party.

Is that the primary issues that motivates persistent (top-level) XRI path
names?



Yes DNS has no way to detect identifier recycling.



That's a pity.



<snip/>





Anyway, the persistence XRI speaks of for persistent identifiers is the
persistent in the relationship between and identifier and its administrative
authority.



Yes,  the identifier is assigned to a XRD and the administrative authority
for that XRD will not be reassigned.



There's that data/metadata thing again...  we (or I) need to have a
consistent understanding of what an XRI is assigned to, AIUI, an XRD(S)
document arising as part of the resolution process is a stepping stone in
making that determination, but in general is *not* what is denoted or
referred to by the identifier being resolved. I think that there may be a
further obligation on the administrative authority not to change *what* is
being described in an XRD(S) document without assigning a new CID.



By contrast a reassignable XRI can be assigned by an identifier authority to
represent a different resource at some future time.



I hope that helps.



Best Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中

<snip/>



Regards



Stuart

--

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