A conversation Drummond and I had on the schema

["Barnhill William" <barnhill_william@bah.com>]

On the addressing element I see your point, and most if not all other 
addressing schemes could probably be expressed as an XRI.

On the container for subresources:
I don't understand the meaning of RDF tuple, I thought they were 
triples : (subject,relationship,direct object or do).
All of the information about a specific subject can be expressed by
(subject, ((relationship1,do1), (relationship2,do2),...
(relationship#,do#)))
If you add the assumption of a default primary relationship (hasData in 
XDI's case) then you get 
(subject, ((relationshipPrimary,doPrimary),(relationship1,do1), 
(relationship2,do2),...(relationship#,do#)))

That can be expressed as
(subject, ((relationship1,do1), (relationship2,do2),...
(relationship#,do#)), doPrimary)

If we then add the possibility of more than one do for each 
relationship it becomes:
(subject, ((relationship1,doSet1), (relationship2,doSet2),...
(relationship#,doSet#)), doSetPrimary)

At this point we have an expression that seems to map to XDI documents 
as we've talked about them.

With v5 of the Schema translations to xpath are:
  doSetPrimary => /resource/data
  doSetPrimary's do #x =? /resource/data/resource[x]
  subject => /resource
  relationship pair #x => /resource/resource[x]

The questions I have with that are:
1. If relationship pair #x => /resource/resource[x] then wouldn't that 
be expressing:
(subject, (relationship1,doSet1), (relationship2,doSet2),...
(relationship#,doSet#), doSetPrimary)? A somewhat subtle difference, 
but it isn't the same as our model

2. 
Would not
  subject => /resource
  doSetPrimary => /resource/data
  doSetPrimary's do #x =? /resource/data/resource[x]
  relationship pair #x => /resource/assoc/resource[x]

be (a) easier to understand/follow, (b) easier to parse, (c) easier to 
express as a graph? For comparison v5 is reproduced here in the same 
order:

  subject => /resource
  doSetPrimary => /resource/data
  doSetPrimary's do #x =? /resource/data/resource[x]
  relationship pair #x => /resource/resource[x]

3) From an easier to follow perspective here is a comparison using 
xpath to represent traversal:
A path of /x/y*z  translates to:
a. start at root of resource returned by authority resolution (ptr=/)
b. Found /, so ptr=ptr/data=/data
c. Found x, so ptr=ptr/resource/xri[text() = 'x']/..
            =/data/resource/xri[text() = 'x']/..
d. Found /, so ptr=ptr/data
            =/data/resource/xri[text() = 'x']/../data
e. Found y, so ptr=ptr/resource/xri[text() = 'y']/..
            =/data/resource/xri[text() = 'x']/../data/resource/xri[text
() = 'y']/..
f. Found *, so ptr=ptr? That works from an xpath perspective, but is it 
what we are trying to model?
g. Found z, so ptr=ptr/resource/xri[text() = 'z']/..
            =/data/resource/xri[text() = 'x']/../data/resource/xri[text
() = 'y']/../resource/xri[text() = 'z']/..

Using assoc container the xpath steps become...
a. ptr=/
b. ptr=/data
c. ptr==/data/resource/xri[text() = 'x']/..
d. ptr=/data/resource/xri[text() = 'x']/../data
e. ptr=/data/resource/xri[text() = 'x']/../data/resource/xri[text() 
= 'y']/..
f. *, ptr=ptr/assoc
 =/data/resource/xri[text() = 'x']/../data/resource/xri[text() 
= 'y']/../assoc
g. ptr=ptr/resource/xri[text() = 'z']/..
            =/data/resource/xri[text() = 'x']/../data/resource/xri[text
() = 'y']/../assoc/resource/xri[text() = 'z']/..

Both work, but the second seems to express the model more. Also it may 
be useful at some point to express XDI traversal mathematically:
a * b => a/resource/xri[text() = 'b']/..
a / b => a/data/resource/xri[text() = 'b']/..

or

a * b => a/assoc/resource/xri[text() = 'b']/..
a / b => a/data/resource/xri[text() = 'b']/..

In short v5 will definitely work, but adding assoc seems to make it fit 
the RDF concept of triples (and the XDI model?) more.

You have more experience in this by far than me, and more stake, so 
I'll definitely bow out gracefully now if you want to go with v5, but I 
do think adding an assoc (or some other name) will aid us greatly in 
the long run.

As a last bit I think I had more than xsd:any in there, as xsd:any does 
not express any element from a different namespace.

Bill

----- Original Message -----
From: "Drummond Reed" <drummond.reed@cordance.net>
Date: Wednesday, August 18, 2004 4:26 am
Subject: RE: RE: RE: XDI XRI Authority use cases

> Bill,
> 
> I just (finally) uploaded all the v5 metaschema and addressing stuff.
> 
> You'll see that I ditched the Comment element in v5, per your 
> suggestion of
> just using XML comments (don't know what I was thinking when I 
> first added
> it).
> 
> I did not add an Addressing element, or a container element for
> subresources, for reasons I'll explain more on the call. There is 
> anotherway to address XRI elements directly (and describe them to 
> any depth, just
> like any other resource) without adding any new elements or 
> attributes. It's
> not shown in these examples yet - I want to run it by you first - 
> but I
> think you'll appreciate its elegance.
> 
> And on the attraction of the symmetry of subresources having a 
> containerelement just like resources in the Data branch have a 
> container element, I
> went down this path when first developing the v5 metaschema. But I was
> surprised that the resulting XDI documents, having 4 elements 
> instead of 3,
> turned out to be more complex and harder to follow, so I took it out.
> 
> There is, IMHO, an amazing elegance to the "XDI tuple". It builds 
> straightoff the RDF tuple. The more I work with it the more it 
> makes sense. After
> tomorrow's call the next step is to start building some more 
> complex XDI
> documents that show i-business cards and link contracts. That's 
> where the
> power of the XDI tuple design really starts to shine.
> 
> I want to go over those with you as soon as they are ready to see 
> if you
> agree, but in the meantime to get you at least this much feedback 
> on your
> excellent ideas.
> 
> Talk to you tomorrow,
> 
> =Drummond