Re: [xdi] Re: XDI addressing across nested contexts: abreakthrough

["Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>]

I think that this is an excellent realization, also because the second  
form (collapsed) is much more explicit as it clearly states what is  
the subject, predicates and objects you're working on.
Actually this was one of my point I proposed for discussion after PDX  
example was issued - point named "'how much' goes in the subject..."  
in the minutes, which we never had the time to discuss...

Kind Regards,
Giovanni

Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:

> I'm guessing from the lack of reply to this post last Friday that either: a)
> it's August and everyone is doing as they should be and enjoying their
> summer, or b) it didn't sink in.
>
> Well, in case the latter is the case, here's another way to explain it that
> should kick a kick to the summer brain. According to this proposal, the
> following two X3 Simple serializations are EQUIVALENT (meaning the express
> the same logical XDI graph):
>
>     +a
>
>       +b
>
>             /
>
>                   $
>
>                   +c
>
>                         +d
>
>                               /
>
>                                     $
>
>                                     +e
>
>
>
> +a
>
> +a+b
>
> +a+b+c
>
> +a+b+c+d
>
> +a+b+c+d+e
>
> And if that doesn't sink in, let me just should it out in black and white:
> WHAT THIS MEANS IS THAT ANY XDI GRAPH, NO MATTER HOW DEEPLY NESTED, CAN BE
> FOLDED INTO A SINGLE LEVEL XDI GRAPH, AND VICE VERSA.
>
> Here's another example, from the PDX Example
> document<http://wiki.oasis-open.org/xdi/PdxExample>.
> Following is an street address example taken from that document:
>
>         =!1111.aaaa.bbbb.cccc!9999.xxxx.yyyy.zzzz   <-- XDI subject -->
>
>       +postal+address$1   <-- XDI predicate -->
>
>             /   <-- XDI object, in this case a nested XDI graph -->
>
>                   $   <-- XDI subject in the nested graph, in this
> case the context root subject -->
>
>                         +1+street
>
>                               "100 Main St"
>
>                         +2+street
>
>                               "Apt 34"
>
>                         +city
>
>                               "Seattle"
>
>                         +state
>
>                               "WA"
>
>                         +postal.code
>
>                               "98101"
>
>                         +country
>
>                               "USA"
>
>
> Now, following the rule stated above, the above can be collapsed into
> (meaning is semantically equivalent to):
>
>     =!1111.aaaa.bbbb.cccc!9999.xxxx.yyyy.zzzz+postal+address$1
>
>             +1+street
>
>                   "100 Main St"
>
>             +2+street
>
>                   "Apt 34"
>
>             +city
>
>                   "Seattle"
>
>             +state
>
>                   "WA"
>
>             +postal.code
>
>                   "98101"
>
>             +country
>
>                   "USA"
>
>
> I don't know about anyone else, but I think this is really profound. It
> means that multi-subsegment XRIs in XDI addresses (+a+b+c) all represent
> addresses across nested contexts and vice versa (i.e., all nested contexts
> can be represented as multi-subsegment XRIs).
>
> IMHO this should go a huge ways towards simplifying XDI conceptually and
> optimizing XDI code and indexing. I look forward to discussing it in depth
> at the XDI Retreat.
>
> =Drummond
>
>
> On Fri, Aug 6, 2010 at 1:44 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
>
>> In working on some documentation for the upcoming XDI Retreat, I had a
>> realization about $has$a statements that I think can help bring even more
>> clarity to their definition.
>>
>> We have said that the XDI statement +a/$has$a/+b, which we have defined as
>> also be expressed as +a+b, represents *the set of all nodes that are
>> objects of the +a/+b relation*. In other words, +a/+b is the relation that
>> defines the set, and +a+b identifies the set of all members who have that
>> relation.
>>
>> What I realized is that from a graphing perspective, this simply means that
>> *+b is a subject inside the context +a*.
>>
>> When I say, "the context +a", what I mean is that every XDI subject, in
>> addition to being INSIDE a context, can also be the root of its own context
>> (every XDI context is an unique XRI addressing space). So if +a identifies
>> the root of a new context nested inside its parent context, then +a+b
>> identifies a subject +b *inside that nested context*.
>>
>> To me this was a revelation because I always considered multi-subsegment
>> XRIs to be addresses within a single context. In other words, +a, +a+b, and
>> +a+b+c can all be addresses of XDI subjects within the same context. However
>> now I'm realizing that *multi-subsegment XRIs are actually XDI addresses
>> that cross a nested XDI context!*
>>
>> This works across any number of nested contexts. For example, if +a+b is
>> the address of the node +b inside the +a context, then +a+b+c is the address
>> of the node +c inside the +b context inside the +a context, and so on.
>>
>> This is very important, because it means that +a/$has$a/+b is not just
>> equivalent to +a+b, but also equivalent to +a/+b//$ (in the old
>> cross-context addressing syntax) and +a/+b/($) (in the proposed new
>> cross-context addressing syntax, where nested contexts are expressed using
>> cross-references -- a topic we have not yet discussed in detail, but of
>> which I have become a very ardent advocate).
>>
>> $ is the unique subject within a context that identifies the context
>> itself. So, using this nested-context-as-cross-reference syntax:
>>
>> +a+b <==> +a/+b/($)
>> +a+b+c <==> +a/+b/(+c)
>> +a+b+c+d <==> +a/+b/(+c/+d/($))
>> +a+b+c+d+e <==> +a/+b/(+c/+d/(+e))
>>
>> and so on.
>>
>> It works the other way around, too: it means *any XDI address that crosses
>> nested contexts can be expressed as a multi-subsegment XRI*. So if
>> =drummond has a predicate +friend whose object is a nested context, and
>> =markus is a subject in that nested context, then this can be expressed as
>> EITHER:
>>
>> =drummond/+friend/(=markus)
>> OR
>> =drummond+friend=markus
>>
>> Note that =drummond/+friend/=markus (i.e., where =markus is NOT in a nested
>> context) can NOT be expressed as =drummond+friend=markus, because it does
>> not identify =markus as a subject within the context of =drummond+friend,
>> but only that =markus as an object of the predicate +friend.
>>
>> I don't know about anyone else, but for me this dramatically simplifies XDI
>> graph structure and addressing, and makes the semantics of $has$a much
>> clearer.
>>
>> =Drummond
>>
>



----------------------------------------------------------------
Invito da parte dell'Ateneo:
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
tuo aiuto. Dona il  5 x mille all'Universita' di Roma Tor Vergata
codice fiscale: 80213750583 http://5x1000.uniroma2.it