Re: XRI, URI

On Jun 14, 2008, at 6:18 PM, Earle Martin wrote:

> If URL stability is an issue, why not use OID URNs (RFC 3061) or UUID
> URNs (RFC 4122)?

How would this help? These identifiers have no protocol by which one  
can locate something. So the comparison seems, to me, to be between  
HTTP URIs which have both the ability to identify, *and* (if tended  
to) the ability to locate, versus other systems that have only the  
ability to identify.

> Both are freely available and permanent, and it is even possible to  
> register UUIDs as OIDs if you wish (HTTP://www.oid-info.com/get/2.25).

some HTTP URIs are also free (such as those at purl.org), and most  
are cheap. As far as their roles as identifiers go, all HTTP URIs are  
permanent. Even upon change of ownership of the domain of a HTTP URI,  
all that changes is the right decide what a server responses when GET  
request is made using the standard protocol. Nothing can force people  
to not simply ignore such responses in the face of malfeasance and  
keep using a HTTP URI to identify what it has always identified.   
Thus these qualities ascribed to the alternatives do not convey any  
advantage over HTTP URIs, and each of them starts with a disadvantage  
- the lack of a well deployed protocol by which to serve  
documentation about the identifier.

> If availability as a URL is also desirable, setting up a resolver  
> (such as the DOI resolver at HTTP://dx.doi.org/) is trivial, and  
> integrates well with the 303 redirect system.

In which case we've the same system as URIs in the first place, with  
the same benefits and weaknesses. So why bother leaving HTTP in the  
first place? In the worse case, a separate resolver can also be set  
up for HTTP URIs should it be determined that owners of domains do  
not continue to responsibly respond to requests at the URI.

> To me, XRIs appear to be the reinvention, at least from the  
> viewpoint of an end user with fairly simplistic requirements.

To be honest, many of the identifier schemes, uuids, oids, and other  
urn schemes seem for the most part, to me, someone with needs that  
range from the simple to the sophisticated, not to offer anything  
over HTTP. Issues around stability are more of a social and  
institutional issue than a technical one.  At worst, these  
alternatives may give users a false sense of security by implying  
that they are somehow superior to HTTP URIs, and therefore lull them  
in to thinking that they somehow need to do less work to ensure that  
adequate documentation remains available over the time one expects  
them to be stable over.

-Alan