RE: Boeing XRI Use Cases

Hi John & Erik (& All),
 
I don't like the pattern ARK uses (for reasons already mentioned), and I'm
not in favor of using the same pattern for XRI (for the same reasons already
mentioned). But I do think it would be interesting to look at expressing
ARKs within XRI.
 
I think the problems Erik mentioned align very well with one of the Boeing
XRI Use Cases (see  <http://wiki.oasis-open.org/xri/BoeingXriUseCases>
http://wiki.oasis-open.org/xri/BoeingXriUseCases). Look at the fifth one:
"Multiple Identity Providers (for the same entity)". 
 
Henry said the metadata for a particular object is intended to be the same
no matter which sponsoring organization is asked. Although the Boeing use
case describes different metadata being returned by each identity provider,
certain metadata items could be intended to carry the same information about
a resource no matter which identity provider is asked. 
 
An ARK expressed in HXRI that is resolvable now might look like this
(unfortunately the delimiter between the NAAN and the name is a slash, which
would have to be percent encoded as %2F in an XRI cross reference):
 
     http://xri.net/ark.example.org*($ark*12345%2Fabcdefg)
<http://xri.net/ark.example.org*($ark*12345%2Fabcdefg> 
 
This example assumes that "$ark" gets defined in the XRI "$" dictionary.
This is an unambiguous way for the minter to declare (and for the relying
party to know) that "12345/abcdefg" is an ARK. It would look a little
cleaner if the delimiter between the NAAN and the name were some other
character that wouldn't require percent encoding. The power of using XRI for
this is that it can work for nearly(?) any type of identifier.

Marty.Schleiff@boeing.com; CISSP 
Associate Technical Fellow - Cyber Identity Specialist 
Information Security - Technical Controls 
(206) 679-5933 

 

  _____  

From: John Bradley [mailto:john.bradley@wingaa.com] 
Sent: Wednesday, July 16, 2008 5:04 PM
To: Erik Hetzner
Cc: Paul Prescod; Henry S. Thompson; Mark Baker; Booth, David (HP Software -
Boston); www-tag@w3.org
Subject: 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