[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] More comments on XDI metagraph predicate examples (was: RE: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2008-12-18)
Yeah that looks a bit strange to me too.. I think what Bill means is that +a/$has/+b//$has/+c is an abbreviation for the two statements +a/$has/+b +b/$has/+c I.e. the // after an object means that the object is also the subject of the next statement. Right? Markus On Fri, Jan 9, 2009 at 6:21 PM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote: > Hello Bill, > > sorry I probably didn't get properly your two statements: > > (1) the XRI +a+b/$has/+c entail the XRI +a/$has/+b//$has/+c > (2) the XRI +a/$has/+b+c entail the XRI +a/$has/+b//$has/+c > > more precisely, I didn't understand how the context transition // is used > here (I'm familiar with // used after predicates, e.g., > =markus/$get//=drummond/+email, but not after objects...)? > > Thanks, > Giovanni > > At 14.46 09/01/2009, Barnhill, William [USA] wrote: > > Hi Giovanni, > > I think I understand your first question but I think the reversal of +a+b+c > still works I think. > > Paraphrasing what you said (let me know if wrong) as the XRI +a+b+c entails > either > (1) +a+b/$has/+c > or > (2) +a/$has/+b+c > or > (3) both > > and the outcomes are different in each case. > > It seems to me the outcomes would be the same though, as doesn't > (1) the XRI +a+b/$has/+c entail the XRI +a/$has/+b//$has/+c > (2) the XRI +a/$has/+b+c entail the XRI +a/$has/+b//$has/+c > (3) If we use the following substitutions > p : +a+b/$has/+c > q : +a/$has/+b+c > r : +a/$has/+b//$has/+c > and from (1) and (2) we know that p entails r, q entails r, then p and q > -> r, so both XRI's being entailed still entails +a/$has/+b//$has/+c > > What about the reverse way? > +a/$has/+b//$has/+c > a)=> +a+b//$has/+c => +a+b+c > b)=> +a/$has/+b+c => +a+b+c > > I am unsure about entailments above as they involve '//' though and need to > punt to Drummond: > Does +a/$has/+b//$has/+c entail +a/$has/+b+c? > Pretty sure it has to for $has to work as it's being used and have it be an > inverse functional property. > > Also in general can +a/P/Q//R be treated as +a/P/Q/R? > Not sure on this one. > > Thanks, > =Bill.Barnhill > > -----Original Message----- > From: Giovanni Bartolomeo [ mailto:giovanni.bartolomeo@uniroma2.it] > Sent: Fri 1/9/2009 5:47 AM > To: Drummond Reed > Cc: 'Nick Nicholas'; 'OASIS - XDI TC' > Subject: [xdi] More comments on XDI metagraph predicate examples (was: RE: > [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2008-12-18) > > Hello Drummond, > > thank you for your answers; but I fear I've some more concerns.. please see > my comments below. > > Thanks, > Giovanni > > > > > At 09.09 30/12/2008, Drummond Reed wrote: > > Giovanni pointed out that Statement 6 in the xdi-rdf-graphing-v1 > document is > not consistent with the link contract example found on page 33 of > the > xdi-rdf-model-v11 document: > > > http://www.oasis-open.org/committees/download.php/29748/xdi-rdf-model-v11.pd > <http://www.oasis-open.org/committees/download.php/29748/xdi-rdf-model-v11.pd> > f > > In that document, =drummond/$has/+friend$contract results in the XRI > =drummond+friend$contract, but it should be > =drummond(+friend$contract). > Drummond agreed this should be changed in the next version. > > UPDATE: In his study of the Statement 6 issue identified by Markus, > Drummond > subsequently revised the proposed graph structure for compound $has > statements. This eliminates the issue identified by Markus and also > removes > the inconsistency with the V11 XDI RDF Model document. V2 of the XDI > RDF > Graphing document has been posted at: > > > > > > [giovanni] To further clarify, I also propose to have > > (1) =drummond+friend/$has/$contract > > instead of > > (2) =drummond/$has/+friend$contract > > even if they both result in > > (3) =drummond+friend$contract > > statement (2) seems to me to assert that a subject +friend$contract > exists regardless the context it is intended to be into (=drummond). > Statement (1) instead put $contract in the context of =drummond+friend and > +friend in the context of =drummond. Or maybe I'm missing something? > > [=Drummond] No, I think you are correct, statement (2) implies that > there is a XDI subject with the XRI +friend$contract. But I think that is > implied in all cumulative $has statements. As I clarified in the page I just > posted ( http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel < > http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel> ), in an XDI context, > the XRI =drummond+friend$contract infers all of the following XDI RDF > statements: > > (a) =drummond/$has/+friend/ > (b) =drummond+friend/$has/$contract > (c) =drummond/$has/+friend$contract > > > > > [giovanni] Yes, I see that > > +a/$has/+b+c ==> +a+b+c > +a+b/$has/+c ==> +a+b+c > > > however, if you want to REVERSE these statements, starting from +a+b+c, you > can infer EITHER (1) +a/$has/+b+c OR (2) +a+b/$has/+c OR (3) both. And the > outcomes are different in the three different cases. > In particular, if you have (1) +a/$has/+b+c, this implies that you should > have also +b/$has/+c. > But if you have (2), then you should have also +a/$has/+b. > > Coming back to the example, from =drummond+friend$contract you may infer > > (1) > =drummond/$has/+friend/ > =drummond+friend/$has/$contract > > OR > > (2) > +friend/$has/$contract > =drummond/$has/+friend$contract > > OR (3) > both. > > I think that (1) and (2) are asserting very different things and that (1) is > what we want to say, whereas (2) is not the same. > > > > [giovanni] In example #8 (equivalence +x/$is/+y) the arc connecting > the two circles is labelled with +y, does it have a particular meaning? > Maybe, for consistency's sake, it is better to maintain the graphical > convention to name the arc after the predicate. Since $is is a symmetric > predicate, what do you think about the following amendment? > > > > [=Drummond] The graph you draw is 100% accurate - it is a depiction > of the full metagraph statement, i.e., of the XDI RDF statement +x/$is/+y. > The graph I was drawing is a depiction of the resulting statement in the XDI > RDF graph, which is that the node +x has a self-referential arc of type +y. > So both are correct, and I agree we should show both in the two columns. > I'll make a note to revise that in the next version. > > > [giovanni] Ok, I see. But in the graph in example #9 > +x/$has$a/+y > +x/+y > the arc +y is used to represent a property belonging to +x (this also > applies to all meta-graphs depicted in the document). Thus wouldn't the > picture in example #8 read as: +x has a property +y whose value is +x > itself: +x/+y/+x ? > > BTW I think this is strongly related to another issue which has come to my > mind. I remember that in the ATI model it was stated that addresses refer to > ARCs, not to NODEs. This is consistent with some OO programming languages > like c++ and Java which have the concepts of pointers and objects. Pointers > are represented through arcs pointing to nodes which are objects. Maybe we > have a similar issues here: XDI addresses might be arcs, not nodes. > > > > This should address also Markus' question: > > [markus] BTW in your terminology, a predicate is not a node in the graph, > right? So predicates themselves don't have addresses? > > What about to amend this > > "Every *node* in the XDI RDF graph can be addressed by at least one XRI > representing an XDI address, and every XDI address identifies a unique > *node* > in the XDI RDF graph." > > into > > "Every *ARC* in the XDI RDF graph can be addressed by at least one XRI > representing an XDI address, and every XDI address identifies a unique *ARC* > in the XDI RDF graph." > > (..but maybe I can miss some issues here...)? > > > > > > --------------------------------------------------------------------- > 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 > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.10.5/1883 - Release Date: 08/01/2009 > 18.05 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]