OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Important issue about inner graphs, relational arcs, and notations


On Mon, Jun 9, 2014 at 8:51 AM, Le Van Gong, Hubert <Hubert.LeVanGong@neustar.biz> wrote:
This has to be the best explanation of XDI context-based statement I’ve ever seen. Thanks for taking the time to write it!

Thanks - documentation is our friend!
 

Now, just to wrap my head around this topic.
It seems to me that all you’re saying is that in <subject>/<predicate>/<object> XDI statements, <object> may point to other graphs. Correct?

Yes—more specifically, in an XDI relational statement (vs. a contextual or literal statement), the object may be another graph. But be careful—in the vast majority of relational statements that cross graphs, the target of the relational arc will be an entity or attribute in the target graph, not the graph itself (i.e., not the root node of the graph). 





-- 
Hubert A. Le Van Gong
Neustar Inc. / Distinguished Engineer
San Jose, CA 95129
USA
--------------------------------------------------
email: hubert.levangong@neustar.biz
tel: +1.858.352.3115

From: =Drummond Reed <drummond.reed@xdi.org>
Date: Saturday, June 7, 2014 at 10:43 PM
To: Dan Blum <dan@respectnetwork.net>
Cc: Markus Sabadello <markus.sabadello@xdi.org>, OASIS - XDI TC <xdi@lists.oasis-open.org>
Subject: Re: [xdi] Important issue about inner graphs, relational arcs, and notations

On Sat, Jun 7, 2014 at 6:10 PM, Dan Blum <dan@respectnetwork.net> wrote:
(AA/RA)$do/$get/=b
(AA/RA)$do/$get/(AA/RA)=b

The first statement provides $get permission to =b under the common graph. The second statement ONLY provides $get permission to =b under the inner root (AA/RA).

Question: Is saying "$get permission to =b  under the common root" the same thing as saying "$get permission to =b in any graph in the world?" or just the same thing as saying "$get permission to =b when it is the root context"?

Dan, that's an extremely good question—and let me explain why.

There are 3 kinds of root nodes in XDI:
  1. The common root node (of which there is only one).
  2. Peer root nodes (no limit).
  3. Inner root nodes (no limit).
Here's the rules:
  1. A node under the common root node and the same node under any peer root node are logically equivalent.
  2. The same is NOT true of an inner root node.
For example, in all the following XDI addresses....

=a
(=b)=a
(=b=c)=a

...the node =a being addressed is logically equivalent in all cases. The peer root infomation, e.g., (=b) and (=b=c) are simply used to identify different peer roots that contain a portion of the graph about =a. The peer root information does not add any semantics about =a itself.

However this statement is this different:

(=b/#d)=a

Even though the =a in this statement represents the same logical resource as the =a in the statements above, it is not logically equivalent to the =a in the statements above because this =a exists in the context of an inner root graph that is making a statement about =a. So the entire subgraph under =a in this inner root context is subject to that statement. For example, in the following statement...

(=drummond/#friend)=markus

...the node =markus represents the same resource as...

=markus
(=bob)=markus
(=alice)=markus
(+xdi.org)=markus

But any statements about =markus in the context of the inner graph (=drummond/#friend) apply only in that context. They cannot be expected to be true in any other context.

For example, this statement...

(=drummond/#friend)=markus<$start><$t>&/&/""2004-09-20"

...expresses how long I have been a friend of Markus. But if you take that statement out of the inner graph context (=drummond/#friend), it doesn't make any sense:

=markus<$start><$t>&/&/""2004-09-20"

So now, returning to your original question, the difference between these two statements

  1. (AA/RA)$do/$get/=b
  2. (AA/RA)$do/$get/(AA/RA)=b
...is that the first one gives RA $get permission on =b in any peer graph anywhere in the world, whereas the second one only gives RA $get permission on =b in the context of (AA/RA).

That distinction is critical, and we can only make that distinction if relational arcs can cross graphs—and thus if we have just one notation.

WARNING: From the standpoint of existing code, based on my conversation with Markus last weekend, this is not a trivial change, either for link contracts or for XDI messaging.

=Drummond 
 



On Sat, Jun 7, 2014 at 6:28 PM, =Drummond Reed <drummond.reed@xdi.org> wrote:
Markus' work on implementing link contracts using inner graphs has brought up a key issue related to inner graphs that I believe we must settles before we continue.

The issue is this: up until now we have said that XDI relational arcs can not cross graphs that have different root nodes, i.e., the subject and object nodes of a relational arc must always be within the same graph that has the same root node.

However in implementing link contracts using inner graphs, Markus discovered that it was necessary for a XDI message (under the common root node, or the "common graph") to reference a link contract defined in an inner root graph.

He and I discussed it last weekend, and then I though about it this week. My conclusion is that:
  1. Since 100% of XDI context nodes are uniquely addressable across all graphs (common, peer, inner), relational arcs MUST be able to cross graphs in any direction.
  2. We don't really have any choice about this, because if we restrict relational arcs to a single graph, we will end out with incorrect semantics for certain types of relational statements (one of them being the permission statements made by link contracts).
A fascinating result of this recommendation is that we would no longer have two notations ("normal" and "short form"). We would have only one. And in this one notation, you would never see two forward slashes inside parentheses, but one one. For example:

=a/#b/=c
(=a/#b)=c/#d/=e
=a/#b/(=c/#d)=e
(=a/#b)(=c/#d)=e/#f/=g
=a/#b/(=c/#d)(=e/#f)=e

There are two key places this would have a major effect: XDI messages and link contracts.

In XDI messages, a $set operation that needs to set a relational or literal statement would take this form:

(SENDER[$msg]!:uuid:1111$do/$set)=a/#b/=c                      <== for a relational statement
(SENDER[$msg]!:uuid:1111$do/$set)=a<#b>&/&/"value"    <== for a literal statement

In a link contract, permissions would also take the same form, i.e.:

(AA/RA)$do/$get/=b

Note that this would no longer require putting the object of the permission statement under the same inner graph. In fact, it MUST NOT require that, because that's the only way permissions can be specific. In other words, the following two permissions in a link contract would NOT be equivalent:

(AA/RA)$do/$get/=b
(AA/RA)$do/$get/(AA/RA)=b

The first statement provides $get permission to =b under the common graph. The second statement ONLY provides $get permission to =b under the inner root (AA/RA).

Interestingly, this would also solve the issue Animesh had on our TC call two weeks ago—a link contract can now point directly at any node it permissions. There is no need to duplicate nodes under inner roots just to permission them.

The fact that this would result in one notation is why I needed to raise this issue before we could resolve Markus' question below.

=Drummond  


On Fri, Jun 6, 2014 at 1:53 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I think the following are all equivalent notations for the same graph:

1. ([=]!:uuid:1111/$public)($do/$get)=markus/$ref/([=]!:uuid:1111/$public)($do/$get)[=]!:uuid:1111

2. [=]!:uuid:1111/$public/($do/$get/(=markus/$ref/[=]!:uuid:1111))

3. ([=]!:uuid:1111/$public)$do/$get/(=markus/$ref/[=]!:uuid:1111))

4. [=]!:uuid:1111/$public/(($do/$get)=markus/$ref/($do/$get)[=]!:uuid:1111))

In 1. the first inner root is in normal notation, and the second inner root is in normal notation.
In 2. the first inner root is in short notation, and the second inner root is in short notation.
In 3. the first inner root is in normal notation, and the second inner root is in short notation.
In 4. the first inner root is in short notation, and the second inner root is in normal notation.

Markus






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]