Re: [External] [xdi] Continuing the $is discussion

[Markus Sabadello <markus.sabadello@gmail.com>]

Hi Bill,

I kind of like $is and $id, it sounds intuitive. On the other hand, I think the reason why on the last XDI TC call we thought it would be better to extend $is was because $is, $is!, $is$private, or whatever, would have the same (or very similar) semantic meanings, the only difference would be how the server resolves/expands/substitutes them.

So in your proposal, there would only be a single $get operation, with no variants, right?

I think it would be great if you could give an example, similar to ones I tried to do in my demo app. Maybe that example could include a graph, a $get message, and the message result? I think that would really help understand your proposed $is and $id functionality.

I don't understand how a link contract can "control access to $id statements differently than $is". In my understanding of link contracts, they apply to XDI addresses and their associated subgraphs, but not to individual relational arcs.

You say that I-Names can have "properties", also you say that you could have relations between I-Names such as =al/$is/=bob. What happens if somebody else registers =al? I thought the whole point of I-Numbers was to have all the data attached to them, rather than attached to I-Names.

Another question.. There are XRIs that are neither I-Name nor I-Number. Would you advocate for a need to be able to assert equality between such XRIs? The $is relation as it is currently understood can be used between any XRIs, and the fact that certain XRIs are I-Names or I-Numbers, that by itself is basically a design pattern but doesn't trigger any special functionality or reasoning on the XDI layer.

This is a typical situation where we would need to be all in the same room for a few days with whiteboards etc, in order to figure it out :) But again I think examples would be useful..

Markus

On Tue, Nov 13, 2012 at 3:57 PM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

The proposal Markus sent covers all the possibilities with different syntax.  I think the syntax you propose Markus is well thought out and covers all the possibilities.

 

Question is… Is that more important than keeping our API simple?  

 

By that I mean that I think we can streamline the number of verbs needed back down to two, and make our API much simpler to understand.

 

In his recognized presentation “How to design a good API and why it matters” Joshua Bloch says APIs should be usable, even without documentation.

 

For these reasons I propose again that we solve this with three rules. Those three, updated a little here, are:

1) The predicate $is can only have subject and object that are each an i-name

2) The predicate $id can only have an i-name as subject and an i-number as object  (a variation on the second verb we’ve discussed on the list and on the call)

3) To indicate that =al is =bob you need =al/$is/=bob in the graph

 

This solves the identity leak problem, because the link contract can control access to $id statements differently than $is

This solves Drummond’s scenario, because $is is now only based on i-names.

 

The implications of this are that:

a) properties defined as under one i-name have a separate access list than those defined under another i-name, unless you have access to the $id statement, or to the statements with the i-number as the subject

b) properties defined under the i-number are visible only to the server and to those with access to i-number as the subject.

 

To connect two identities by an equivalent i-number you need $id statement access to the i-names of both identies, which means it requires authorization from both identities.

To walk all the identities under an i-number you need access to the statements with the i-number as the subject, then you use the inverse of $id.

 

Do we need a predicate to connect two i-numbers, i.e. one with i-number for subject and i-number for object?  I don’t think so, for two reasons

a) If there is a persistent identifier for a resource within the same data authority, then why are we creating a new persistent id within that authority

b) If the persistent identifier is at a 2nd data authority then it can be pointed at by an i-name at the first data authority, which If desired can point to an i-number using $id. This makes more sense to me as the local persistent resource is not the same as the resource at the 2^nd data authority, the local resource is instead the data the local authority knows about that remote resource.

 

 

This still leaves a more fundamental decision: do we have implicit statements derived from reasoning rules in returned graph results?  Put more simply, does XDI have a reasoning required for any implementation, or is it an additional optional layer?  As most of you guess my vote would be to have reasoning as a core capability, requiring implicit statements be returned.  I do think there is a need to qualify a target graph in a request so that only explicit statements are used/returned.

 

Kind regards,

 

Bill Barnhill

Booz Allen Hamilton - Belcamp,MD

barnhill_william@bah.com

Cell: 1-443-924-0824

Desk: 1-443-861-9102

 

From: xdi@lists.oasis-open.org [mailto:xdi@lists.oasis-open.org] On Behalf Of Markus Sabadello
Sent: Saturday, November 10, 2012 7:34 AM
To: xdi2@googlegroups.com; OASIS - XDI TC
Subject: [External] [xdi] Continuing the $is discussion

 

During the last XDI2 and XDI TC calls, we considered how $is relations should behave.

 

One idea was that on the server side there could be a distinction between "public" and "private" links, or between "transparent" and "opaque".

Another idea was that a client could qualify its operations to request "expanded" or "compressed" responses.

 

I tried to summarize a few variants here:

https://docs.google.com/spreadsheet/ccc?key=0AgNBumZ7dHSSdC14cmNieUgtLXA3QVR5SzFTcmxoV3c#gid=0

 

The ideas there are that...

- $is would be a "public" / "transparent" link, i.e. visible to clients

- $is! would be a "private" / "opaque" link, i.e. not visible to clients

- $get would tell the server not to treat $is in any way special

- $get* would tell the server to follow $is links and return an "expanded" response

- $get! would tell the server to follow $is links and return a "compressed" response

 

I did an experimental implementation of this, just to see how it could work..

http://xdi2.projectdanube.org/XDITestLocalMessenger

 

Not sure if all this functionality is required, or if the defaults should be different, or if the $is and $get qualifiers should be named differently.

But I hope this can help continuing the discussion..

 

Markus