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

Hello John,

> Stuart Williams wanted me to have a stab at the persistence question.
> Hopefully this will advance the conversation.

Let me unpick may question a bit, largely from a position of personal
ignorance on persistent XRI.

Firstly a couple of syntactic/administrative questions using your example
from below:

	xri://@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9

As an XRI, this has two peristent segments: 

	!B1E8.C27B.E41C.25C3
and
	!A7B8.4D42.3EF6.C2A9

Which of the following (if any) is correct:

a) The second segment is scoped by the first (ie. the authority for
!B1E8.C27B.E41C.25C3 
   can mint subordinate persistent path segments provided they meet some
administrative 
   policy requirement eg. such that they are never re-assigned).

Or...

b) Each persistent segment name is independently globally significant and
assigned by some 
   centrally administer registry.


Secondly, how does one obtain an assigned persistent segment name?

Ok... syntactic/admin questions out of the way...

What is it that is intended to be persistent? Some candidate responses...

a) The identifier? (but that is trivially true)

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

c) The resource itself in the sense that the resource is persistently
available to be accessed via the given identifier?

d) The resource state in the sense that the state of the resource is
invariant over all (future?) time
   ie. all future retrieval operations provide access to an invariant set of
resource representations (content-type + bits).

e) The meta-data accessed via the given identifier in the sense that, whilst
it may change, it is persistently avaialable and
   persistently about the thing designated by the identifier.

f) The meta-data accessed via the given identifier in the sense that that
meta-data is invariant (and persistently available).

In terms of wha you say below:

> 2. Persistent,  "Not Reassignable"  These entities will by  
> administration policy will not change owner, or be reassigned in any  
> way.
> 
> Nether of these say anything about the contents of the XRDS,  the  
> contents of a given XRD associated with a CID can change at any time.
> 
> In XRI persistence is a quality of the identifier not the data.

I don't know what you mean by this... that persistence "is a quality of the
identifier." 
That seems most closely aligned with a) or b) above, of which b) is more
useful and likely.

> In ARK Persistence is a quality of the data not the identifier.   A  
> given ARK URL may or may not exist at any point.  The only thin that  
> may be persistent aside from the data would be the URI path.

Ok... that's close to c) or d) above, I suspect d) with an expectation that
the resource itself is invariant.

Wrt to CanonicalIDs. Are they necessarily fully persistent XRIs? Can they be
any XRI or indeed URI?

If two non-persistent XRI resolve (eventually possibly after serveral
resolution cycles) to the same (fully persistent?) XRI
can we conclude that the original pair of XRI designate the same thing
(whatever it may be)? Currently? Over what temporal scope?

All of these questions are merely seeking to understand the design intention
or persistent requirements of XRI.

Regards

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

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of John Bradley
> Sent: 25 July 2008 19:40
> To: Mark Baker
> Cc: Henry S. Thompson; www-tag@w3.org
> Subject: Re: [XRI] Private naming conventions and hypermedia
> 
> Hi Mark,
> 
> I am going to use the IRI form with the xri: scheme in my 
> examples as  
> that is what is currently in the spec.
> the proposed HXRI forms add additional complexity.
> 
> Remember XRI is more like DNS resolution than http:
> 
> The process of dereferencing an XRI via native resolution always  
> results in a XRDS document containing a CannonicalID element
>   <CanonicalID>xri://@!1</CanonicalID>
> 
> Any number of XRI may resolve to the same CID
> 
> As an example
> xri://@id*fmof
> xri://@id*五里霧中
> xri://@id*gorimuchuu
> xri://@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9
> 
> All of these deference to an XRDS document  with a CannonicalID  
> element in the final XRD containing
> <CanonicalID>xri://@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9</ 
> CanonicalID>
> 
> The process of dereferencing a XRI maps the identifier to a uniques  
> entity described by an XRD
> 
> Each XRI identifier may produce a different XRDS document during  
> resolution depending on the path through the XRI graph it takes.
> The sequence of XRD's in a XRDS are determined by XRD refs and XRI  
> cross-references encountered during the resolution of the authority  
> sub segments.
> However equivalence is determined via the contents of the final XRD.
> 
> If you look closely at the CID you will notice that it contains  
> subsegments prefixed with !.
> 
> The ! indicates a persistent subsegment.
> 
> The Syntax spec states:
> 
> > An XRI consisting entirely of persistent segments is designed to  
> > meet the requirements set out in Functional Requirements 
> for Uniform  
> > Resource Names [RFC1737].
> >
> > XRI syntax extends generic IRI syntax in the following four ways:
> >
> > 	* Persistent and reassignable segments. Unlike generic 
> URI syntax,  
> > XRI syntax allows the internal components of an XRI 
> reference to be  
> > explicitly designated as either persistent or reassignable.
> >
> > 	* Cross-references. Cross-references allow XRI references to  
> > contain other XRI references or IRIs as 
> syntactically-delimited sub- 
> > segments. This provides syntactic support for “compound  
> > identifiers”, i.e., the use of well-known, fully-qualified  
> > identifiers within the context of another XRI reference. Typical  
> > uses of cross-references include using well-known types of 
> metadata  
> > in an XRI reference (such as language or versioning metadata), or  
> > the use of globally-defined identifiers to mark parts of an XRI  
> > reference as having application- or vocabulary-specific semantics.
> >
> > 	* Additional authority types. While XRI syntax supports 
> the same  
> > generic syntax used in IRIs for DNS and IP authorities, it also  
> > provides two additional options for identifying an authority: a)  
> > global context symbols (GCS), shorthand characters used for  
> > establishing the abstract global context of an identifier, and b)  
> > cross-references, which enable any identifier to be used to 
> specify  
> > an XRI authority.
> >
> > 	* Standardized federation. Federated identifiers are those  
> > delegated across multiple authorities, such as DNS names. Generic  
> > URI syntax leaves the syntax for federated identifiers up to  
> > individual URI schemes, with the exception of explicit support for  
> > IP addresses. XRI syntax standardizes federation of both 
> persistent  
> > and reassignable identifiers at any level of the path.
> >
> 
> This leads us to the question of what do we all mean by "Persistence"
> 
> In ARK I think that persistence is meant as some indication that the  
> "Data/Meta Data"  pointed to by a specially formated URL path is  
> intended to be the same as data pointed to by the same specially  
> formated path under a different authority.
> 
> This would seem on first examination completely different use case  
> compared to the "Persistence"  provided by XRI syntax and resolution.
> 
> 
> In XRI there are two basic subsegment types:
> 1. Reassignable,  These identifiers can be re-used and move from one  
> persons control to another they may be reconfigured to point to any  
> CannonicalID at any time for any reason under the control of the  
> person or organization who has administrative control of the 
> identifyer.
> 
> 2. Persistent,  "Not Reassignable"  These entities will by  
> administration policy will not change owner, or be reassigned in any  
> way.
> 
> Nether of these say anything about the contents of the XRDS,  the  
> contents of a given XRD associated with a CID can change at any time.
> 
> In XRI persistence is a quality of the identifier not the data.
> 
> In ARK Persistence is a quality of the data not the identifier.   A  
> given ARK URL may or may not exist at any point.  The only thin that  
> may be persistent aside from the data would be the URI path.
> 
> I find the concept of a persistent URL path without a persistent URL  
> authority a bit of a slippery one.
> 
> People will raise the question of what is a good administrative  
> authority who adheres to the rules vs a bad one.
> 
> XRI and ARK have to answer that question to there constituent  
> communities.
> 
> What ARK and XRI both enable is a syntactical way of communicating  
> persistence.
> 
> Though I would argue different notions of persistence.
> 
> When we look at HXRI the http: proxy starts attracting some of the  
> problems encountered by ARK.
> 
> Take one of my above examples as a HXRI:
> 
> http://xri.net/@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9
> 
> I have now mixed what may be an in-persistent DNS authority with a  
> persistent XRI.
> I have certainly lost the benefit of it being a URN, unless we move  
> forward with one of the proposals to create "Special DNS Authorities"
> 
> I suppose ICAN could make a special class of "Persistent 
> Authorities"  
> for DNS.
> 
> Stuart Williams wanted me to have a stab at the persistence question.
> Hopefully this will advance the conversation.
> 
> Best Regards
> John Bradley
> OASIS IDTRUST-SC
> http://xri.net/=jbradley
> 五里霧中
> 
> 
> 
> >
> > On 25-Jul-08, at 9:41 AM, Mark Baker wrote:
> >
> >
> >> HST [...] I think there's a fundamental issue we need to be clear  
> >> on: is it OK for a group of domain name owners to agree a naming  
> >> convention amongst themselves? In the ARK case, this 
> trespasses on  
> >> the WebArch advice wrt aliasing, and in general might also 
> seem to  
> >> fall foul of the whole business of URI opacity (that was Mark  
> >> Baker's particular concern).
> >
> > "URI Opacity" is a term that I've found means different things to
> > different folks, so I try to avoid it now.  But I do believe that
> > private naming conventions do cause harm to the Web because they are
> > essentially a proprietary form of link and link metadata.  
> If two URIs
> > at different domains identify the same resource, 
> dereferencing one of
> > them should provide a declaration (Link header, RDFa, whatever) that
> > the resource is the same (owl:sameAs or equivalent) as the other.
> >
> >> From a REST perspective, the architectural constraint that's being
> > disregarded by this practice is "hypermedia as the engine of
> > application state", and IMO, it's the constraint most 
> responsible for
> > imparting Web-nature.
> >
> > Cheers,
> >
> > Mark.
> >
> 
>