Reading the minutes of the last TC call (relevant section attached at the end of this message) RE the issue of what XDI statements should be "graph-relative" (more accurate than "root-relative") and what statements should be "authority-relative", here are the thoughts I had during my London trip, organized into four parts.
(Note: I apologize in advance to Markus for being so insistent about this issue but I hope it will be clear why I believe it is so important.)
#1: Graphs Are Not Authorities
This whole issue arose because we have been making $do and $public$do link contracts graph-relative instead of authority-relative. But making link contracts graph-relative only makes sense if a graph represents an authority, because then that authority can exercise that graph-relative link contract. Imbuing graphs with authority is also the reason that we have, as Markus has pointed out, spoken of "my graph" and "your graph", reflecting the assumption that one authority controlled an entire graph.
But, as I said in an earlier thread, I believe if we start mixing up graphs and authorities, we will tie ourselves up in semantic knots from which we will never get untangled. Here's how that happens:
- If a graph represents an authority in any way—even just the ability for an authority to control the contents of the graph—then a graph is no longer just a network-addressable repository of XDI statements. Rather the graph itself needs to have statements that declare who is authoritative for the graph.
- That is how we have been interpreting the (=some.authority)/$ref/ statement (or the inverse /$is$ref/(=some.authority) statement). But in fact that statement only asserts an equivalence of two graph identifiers, not of equivalence of two authority identifiers.
- If we tried to interpret those statements as equivalence of authority identifiers, it would be like trying to assert =some.authority/$ref/ —in other words, that a graph was equivalent to an authority. But a graph is NOT equivalent to an authority, because a graph is a graph and an authority is an entity (specifically a person, legal entity, or non-legal entity). A graph is not an entity and an entity is not a graph.
- Therefore the graph reference statement (i.e., (=some.authority)/$ref/ ) is only an assertion of graph equivalence, i.e., it gives a client an address for the current graph from which it can discover the network location, but nothing more.
I would submit that the more we think about it, the more reasons there are for us to keep the definition of an XDI graph as strictly a repository of XDI statements at a network endpoint that has exactly two attributes:
- It's coordinate in "space", i.e., it's network-addressable endpoint(s) in the form of <$uri> attributes.
- It's coordinate in time, i.e., it's timestamp(s) in the form of <$t> attributes.
(The question of whether graphs, as pure XDI statement repositories, can be versioned is a good one. In theory an XDI graph can be versioned just like an XDI entity or XDI attribute can be versioned, but whether in practice XDI versioning would ever be employed at the graph level is an open question.)
So if graphs are not authorities, and graphs do not carry any assumption about authority, then:
- The only XDI nodes that represent authority are—authorities!
- There is no "my graph" and "your graph", there is only "the graph that is the authoritative location for my authority" and "the graph that is the authoritative location for your authority"—which could, by the way, be the same XDI graph at the same network location, because the same XDI graph can serve multiple authorities (i.e., be "multi-tenated").
- All link contracts must be authority-relative, because only authorities can exert control over a link contract.
#2: Every Message Is a Merge
The second advantage of keeping an XDI graph as strictly a repository of XDI statements at a network endpoint is that we can very strictly define XDI messaging as a merger of at least two graphs:
- The XDI message graph (which itself is a valid XDI graph that can be added to any other XDI graph).
- Any graph that is a target of the message.
This logical definition is true even if neither the sending or receiving graphs actually keep a copy of the message (i.e., they do not log messages).
Note that an XDI message that includes a $set operation is a merger of THREE graphs: the message graph, the target graph, and the inner graph that is the object of the $set operation.
This very strict definition of XDI messaging has several advantages:
- It makes it clear that every XDI message must be a globally unique subgraph. This way it can be added to any target XDI graph without conflict.
- This subgraph MUST be a subgraph of the XDI authority representing the sender. This makes it unambiguous who is responsible for the message.
- It makes it clear that every XDI message, even a $get, is a state change in the target graph. In other words, just receiving the message is a state change—a merger of the message graph with the target graph, against which other rules can be triggered.
- Messaging processing is semantically precise. Every message is a strict graph merge operation, and a $set message is a second merge of the object inner graph with the target graph.
#3: "Cut, Copy, Paste"
Once we take a strict graph merge view of XDI messaging, it becomes easy to understand how it works in terms of classic "cut, copy, paste" functionality. For example:
- Moving XDI data is cutting a subgraph from the source graph and pasting it to the target graph. 100% of the subgraph is exactly the same; all that has changed is the network location.
- Copying (sharing) XDI data is copying a subgraph from the source graph and pasting it to the target graph. Now exactly the same subgraph exists in both the source and target network locations.
- Caching XDI data is copying a subgraph from the source graph and pasting it into a peer graph under the target graph. This is important—caching is just like copying except the copy is NOT merged with the target XDI graph, rather it is merged into the peer graph under the target XDI graph. Example:
SOURCE GRAPH:
=drummond<+tel>&/&/"+1-222-333-4444"
TARGET GRAPH - COPY:
=drummond<+tel>&/&/"+1-222-333-4444"
TARGET GRAPH - CACHE:
(=drummond)=drummond<+tel>&/&/"+1-222-333-4444"
This distinction between merging directly into the target graph or into a peer graph under the target graph helps keep a clean semantic separation between:
- A link contract XDI $copy operation which authorizes the target graph to have a copy of the shared subgraph.
- A link contract XDI $get operation with associated cache control semantics.
#4: All Authority is Exerted Via Authority Subgraphs
My final set of throughts about the separation of graphs and authorities is about the implications that all authority in XDI is exerted through authority entities and the subgraphs rooted on them.
As mentioned above, the first implication is that all link contracts MUST be authority-relative, because only an authority can exert control over a link contract.
The second implication is that one authority can still exert control over whether a second authority can write to an XDI graph by virtue of a link contract in that graph between the first authority and the second. For example (note that all of these examples use cloud names for simplicity):
=drummond$to=markus$from+friend$do/$set/=markus
This link contract gives Markus permission to write to his own authority space in the (=drummond) graph. This includes XDI messages, of course.
A third implication is that public link contracts are just like any other link contract except expressed for the $anon authority.
=drummond$to$anon$from$public$do/$get/=drummond$public...
And a final implication is that "root" link contracts are just like any other link contract except they are self-reflexive:
=drummond$to=drummond$from$do/$all/=drummond
Net net: I believe authority-relative link contracts can give us 100% of the control previously expressed via graph-relative link contracts without any of the problems associated with mixing graphs and authorities.
=Drummond
From the 2013-11-22 XDI TC meeting minutes:
Root-relative vs. authority-relative statements, and merging graphs
A discussion has begun about whether certain statements in an XDI graph should be “root-relative”, e.g.:
=markus<$public><$key>&/&/”...”
or “authority-relative”, e.g.:
<$public><$key>&/&/”...”
This may have an impact on the mathematical correctness of the XDI graph model, on link contract functionality, on practical graph merging scenarios, and on uses cases where the authority of one graph makes statements about another authority (e.g. =markus making statements about =drummond).
We had not planned to discuss this in Drummond’s absence, but did end up going over one of the examples: Drummond says he is not a smoker, but Markus says Drummond is a smoker. In this example, Drummond’s graph would contain this:
=drummond<+smoker>&/&/false
Then the question is what Markus’ graph would contain:
Option 1: =drummond<+smoker>&/&/true
Option 2: =markus=drummond<+smoker>&/&/true
Markus believes Option 1 is correct.
In the recent e-mail threads Drummond explained that Option 2 is correct.
Animesh felt that Option 2 is right, because otherwise the statement does not fully describe the context in which it is made.
Dan also liked Option 2, because it is Markus making an assertion about Drummond.
Since this is just one example of a much deeper topic, we decided not to explore it further and instead continue the discussion next week with Drummond.
Animesh also brought up the analogy of having two bank accounts. Each bank account would be represented as an XDI graph with his cloud number. What would happen when the bank accounts get merged?