So the point is that in a PDS you want to do this, right?
=example
$is$a
+person
+email$1
“”
=example$1
$is$a
+home+person
+home+email
=example+email$1
Not really sure how well it would work in practice.. If there were more subsegments than just =example and +email$1, how would I know where to break them up into their "subject" and "predicate" parts in order to follow the reference and find the literal value?
I.e. in the above example, how do I know I have to look for subject =example and then for predicate +email$1, rather than for subject =example+email and then for predicate $1 ?
Markus
On Mon, Mar 22, 2010 at 9:47 AM, Drummond Reed <> wrote:
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
