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: Proposal to kill two birds with one stone with $same


XDI TC Members:

Having had the long weekend (in the U.S.) to think about it, plus Giovanni's email yesterday, I had an insight about defining a predicate for equivalence/synonymity that has owl:sameAs semantics. This could kill two current birds with one stone. Here's a summary of my thinking:

1) WHY WE SHOULD AVOID MULTIGRAPHS

First, with regards to the option we discussed last Thursday of the XDI graph supporting multiple XRI arcs between the same XDI subject and XDI object -- a directed multigraph. As I've pointed out before, this creates problems determining the canonical XRI for identifying an XDI context node. But over the weekend I realized there's a second reason to avoid multigraphs: RDF graphs are not multigraphs either. In RDF, you must use an owl:sameAs statement to create an equivalence statement between two distinct RDF graph nodes. The owl:sameAs statement is a way to assert that the two nodes represent the same logical subject, but the two nodes still remain distinct and separate nodes in the RDF graph. Thus RDF graphs and XDI graphs currently share the same quality: every graph node has exactly one arc (one URI) that identifies it.

With XDI graphs this has the further advantage that every arc in an XDI graph corresponds to exactly one XDI statement and vice versa. This is not only conceptually very clean and easy to understand and teach, but it is a very computation-friendly rule.

So I would submit that XDI graphs should to follow the same underlying architecture as RDF graphs, i.e., be simple directed graphs and not multigraphs.


2) USE $SAME FOR OWL:SAMEAS SEMANTICS

My second realization was that if we want to be able to express the owl:sameAs semantics for equivalence, which only expresses general equivalence and does not include the notion of canonical equivalence, then we should assign an XRI to have the same semantics as owl:sameAs. To keep it simple, I propose that we use $same.

As a relational arc, a $same assertion of equivalence would NOT be canonical, i.e., any two XDI subjects could have a $same relational arc that asserts that they are equivalent, and this arc could go in either or both directions between them, i.e., $same would be its own inverse (like $is, see below). So we would say:

  =!1111/$same/=example.name1
  =!1111/$same/=example.name2
  =example.name1/$same/=!1111
  =example.name2/$same/=!1111


3) KEEP $IS FOR BOTH CANONICAL EQUIVALENCE AND ALGORITHMIC INVERSION

Lastly, because $same solves the RDF-equivalence semantics issue, I recommend keeping $is for exactly what we are using it for right now, i.e.:
  1. By itself, for canonical equivalence (as illustrated in slide #3 of the latest XDI Graph Patterns PDF).
  2. As a prefix, for algorithmic inversion for any other XDI predicate (example: $is$do as shown in slide 9 of the latest XDI Graph Patterns PDF).
There are three reasons for this recommendation:
  1. Since we have a separate $word for owl:sameAs equivalence, $same, there is no longer a conflict with using $is for canonical equivalence or algorithmic inversion or both. The latter are both XDI-only concepts, so it makes sense to use an XDI-defined predicate for them.
  2. The reason for using it for both canonical equivalence and algorithmic inversion lies in the underlying metagraph model. In short, $is represents a self-referential arc (a loop). Since you can't actually express a loop in a simple directed graph, you use the $is metagraph statement to do it -- that's how we express canonical equivalence. When you then put any other XDI graph statement in the context of a parent self-referential arc (loop), you are "turning it back upon itself", i.e., expressing the inverse.
  3. $is for inversion reads very well in English. We have seen numerous examples over the past several years. One of the most frequent is using $is$a to express supertype, which is the inverse of $a to express subtype. Or in the current link contract proposal, using $is$do to express the inverse of $do. But it also works works with virtually any English word. For example, =abraham/+son/=cain has the inverse =cain/$is+son/=abraham.
=Drummond


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