Re: Boeing XRI Use Cases

Hi Erik,

I think the specific's of ARK  are a bit of a diversion from the main  
topic.

If I understood Henrys suggestion correctly he was proposing using a  
mechanism similar to ARK for indicating to client applications that  
they are processing an XRI rather than a http: URL.

I don't think the proposal went as far as using ARK itself though I  
could be wrong about that.

There seems to be a diversity of opinions regarding the idea of  
encoding a special identifier at the start of the http: path segment  
to indicate that a http: URL is something other than a "plain" http:  
URL.

In the ARK case we seem to be encoding a sub scheme in the URL path.

So to use the ARK pattern to encode a XRI it would look like:
http://xri.example.org/xri:/@boeing*jbradley/+home/+phone

Persistent identifiers in XRI would use the ! symbol in the XRI part  
to indicate persistence,  as per the XRI 2.0 spec.

I don't personally want to pass any judgement on ARK itself.  I think  
it is a valid pattern for us to consider.
It remains to be seen if it is the best of the proposals under  
consideration.

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley



On 16-Jul-08, at 4:40 PM, Erik Hetzner wrote:

> At Wed, 16 Jul 2008 14:12:43 -0700,
> "Paul Prescod" <paul@prescod.net> wrote:
>>
>> I don't think that your analogy is quite right. The problem is not
>> that two different URIs address the same resource. The problem is
>> that third-parties are encouraged to make general-purpose software
>> that pulls apart *any* URI and infers something about it on the
>> basis of whether it matches that pattern or not. That software will
>> make the wrong inference if it encounters a legacy URI that just
>> happens to match the pattern.
>>
>> […]
>
> Will this objection hold if third parties do not pull apart any URL,
> but only the URLs of organizations that have agreed to be part of ARK?
> In other words, if we know that example.org & example.com have agreed
> to be a part of ARK, is there a problem with pulling apart
> http://ark.example.org/ark:/12345/abcdefg and pointing at
> http://ark.example.com/ark:/12345/abcdefg, knowing that example.org,
> which no longer exists, was part of the ARK system, and not to pull
> apart http://ark.example.net/ark:/12345/abcdeg, a site devoted to
> Arkology?
>
> If this does not address the objection, then I am at a loss for a
> solution to the problem of:
>
> | objects that last longer than the organizations that provide
> | services for them, so when the provider changes it should not affect
> | the object's identity. [2]
>
> that: a) provides HTTP URLs which are resolvable now, b) allows for
> some simple mechanism to make them resolvable at some point in the
> future when the sponsoring organization no longer exists, and c) does
> not have a single point of failure (for instance, PURLs).
>
> best,
> Erik Hetzner
>
> (Here of course speaking only for myself, and not for the California
> Digital Library)
>
> 1. http://www.cdlib.org/inside/diglib/ark/
> ;; Erik Hetzner, California Digital Library
> ;; gnupg key id: 1024D/01DB07E3