[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] 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
����������� ����������� �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
�
�
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]