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.  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?  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)?


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


> 
>> , 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.  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.


> 
>> ;  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.    If all usage of rdf:type in RDF necessarily involves the 
processor understanding the RDFS semantics (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.

--Frank




-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Wednesday, 21 August 2002 10:49:56 UTC