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>]

You say " +a+b IMPLIES +a/$has/+b, but +a+b is  not EQUIVALENT TO +a/$has/+b", yet equivalency is what has been being discussed as I understand it in using +a+b as an abbreviation for +a/$has/+b. In fact, for it to be an abbreviation it would have to be equivalent, which would mean not only that +a+b implies +a/$has/+b but that +a/$has/+b implies +a+b.

You also refer several times to the entity +a+b, which I do not understand given the definition of + terms that's been accepted by the TC. A + term does not refer to an entity, it refers to a concept. In talking about entities the closest thing in RDF terms to a + term would in my opinion be a class.

You also said  "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."

I don't see the source of the ambiguity of  +a+b. By the working definition of $has that seems to be in place this is +a/$has/+b. If we say +a by itself then I'd reach from RDF to OWL and say the entity set denoted by +a is equivalent to the set of OWL:Thing. In simple terms it could be any thing.  When we instead say we are talking about the entity set denoted by +a/$has/+b we narrow +a by constraining our entities to only those that have a predicate +b. In this way +b is both a property and defining +a as a subset of the XRI equivalent to OWL:Thing. This is similar to how OWL defines a class by using subClass and a restriction on a property.
For example:
<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
  ... 
</owl:Class>

You go on to say "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"."

I disagree, I think it's misleading to do anything other than treat this as a constraint.

First, to use +a+b as an abbreviation for +a/$has/+b, as I believe the TC has decided to do, means that (a) +a+b implies +a/$has/+b, and  (b) +a/$has/+b implies +a+b. By definition they are then equivalent, as I mentioned before.

Second,  I agree "Bird Wings"  is not the constraint "Birds have wings", but it's not an entity. It is the set of the wings from birds that have wings, presupposing 'some birds have wings'. I'm not sure where to take this further, since "Bird Wings" is not an XRI.

If you mean +bird+wings then this is an abbreviation of +bird/$has/+wings, which I take as a constraint that $$X/$is$a/+bird in a graph implies that there exists some $$Y in the graph such that $$X/+wings/$$Y, and that unless further constraints indicate otherwise a statement in the graph of $$X/+wings/$$Y implies $$X/$is$a/+bird.  If you intend to do reasoning using an XDI graph then presence of a property on an instance must have some implication about that instance's class through the property's domain property. That means $has and $is$a are tied such that +a/$has/+b implies ($$X/$is$a/+a => $$X/+b/$$Y).

As for "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.", I'd like to shorten that because it seems then that you are saying +a+b tells you nothing about the relationship between +a and +b. I disagree. I think it tells you that +a is the domain of +b when used as a predicate (technically this could be just +a is a subset of that domain, and this is something the TC needs to determine to enable decidable XDI reasoning) and that having a predicate +b is a requirement for an entity to be an instance of +a.

On  +bison+female+mammaries not implying +bison/$has/+mammaries, and not implying +female/$has/+mammaries I agree completely and wasn't saying either.

What I was saying was that
$$X/$is$a/+bison+female => $$X/$has/+mammaries, or stated another way $$X/+mammaries/$$Y (TC has not clarified which yet).

I like this example as it points out a problem with $has that we do need to resolve: the difference in meaning, if any, of statements where $has as the predicate and the subject is an entity (=,@) vs when the subject is a class of entities (+), vs when it's type is unknown ($$).

This is more apparent when I look at the other side of the example:
($$X/$is$a/+bison ^ $$X/$has/+female)  => $$X/$has/+mammaries
or...
($$X/$is$a/+bison ^ $$X/+female/true)  => $$X/$has/+mammaries

On your =Hector example:
"
  =hector+male   
  =hector+male+wife
  =hector/$has/+male    =hector/$has/+wife    not: +wife/$has/+male
"
What did I say that indicated I thought +wife/$has/+male would be correct?

But is +male a property on =hector? Most would take it to be a special kind of property then, a flag property if you will, whose presence is a constraint on membership in the class of +male.
It could then be viewed as implying =hector/$is$a/+male, so (=hector/$is$a/+male ^ +male/$has/+wife) => =hector/$has/+wife (specious, as not all males have wives, but thats what we're saying by +male/$has/+wife).

As for "p => r and q => r hardly means that p == q" I don't see how you got that out of my question to Drummond and TC in general "can +a/P/Q//R be treated as +a/P/Q/R?".

In addition to the above questions I'd like to pose the following to the TC at large:

Is $has transitive? If yes then $$X/$has/$$Y together with $$Y/$has/$$Z implies $$X/$has/$$Z?

Can the domain of $has be (a) only concepts, ie. + terms classes, (b) only entities (= @), (c) both?

Right now $has seems to be used in different ways depending on who you talk to and I'd like to see us determine and document exactly how it's used.

--------------------------------------------------------------------------------
From: Nick Nicholas
Sent: Fri 1/9/2009 10: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://
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