Next in thread → Next in month →

RE: [xdi] New proposed definition for $has$a

From
Drummond Reed <>
Date
2009-05-11T06:52:40+00:00
ID
BB099C86486E4F518FF70591DF503DE7@ELROND
Thread
RE: [xdi] New proposed definition for $has$a
Bill, thanks for the message – it was
very helpful.

 

I just posted the minutes of the last call
where we talked about this further. We agreed the wording I proposed in the
message you responded to needs revision (and that the +car/$has$a/+watermelon
example I provided didn’t actually apply to this discussion the way I
intended). 

 

I also agree with you about adding cardinality
constraints. I’ve always felt $has$a should accept them, i.e.:

 

            +x/$has$a$min$2/+y

            +x/$has$a$max$4/+y

            +x/$has$a$min$2$max$4/+y

            +x/$has$a$1/+y

 

However these examples in fact illustrate
precisely why we can’t conflate $has and $has$a statements. Cardinality only
makes sense when you are talking about instances of a property on a subject,
which is the purpose of $has$a statements:

 

+chair

            $has$a$min$3

                        +leg

            $has$a$max$4

                        +leg

 

However cardinality does not make sense
when you are talking about defining a new set based on a property of a subject,
which is the purpose of $has statements:

 

+chair

            $has

                        +leg

 

This second example produces the XDI RDF subject
+chair+leg, which inherently doesn’t have cardinality because it’s
not a property of a subject, it’s a new subject.

 

That, in a nutshell, is the “bright
line” that we’ve been trying to capture between $has and $has$a. So
here’s a revised set of definitions:

 

1) $has asserts the definition of a new XDI
RDF subject based on two other XDI RDF subjects. Specifically:

 

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

 

$has statements do not have cardinality,
since they do not assert an XDI RDF property on an XDI RDF subject.

 

2) $has$a asserts an XDI RDF property on
an XDI RDF subject. Specifically, where $$ is a variable:

 

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

 

$has$a statements MAY have cardinality constraints.
Without a cardinality constraint, the default cardinality is zero-or-more. Any
other cardinality MAY be expressed by adding cardinality constraints as defined
in the XDI Dictionary specification.

 

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

How does that work for everyone?

 

=Drummond 

 

 

From: Barnhill,
William [USA] [mailto:] 

Sent: Thursday, May 07, 2009 10:12
AM

To: Drummond Reed; Markus
Sabadello; OASIS - XDI TC

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

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

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:
 [mailto:] 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
Next in thread → Next in month →