OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xdi] Realizations about $has statements


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.


On Tue, Mar 23, 2010 at 2:40 AM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> 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.


...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,

Def. Quota "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 -->




                       “person@example.com”            <-- a literal as XDI
object -->

=example$1            <-- first persona -->




                       (=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



implies the XDI subect


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:



implies the XDI subject


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):





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:



That is: =drummond/+friend/=markus is

logically equivalent to the three statements:




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

In other words, the XDI statement




implies the XDI subject


but it does not imply the XDI subject


because, as we saw above, the XDI statement =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



The result is the XDI subject


But these two $has statements CANNOT be expressed as


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


which can also be expressed as




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):









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:














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.


This message was sent using IMP, the Internet Messaging Program.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]