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,

None. The distinction is meaningless. Everything is an 'instance' and 
anything can be a class.

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

Well, of course. For example, everything in the universe is in the 
class rdfs:Resource

>  which means that it acquires from that class certain features and 
>requirements

No, it doesnt mean anything like that. It just means that it is in the class.

>  (which are...?).
>
>a) If a resource is merely an instance

All resources are instances, so 'merely' is inappropriate here. 
Classes are instances, for example. (They are all in rdfs:Class).

>then its likely use is probably just as a holder of "data", 
>generally data meaningful to the user's application.

No, that would be a misapprehension. RDFS talks about resources, 
which can be anything. There is no supposition that resources have 
any particular use. The data encoded in RDFS is in the assertions 
(triples) themselves; the resource identifiers are merely opaque 
identifiers.

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

No. Classes need not have definitions; all that is known about a 
class is what can be inferred from the assertions involving the class 
name.

>From a user application point of view, this would be meta-data, ie: 
>it defines application data *structure* as opposed to recording 
>application *data*.

RDFS could be used that way, but its not required or enforced; and 
the let-it-all-hang-out freedom of RDFS to be non-heirachical 
(allowing classes to contain classes and properties, for example) 
tends to push in a rather different direction.

>2. For a resource which is a *class* (ie: rdf:type...Class):
>
>a) The resource can optionally have one or more subClassOf tag(s),

No, subclasses are not tags. The fact that A is a subclass of B is 
encoded in an RDF graph by making assertions about A and B (eg that A 
rdfs;subClassOf B).

>which adds features [which are...?] to this resource from the specified class.

Resources don't have 'features' (well, maybe they do, but that has 
nothing to do with RDFS.) Classes do not add features, in any case. A 
class is just a collection, a set; it isnt something associated with 
a piece of code or a definition, or used to 'pass down' a constraint 
of some kind to its members. Its just a set of things. If I say that 
Pat is in the class of Humans, all Im saying is that fact; there 
aren't any human-type things to get inherited from the class to its 
members. All that I 'inherit' is the fact that Im human.

>b) This resource becomes a legitimate value that other resources can 
>use in a subClassOf tag,

It doesnt 'become' anything. Any resource can be asserted to be a 
subClassOf relation to a class.

>  by which they acquire features  [which are...?] as in (2a).

Nothing gets acquired in RDFS.

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

Indeed there is no such distinction in RDF. In fact this entire topic 
seems to have nothing whatever to do with RDF.

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

??Such as?? RDFS's view of classes is the one used throughout 
elementary set theory, most of mathematics, Venn diagrams, 
classification heirarchies, descriptive logic and relational data 
bases.

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

Right, RDF is very like a simple database language and can be 
processed using database technology.

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

Right.

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

?? They seem quite distinct. rdf:type is membership in a set, 
subClassOf is subset of a set.

>
>If subClassOf really does define a new class that extends the superclass

Its a subclass of it, not an extension.

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

See my message to Frank for some examples.

>
>Recap
>-----
>I think much of this would be settled with a clear discussion of
>
>-- What features does an resource have.

None whatever. The term 'resource' in RDF is just a fancy name for 
'entity' or 'thing'.

>
>-- What features beyond this does a class resource have

Members.

>
>-- What features beyond this does Class have.

rdfs:Class is the class of all classes.

>
>-- What features does rdf:type transmit from one resource to another

None, in general.

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

None. Well, apart from being a subclass, that is. Which just means 
the same as subset, ie all the members of the subclass are also in 
the superclass.

Pat Hayes
-- 
---------------------------------------------------------------------
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 Sunday, 25 August 2002 22:42:50 UTC