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

["Drummond Reed" <drummond.reed@cordance.net>]

Giovanni,

I agree with the intent of what you are staying, i.e., that +x+y+z is a way
of addressing +z in the context of +x+y.

To be VERY precise, under the new $has definition, +x+y+z is:

	(+x+y/+z)

...which expands to...

	((+x/+y)/z)

...which, if you really wanted, expands to:

	((+x/$has/+y)/$has/+z)

Secondly, I agree with you that on the surfact it may look like there is a
lot of difference between the set +x+y+z and the reified statement
(+x/+y/+z). For example, you might be tempted to make both of these XDI RDF
statements and English interpretations:

	=drummond+friend=markus/+nickname/"Mark"
	Drummond's friend Markus's nickname is "Mark".

	(=drummond/+friend/=markus)/+nickname/"Mark"
	Drummond has a friend Markus whose nickname is "Mark".

However, while the first one is fine, the second English translation is not,
because the subject (=drummond/+friend/=markus) is NOT referring to the
object =markus, but the statement "Drummond has a friend Markus". So, when
the subject is a reified statement, the property needs to be making an
assertion /about that statement/. You gave an excellent example in your
message:

	(=drummond/+friend/=markus)/+since/$d$2004

My conclusion, then, is that if in fact you want to refer to "Drummond's
friend Markus" as an XDI RDF subject -- in other words, if you want to talk
about the subject =markus, but only in the context of him being Drummond's
friend, then the ONLY way you have of doing that is $has statements, i.e.:

	=drummond+friend=markus/+nickname/"Mark"
	Drummond's friend Markus's nickname is "Mark".

Hope this helps,

=Drummond 

> -----Original Message-----
> From: Giovanni Bartolomeo [mailto:giovanni.bartolomeo@uniroma2.it]
> Sent: Sunday, May 10, 2009 8:49 AM
> To: Drummond Reed; barnhill_william@bah.com
> Cc: xdi@lists.oasis-open.org
> Subject: RE: [xdi] Key implications of new metagraph $has definition
> 
> Hello, Drummond, Bill,
> 
> I'd like to come back on this issue related to +x+y+z.
> 
> Actually, I think you're right, +x+y+z is not the same as (+x+y+z),
> and thus, I think, should not be used on its behalf. So if I want to
> express the reified fact that Markus is Drummond's friend since 2004,
> I can do this.
> 
> (=drummond/+friend/=markus)/+since/2004
> 
> and the predicate +since applies to the whole fact
> (=drummond/+friend/=markus) - as I've learnt from one of Nick's email
> during past months ;-)
> 
> My proposal for +x+y+z is slightly different. If +x+y can be used to
> identify +y in the context of +x ("those particular +friend which are
> =drummond+friend"), why not going further and use +x+y+z to identify
> that +z in the context of +x+y ("that particular =markus who is
> =drummond+friend=markus")?. This sounds powerful to me, as, having the
> subject =drummond+friend=markus, I could have an easy way to express
> attributes of =markus which are valid in the context of
> =drummond+friend; for example
> 
> =drummond+friend=markus/+nickname/"Mark"
> 
> i.e. "Mark" is the friendly name =drummond assign to =markus (the
> second way it has been proposed to do this was
> =markus/=drummond+friend+nickname/"Mark", but I like better the former
> one, as it respects the "narrowing principle" Bill suggested some time
> ago).
> 
> 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.
> 
> But I've a second argument: even if it could be, would it be a matter?
> In terms of sets, +x+y+z reads always as "that +z in the context of
> +x+y", and give the possibility to assert statements on that +x+y+z,
> regardless +z represents the object of +x/+y or a predicate of +x+y.
> 
> What do you think?
> 
> Giovanni
> 
> At 00.20 07/05/2009, Drummond Reed wrote:
> Giovanni, yes, I always think it's good to think on it before putting a
> stake in the ground.
> 
> I'm just excited to finally have a solution to the +x+y issue that doesn't
> introduce the +x/+y/+x+y complication.
> 
> I'll put this on the agenda for tomorrow's telecon.
> 
> =Drummond
> 
> > -----Original Message-----
> > From: Giovanni Bartolomeo [mailto:giovanni.bartolomeo@uniroma2.it]
> > Sent: Wednesday, May 06, 2009 2:16 PM
> > To: Drummond Reed; xdi@lists.oasis-open.org
> > Subject: RE: [xdi] Key implications of new metagraph $has definition
> >
> > 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.
> 
> 
> 
> ---------------------------------------------------------------------
> 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.