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