RE: More on the distinction between $has and $has$a

In a message to the list on Friday about $has statements, I said:

+x/$has/+y does in fact translate into two base graph statements: +x/+y/+x+y and +x+y

In reply Bill asked two questions. The first one was:

But what do you mean by translate? Do you mean (a) that the presence of the first (+x/$has/+y) in the graph implies the other two (+x/+y/+x+y and +x+y) ; (b) that the presence of the other two in the graph implies the first, or (c) both?

What I meant by “translate” should more accurately have been “infer”, i.e., +x/$has/+y in the metagraph infers both +x/+y/+x+y and +x+y . The opposite applies as well. In fact, any one of the following three statements infers the other:

+x/$has/+y

+x/+y/+x+y

+x+y

Nick and I also noted that the second statement above infers a fourth statement:

+x+y/$is$a/+y

** If you mean what I think you mean Drummond then I'd suggest 'implies' as the term, or 'entails'. Inference I think has some other baggage in meanings.

** Also, if +x/$has/+y implies +x/+y/+x+y and +x+y, then are you saying you mean (c)?

Bill then posed a second question:

I agree with (c) for the +x+y part, but am having trouble with the other. If you say (c) for both then +x/+y/+x+y <=> +x+y. So the subject +ball, predicate +color has the object +ball+color as well as +red? That would mean that a query of +ball/+color would return two answers: +ball+color and +color*red?

My answer is that the subject +ball with predicate +color COULD produce both the objects +ball+color and +red. But the semantics of both answers are clear if we follow the statements and inferences all the way though.

** Semantics is about meaning though..what does +ball/+color/+ball+color mean?

I found it quite instructive to do this, so I offer the following writeup:

Start by substituating +ball for +x and +color for +y in the three statements above. This yields:

+ball/$has/+color

+ball/+color/+ball+color

+ball+color

So far these are all metagraph statements (T-box statements to use the terminology Bill suggests) about classes. There are no base graph (A-box) statements about instances yet. To do that we would need a fourth statement:

+ball/+color/+red

That’s an A-box statement that says in English “a ball has a color of type red”. Note the “has a” in that sentence. The object of an A-box statement is an instance (yes, +red is also a class, but in this context it is an instance of the class +color). That means that the A-box statement +ball/+color/+red is described by the following two T-box statements (or their inverses):

+ball/$has$a/+color

+red/$is$a/+color

** This is still a T-Box statement. If the subject is a class, or a property, then it's almost always in T-Box (could make A-Box case for something like a statement with dc:created as a predicate, but still arguable that's in T-Box).

** Also, T-Box statements are about instances in that they constrain instances. So +ball+color is a statement that says for some node to be an instance of +ball that node must have an outgoing arc labelled +color to some existing node which $is$a +color.

But neither of those is a $has statement. That’s because $has can only be used to describe an arc whose object is a restricted class of that type of arc. In other words, +ball/$has/+color can only be used to create a restricted subclass of +color – specifically the type of color that a ball has. XDI RDF assigns this restricted subclass the XRI +ball+color. About the subclass +ball+color we can infer the following two T-box statements:

+ball+color/$is$a/+color

+ball+color/$is$has/+ball

** I think the idea of a metagraph $ predicate that does this, essentially the inverse of subClassOf, is an interesting idea. I think making $has that $ predicate is not such a good idea because it violates the principle of Subj Pred Obj. What you are talking about is a subClass of +color that is +ball+color. Saying that +ball $has +color intuitively says something about +ball, not something about +color. Perhaps an alternative is $narrows?

** Also, is such a predicate really needed? How does RDF do this without such a special predicate? It does it by combining subclasses. If I want to describe the color on all instances of Ball (making this easier by having color have an inverse predicate colorOf)

** a class BallColor, union of

subclassOf Color

subClassOf defined by restriction on colorOf st. the value of colorOf must be instance of Ball

** This also btw presents a possible alternative to $is as inverse..$of. Inverse pred of +x is +x$of

** A thing that really hurt RDF adoption was that they did not examine carefully each element of the spec through the lens of the principle of least surprise. I think predicates like $is$has violate that principle and so I'd really like to see changes in our predicates.

** I've proposed a fair number of changes and will get them up on the wiki ASAP (tonight or tomorrow night).

The opposite is true for $has$a. $has$a can only be used to describe an arc whose object is an instance of that type of arc. For example, if we say +ball/$has$a/+color, then we actually can’t infer any other T-box statement. All we can do is say that the XDI address +ball/+color is valid and then make A-box statements against an XDI dictionary defining instances of the class +color:

** I don't understand the above reasoning. How then do you contrain a particular class so that having a certain property is part of the definition of the class? If you say "+ball/$has$a/+color implies that for all $$x s.t. $$x/$is$a/+ball implies $$x/+color/$$y and $$y/$is$a/+color" you can have restrictions. Without those restrictions I think any reasoner will be crippled, if it is even a reasoner in the semantic technologies sense.

XDI DICTIONARY (T-BOX)

+ball/$has$a/+color

+color/$a/+red

+color/$a/+blue

+color/$a/+yellow

XDI INSTANCES (A-BOX)

+ball/+color/+red

+ball/+color/+blue

+ball/+color/+yellow

** The above 3 are all TBox statements and imply any ball has 3 colors, red blue and yellow.

But we can’t say

+ball/+color/+small

because +small not an instance of +color.

** Agreed, but this is the case with either approach

So, to get back to Bill’s question, say we had an XDI document with the following statements in it:

+ball/$has$a/+color

+color/$a/+red

+color/$a/+blue

+color/$a/+yellow

+ball/$has/+color <== same as the statement below

+ball/+color/+ball+color <== same as the statement above

+ball/+color/+red

+ball+color/+color/+red

This would be a little strange since the two marked statements mean the same thing, but it would still be valid.

If we then did a $get on +ball/+color, we’d get two answers:

+ball/+color/+ball+color

+ball/+color/+red

But the metagraph semantics of this answer are clear. +ball+color is not in the dictionary as an instance of +color. So if you did a $get on +ball+color from the same XDI document, you would get:

+ball+color/+color/+red

** The color of the class +ball+color is red? I can see +red/$is$a/+ball+color, or +ball+color/$instance/+red, but the above makes no sense to me semantically or intuitively.

In other words, for this XDI subject – +ball – there are two ways of expressing that it has the color +red. The first way is direct:

+ball/+color/+red

** +ball is a class of balls, not an individual ball therefor it can't have a color.

The second way is to subclass +color into +ball+color and then give its value:

+ball/$has/+color

+ball+color/+color/+red

** Am ok on first statement, same objections on second.

Both are valid. Both could appear in the same XDI document, though that would be somewhat redundant. Though the first way is simpler, but there can be good reasons to use the second, i.e., create a restricted subclass. One of them is that you want to express different predicates on the subclass. For example:

+ball/$has/+color

+ball+color/+color/+red

+ball+color/+density/+high

Note that +ball+color/+density/+high is very different that +ball/+density/+high

For me, this analysis helps make the distinction between $has and $has$a much clearer. The former asserts a restricted subclass as a new XDI subject. Its object is always a new class. The latter asserts a predicate on the existing XDI subject. Its object is always an instance.

** For me we cannot treat +ball as an individual ball, to quote ancient explorers.."Here they be dragons!". By that I mean that we might be able to treat +ball as an individual of type +,ie a class, but we cant treat it as an individual ball because how then do we represent the class of balls?

** As a side note RDF has individuals rooted in rdf:thing. I had the interesting observation that our individuals are rooted in one of two roots..a community (@) or an individual (=). I think the implications of this simple thing are pretty far reaching and will prove very interesting.

** Instead it is a class of balls, a set of individual balls. +ball+color by your reasoning would then be a subclass of Color per discussion several paras above.

What $has and $has$a have in common, as Nick observed, is that both describe outgoing arcs on an XDI subject, i.e., both are rooted in $has, which is the metagraph predicate representing an outgoing arc.

** Isn't any predicate an outgoing arc on a graph node, so it makes sense that these two would be as well?

However this brings up a one more very interesting point that Nick and I discussed last Thursday: at first glance it might appear that if an XDI subject has a $has$a, it implies it has a $has. For example, if you saw

+ball/$has$a/+color

then it looks like it implies

+ball/$has/+color

However the analysis above – and specifically the inferences between +x+y and +x/+y/+x+y – show why that’s not true. +ball/$has$a/+color only means you can make XDI statements about +ball/+color. It does not infer that the XDI subject +ball+color exists because it doesn’t infer that the statement +ball/+color/+ball+color exists. That’s a separate statement.

** Hmm.. sounds like what you are saying is that the existence of an instance of a +ball with predicate +color and some object that is an instance of +color does NOT imply that there is a subclass of color which is the color of a at least one ball. I think that's false for not just +color but for any property.

Hope this helps.

=Drummond

xdi message