RE: [xdi] More comments on XDI metagraph predicate examples (was: RE: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2008-12-18)

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

I did get the sleep but when I went to work on this reply, I decided first
to take care of my other action items related to updating the XDI RDF graph
model wiki page upon which all of this discussion is based. I finished that
update - you can review it at:

	http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel

But I ran out of time to compose my comments/answers to the questions on
this thread. I'll get on it after another good sleep.

'night,

=Drummond 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, January 09, 2009 11:15 PM
> To: 'Nick Nicholas'; 'OASIS - XDI TC'
> Subject: RE: [xdi] More comments on XDI metagraph predicate examples (was:
> RE: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2008-12-18)
> 
> I agree with Nick - much of this appears to conflate $has metagraph
> statements with $is$a metagraph statements. But this thread has grown so
> long (and I'm coming to it so late Friday night) that I'm going to get a
> good sleep and then send some fresh message RE the questions Giovanni and
> Bill have raised.
> 
> 'night,
> 
> =Drummond
> 
> > -----Original Message-----
> > From: Nick Nicholas [mailto:opoudjis@optushome.com.au]
> > Sent: Friday, January 09, 2009 7:10 PM
> > To: OASIS - XDI TC
> > Subject: Re: [xdi] More comments on XDI metagraph predicate examples
> (was:
> > RE: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2008-12-18)
> >
> > I'm sorry, but I'm not liking the turn this is taking at all.
> >
> > I am still unhappy about the smooshing together of (+a+b)+c and +a(+b
> > +c). +a/$has/+b+c and +a+b/$has/+c are clearly different predicates.
> > And an "empty bottle collection" can refer to two different states of
> > affairs.
> >
> > Moreover, clearly +a+b is a distinct entity to +a and +b. +a+b may be
> > a subclass of +a, or a subclass of +b --- or either, although that's
> > an outcome I'd hope to avoid.
> >
> > To cast +a+b as a constraint rather than as a description of a
> > distinct entity is misleading. +a+b IMPLIES +a/$has/+b, but +a+b is
> > not EQUIVALENT TO +a/$has/+b. "Bird wings" is not the constraint
> > "Birds have wings": it is the entity "bird wings", which presupposes
> > the statement "birds have wings".
> >
> > Given that, (+a+b)+c tells you that +a/$has/+b, and that +a+b/$has/+c.
> > It tells you absolutely nothing about a relation between either +a or
> > +b and +c. That's because we don't have an +a+b/$is$a statement
> > inferred anywhere.
> >
> > +bison+female+mammaries
> >
> > does not imply
> >
> > +bison/$has/+mammaries (male bisons don't)
> >
> > nor
> >
> > +female/$has/+mammaries (female reptiles don't)
> >
> > All you can infer is +bison+female/$has/+mammaries . (In fact, +mammal/
> > $a/+bison and +mammal+female/$has/+mammaries, ergo +bison+female/$has/
> > +mammaries .) +flyingbird+wings+flightspeed does not mean  +flyingbird
> > +wings and +wings+flightspeed , for the same reason: at most, +wings
> > +flightspeed only in the context of +flyingbird+wings. But even that
> > is not guaranteed, because +a+b/$is$a/+a is possible, so you end up
> > with +a+b and +a+c, not +a+b and +b+c:
> >
> > =hector+male
> > =hector+male+wife
> >
> > =hector/$has/+male    =hector/$has/+wife    not: +wife/$has/+male
> >
> > So I question attempts to impose transitivity on properties of +a+b+c.
> >
> > As for what follows, p => r and q => r hardly means that p == q. They
> > don't describe the same state of affairs, so they're not the same
> > outcome.
> >
> > On 10/01/2009, at 12:46 AM, 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...)?
> > >
> > >
> > >
> > >
> > > <8b72075.jpg><8b720e2.jpg>
> >
> > &&&
> > NON ME TENENT VINCVLA NON ME TENET CLAVIS     STETIT PVELLA RVFA TVNICA
> > Dr Nick Nicholas                       IT Consultant, Link Affiliates
> > QVAERO MIHI SIMILES ET ADIVNGOR      SI QVIS EAM TETIGIT TVNICA CREPVIT
> >    opoudjis@optushome.com.au                      http://
> > www.opoudjis.net
> > PRAVIS    ARCHIPOETAE CONFESSIO           EIA      E CARMINIBVS BVRANIS
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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