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] Splitting $is into $is and $ref

Just to clarify, I am not proposing that $ref "behave differently depending on the situation". To the contrary, to make the proposal clean, I'd be happy to define $ref as NOT having equivalence semantics, but just defining it as "a canonical assertion that the XDI context node that is the object of a $ref arc should be substituted for the XDI context node that is the subject of the $ref arc". With $ref, this substitution is transparent to a client; with $ref!, it is not, i.e., it is opaque.

Since this 'identifier redirect" semantics effectively asserts equivalence of identifiers, I can see little if any value in needing to add a $is statement in places where you would use a $ref statement, such as with the "I am" statements for root nodes. But at least the semantics would now be very clean such that you COULD add a $is statement whenever you wanted to assert full logical semantic equivalence.

I think that makes it the equivalent (so to speak ;-) of Bill's $is and $id proposal (except his had some restrictions about the range being i-numbers as I remember). I'm not proposing any restrictions on the domain or range of either $is or $ref or $ref!


On Wed, Dec 12, 2012 at 2:20 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Fine with me, but I am not sure if it addresses Bill's concern that $ref (formerly $is) "behaves differently depending on the situation".

I.e. $ref (formerly $is) would be symmetric in the logical equivalence sense, but not when it comes to how it makes the server behave.
So while your split makes $is very clean, it still has these mixed semantics for $ref.
Not that I think that's a bad thing, just thinking loud.

Of course if you wanted you could really separate these two ideas, by having both arcs:

=markus/$is/=!91F2.8153.F600.AE24  <-- logical equivalence (symmetric)
=markus/$ref/=!91F2.8153.F600.AE24  <-- processing instruction for the server (not symmetric)

This might be similar to Bill's $is and $id proposal, not quite sure.

Note that in XRI Resolution 2.0 the <Ref> element didn't assert logical equivalence, but it did make a resolver follow it.


On Wed, Dec 12, 2012 at 4:44 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

On Wed, Dec 12, 2012 at 1:19 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I think I understand, so an XDI server would automatically follow $ref arcs the way it is following $is arcs now?

Yes - exactly the same.
What would an XDI server do when it encounters a $is arc?

Nothing. $is as a standalone arc that asserts pure logical, non-canonical equivalence for semantic purposes. We have always needed it - in fact Kari came up with a use case last spring that required it within one local graph (identifying the same device in the context of different collections of measurements it was taking). But since at that time we had defined $is to be directional and canonical, we could not use $is to solve that use case. Now $is would work perfectly for it.
Wouldn't there be many cases where you'd need both a $is arc and a $ref arc, therefore making the graphs bigger than they are today?

No. $ref still carries the equivalence semantics of what we have been using $is for. So $ref would replace 100% of the places were we are using $is today.
Would there still be a distinction between public/standard and private/compact equivalence links, e.g. $ref and $ref! ?

Yes. Exactly the same as we had it with $is and $is!.

What would the "I am" statements look like?
Currently they look like this:


The new ones would be:


Note how the latter statement reads much more intuitively that the former "$is$is" that we all didn't like.

Please do post any other thoughts on this. I'll put this on the agenda for Friday's call - I'm eager to put this question to bed so we can update our example graphs and any implementation code bases.

I also had a huge light bulb idea while working on how to model the declarative policy statements that Phil needs for link contracts on event channels. I'll post that later today.



On Tue, Dec 11, 2012 at 3:50 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
Although it's been a very busy week, in my background "cook time" I've been thinking about the suggestion on last Friday's TC call that we split the current proposal for $is predicate behavior (https://wiki.oasis-open.org/xdi/EquivalenceLinks) into two verbs.

The strawman I began playing with this weekend was to break it into:
  1. $is = logical equivalence = symmetric, transitive, reflexive
  2. $ref = canonical directional equivalence = asymmetric, intransitive, irreflexive
In thinking it through, I realized that this works very cleanly in three ways:
  1. Every standalone use of $is as a predicate that we currently have (at least in the XDI graph model document) would become $ref
  2. Everyplace where $is is used as the PREFIX for another predicate (e.g., $is$do) would NOT change, i.e., IMHO $is would still work well for this inversion function.
  3. This means that the awkward $is$is predicate (needed to identify the equivalence links for root nodes, for example) would now become $is$ref, which reads much better and is certainly more intuitive.
So, at this point I'm very much liking this idea, and I'm ready to write it up as a formal change to the https://wiki.oasis-open.org/xdi/EquivalenceLinks proposal, but first I wanted to post it here on the mailing list for discussion. (I'm also copying this to https://wiki.oasis-open.org/xdi/EquivalenceLinks/Discussion).


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