Re: [xdi] Realizations about $has statements

["Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>]

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" <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 -->
>
>             $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
>
>
>
> =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.