- From: Schleiff, Marty <marty.schleiff@boeing.com>
- Date: Wed, 16 Jul 2008 23:14:09 -0700
- To: "Schleiff, Marty" <marty.schleiff@boeing.com>, "John Bradley" <john.bradley@wingaa.com>, "Erik Hetzner" <erik.hetzner@ucop.edu>
- Cc: "Paul Prescod" <paul@prescod.net>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Mark Baker" <distobj@acm.org>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, <www-tag@w3.org>
- Message-ID: <173625C7A199934BA40AAA1CD296D2B54DE0B3@XCH-NW-03P.nw.nos.boeing.com>
I've been informed that a couple things in my prior message (below) were confusing. I'll try to clear them up. First, my example had a slight syntax error (the first asterisk should have been a slash). Second, I reused the authority segment ("ark.example.org") from Erik's example, and some people though the "ark" was significant to the discussion. I'll just use "example.org" in the new example. Third, I mentioned ARK's acronym "NAAN" without defining it. It stands for Name Assigning Authority Number. It's the part before the slash ("12345" in the example). Here's the corrected example of an ARK expressed in HXRI: http://xri.net/example.org/($ark*12345%2Fabcdefg) A fourth possible point of confusion is that I took liberty to drop parts of the ARK syntax that I thought could be better served by XRI syntax. In fact the complete ARK syntax (see http://www.cdlib.org/inside/diglib/ark/) could be retained when expressing an ARK in an HXRI, something like the following (it gets pretty ugly having to percent encode all the slashes): http://xri.net/$ark*(http:%2F%2Fexample.org%2Fark:%2F12345%2Fabcdefg) ARK proponents could pick their preferred format (there are probably other options as well) and specify the definition of "$ark" so that everyone understands the intended meaning and syntax constraints. I hope ARK proponents will be interested enough to explore use of XRI to represent ARKs. Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow - Cyber Identity Specialist Information Security - Technical Controls (206) 679-5933 _____ From: Schleiff, Marty Sent: Wednesday, July 16, 2008 6:08 PM To: John Bradley; 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 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
Received on Thursday, 17 July 2008 06:15:41 UTC