More on +x/+y/+x+y

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

Based on our discussions on the telecon today, I want to return to the
"+x/+y/+x+y dilemma" and propose a solution.

The "dilemma", as Giovanni explains in his message below, is that if
+x/$has/+y metagraph statements infer that both +x+y/$is$a/+y and
+x/+y/+x+y, then every $has statement infers that a subclass of +y is also
an instance of +y. As Giovanni's example goes:

#1	=drummond/$has/+friend
#2	=drummond/+friend/=drummond+friend	<-- inferred from #1 -->
#3	=drummond/+friend/=giovanni
#4	=drummond/+friend/=markus
#5	=drummond+friend/$is$a/+friend	<-- inferred from #2 -->
#6	=giovanni/$is$a/+friend	<-- inferred from #3 -->
#7	=markus/$is$a/+friend	<-- inferred from #4 -->

Or in X3 form:

=drummond
	$has
		+friend
	+friend
		=drummond+friend
		=giovanni
		=markus
=drummond+friend
	$is$a
		+friend
=giovanni
	$is$a
		+friend
=markus
	$is$a
		+friend

Giovanni's concern, as I understand it, is whether =drummond+friend is an
instance of +friend the same way =giovanni and =markus are.

Based on today's discussion and the proposed "last subsegment wins" rule,
the answer is that =drummond+friend is a subclass of +friend, while
=giovanni and =markus are instances of +friend. All three --
=drummond+friend, =giovanni, and =markus have $is$a relationships to
+friend, but the first is a subclass and the latter two are instances.

This can be generalized to anything. Here's another example:

*bugs.bunny/$is$a/+animal
*flipper/$is$a/+animal
+lion/$is$a/+animal
+sheep/$is$a/+animal

Or, to use the inverse:

+animal/$a/*bugs.bunny
+animal/$a/*flipper
+animal/$a/+rabbit
+animal/$a/+dolphin

The first two are instances of animals and the second two are subclasses of
the class animal. There's no conflict in this - both the instances and the
subclasses have $is$a relationships to +animal.

It gets even more interesting - if you turn the last example into $has
relationships, you get:

*bugs.bunny/$has/+animal	-->	*bugs.bunny+animal
*flipper/$has/+animal		-->	*flipper+animal
+rabbit/$has/+animal		-->	+rabbit+animal
+dolphin/$has/+animal		-->	+dolphin+animal

These are all now classes of +animal. In English they would be expressed as:
"Bugs Bunny animal", "Flipper animal", "rabbit animal", "dolphin animal".
The first two "inherit" the qualities of the instance they name (young
children often use this kind of speech logic.) This illustrates how
instances can be used to create subclasses just like classes can be used to
create subclasses.

And the inverse is true too. Classes can be used to restrict instances.

+car/$has/*monte.carlo		-->	+car*monte.carlo
+city/$has/*monte.carlo		-->	+city*monte.carlo

In the first case Monte Carlo is an instance of a car, and in the second it
is an instance of a city.

From all of these, my conclusion is that it is not a problem for +x/$has/+y
to infer both +x+y/$is$a/+y and +x/+y/+x+y. The first expresses inheritance
(subclassing) and the second expresses hierarchy -- in particular the
machine-navigable hierarchy which is the key (literally) to XDI addressing.

In terms of the question of defining, "What is the range of +y?", I think
the answer is, "at least all the subclasses of +y". These do not need to be
enumerated; they can all be expressed generically as +y/$a/$$+y. The rest of
the range of +y -- all the instances which must be enumerated in some XDI
dictionary definition of +y, can be expressed generically as +y/$a/$$.

Hope this helps,

=Drummond 


> -----Original Message-----
> From: Giovanni Bartolomeo [mailto:giovanni.bartolomeo@uniroma2.it]
> Sent: Sunday, February 15, 2009 11:12 AM
> To: Markus Sabadello; Drummond Reed
> Cc: OASIS - XDI TC
> Subject: individual space vs class space (was: Re: [xdi] Minutes: XDI
> TCTelecon Thursday 1-2PM PT 2009-02-12)
> 
> Hello Markus, Drummond,
> 
> thanks for this input; I think this is a good way to explore:
> information about instances of class should be somehow inside the xri.
> However, this again clashes with (probably my wrong understanding of)
> +x/+y/+x+y.
> In fact, =giovanni+ball would mean =giovanni/$has/+ball, thus
> =giovanni/+ball/=giovanni+ball. Indeed, =giovanni+ball is an instance.
> Well, this apparently might make sense, but consider a similar example:
> 
> =drummond/$has/+friend
> 
> thus
> 
> =drummond/+friend/=drummond+friend
> 
> would =drummond+friend be an instance, like =giovanni or =markus?
> 
> =drummond/+friend/=giovanni
> =drummond/+friend/=markus
> 
> In case not, what would be then the range of +friend?
> 
> The strange aspect is that things would work fine without +x/+y/+x+y!
> Sorry, I'm probably still missing the real need to have this pattern
> in our model.
> 
> Giovanni
> 
> At 20.39 13/02/2009, Markus Sabadello wrote:
> Maybe the "class" ball should be +ball, and the "instance" ball should
> be =giovanni+ball or =markus+ball or =drummond+ball or simply =+ball !
> 
> Markus
> 
> On Fri, Feb 13, 2009 at 7:37 PM, Giovanni Bartolomeo
> <giovanni.bartolomeo@uniroma2.it> wrote:
> Dear Drummond,
> 
> Thanks for these detailed minutes. Let me check if I've understood
> correctly:
> In this example, let us assume that +ball/+color/+ball+color is a
> valid dictionary entry (class definition).
> Let suppose +aBall/$is$a/+ball (i.e. +aBall is an instance of +ball).
> Since +aBall inherits properties from +Ball, I can say
> +aBall/+color/+red, which is an "instance level" predicate.
> But I cannot say +aBall/+color/+ball+color (right?)
> Main question: would +aBall/+color/+aBall+color make any sense?
> Second question: how to know that +aBall is "an instance"? $is$a might
> also mean "subclassOf", right?
> 
> Thanks (and sorry for being so obsessive on this topic, countless
> nights spent on this :-(,
> 
> Giovanni
> 
> 
> 
> 
> At 06.34 13/02/2009, Drummond Reed wrote:
> We next discussed another concern of Giovanni's with some "strange"
> statements that can be made with $has. This is related to this email:
> 
>         http://lists.oasis-open.org/archives/xdi/200901/msg00054.html
> 
> It is the example about balls and their colors, where +x is +ball and +y
> is
> +color. This produces the XDI RDF statement +ball/+color/+ball+color. But
> in
> the same document we have also +ball/+color/+red. So you have two
> different
> objects of the same predicate, which is fine in RDF, but one (=red) is an
> instance of color and the other (+ball+color) is a subclass of color.
> 
> After some discussion, we realized that what was deceiving about these
> examples is that they confuse the dictionary/class space (Bill would say
> "T-box") from the individual/instance space ("A-box"). For example, in
> some
> email threads we had talked about having +ball/+color/+ball+color and
> +ball/+color/+red in the same graph. While this is technically possible,
> it
> doesn't make sense because the first statement is appropriate to a
> dictionary and the second would be more appropriate to an instance, except
> that +ball is not a typical instance. More typical would be
> =jbradley+ball/+color/+red.
> 
>