Re: [xdi] A new observation about $ref/$rep behavior

[Markus Sabadello <markus.sabadello@xdi.org>]

Thanks, that last $ref statement is interesting (I removed the @)..

[=]!1111(https://facebook.com/)/$ref/(https://facebook.com/)[=]!(588183713)

So an XDI client could access my "e-mail address in my Facebook account" via either one of the following XDI addresses:

(https://facebook.com/)[=]!(588183713)+(user)<+(email)>


[=]!1111(https://facebook.com/)+(user)<+(email)>

And I could add the following $ref link:

[=]!1111<+email>/$ref/[=]!1111(https://facebook.com/)+(user)<+(email)>


Markus

On Mon, Aug 12, 2013 at 9:22 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

Markus, I think the pattern you describe will be found anywhere that there is a subgraph of data describing an XDI entity (such as a person) in more than two places in the global XDI graph.

By subgraph I mean more than one node, i.e., some collection of entities and/or attributes that you can't describe with just a $ref because it's not just a pointer from one place that a graph ends (the source of the $ref) to another place where the graph begins again (the object of the $ref). Instead there is an actual subgraph in both locations.

That's the case in your example, where you have a subgraph at both [=]!1111 and (https://facebook.com/)[=]!(588183713).

In this case, you can't use a $ref, you can only use a $is statement. The $is relation tells you both branches are authoritative.

The only places that your [=]!1111 graph could use $ref statements into the Facebook graph is at the leaf nodes where you want a branch of the [=]!1111 graph to point to a branch (or leaf node) of the (https://facebook.com/)[!]!(588183713) graph. This is what you did with this statement:

[=]!1111<+email>/$ref/(https://facebook.com/)[=]!(588183713)+(user)<+(email)>

However if you want to do a $ref to your entire Facebook graph from your [=]!1111 graph, you can still do it. You just need to create a branch for it, e.g.:

[=]!1111@(https://facebook.com/)/$ref/(https://facebook.com/)[=]!(588183713)

Now all the information about you in Facebook is referenceable (via link contracts) through your [=]!1111 graph.

On Sun, Aug 11, 2013 at 11:53 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

In working on the XDI2 Facebook connector, I came across some interesting behavior of $ref/$rep equivalence links.
Warning, this is a pretty advanced application of the equivalence links concept and probably not so easy to read.

Let's say my "e-mail address in my Facebook account" is expressed as follows:

(https://facebook.com/)[!]!588183713+(user)<+(email)>&/&/"markus.sabadello@gmail.com"

Note that 588183713 is my Facebook user ID.

Now I want my Facebook data to be accessible to XDI clients that only know my Cloud Number, but not my Facebook user ID.

Let's say my Cloud Number is [=]!1111. So I create the following $ref link:

(https://facebook.com/)[=]!1111/$ref/(https://facebook.com/)[!]!588183713

Thanks to this new $ref link, my "e-mail address in my Facebook account" can now be accessed via either one of the following XDI addresses:

(https://facebook.com/)[!]!588183713+(user)<+(email)>
(https://facebook.com/)[=]!1111+(user)<+(email)>

Now I want to go one step further and create a $ref link from my "primary e-mail address" to my "e-mail address in my Facebook account":

[=]!1111<+email>/$ref/(https://facebook.com/)[=]!1111+(user)<+(email)>

So I end up with the following graph:

(https://facebook.com/)[!]!588183713+(user)<+(email)>&/&/"markus.sabadello@gmail.com"
(https://facebook.com/)[=]!1111/$ref/(https://facebook.com/)[!]!588183713
[=]!1111<+email>/$ref/(https://facebook.com/)[=]!1111+(user)<+(email)>

Looks nice, but it is actually invalid, since the context node (https://facebook.com/)[=]!1111 now contains both a $ref relation and a sub-context.

Instead, it would have to be this:

(https://facebook.com/)[!]!588183713+(user)<+(email)>&/&/"markus.sabadello@gmail.com"
(https://facebook.com/)[=]!1111/$ref/(https://facebook.com/)[!]!588183713
[=]!1111<+email>/$ref/(https://facebook.com/)[!]!588183713+(user)<+(email)>

The primary goal of this whole exercise has thus been achieved, which is to make my "e-mail address in my Facebook account" accessible via the following XDI address:

[=]!1111<+email>

However, the weakness is that the $ref that links my Cloud Number to my Facebook user ID is not being used. So if for some reason my Facebook user ID changed, I would have to update potentially a large number $ref links all over the place, rather than having a single $ref link that controls the "Cloud Number to Facebook user ID" mapping.

Not a big problem for now, but a bit unsatisfying.

Markus

P.S. I remember we said that my Facebook user ID should be represented as [=]!588183713 instead of [!]!588183713, but this doesn't change anything about the above observation.