[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]