xdi message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-04-01
- From: "Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>
- To: "Drummond Reed" <drummond.reed@xdi.org>
- Date: Thu, 08 Apr 2010 14:20:07 +0200
Dear Drummond and All,
please find below a collection of my thoughts about the example we discussed last week. Comments are welcome!!
Kind Regards,
Giovanni
Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:
> 2) $HAS STATEMENT EXPRESSION OPTIONS
>
> Our main topic was to discuss the different options for expressing
> $has relationships as outlined in this thread:
>
> http://lists.oasis-open.org/archives/xdi/201004/msg00002.html
>
>
>
> We discussed whether the three examples Drummond provided are
> semantically equivalent. Giovanni felt that while they may be
> logically equivalent, they were not resolution equivalent. Drummond
> explained that this could create a huge interop problem if the TC does
> not address this by specifying a normalized or canonicalized form of
> the XDI graph.
>
>
>
> Giovanni preferred the second example, where every predicate is a
> single subsegment. Others did not have a strong opinion yet.
>
>
>
> # ACTION: Giovanni will write up rationale for why the second form
> should be the canonical form.
>
Drummond has illustrated a classification based on syntactic definition (fully collapsed, fully expanded, etc). What I think instead is that segments should have a precise syntax according to what they represents (their semantics). Actually my idea is that there is only one unambiguous form which is a combination of #2 and #3. I'm going to explain this, saying why I do not like other forms.
Example #1 is not very clear to me for the use of "relative" cross references like (/+work+email). I've not a strong view on this, but since it sounds a bit new to me I've to think a bit at this before say something on them.
Regarding the statement
=example
+email$1
"example@example.com"
I would prefer the form
=example+email
$1
"example@example.com"
In the latter form it is unambiguous that we refer exactly to =example+email and we are accessing its first element (which is "example@example.com"). In the former one, we are accessing the property +email$1. But, as in OWL philosophy I would prefer to let our properties be context independent (see rdf:domain and rdf:range) and narrowing their semantics only when assigned to a specific class or instance (see owl:restriction, http://www.w3.org/TR/owl-ref/#Restriction). In this case, cardinality. Whereas =example could have +email$1 or +email$25, =example2 could not have them. Therefore +email$25 exists not in its own, but only when +email is a property of =example. Yes, I know, maybe it is a very subtle nuance but worths to be considered.
In #2, I do not like (=example+email/$1) as I read that as "the fact that =example+email has a first element ($1)" (reification). I think instead that it should be =example+email$1, I read this as "the first element in the collection of +email (addresses) in the context of =example, i.e. =example+email". BTW =example+email$1 correctly appears in #3 (fully expanded form).
I would modify the whole example as follows:
+home
$has
+email <!-- asserted somewhere in the web -->
+work
$has
+email <!-- asserted somewhere in the web -->
=example
$is$a
+person <!-- asserted statement -->
$has
+home+email <!-- this statement is likely inferred from =example/$is$a/+person -->
+work+email <!-- this statement is likely inferred from =example/$is$a/+person -->
+email <!-- this statement is inferred from any one of the previous three -->
=example+email
$1
"example@example.com" <!-- asserted statement -->
=example
+home+email
=example+email$1 <!-- asserted statement -->
=example
+work+email
=example+email$1 <!-- asserted statement -->
=example(+home+email)
$is
=example+email$1 <!-- inferred statement -->
=example(+work+email)
$is
=example+email$1 <!-- inferred statement -->
Note that some statements are asserted, others can be inferred (e.g. using a reasoner). This example is good to showcase some concepts we discussed during these weeks. For example, consider:
=example
+work+email
=example+email$1
and
=example(+work+email)
$is
=example+email$1
these statements are LOGICALLY equivalent as the one infers the other and viceversa (I could have had asserted the second and the reasoner would have inferred the first one).
=example(+work+email) and =example+email$1 are RESOLUTION equivalent (because $is says that they resolve to the same node).
Last, I've used brackets for +work+email (and similarly for +home+email) in the composite subject, i.e. =example(+work+email), allowing to keep together +work+email. This is because the statement which allows such a composition
=example
$has
+work+email
asserts that =example has the property +work+email, i.e. a specialization of +email. If I didn't use brackets, e.g. =example+home+email, it would have been
=example+work
$has
+email
Though this could make some sense as well, it is not asserting the same, actually it is asserting that =example+work, a different subject than =example, has a property, +email. I think this is a subtle but important semantic nuance.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]