RE: [xri] Outline for XRI Primer

["Drummond Reed" <drummond.reed@cordance.net>]

Great stuff! This really helps me understand the logic of your ranking.

The larger issue this brings up is the many different perspectives we bring
to the question of "Why XRIs?" It's entirely possible that among the editors
(let alone the entire TC), if we asked everyone to stack rank the features
by importance, we'd get 7 different lists.

And that's not a bad thing. It's a GOOD thing. That's why we're all on this
TC together. We all have different use cases that have different priorities
for different features.

The challenge it presents us is how we come together on one Primer that's
designed to quickly orient a newcomer by answering the following two
questions:

1) Why might I want to use XRIs - what problems do they help me solve that
URIs alone don't? 

2) How do XRIs, XRI resolution, and XRI metadata help me solve these
problems?

As I write this, I'm already seeing a new approach to the outline, which is
to focus less on which feature is more/less important (because that
ultimately can only be determined by the reader) and more on providing clear
articulations of:

a) The types of problems XRIs are designed to help solve (problems of
federating identifiers across distributed systems, problems of maintaining
persistent relationships, problems of sharing identifiers across many
contexts, problems of providing identifier interoperability across many
different disparate systems.)

b) How XRIs are designed to solve these problems (how they can be used to
federate systems, how they can be used to provide persistent
identity/linking, how they can be used to share identifiers across contexts,
how they can be used to provide identifier interoperability across disparate
systems).

The first part could be a relatively short, crisp description of the types
of problems XRIs are designed to solve. The second part can be a sequence of
example usage scenarios that show how how it can be done (all feeding off
each other so we don't have to set up new example scenarios over and over
again.)

So the high-level outline becomes:

1) Introduction (very short)

2) The Types of Problems XRIs Are Designed to Solve

3) How XRIs Can Help Solve These Problems: Example Usage Scenarios

4) A Brief Guide to the Normative 2.0 Specifications

Appendix A: Glossary

How does this new high-level approach sound?

=Drummond 

-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Thursday, February 10, 2005 9:17 AM
To: xri@lists.oasis-open.org
Subject: RE: [xri] Outline for XRI Primer

 I came up with this order of the features by doing two things.  A
pairwise comparison between each feature and thinking about which
feature was most useful to me as an architect or developer of
distributed systems.  The other factor I considered was which features
are more clearly available in XRIs than in other URI schemes (e.g., HTTP
URLs).  For me the key is that XRIs support the development of
distributed systems and federation is something that I would argue is
necessary for those systems and not as easily available in other URI
schemes.

As for persistence falling to the bottom of my list, while I find it a
theoretically interesting feature, I don't have good use cases for it --
and XRI only supports it in syntax, not in implementation or deployment.
So given that perspective, I find all of the other features more useful
to architects/developers.

Mike

>-----Original Message-----
>From: Drummond Reed [mailto:drummond.reed@cordance.net] 
>Sent: Wednesday, February 09, 2005 5:52 PM
>To: Lindelsee, Mike ; xri@lists.oasis-open.org
>Subject: RE: [xri] Outline for XRI Primer
>
>This is great stuff for helping stamp out "tunnel vision" 
>(like I said, I've
>spent too much of my time explaining this stuff to have a fresh
>perspective).
>
>I like the idea of introducing these features first (in the 
>context of a
>high-level "Why XRI" section), then going into usage scenarios.
>
>I also fully agree with emphasizing Internationalization, I 
>just intended to
>do that in a separate section devoted to IRIs.
>
>That said, please do elaborate on why you feel Federation 
>should be the #1
>feature (and persistence the #6 feature - I find it hard to justify
>Persistence being that low.)
>
>=Drummond 
>
>-----Original Message-----
>From: Lindelsee, Mike [mailto:mlindels@visa.com] 
>Sent: Wednesday, February 09, 2005 10:34 AM
>To: xri@lists.oasis-open.org
>Subject: RE: [xri] Outline for XRI Primer
>
>While persistence might be easy to explain, I don't see it as the most
>important feature of XRIs.  I'd prefer to order the material covered in
>the primer by importance or value. In those terms, I see the 
>five listed
>features (and have added I18N to the list) as having this order (in
>order of descending value):
>
>  Federation
>  Cross References
>  Internationalization
>  Extensibility
>  Global Context Symbols
>  Persistence
>
>I also wonder if it makes sense to introduce these features first and
>then move on to the more general question of "why XRIs" followed by
>usage scenarios.
>
>Mike
>
>>-----Original Message-----
>>From: Drummond Reed [mailto:drummond.reed@cordance.net] 
>>Sent: Wednesday, February 09, 2005 9:59 AM
>>To: Wachob, Gabe; xri@lists.oasis-open.org
>>Cc: 'Fen Labalme'
>>Subject: RE: [xri] Outline for XRI Primer
>>
>>Gabe,
>>
>>Great points all. I agree that I don't think we can emphasize 
>>enough that
>>XRIs only deliver *syntactic support* for persistent 
>>identifier management.
>>The rest is up to XRI authority management policies.
>>
>>That said, let me play devil's advocate and suggest the 
>>reasons for still
>>putting it first. IMHO the first and foremost job of the 
>>Primer will be to
>>answer the questions: "Why might I want to use XRIs? What 
>>problems do they
>>help me solve that URIs alone don't? And how do they help me 
>>(an Internet
>>architect, a software developer, a network administrator, an 
>>schema/ontology
>>developer, a policy maker) solve these problems?"
>>
>>If you agree that this is the overall objective, then the 
>>reason I would
>>still suggest putting persistence first is simply that it's 
>the easiest
>>problem to explain. The need for persistent identifiers goes 
>>back almost a
>>decade, as witnessed by the entire IETF/W3C URN effort. IMHO, 
>>persistence is
>>THE killer argument for abstract identifiers. While there are 
>>solutions to
>>providing persistent network identifiers that do not involve 
>>an additional
>>layer of abstraction, using abstract identifiers is the 
>>obvious solution.
>>
>>Secondly, in the presentations I've given about XRI 
>>architecture, starting
>>with the need to use abstract identifiers for persistence 
>>leads naturally to
>>the follow-on question, "Okay, so why haven't URNs been more 
>>widely adopted?
>>What do XRIs provide that URNs didn't?" With the answer being, 
>>"A uniform
>>way to provide both a layer of persistent abstract identifiers 
>>AND a layer
>>of human-friendly, reassignable identifiers that make 
>>persistent identifier
>>layer much more useable".
>>
>>In short, the i-name --> i-number --> URI resolution pattern 
>>that has become
>>so familiar to those of us working on XRI infrastructure.
>>
>>Thirdly, I've found that leading with how XRI architecture 
>>applies to the
>>persistence problem works great as a lead-in to cross-references. IMHO
>>cross-references are the "headline" feature of XRI 
>>architecture. But I find
>>that they can also be the most challenging feature to understand. In
>>particular, if I start out trying to explain XRIs using 
>>cross-references, it
>>can be very rough going. However I've found that if I've laid 
>>out the basics
>>of how XRIs work as abstract identifiers by explaining the persistence
>>problem first, then explaining cross-references gets much easier.
>>
>>Likewise the reason I suggest placing Global Context Symbols 
>>third is that
>>GCS architecture makes a lot more sense once you understand
>>cross-references, because you understand the reasons you'd 
>>want these five
>>abstract global contexts. It also sets up nicely the other 
>>option for an XRI
>>authority, which is using a cross-reference itself as a global root.
>>
>>Once these three key concepts are in place, explaining 
>>delegation/federation
>>syntax is pretty easy, especially because you can show the 
>>usefullness of
>>delegating/federating using cross-references (e.g.,
>>"@Example.Corp*(+customer.service)".
>>
>>And with those four topics behind you, explaining XRI extensibility is
>>simply a matter of showing how these four features are 
>>combined to allow any
>>XRI authority to extend any XRI namespace.
>>
>>So that's my case for the proposed order. However as a writer, I fully
>>understand the problem of my having been steeped in XRI too 
>>long, leaving me
>>a potential victim of "tunnel vision". So if you believe 
>>there's a better
>>path we can take to explain these five features - either in a 
>different
>>order, or using a different approach altogether - let me know. 
>>I plan to
>>spend pretty much all of the week of 2/21 working on the 
>>Primer, and before
>>I start, I'd really like to have an outline everyone is 
>>comfortable with.
>>
>>=Drummond 
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_
>workgroup.php
>.
>
>
>
>

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php
.