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