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] equivalence and reference (Re: [xdi] Agenda: XDI TC Telecon Friday 9:00 - 10:30AM PT 2013-01-11)


Giovanni, thanks for sending this, and sorry it's taken me a week to respond. Because the Equivalence Links proposal is on the decision queue again tomorrow, I wanted to give you a detailed reply. Hopefully it will save us time in discussion tomorrow (especially if you are able to join us). See inline.


On Fri, Jan 11, 2013 at 5:34 AM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote:
Hello All,

I will not be able to make the call this week as well. However, the good news is that I'm happy with having two properties $is and $ref. The bad one is that I'm not happy with their semantics.

However, I understand I'm quite late. I've been far away from the TC for several calls, and might have missed agreements and decisions. Thus if you, TC, think this is the right way, go ahead, no worry about my opinion.

For those who are interested, instead, a longer explanation follows.

Best Regards.
Giovanni

* Longer explanation *

To me $is is the XDI counterpart of owl:sameAs, logical equivalence following the definition of identity by Leibnitz (see Halpin's paper). I do not agree with the sentence: "a local root node MUST NOT have a is statement. This avoids the logical entanglement of a graph containing a copy of itself". Because it just violates the universality of this semantics (Leibnitz's law should hold for the root node as well!).

Actually, that was my mistake, and Markus corrected it in the proposal. It now says:

      For this reason, the subject of a $is statement SHOULD NOT be a parent context of the object of the statement, and vice versa. This avoids the logical entanglement of a graph "containing a copy of itself".

It's not peer equivalence that's a logical problem, it's container/containee equivalence. Again, my apologies for my mistake.

 
The nonsense you have expressed in this sentence comes from the fact that you read addresses directly from the graph. We discussed this in middle 2011

https://lists.oasis-open.org/archives/xdi/201107/msg00007.html

Unfortunately we suspended this thread in November 2011 (https://lists.oasis-open.org/archives/xdi/201110/msg00002.html) when it disappeared and was never resumed again...

Ironically, as I review those threads now, it appears to be exactly the issue we are covering in this proposal. So we're finally resolving it.

 

It is correct that "in RDF, you must use an owl:sameAs statement to create an equivalence statement between two distinct RDF graph nodes". But not that "every [RDF] graph node has exactly one arc (one URI) that identifies it". RDF graphs are not addressable (although you can assign an URI to each node, you cannot create a path to a node following the connections of arcs, as we do in XDI). If you want to have this in XDI, the only way you can is to have the two nodes drawn as one single node (otherwise you have the nonsense above). In the thread above, the main argument against this representation was canonical identifiers, which are not in RDF/Linked Data but appear in the definition of $ref. Therefore although I like $ref to be distinguished from $is, I would rather prefer to read another semantics in it. According to Halpin's paper: "Individuals could be thought of as being composed of differing aspects at different levels of granularity rather than the notion of individuals traditionally used in semantics [that is in owl:sameAs]". So $ref to me should be only "a simple similarity property [...] sub-property of rdfs:seeAlso."

So I read Halpin's paper in its entirety, and I agree that semantics for describing other types of similarity (those that don't satisfy Leibnitz's law) are needed in XDI. I very much like the three-dimensional matrix he and his co-authors present for this, and I think we should consider adapting it for the $ dictionary.

However this is a different issue from the problem that $ref solves, which is one of being able to specify canonical references. RDF does not have the problem of canonical referencing because it doesn't have addressable graphs, as you say. But in an addressable graph, you need a way to specify at a node that it serves only as a reference to another node and has no subgraph.

Given the correction above, and given that canonical referencing has been an issue for both the XRI and XDI Technical Committees for 9 years now (since 2004), it seems that there is a extremely strong case for having clear and unambiguous semantics for a canonical reference. That is the semantics that the Equivalence Link proposal proposes for $ref (and why it is now completely distinct from $is).

I hope this helps,

=Drummond 
 

* End of explanation *


Def. Quota Drummond Reed <drummond.reed@xdi.org>:


--- EQUIVALENCE LINKS AND REFERENCE LINKS (DRUMMOND & MARKUS)

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

This proposal has been updated to reflect the consensus to use two
different XDI verbs - $ref and $is - to express two different kinds of
equivalence.

Note also this paper referenced by Giovanni Bartolomeo:

   http://iswc2010.semanticweb.org/pdf/261.pdf

We are ready to move this into Last Call provided there is consensus on the
call.




----------------------------------------------------------------
Invito da parte dell'Ateneo:
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
tuo aiuto. Dona il  5 x mille all'Universita' di Roma Tor Vergata
codice fiscale: 80213750583 http://5x1000.uniroma2.it



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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