RE: [xdi] +x/+y/+x+y

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

 

Cool, thank you very much for taking the time to do this. Comments inline.

 

---

From: Nick Nicholas
Sent: Thu 3/12/2009 2:49 AM
To: OASIS - XDI TC
Subject: [xdi] +x/+y/+x+y

Dunno if there is much point in this post, but it's sort of a global  
response to Giovanni's postings over the past month; it is a "+1" to  
what Drummond and Bill said, and an attempt to stand back and  
summarise things that have been worked through.

I won't make tomorrow's teleconf, and don't want this to sidetrack the  
teleconf: could you point out glaring errors on list?



XDI models a universe with the following characteristics:

* There is no primitive distinction made between instances and  
subclasses in the metagraph: both are encompassed by $a

Bill : +1, but isn't this $has? I thought $a was now the inverse operator?

* As a result, there is no primitive distinction made through  
operators between instances and classes: +friend could be either (as  
Bill argued)

Bill: +1

* There *is* a primitive distinction made by the Global Context Symbol  
between individuals and groups in $ and @; but that is so bound up  
with XRI authority, that I think it's of only limited use in overall  
inferencing.

Bill: Not +1, but not -1 (0?) as I agree the distinction is very bound up in auth defs, and may have limited use in inferencing, but implications in application of treating every =, @ XRI authority as a community (if my concept of = being a community of one is accepted) could be big I think.

* There is a distinction between RDF terms (subjects and objects) and RDF predicates...

* ... however, any RDF predicate defines the class of all its objects:

* e.g. +son defines the class of all x such that there exists y such that y/+son/x. (In English: "Y has-son X" defines the class of all sons.

* So any predicate can be used as a term, the term being the class of objects of the term.

* Which complicates things. :-)

Bill: :) Agreed on all four of the above points, especially last one, but I still think the benefits outweigh the added complexity.

 

.... have to review rest later this weekend...

 

* This allows us to treat predication and type hierarchy as the same thing ("incoming arrows" in the metagraph): any object of a predicate $is$a member of the predicate class.

* So =abraham/+son/=isaac corresponds to the metagraph statement +son/$a/=isaac, and the assertion that $a represents incoming RDF arcs (+son is an arc incoming to =isaac)

* On the flip side, $has in the metagraph conflates properties and predication: any subject of a predicate has that predicate as a property

* So =abraham/+son/=isaac corresponds to the metagraph statement =abraham/$has$a/+son, and the assertion that $has represents outgoing RDF arcs (+son is an arc outgoing from =abraham)

* We can also define the class of all objects of a predicate with a given subject:

* e.g. =abraham/+son defines the class of all x such that =abraham/ +son/x

* This introduces restrictions on classes: it is equivalent to relative clauses.

* Related to that, we have a notation of concatenation XY (e.g. =abraham+son), defined as the class of all Y such that X/$has$a/Y.

* Because X/Z/Y corresponds directly to X/$has$a/Z, it follows that if Z is a predicate, then XZ expresses the class of all y such that X/Z/ y. This lets us express X/Z as a XZ, which is more straightforward syntactically as a term.

* But note that XZ is meaningful even if Z is NOT a predicate: it just presupposes that X and Z are in some relation (an arc metagraphed to $has$a), but not what that relation is.

* This makes XZ in general vague. In fact, even if Z was a predicate class, I was originally inclined to leave it vague --- to allow =shakespeare+wife to refer to the wives Shakespeare wrote about, instead of the woman he was married to. (So =shakespeare/+writes-about/ =gertrude/$is$a/+wife, not =shakespeare/+wife/=ann.hathaway). But I do not now think allowing that vagueness for predicate classes is useful. * We can further say that a full RDF clause defines the class of all of its subjects.

* e.g. +australian/+member/@XRI.TC defines the class of all Australians who are members of the XRI TC.

* But syntactically this is awkward to express as a term --- particularly because we also want to refer to reifications of XRI statements.

* We'd rather have (+australian/+member/@XRI.TC)/$is$a/+true-statement

* =drummond/+friend === =drummond+friend is a class, of which =giovanni and =markus are instances * But bear in mind what we said above: outside of the Global Context Symbol (and even then), XDI does not diferentiate classes from instances.

* So while Giovanni and Markus are instances of =, it is also true to say they are instances of the class +friend. XDI certainly allows things to be instances of more than one class! In some sense, = is more primitive than +friend as a class, and is a global root for their ontology, as Giovanni says. But as Bill retorted (I interpret), XDI graphs are closed worlds anyway.

* And nodes in a graph are there only because arcs are connecting them to other nodes: if Jack is unrelated to any other node, he has no business showing up in the graph. An RDF graph is not the world, it's a slice of the world.

* So I don't quite agree with the consensus of 2009-02-26 that "+x/ +y/=z does not mean that =z is a +y". Giovanni is a friend too. (In fact not even +friend/$member, as Bill responded: +friend/$a or just plain +friend will do.) It's the priority of what hierarchies Giovanni belongs to that is at issue: Giovanni is defined first through = , and only contingently through +friend. (That's what Giovanni means by "would exist without +friend.)

   * Giovanni in response distinguishes between "references" and "is instance of" for =Drummond/+Friend. I am having difficulty seeing the distinction.

* +car/$has/*monte.carlo can correspond to +car/+name/"monte carlo", since $has is so vague (and names are clearly properties of things); in that case +car*monte.carlo is the class of Monte Carlos such that cars are associated with them (XZ = Z such that X/$has/Z).

* It's widely known that names *should* be individuals, but end up being classes, because they're not globally unique. (Bill said as much.)

* So I disagree with Giovanni's initial statement: +city*monte.carlo/$is$a/*monte.carlo is meaningful (given the smudging of classes and instances), though it is pathological.

* Giovanni now characterises this as a metalevel; of course, that metalevel potentially applies to any individual in XDI, so it's a feature not a bug that XDI does not clearly differentiate them.

* I admit I find +car*monte.carlo a bit too cute, but it is meaningful the way Drummond said. (It is also pretty vague: it's not just the cars named Monte Carlo, but also the cities called Monte Carlo that a car has driven through: how the car relates to "Monte Carlo" is undefined!)

* We could decide that X*Y, where *Y is a literal, means only "is the individual of the class named *Y). That's where 2009-03-05 seems to have headed. Looks somewhat artificial to me, but meh, it's not like I spoke up at the time...

* *flipper/$has/+animal is even vague. It *can* be the animal Flipper (so $has in the metagraph is $is$a in the graph), but it needn't be. It can be just Flipper's animal -- a parasite or whatnot. Again, $has is any outgoing arc in the RDF -- any property.^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Dr Nick Nicholas, Link Affiliates Rode like foam on the river of pity skype:opoudjis Turned its tide to strength http://www.opoudjis.net Healed the hole that ripped in living opoudjis@optushome.com.au - Suzanne Vega, Book Of Dreams __________________________________________________________________________ --------------------------------------------------------------------- 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