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

["Barnhill, William [USA]" <barnhill_william@bah.com>]

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

Please see inline, starting at [+ =Bill.Barnhill]

-----Original Message-----
From: markus.sabadello@gmail.com on behalf of Markus Sabadello
Sent: Fri 1/9/2009 12:47 PM
To: Giovanni Bartolomeo
Cc: Barnhill, William [USA]; Drummond Reed; 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)

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?

[+ =Bill.Barnhill]
Kind of. What I intended was that +a+b+c is constraint on the graph such that for all +b in the context of a +a there exists an X such that there is a node in the graph addressed by the XRI +a+b+c/X , but not necessarily that there is a node in the graph addressed by +b+c/X.

An XRI problem similar to tweetybird problem:
Assume you have the following XRIs in your graph:
+bird+wings
+flyingbird+wings+flightspeed
+penguin/$a/+bird
+robin/$a/$flyingbird
=bob/$a/+penguin
=ben/$a/+robin

If +a+b+c in the form of +flyingbird+wings+flightspeed is an abbreviation for the constraints:
+flyingbird+wings
+wings+flightspeed

Then it's expected that the following XRI's are valid addresses in the graph (i.e. are entailed):

=bob+wings+flightspeed , which is false since =bob is a +penguin and not a flyingbird
                        (making closed world assumption)

=ben+wings+flightspeed , which is true since ben is a robin and robins are flying birds

If you take the context into account the context then +flyingbird+wings+flightspeed is an abbreviation for the constraint +flyingbird+wings. It is also an abbreviation for the constraint
$X+wings+flightspeed , where $X/$a/+flyingbird. So only the following XRI is entailed:

  =ben+wings+flightspeed


Note I am still working on understanding the distinction between $has and $has$a. Once I have that down I'm going to collect my notes and publish an first cut at a proposed entailment rules section on the wiki or a doc, for inclusion into one of the specs (probably the model spec). That would also include a cut at a description of the concept of entailment in an XDI graph and XRI resolver context, i.e. in an XDI graph supporting reasoning.

So, that said I've listed below some short forms I've been using and what I'm taking them to mean. I'd like to know if what I take these forms to mean jibes with the tc accepted current meaning.  Where the form isn't in use by others in the TC I'd like to hear everyone's opinion on whether the form would be useful to adopt in the spec.

So, that said what is everyone's take on the current meaning (or lack thereof) of the following and whether the form, meaning, and rationale make sense for inclusion in the spec?

Form 1: $$s/$$p//$$q
Meaning:
     $$s/$$p and $$s/$$q
Rationale: Ability to concisely specify property constraints

Form 2: $$s/$$p//$$q/$$o
Meaning:
     $$s/$$p/$$o and $$s/$$q/$$o
Rationale: Awkward, but follows from form 1

Form 3: $$s/$$p/$$o1//$$p2/$$o2
Meaning:    
     $$s/$$p/$$o1 AND ($$o1/$$p2/$$o2 where $$s/$$p/$$o1)
Rationale: Needed to express nested graphs in single XRI so as to maintain XDI graph <==> XRI

Form 4: $$s/$$p/$$o1//../$$o2
Meaning:
     $$s/$$p/$$o1 AND $$s/$$p/$$o2
Rational: Short form for lists of property values

Form 5: $$s/$$p/$$o1//.../$$p2/$$o2
Meaning:
     $$s/$$p/$$o1 AND $$s/$$p2/$$o2
Rationale: Ability to express graph representing properties of an object (XDI version of SPARQL DESCRIBE)

[- =Bill.Barnhill]

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
>