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