Re: [xdi] RE: [External] [xdi] Re: Update on $is and $is!

Markus

On Wed, Nov 21, 2012 at 12:44 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

Thanks for the response Markus, comments inline.

From: xdi@lists.oasis-open.org [xdi@lists.oasis-open.org] on behalf of Markus Sabadello [markus.sabadello@xdi.org]
Sent: Tuesday, November 20, 2012 5:19 PM
To: Barnhill, William [USA]
Cc: Drummond Reed; OASIS - XDI TC
Subject: Re: [xdi] RE: [External] [xdi] Re: Update on $is and $is!

Hi Bill,

On Tue, Nov 20, 2012 at 10:49 PM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

Markus, I looked at it and agree that it looks good based on the premises the TC accepted. Though I still think this approach is too complex, it seems to be the approach that has majority consensus within the TC . I believe that majority has been you, Drummond, Phil, and Joseph - with Giovanni and Les being mostly silent on this matter, and myself opposed.

Today we discussed one simplification, which is to have the ! syntax only on the $get operation (i.e. $get!), but not on the others (i.e. there is no $add!, $mod! and $del!).

I realize this probably doesn't affect your general concerns about this proposal, but still it might be worth mentioning.

*wab: Discussed on what? Wouldn't be the XDI TC call, is this the XDI2 implementers call?

[Markus] Yes it was on the XDI Implementer's Call, but since it's just a proposal right now, it's okay to talk about it outside of the XDI TC, right?

One thing to possibly consider more is on #4:

4. If a context node has an equivalence link, is MUST be the only statement on that node.

Is an equivalence link relation intended to be symmetric? I am not sure it can be, given the ‘follow’ rules.

I would say it's symmetric in the sense that both nodes identify the same logical entity.

If A is the same as B, then B is the same as A, that's a fundamental logic principle, i.e. symmetry.

But no it's not symmetric when it comes to the following while applying XDI operations, i.e. just because A is followed to B doesn't mean B is followed to A.

If you had both A/$is/B and B/$is/A, you're creating an infinite loop.

We should probably specify how the server should behave in this case.

I don't think I'm covering that case adequately in my implementation right now, oops.

*wab: This is an indication to me that we do not fully understand the semantics of $is and I think we need to nail that down completely and unambiguously (including not having it behave differently depending on the reason for traversing the $is link: for id vs. for follow)

[Markus] To me, logical semantics and processing behavior(s) are two different things, and I think they're both quite clearly defined on the proposal page, using only a few simple bullet points. I don't think there's anything wrong with having certain properties for (part of) the logical semantics and certain other properties for processing behavior. But I'd love to see a (counter?) proposal that describes $id and $is, ideally with examples.

If it is, then I don’t see #4 working because $(A)/$is/!1234 will imply !1234/$is/$(A), and !1234 may be the subject of more than one statement.

See above, the first statement doesn't imply the second, but if you explicitly had them both, I'm not sure what would happen.

$is doesn't only state equality, but also that the target is the canonical identifier.

*wab: See comment at bottom, where this is restated

*wab: Also, when was $is as stating the target is the canonical identifier proposed? This, combined with it being symmetric in some situations but not symmetric in others, sounds like an overly-overloaded predicate.

[Markus] Not sure when this was originally proposed, but it had been part of my understanding of $is for a pretty long time. This also has to do with XRI's CanonicalID element as an inspiration for $is.

I just realized this isn't explained in the proposal, so I added this sentence:

"The identifier of the object node MUST be interpreted to be the canonical identifier of the logical entity."

*wab: The canonical identifier must be an i-number, correct? Then you have ruled out a $is relation between two i-names and essentially made $is the $id predicate I proposed last week. This seems good evidence for use of $is and $id instead of just $is, or just $is and $is! (2nd still does not appeal to me).

[Markus] I don't think the object of a $is / $is! relation MUST be an I-Number, but I'd say it would be HIGHLY RECOMMENDED for it be a persistent identifier (i.e. I-Number). See CanonicalID, you could also use I-Names for that, but it would be stupid. By the way, I really liked $is and $id from the start, a proposal page and examples would be great to see what use cases it can satisfy. The reason why I like $is and $is! is because they align well with the proposed $get and $get! operations.

Therefore, I'd say a $is loop is invalid, because you can only have one canonical identifier for a logical entity.

*wab: Why? Why can't a logical entity have one canonical identifier per link contract?

[Markus] I think this is a problem of terminology. You can of course set up link contracts and $is / $is! equivalence links in a way that makes XDI clients see different identifiers for the same underlying data. This was in fact one of the main motivations for this proposal. But I would still maintain my view that in the XDI graph each context node can only have one canonical identifier. Note that this is similar to how CanonicalIDs work today in XRI resolution.

I think it is important that whenever we define our binary relations/predicates we explicitly say which of the following they are: symmetric, asymmetric (differs from non-symmetric), transitive, reflexive, irreflexive (differs from not necessarily reflexive), functional, inverse functional.

Makes sense, but I think for each of those, we should distinguish between logical equality, and the following while applying XDI operations.

*wab: A relation is symmetric, transitive, etc. or it is not. For me, to say that it is symmetric when your using it this way but not symmetric when you're using it that way invites confusion on the part of implementers, and implementation bugs, as well as making a nightmare for the creation of a conformance test kit.

[Markus] So I guess that means the currently proposed $is and $is! relations are NOT symmetric. But they do have some symmetric properties, e.g. that their subject and object identify the same logical entity.

I'd say:

$is logical equality: reflexive, symmetric, transitive

$is following when applying XDI operations: irreflexive, asymmetric, not transitive, functional

*wab: see previous comment.
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 Drummond Reed
Sent: Tuesday, November 20, 2012 1:30 AM
To: xdi2@googlegroups.com
Cc: OASIS - XDI TC
Subject: [External] [xdi] Re: Update on $is and $is!
Markus, I just reviewed the updated https://wiki.oasis-open.org/xdi/EquivalenceLinks page, and it looks really good.

My only question is about the final example in https://wiki.oasis-open.org/xdi/EquivalenceLinks#Examples-1

In this example, the operation is a $mod, and the standard graph response is:
 
=abc/$is/=!1111
My question is, why is the response to a $mod operation an equivalence link? Why isn't it just something indicating success?

Thanks,

=Drummond

On Mon, Nov 19, 2012 at 2:51 PM, Markus Sabadello <markus.sabadello@gmail.com> wrote:

Per my action item from the last XDI TC call, I worked a bit on this page:

https://wiki.oasis-open.org/xdi/EquivalenceLinks

- I added information and examples for $add, $mod and $del operations

- I also changed some of the wording in the other sections of the page, just to clarify things

I updated the following pages to reference the EquivalenceLinks one:

https://wiki.oasis-open.org/xdi/AddOperation

https://wiki.oasis-open.org/xdi/ModOperation

https://wiki.oasis-open.org/xdi/DelOperation

In the next few days, I'll work on the GetOperation page (the only one of the operations that's still missing).

I also updated the implementation:

http://xdi2.projectdanube.org/XDILocalMessenger

You can try the samples 8, 9 and 10 to see some of the equivalence links functionality in action.

Looking forward to discuss.

Markus

--
Project Danube: http://projectdanube.org
Personal Data Ecosystem Consortium: http://personaldataecosystem.org/

--
You received this message because you are subscribed to the Google Groups "XDI2" group.
To post to this group, send email to xdi2@googlegroups.com.
To unsubscribe from this group, send email to xdi2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

xdi message