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

Brian:

OK, making some progress. I believe the heart of the matter is fuzziness over the following topics:

a. Class vs Instance: What features/requirements constitute classness and instanceness, and which keywords are used to transmit some or all of these features/requirements from one thing (one resource) to another.

b. Metadata vs data (or RDF mechanisms domain vs User Application domain).

So, I *think* the way this is turning out is approximately as follows:


1. An RDF resource description is *always* an instance of some class (as specified by rdf:type...SomeClass), which means that it acquires from that class certain features and requirements (which are...?). 

a) If a resource is merely an instance then its likely use is probably just as a holder of "data", generally data meaningful to the user's application. 

b) In the special case of rdf:type...Class, the "data" that the resource contains includes what's necessary for the resource to define a new class. From a user application point of view, this would be meta-data, ie: it defines application data *structure* as opposed to recording application *data*.


2. For a resource which is a *class* (ie: rdf:type...Class):

a) The resource can optionally have one or more subClassOf tag(s), which adds features [which are...?] to this resource from the specified class.

b) This resource becomes a legitimate value that other resources can use in a subClassOf tag, by which they acquire features  [which are...?] as in (2a).

If I'm right about the above, then my confusion stems from (what I think I now understand to be) RDF's lack of emphasis on the separateness of mechanisms for defining *data structure* versus *recording data*. This might easily be regarded as a good thing -- not complaining about this. However, this needs to be made clear, since it's a significant difference relative to other familiar environments.

While the primer makes comparisons to traditional programming languages and to animals (but with Brian at one point commenting "RDF is not a programming langauge"), perhaps it might be more helpful to make comparisons to a parallel field that actually endeavors to facilitate similar quests, and that's the field of databases, large or small.

I'm sure you know these details, but for purposes of my point... in working with databases we have distinct activities for defining data structure, and for recording data. Indeed SQL identifies two separate vocabularies for this: Data Definition Language and Data Manipulation Language.

But then, behind the scenes it turns out that in many databases, the metadata resulting from DDL statements is actually stored in tables (TableSpecs, ColumnsSpecs etc), just like any other data, and could be manipulated just fine using DML, aside from access restrictions. So here we see the data-holding mechanism supporting the structure-defining mechanism -- parallel to the RDF case I think.

So, yes, programming languages and databases all need to define "types" and "instances", not to mention "inheritance", and hence can be bases for comparison in a discussion about RDF. The comparison seems a little more direct from RDF to databases and E-R, IMO.

Ie: there is already a broad base of understanding out there which thinks in terms of data structure and data content as usefully separate activities. An RDF primer, IMO, would benefit from building on that. There is presumably utility from being able to treat structure and content a little more fluidly as in RDF  (if I'm understanding RDF a bit more correctly), so then the RDF primer could explicitly point out that RDF has this feature and cover the topic of what this buys you.

----------------
As a side topic, I think this all clears up the mystery of: "(or some subclass of rdfs:Class)".

To define a new class, the new class must acquire 
a) the general RDF-required structure of a class definition, and 
b) optionally, user-application-oriented specifics of particular other classes.

It can get (a) by rdf:type...Class
It can get (b) by subClassOf...Y

However, once can conceivably *subclass* the Class class, the result being a new class that confer classness on other classes via rdf:type. 

Now, Frank's email implies that this mechanism may no longer be part of the picture so the conversation may be moot.

However, to beat a dying horse, it seems to me that the confusion here is due to the functions of rdf:type and subClassOf overlapping and not being orthogonal.  

If subClassOf really does define a new class that extends the superclass, then we really should be able to use a subclass of Class to rdf:type a new class, though the utility of this escapes me at the moment.

Recap
-----
I think much of this would be settled with a clear discussion of

-- What features does an resource have.

-- What features beyond this does a class resource have

-- What features beyond this does Class have.

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

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

Thanks to the both of you for indulging in this discussion,

Graham



---------------------------------------------------
Graham Wideman
Resources for programmable diagramming at:
http://www.diagramantics.com
graham@wideman-one.com
http://www.wideman-one.com

Received on Tuesday, 20 August 2002 22:40:52 UTC