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


OK, I'm up way too late, and a couple of messages from Pat arrive. Now, with all due respect to Pat, who I assume is diligently reflecting the customary way of describing RDF features, 
I find these great examples of things that are way difficult to get traction upon (ie: just when I thought I knew something, Pat now makes me think I don't! :-).

So, just on a couple of fundamental points from Pat...

>there isn't a sharp distinction in kind between a category of 
>classes and a different category of non-classes.

...and then...
>What makes something a class is just that it has some 
>things in it and [...]  rdf:type is what puts 
>things into a class

OK, a and b seem directly contradictory. Surely applying rdf:type is a pretty clear cut act, which to me looks like a "sharp distinction". What the "in kind" means here I'm not sure... is "kind" an RDF concept?

Now, I could buy a description along the lines of "any resource can play the role of class". But I'm currently resistant to believing that, because (i) if it's that simple why doesn't somebody just say so, and (ii) what then is the point of rdf:type...Class.

The more complicated assertion of "we don't regard a resource as a class until something else treats it as a class" has a degree of specificity that seems to suggest some nuance that I don't understand. What suddenly happens to that resource once you realize that it's been refered to, and is now, presto, considered a class? I'm fairly sure nothing important, but this assertion has me vigilant. 

And that vigilance is triggered a few sentences later, where Pat says...

>bwm:AClass rdf:type rdfs:Class .
>Both the subject and object here are classes. All this says is that 
>bwm:AClass is in fact a class.

... but what Pat said previously which would lead us to expect that AClass is *not* in fact a class until some resource points an rdf:type at it. (Or maybe Pat meant to say that the above rdf:type causes AClass to "be" an rdfs:Class, even though it's not yet a lowercase-class?). Uggg.

Ie: all this makes me less able to assemble a coherent model of RDF classness than I was a couple of emails back. :-(


I'm totally prepared to hear that RDF supports the equivalent of multiple inheritance (ie: multi subClassOf's), and that any resource may or may not behave as a class in its own right (through some action of rdf:type or otherwise). But I'm just having a devil of a job mapping the discussion in the primer and in these emails onto a single coherent set of features. All this discussion of sets, extensions, Venn diagrams, examples of red-haired humans and anything else not directly about the actual features of actual RDF is not helping to understand actual RDF.

I repeat my previous recommendation (here slightly embellished, to simply list the actual RDF *things* that are worthwhile distinguishing, tell what their *features* are, and what the *relationships* among them are. Specifically, as an initial guess at this enumeration:

Things of interest: 
   -- resource 
   -- resource that can act as a class
   -- resource with special powers granted by rdf:type...Class
   -- rdf:type
   -- rdfs:subClassOf


-- What features does a resource have?

-- What features beyond this does a class resource have? Resolving this would be very illuminating. Pat claims no added features other than being referenced by rdf:type, but later seems to contradict this; I previously had convinced myself that there must be additional features but now am unsure.

-- What features beyond this does Class have? More illumination eagerly awaited here.

-- What features does rdf:type transmit from one resource to another? And maybe this involves "if the value is Class then rdf:type also transmits X, Y, Z".

-- What features does subClassOf transmit from one class to another?

....Much of this being parallel to Piotr's suggestion to discuss "simple summary of the "features" of class-ness".

OK, time for bed,


Graham Wideman
Resources for programmable diagramming at:

Received on Wednesday, 21 August 2002 06:32:36 UTC