Giovanni,
Per the +car+engine+fan example I provided an example in my last message, it doesn't seem possible that $has statements can apply to both XDI predicates and XDI objects. But I'm willing to keep an open mind - I suggest we discuss on tomorrow's call. I'm sending out an agenda now.
=Drummond
On Tue, Mar 23, 2010 at 2:40 AM, Giovanni Bartolomeo <> wrote:
Dear Drummond,
thank you very much for your email. Although I still do not understand the syntax/semantics of some statements in the example, it is great to note that we are going to agree on this important point.
Let's try one more step forward. What looks odd to you ($has used for objects) has annoyed my sleeps for several nights since last Spring:
Yes, we have one issue: +x+y+z could be interpreted as a way to address +x+y/+z. However, I think, whether +x+y+z refers to +x+y/+z, or to +x/+y/+z, it depends on what's described in the document. My intuition is that it is unlikely that +z is used both as object of +x/+y and as predicate of +x+y; unfortunately I've not yet a formal proof of this... but I'm working on it.
(http://lists.oasis-open.org/archives/xdi/200905/msg00012.html)
...till two months ago when I finally realized that +x+y was nevertheless a set and that set membership could be described by aggregation and specialization.
To validate my idea I started some investigations in the set theory and its applications (whose OWL is one of) looking for papers and standards in this area.
And this story looks interesting enough... to be continued during our next phc :-)
Kind Regards,
Giovanni
Def. Quota "Drummond Reed" <>:
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
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
