Re: [xdi] Re: XDI addressing across nested contexts: a breakthrough

[Drummond Reed <drummond.reed@xdi.org>]

On Tue, Aug 10, 2010 at 2:42 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

I think I'm halfway getting it, yes this needs some F2F discussion..

I knew it would; that's why I wanted to get it on the list.
 

Somehow I'm having trouble formulating a coherent reply right now :)
Not quite sure why, but every time there's talk about the relation between multi-subsegment XRIs and the XDI graph model, I get confused.

Agreed - drawing it on a whiteboard is much easier.
 

What I know for sure is that support for this would mean a LOT of effort / refactoring of my code.
Right now, parsing XRIs is done by openxri-syntax, and the XDI graph model (subject/predicate/object) is implemented at the heart of XDI4j.
What you're proposing would probably mean linking those 2 pieces closely together, or even merging them into a single component.

What I posted was not a proposal. It was just a realization of what is actually going on in the graph. I think it has always been this way,; we're only just realizing it.
 

Instead of a
"graph model consisting of XRI segments"
there would then be a
"graph model consisting of XRI subsegments with several equivalent ways of connecting them to XRI segments"

I wouldn't do that yet, at least not until we discuss it in detail at Whistler.

- My current instinct is that support for this would slow down XDI endpoints because of the extra logic needed for parsing XRIs and the XDI graph model. On a different thread on the Higgins list we were considering a way of speeding up XDI endpoints by treating XRIs as opaque strings, and only actually parsing them when their internal structure is really needed. With your proposal, this wouldn't be possible anymore, on the contrary, the XDI endpoint would have to do quite a bit MORE processing that today.

Again, it's not a proposal, just a realization. Whether XDI endpoints optimize for it is a whole 'nother subject - one we should definitely discuss at Whistler.
 

- I'm pretty sure that "having different ways of doing the same thing" is not good. Developers will ask, which one is the preferred way, what's the difference between the options, etc.

Agreed. There's already different ways to do several things in XDI, i.e., different ways to express the same graph. Again, I'm not proposing to add anything, just sharing a realization about what in fact we already have.
 

- If there are different ways of serializing the same graph, which one of those ways would a serializer choose?

I agree this is important and myself have a strong opinion, but let's discuss at Whistler and see what we come up with.
 

- Just looking at this example:

+a+b <==> +a/+b/($)
+a+b+c <==> +a/+b/(+c)

I find the above incredibly confusing for any practical use..

I know. It helps to draw it.
 

Does this also mean that +person+full+name is equivalent to +person/+full/(+name)?

Yes.
 

This doesn't make any sense to me whatsoever..

It will when we draw it. I'm agreeing with Joseph at this point that we really need an XDI graphing utility that draws real arcs.
 

So, I think for now I would argue that all these metagraph observations such as "+a/$has$a/+b is equivalent to +a+b is equivalent to +a/+b/($)" are nice for higher level applications such as semantic reasoners, but I'd prefer to leave that out of the core XDI graph model and messaging for now.. But maybe you'll convince me otherwise later this week :)

I'm going to try not to "convince you" of anything. Instead I'll just explain the "ahha" I had about what it really looks like in the graph. Then -- if everyone agrees -- we'll just figure out the rules (per your points above) for how XDI documents/messages SHOULD or MUST serialize the graph.

Looking forward to it.

=Drummond
 

On Mon, Aug 9, 2010 at 7:49 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

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. 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