Realizations about $has statements

[Drummond Reed <drummond.reed@xdi.org>]

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

����������� ����������� �person@example.com������������ <-- 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 "person@example.com", 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