Realizations about $has statements

Giovanni  et al,

 

The work I have been doing with Markus and others on XDI
patterns for personal data stores (PDS) have led me to an interesting
realization. In doing cross-references between an XDI
subject representing a person (=example in the examples below) and another
representing a “persona” of that person (=example$1 in the example below), the
following pattern (shown in X3 Simple) appears frequently:

 

=example            <--root
XDI subject for an individual's PDS -->

            $is$a

                        +person

            +email$1

                        “”            <--
a literal as XDI object -->

=example$1            <--
first persona -->

            $is$a

                        +home+person

            +home+email

                        (=example/+email$1)            <--
cross-reference to the literal above -->

 

Although we have used this form of cross-reference for many
months now, when I returned to it after all our discussions of the semantics of
$has statements, I realized that

 

            (=example/+email$1)            <==>            =example+email$1

 

This was particularly interesting since (=example/+email$1)
is clearly the XDI address of the XDI object literal
"", however =example+email$1 is an XDI subject.

 

My conclusion was the realization that the XDI statement

 

=example/

            +email$1

 

implies the XDI subect

 

=example+email$1

 

and vice versa - which is what I think Giovanni has been saying for some time now.

 

This pattern can be repeated to any depth. For example the XDI
statement:

 

=example+email$1

            $v$1

 

implies the XDI subject

 

=example+email$1$v$1

 

and vice versa.

 

This was startling to me because it means the distinction I
have been maintaining (and Giovanni has been objecting to) between $has and
$has$a statements—saying that $has statements identify a new XDI subject but
only $has$a statements identify an XDI predicate on an existing XDI subject—is
not needed. Rather a $has statement implies both that an XDI subject has a
particular predicate AND that this relationship can be described by a new XDI
subject.

 

If there is agreement on the TC about this, it means we can
eliminate two metagraph predicates ($has$a and $is$has$a) in our current wiki
spec. Note however that $has$a statements may still be a good way to express
cardinality on the number of instances of a particular predicate. For example,
following would be a way to express that =example must have at least one and at
most three instances of a +email predicate (each of which must be unique of
course):

 

=example+email

            $has$a

                        $min$1

                        $max$3

 

This realization also means I can complete another action
item, which is to provide my feedback on the issue I had with one slide in the
presentation Giovanni posted to the XDI doc repository last month.

 

In this slide, Giovanni says:

 

Therefore, the second part of
the statement

=drummond/+friend/=markus is
described by:

            =drummond+friend/$has/=markus

            =markus/$is$a/=drummond+friend

That is:
=drummond/+friend/=markus is

logically equivalent to the
three statements:

            =drummond/$has/+friend

            =drummond+friend/$has/=markus

            =markus/$is$a/=drummond+friend

 

The error I see here is that the rule I describe above --
that each XDI  subject/predicate
relationship can be expressed as a new XDI subject -- does not extend to XDI
objects.

 

In other words, the XDI statement

 

=drummond

            +friend

                        =markus

 

implies the XDI subject

 

=drummond+friend

 

but it does not imply the XDI subject

 

=drummond+friend=markus

 

because, as we saw above, the XDI statement
=drummond+friend=markus

implies

 

=drummond+friend

            =markus

 

Here's another example that shows this semantically. Say we
want to talk about the engine fan of a car. This could be represented by the
following XDI statements

 

+car/$has/+engine

+ear+engine/$has/+fan

 

The result is the XDI subject

 

+car+engine+fan

 

But these two $has statements CANNOT be expressed as

 

+car/+engine/+fan

 

because that would be saying, "The engine of a car is a
fan".

 

Instead, if you want to express the nested $has
relationships as a single XDI statement, you must say

 

(+car/$has/+engine)/$has/+fan

 

which can also be expressed as

 

(+car/+engine)/$has/+fan

+car+engine/+fan

+car+engine+fan

 

So my conclusions about $has semantics are:

 

1) $has statements may represent any chain of nested XDI
subject/predicate relationships to any depth. By "nested", I mean the
following (using the +car example from above):

 

+car

            +engine

+car+engine

            +fan

+car+engine+fan

            +bolt

+car+engine+fan+bolt

            ...

 

2) This nesting pattern cannot include an XDI object,
because an XDI object terminates the nesting.

 

3) A $has statement implies all the following XDI
statements:

 

+x/$has/+y

+x/+y

(+x/+y)

+x+y

+x+y/$is$a/+y

+y/$a/+x+y

 

Example:

 

+car/$has/+engine

+car/+engine

(+car/+engine)

+car+engine

+car+engine/$is$a/+engine

+engine/$a/+car+engine

 

Again, if there is agreement across the TC on these points,
then I'd suggest the next step is to update the wiki spec to reflect this
revision to $has semantics. Let's discuss on this Thursday's TC telecon.

 

=Drummond