Re: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-04-01

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" <>:
 

> 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
                        ""
 
I would prefer the form

=example+email
         $1
                        ""

In the latter form it is unambiguous that we refer exactly to =example+email and we are accessing its first element (which is  ""). 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
                "" <!-- 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.