Re: RDF Issue rdfs-clarify-subClass-and-instance

>Comments below.
>
>pat hayes wrote:
>
>>
>>Guys:
>>
>>>Graham, Brian--
>>>
>>>Thanks for the comments.  Actually, I think the situation is both 
>>>less complicated and more complicated than you've described it, as 
>>>I'll try to explain below.
>>>
>>>graham wideman wrote:
>>>
>>>>Brian:
>>>>
>>>>Heh heh heh, your writing is helpful in tone, though I'm not sure 
>>>>whether I'm getting clearer or muddier :-)
>>>>
>>>>1. You are right that *part* of what's confusing is the phrase 
>>>>"(or some subclass of rdfs:Class)". Absent that phrase, I would 
>>>>believe that if a resource Description has a property
>>>>rdf:type...Class
>>>>
>>>>then that resource is a Class, and otherwise it's not.  (If we 
>>>>can't delete that phrase, then I have no idea how to distinguish 
>>>>a Class from a non-Class.)
>>>
>>
>>A class is a thing with other things in its class extension, ie 
>>with a nonempty class extension. Don't think of Class versus 
>>non-Class as a category distinction. In RDFS, anything can act as a 
>>class.
>
>
>So far, so good.
>
>>
>>>I'm grateful for Brian's confidence in my infallibility, but I've 
>>>also received a comment from Peter Patel-Schneider on this, and on 
>>>looking at it carefully, I've decided that the inclusion of the 
>>>phrase "(or some subclass of rdfs:Class)" is wrong (or at least 
>>>unnecessarily confusing),
>>
>>
>>It certainly is not wrong.
>>
>>>and the current Primer Editor's Draft (which has not yet been made 
>>>public) doesn't include it.   The phrase was included originally 
>>>because it was copied from the original RDFS Schema specification 
>>>(the March 2000 Candidate Rec).  However, there is nothing in that 
>>>document that actually illustrates that particular usage (all the 
>>>subclass examples are declared with rdfs:type...Class, and none of 
>>>the diagrams show it).   There's nothing in the current Schema 
>>>draft that says anything about this either.
>>
>>
>>Well, OK, but I really don't see why it is considered confusing. If 
>>something is in a subclass of rdfs:Class then it must be in 
>>rdfs:Class, right? (Imagine a Venn diagram with one bubble inside 
>>another and a dot in the inner bubble.) What is confusing about 
>>that?
>
>
>That's not the part that's confusing.  The part that's confusing is 
>when, having defined B as a subclass of A, you then define Foo as 
>having type B, you then say (a) Foo is of type Class, and at the 
>same time say you can't infer anything about the class hierarchy.

OK, maybe I didnt follow this example properly, because now Im 
confused. Foo is in B which is a subclass of A; OK so far. Then you 
say that Foo is a class? OK, though that rather comes out of left 
field. Now, if Foo is a class, then you know that B  (and therefore 
A) has a class in it. OK, but thats all you know; for all you know so 
far, B might have some nonclasses in it, eg it might have some sheep 
in it; so it might not be a subclass of rdfs:Class. Or, of course, it 
might be. YOu really don't know enough to tell.

>  It may not be wrong, but, I think, it's confusing.  Could you 
>extend your analysis to this case?
>
>>
>>>  Moreover, nowhere do we explain the ramifications of declaring a 
>>>new class by using an rdf:type property to point to a subclass of 
>>>rdfs:Class.
>>
>>
>>But we do this all the time.  There are no ramifications, other 
>>than saying that the 'declared' class (that is a very bad word to 
>>use, but never mind) is a member of a class of classes; in other 
>>words, it is a class. After all, if it were a member of a class of 
>>rabbits then it would be a rabbit, right?.
>
>
>We don't do this all the time in any of our documents, which is the 
>point here.  This all may make perfect sense given the proper 
>explanation of what classes and types in RDF(S) mean, but I don't 
>think that explanation exists in our documents (that is, I'm sure 
>the *definition* is in the model theory, but I'm not sure an 
>*explanation* exists).
>
>>
>>>Mind you, I think Brian's example works, at least up to the point 
>>>where we can't say anything about the class hierarchy of 
>>>bwm:AClass, and at that point it seems a little counterintuitive 
>>>(and I think we'd need to look carefully at that, were we to 
>>>continue to want to talk about classes being defined by having 
>>>their types be subclasses,
>>
>>
>>No no no. The use of rdf:type is just saying that something is in a 
>>class. That is,
>>A rdf:type B
>>says that A is in the class (extension of) B. No more, no less. 
>>Rdfs:Class is supposed to be the generic class of classes. There 
>>are many interesting subclasses of rdfs:Class which someone might 
>>want to classify a class as belonging to, however. For example, 
>>owl:Class and owl:Restriction are both proper subclasses of 
>>rdfs:Class. In general, the 'heirarchy' of subclasses of rdfs:Class 
>>can get arbitrarily deep. In fact, most classification languages 
>>will use a notion of class that is more restrictive than 
>>rdfs:Class, so for example if there were a formalization of UML in 
>>RDFS then it would need to explicitly restrict itself to something 
>>like uml:Class (just as OWL does) since there are RDFS classes 
>>which are illegal in UML (or OWL).
>
>
>This is where my earlier question about the relationship between RDF 
>and RDFS arises.  I'll put that question another way now:  does RDF 
>decide what rdf:type means, or does RDFS?

THey both contribute to the meaning. rdf:type means more in RDFS than 
it does in RDF, of course, so the 'full' meaning of rdf:type , I 
would say, is given by RDFS rather than RDF. In plain RDF, rdf:type 
is just another property.

>Putting this another way, if I have an RDF processor, is it expected 
>to understand the entire RDFS vocabulary, and is it expected to 
>interpret the object of an rdf:type property as a (RDFS) Class?  I 
>can understand it if an RDFS-aware processor gets an rdf:type 
>property and interprets the object as a class;  that's what rdf:type 
>is defined to point to in RDFS.  But is that true in RDF by itself 
>(or is that even a meaningful concept)?

I think it is meaningful, and the answer would have to be that a pure 
RDF (ie RDF- but not RDFS-aware) processor would not interpret 
rdf:type as referring to classes. BUt then a pure RDF-aware processor 
is pretty dumb, as the MT makes clear.

>>
>>>but I'm hesitant to have the Primer continue to use that phrase 
>>>without that investigation).  However, see my response to the next 
>>>point:
>>
>>
>>No investigation is required, but I think the phrase is OK. Maybe 
>>it needs some elaboration to guard against misunderstanding.
>>
>
>
>It certainly does!
>
>>>
>>>
>>>>Or maybe the escape hatch is that it's possible to write:
>>>>
>>>>rdf:type...SomethingThatsNotAClass
>>>>
>>>>Is that legit? If it is (and I'm now thinking it is) then the 
>>>>earlier sentence in the primer:
>>>>"The RDF Schema *type* system allows resources to be defined as 
>>>>*instances* of one or more *classes*."
>>>>... is kind of misleading, since apparently the type system (ie: 
>>>>the system using the keyword "type") can define resources to be 
>>>>of something other than classes as well.
>>>>
>>>
>>>
>>>This is where things may appear a little complicated.  In the 
>>>first place (at least as far as I know), rdf:type doesn't require 
>>>that its object (the thing it points to) be a Class
>>
>>
>>Yes it does. That is, it hardly amounts to a 'requirement', but the 
>>object of any rdf:type triple must be a class in RDFS simply by 
>>definition, because the truth of that very triple guarantees that 
>>it has something (the subject) in its class extension. You could of 
>>course make anything into a class in this sense: for example if you 
>>assert
>>
>>ex:whatever rdf:type ex:PatHayes .
>>
>>then (if what you say is true) I'm an RDFS class. I might well be, 
>>for all I know.
>
>
>By definition of RDFS, this is certainly true.  The question is, is 
>this also true if the triple is processed by an "RDF-only" processor 
>(assuming such a thing exists), rather than by one that understands 
>RDFS.

Ah, then OK, the answer would be no. But the answer is obviously no 
in that case, because RDF doesnt even have the notion of Class; its 
not in the RDF vocabulary.

>
>
>>
>>>, nor does it require that an application that uses rdf:type even 
>>>use RDFS (note the "rdf:" namespace on rdf:type).  The intent is 
>>>that it be used for "type-like" things,
>>
>>
>>That phrase doesnt make sense. Anything can be 'type-like' as far 
>>as RDFS is concerned.
>>
>>>but it doesn't specifically require RDFS classes
>>
>>
>>That seems to assume that 'RDFS classes' is a kind of category, 
>>like fish or furniture. But that way of thinking is a mistake. They 
>>are all RDFS classes, but that isn't any kind of constraint or 
>>requirement. The notion of 'Class' in RDFS is about as elastic as 
>>it is possible to be.
>
>
>They are all RDFS classes to an RDFS processor.  The question is, 
>what are they to a vanilla RDF processor.

Nothing special. To a vanilla RDF processor, the universe consists of 
things that are all on a par with one another, and relations that 
hold between them. That is ALL. Well, apart maybe from some stuff 
about literal, values.

>The question of whether there *is* such a thing as "a vanilla RDF 
>processor", which does not necessarily grok RDFS, is the question 
>here.  If such a thing can't exist, then lots of things get cleared 
>up (in particular, an "RDF processor" necessarily understands RDFS 
>vocabulary as defined by RDFS).  But I still haven't heard an answer 
>to that question.

I think it can exist, but its not particularly interesting.

>
>
>>
>>>;  so users could "roll their own" type systems if they wanted (or 
>>>point to classes or types from DAML, OWL, or some other language 
>>>that defines "type-like" things).
>>
>>
>>Right, they could; and when they do, they make those things, 
>>whatever they are, into RDFS classes. RDFS is designed to be a 
>>'fit-all' system; it doesn't come with its own notion of 'class' 
>>pre-defined. Its a general-purpose system for reasoning about 
>>almost *any* notion of 'class' which anyone might dream up.
>
>
>Again, they would make those things into RDFS classes if the thing 
>that was processing the rdf:type properties understood RDFS.  Is 
>that necessarily true?
>
>>
>>>   So "the RDFS type system" allows instances to be declared as 
>>>Classes, but RDF doesn't require that only RDFS classes be used 
>>>(nor does it require that an application even think that there 
>>>*are* such things as RDFS classes).  This is a point of 
>>>interaction between RDF and RDFS that may require a little more 
>>>explanation.
>>
>>
>>I think this way of putting it is highly misleading. It suggests 
>>that RDFS has one notion of 'class' that might or might not be 
>>suitable for some purpose. We should carefully guard against giving 
>>that impression
>>
>
>
>If it's wrong, we should certainly guard against giving that 
>impression.    However, there are certainly multiple class systems 
>in the world, many of which use notions of class that are not the 
>same as the one in RDFS.

But I claim that they are all special cases of it. That is, the RDFS 
class theory is the most (need a good word here...) 'liberal' or 
'agnostic' or 'catholic' or 'generous' or 'unrestricted' class theory 
one can imagine. It allows anything to be a class and anything to be 
in any class. It imposes no restrictions on class-ness at all, other 
than the obvious naive facts about subclass and membership.

>  If all usage of rdf:type in RDF necessarily involves the processor 
>understanding the RDFS semantics

No, sorry I didnt mean to give that impression. I thought we were 
talking about RDFS itself.

>(in particular, interpreting the object of rdf:type to be an RDFS 
>class), then this coupling of RDF and RDFS needs to be more clearly 
>stated than I think it is in any of our documents so far.

Right. I think it is fine to keep them uncoupled, but then we should 
be careful to make it clear just how very little one gets from 
vanilla RDF. It is very little more than a tabular database language.

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 26 August 2002 13:32:52 UTC