RE: [xdi] Key implications of new metagraph $has definition

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

Yes, Drummond I see your argument. But as you said:

"the potential that +x/+y/+z could be referred to as +x+y+z sounds appelling"

so my suggestion is: let us think at it a bit more before taking a  
final decision..

Giovanni

At 00.15 06/05/2009, Drummond Reed wrote:
Giovanni et al,

In re-reading my message below, the final paragraph may not have been clear.
Let me restate it. In Giovanni's original proposal for a new definition of
the $has metagraph predicate that would avoid the RDF interpretation we
found troubling (as discussed in
http://lists.oasis-open.org/archives/xdi/200904/msg00017.html), he proposed
that:

#1) The relationship +x/+y can be referred to as the subject +x+y and vice
versa, and

#2) The relationship +x/+y/+z can be referred to as the subject +x+y+z and
vice versa.

The result of our discussions of this proposal is, as I understand it, that
we are adopting #1 (with one small but important clarification), but that we
are rejecting #2, since the definition that supports #1 does not support #2.

The small but important clarification on #1 is that it is not the XDI
statement +x/+y that can be referred to as the XDI RDF subject +x+y, but the
_reification_ of the XDI statement +x/+y, which is (+x/+y). So, restated:

#1) The relationship (+x/+y) can be referred to as the subject +x+y and vice
versa.

I am fully satisfied that this gives us a precise definition of $has
relationships, i.e., +x/$has/+y ==> (+x/+y) ==> +x+y, and that this
definition to finally solve the problem we had with the original $has
definition (that +x/$has/+y inferred +x/+y/+x+y, which it no longer does).

The reason #2 does not hold is that in order for #1 to be consistent, it
must recurse. So +x+y+z refers to ((+x/+y)/+z) and vice versa.

While the potential that +x/+y/+z or (+x/+y/+z) could be referred to as
+x+y+z sounded appealing in some respects, it struck me from the outset that
this was likely to conflict with a rigorous definition of #1, which it turns
out it does.

Giovanni, I am happy to give up #2 (for which I don't have any use cases) to
solve #1. Did you have any particular reason for wanting +x+y+z to express
(+x/+y/+z) as a shorthand? Is there any reason not to just use (+x/+y/+z)?

=Drummond

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, May 05, 2009 12:51 PM
> To: 'Giovanni Bartolomeo'; xdi@lists.oasis-open.org
> Subject: RE: [xdi] Key implications of new metagraph $has definition
>
> Giovanni,
>
> The proposed definition didn't say that +x+y and +x/+y are synonyms - they
> are not, and cannot be, since the first one -- +x+y -- is a single-segment
> XRI representing an XDI RDF subject and the second one -- +x/+y -- is a
> two
> segment XRI representing an XDI RDF subject/predicate relationship.
>
> The proposed definition said that +x+y and (+x/+y) are synonyms. The
> cross-reference parentheses around the latter are critical. It is only by
> turning +x/+y into the cross-reference (+x/+y) that it becomes a single
> XDI
> RDF subject.
>
> RE the three part statement +x/+y/+z, you are correct that, based on the
> proposed $has definition, +x+y+z cannot infer either +x/+y/+z OR
> (+x/+y/+z).
> Rather +x+y+z can only infer ((+x/+y)/+z).
>
> The proposal that +x+y+z could refer to +x/+y/+z, or even to (+x/+y/+z),
> was
> the one part of your initial proposed definition that I didn't fully
> understand. Now that we have a clear proposed definition of +x+y as
> defined
> above, I am satisifed. If you needs to refer to the full statement
> +x/+y/+z
> as an XDI RDF subject, then you would use the cross-reference (+x/+y/+z).
>
> Do you see any issues with that?
>
> =Drummond
>
> > -----Original Message-----
> > From: Giovanni Bartolomeo [mailto:giovanni.bartolomeo@uniroma2.it]
> > Sent: Tuesday, May 05, 2009 9:28 AM
> > To: Drummond Reed; xdi@lists.oasis-open.org
> > Subject: Re: [xdi] Key implications of new metagraph $has definition
> >
> > Hello Drummond,
> >
> > I'm still thinking at all possible implications, however I'd like to
> > express one first comment on this: if we assume that +x+y and +x/+y
> > are synonyms, we have two implications, as you properly describe:
> >
> > from point 1) we have two ways of saying the same thing
> >
> > from point 2) we have an asymmetry in case of a three part statement,
> > cannot use +x+y+z to refer to +x/+y/+z
> >
> > Right now +x/+y and +x+y have been thought for different purposes: the
> > first one to be used in query, e.g.
> >
> > =markus
> >    $get
> >      /
> >        =drummond
> >          +friend
> >
> > whereas the second one has been introduced in order to have the
> > possibility to assert something about +x/+y, having a way to reference
> > it as a new subject in the graph.
> >
> > Are we sure that we really want to use them as synonyms?
> >
> > Thanks,
> > Giovanni
> >
> > At 08.16 05/05/2009, Drummond Reed wrote:
> > It was an extremely productive XDI TC telecon this last week (see the
> > minutes at http://lists.oasis-
> open.org/archives/xdi/200905/msg00000.html)
> > because it resulted in, I believe, a precise definition of Giovanni's
> > proposal for the definition of $has statements. I want to reiterate that
> > definition here and discuss two key implications that need to be
> reflected
> > in the XDI Addressing & RDF Graph Model spec.
> >
> > 1) REVISED DEFINITION OF $HAS PREDICATE
> >
> > An XDI RDF $has statement between +x and +y, i.e., +x/$has/+y, asserts
> > that
> > +y is a predicate on the subject +x. It infers the following two XDI RDF
> > subjects exist:
> >
> > (+x/+y)
> > +x+y
> >
> > These two XDI RDF subjects are synonyms, i.e. this means the following
> two
> > XDI RDF statements are true:
> >
> > +x+y/$is/(+x/+y)
> > (+x/+y)/$is/+x+y
> >
> > In addition, both the subjects (+x/+y) and +x+y identify the set of all
> > XDI
> > RDF nodes that are objects of the XDI RDF statement +x/+y.
> >
> > Lastly, this definition is recursive. So the XDI RDF statement
> > +x+y/$has/+z
> > identifies the set of all XDI RDF nodes that are objects of the XDI RDF
> > statement +x+y/+z, and that this set can be identified by either of the
> > following two XDI RDF subjects:
> >
> > ((+x/+y)/+z)
> > +x+y+z
> >
> > This recursion repeats to any depth; ordering is always left-to-right.
> >
> >
> > 2) THREE PART XDI RDF STATEMENTS
> >
> > Giovanni's email
> > (http://lists.oasis-open.org/archives/xdi/200904/msg00017.html) also
> > proposed that +x/+y/+z infers +x+y+z. However the above definition does
> > not
> > allow this. +x+y+z expresses +x+y/$has/+z, which is equivalent to
> > ((+x/+y)/+z). Rather, if there is a need to refer to a complete three-
> part
> > XDI RDF statement such as +x/+y/+z, the entire statement becomes a
> > cross-reference (+x/+y/+z). There is no shorthand for this statement.
> >
> >
> > 3) $HAS$A STATEMENTS NOT NEEDED
> >
> > Another key implication of this new definition is profound: $has$a
> > statements no longer appear to be necessary. Rather $, $a, $is, and $has
> > appear to be the complete set of metagraph predicates needed to express
> > the
> > fundamental relationships in an RDF graph:
> >
> > 	$a is an incoming arc relationship (inverse: $is$a)
> > 	$is is a self-referential arc relationship (and is its own inverse)
> > 	$has is an outgoing arc relationship (inverse: $is$has)
> >
> > This actually solves some longstanding issues around clarifying the
> > relationship of $has and $has$a
> >
> > If everyone is in agreement with these conclusions, I will update
> > http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel to reflect them,
> which
> > will move us one step closer to publishing it as a spec.
> >
> > =Drummond
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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