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] New proposed definition for $has$a


I won't be able to make the meeting today due to client meeting but I want to contribute a few thoughts about this via email:
 
Drummond, I'd like to do a re-wording of the following:

In other words, +x/$has/+y is an assertion of the existence of a new set identified by the new XDI RDF subject +x+y. By contrast, +x/$has$a/+y is an assertion of the existence of a member of the set +x+y, but does NOT assert the existence of the whole set, and does NOT create a new XDI RDF subject identifying the set.

 
The reason is that in RDF when you assert the existence of a collection resource in RDF (of which a set is one type) all you are asserting in arc terms is that there is some outgoing or incoming arc in the graph that has that collection resource as one or both of it's vertices.  By asserting there is a member of that set you are asserting that there is some outgoing or incoming arc in the graph that has that collection resource as one or both of it's vertices and that there is an outgoing arc representing a containment relationship from the collection resource to the member resource.  I could be wrong but AKAIK you cannot specify the containment relationship arc without specifying that the collection resource exists, due to built in axioms within RDF.  One of these axioms rephrased is that if you have a subject of a triple then that subject is a resource known to the graph and may be a URI or a blank node but it's listed when you get resources in the graph (vertices) which means I think that it would be listed when you get the subjects in an XDI graph.
 
Given the above I don't think "does NOT create a new XDI RDF subject identifying the set."  can work. I don't see how you can describe the member of a set within RDF and not also provide either a URI or a BNode identifier for the set resource.
 
Also, unless you have a specifically enumerated set I neither of the above assert the existence of the whole set..one part asserts the existence of a possibly empty set and the other parts each assert membership in the set.  To assert the set as a whole consisting of specific members I believe you would need to define a class of set resources which are constrained to have a membership relationship for each required member. Might be able to do this in something like CWM with extended axioms by constraining membership to members within the certain set of required members and constraining the cardinality of the member relations must equal the number of elements in the set of required members, not sure.
 
Also, I thought we were using $$ to indicate variables, what are you using it to indicate here?
        +x/$has$a/+y ==> +x/+y/$$
 
So given the above, what can $has$a mean?
 
Well I propose +x/$has/+y => a new subject identified by +x+y that is a sub-graph of the current context consisting of the minimum vertices and edges needed to describe all triples, implicit and explicit, in the current context of the form +x/+y/_  (where _ represents any valid XDI object segment).  This is basically the same thing as the first part of what you are saying as +x+y can be viewed as the set of matching object segments.
 
I also propose that the assertion +x/$has$a/+y constrains the current context by asserting that +x/$has/+y and that the min cardinality of +x+y is 1.
 
This may be extendable to forms like +x/$has$2/+y to indicate a min cardinality of 2.  If that's agreed on then essentially $has$a is syntactical sugar for $has$1.
 
For the above reasons I think the presence of +x/$has$a/+y should constrain +x+y to a min cardinality of 1,the presence of +x/$has/+y implies no cardinality constraints.  I'd also like to be able to express a max cardinality of 0 and propose initial discussion around +x/$not$has$a/+y for that purpose.
 
Thanks,
Bill

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thu 5/7/2009 3:48 AM
To: 'Markus Sabadello'; 'OASIS - XDI TC'
Subject: [xdi] New proposed definition for $has$a

As promised in the thread below, I want to withdraw the suggestion I made Monday that $has$a might no longer be necessary as a metagraph predicate. Instead I want to offer a new definition consistent with our new definition of $has.

 

$has definition:

 

            +x/$has/+y ==> (+x/+y) ==> +x+y

 

Proposed $has$a definition:

 

            +x/$has$a/+y ==> +x/+y/$$

 

In other words, +x/$has/+y is an assertion of the existence of a new set identified by the new XDI RDF subject +x+y. By contrast, +x/$has$a/+y is an assertion of the existence of a member of the set +x+y, but does NOT assert the existence of the whole set, and does NOT create a new XDI RDF subject identifying the set.

 

So:

 

            +x/$has/+y        ==>      asserts and identifies a new set +x+y

            +x/$has$a/+y    ==>      asserts (but does not identify) a member of the set +x+y

 

This is consistent with English usage of the words. For example:

 

            Drummond has cats.      ==>      identifies a new set: “Drummond’s cats” (which may be empty)

            Drummond has a cat.     ==>      asserts a member of the set of Drummond’s cats

 

For the sack of precision, I also propose the following inference rules:

 

RULE                XDI RDF STATEMENT                INFERENCE

======            =================              =========

Rule #1:            +x/$has/+y                                infers ONLY +x+y, NOT +x/+y/$$

Rule #2:            +x/$has$a/+y                            infers ONLY +x/+y/$$, NOT +x+y

Rule #3:            +x/+y/+z                                   infers ONLY +x/$has$a/+y, NOT +x/$has/+y

Rule #4:            +x/+y                                        same as Rule #3

Rule #5:            (+x/+y)                                      infers ONLY +x/$has/+y, NOT +x/$has$a/+y

 

What this does is cleanly separate the semantics of $has and $has$a. $has always refers to a set, $has$a always refers to a member of a set. This even follows in natural language English. For example, I can say:

 

            A car has tires.

 

Now I can talk about the set “car tires”. But that doesn’t mean that a particular car has tires – they might be missing. Another example in the opposite direction is that I can say:

 

            A car has a watermelon.

 

But that doesn’t mean I can talk about “car watermelons”, i.e. it doesn’t mean there exists such a general set, or that I can say:

 

            A car has watermelons.

 

Keeping these inference rules crytal clear allows us to be very precise in XDI dictionary statements about when we are creating a new set (class) – by using a $has statement – and when we are creating a new set member (individual) – by using a $has$a statement.

 

*********************

 

Lastly, if +x/$has$a/+y ==> +x/+y/$$, what is the cardinality of $$?

 

            a) zero or more

            b) one or more

 

I think it must be zero or more because there are many times when you need to refer to a member of a set which may be empty. Classic example: +person/$has$a/+middle+name. Some do, some don’t.

 

All food for tomorrow’s telecon.

 

=Drummond

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, May 06, 2009 3:18 PM
To: 'Markus Sabadello'; 'OASIS - XDI TC'
Subject: RE: [xdi] Implications of removing $has$a

 

Markus,

 

Thanks for researching this – it is VERY useful info. I too did a search in several places for $has$a usages, but I forgot to look at versioning.

 

The other place we have been using both $has and $has$a is in dictionary defintions. And there it is clearly useful. In thinking about it more since posting that message on Monday, I’ve come up with several other places where not having $has$a would actually be a problem.

 

The good news is that I think there is a corresponding definition for $has$a which works nicely with the new definition of $has, and which would yield exactly the uses for $has$a that we’ve found useful in versioning and dictionaries, but which would not introduce the RDF problem we had before. I don’t have time to write it up right now, but I’ll post something before tomorrow’s telecon, so we can go over it on the call.

 

=Drummond

 


From: markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Wednesday, May 06, 2009 1:53 PM
To: OASIS - XDI TC
Subject: [xdi] Implications of removing $has$a

 

Hi,

I tried removing $has$a from XDI4j (http://wiki.eclipse.org/XDI4j) to see what it breaks.
Actually I found only one piece: Versioning

In XDI Versioning we were using $has for "version snapshots" and $has$a for "version logs".
- A "version snapshot" is a complete copy of a subject at a given version
- A "version log" is a copy of the XDI message that produced the given version

We had a nice wiki page about this, but somehow I can't find it right now.

Anyway, here is an example XDI document with 2 versions of =markus, complete with "version snapshots" and "version logs":

=markus
    +name
        "Markus Sabadello"
    $has
        $v
    $v
        !2
    +friend
        =drummond
=markus$v
    $has
        !2
    =markus$v!1
        /
            =markus
                $add
                    /
                        =markus
                            +name
                                "Markus Sabadello"
    $has$a
        =markus$v!2
    =markus$v!2
        /
            =markus
                $add
                    /
                        =markus
                            +friend
                                =drummond
=markus$v!1
    +name
        "Markus Sabadello"
=markus$v!2
    +name
        "Markus Sabadello"
    +friend
        =drummond

My guess is that we can simply leave out the one $has$a statement, since it doesn't really add much additional information anyway. But maybe someone has a better idea...

Markus



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