Re: rdfs:class and rdfs:resource

Dieter,

in a sense, a (minimal) axiomatization might have a certain advantage over
the current/previous versions of the RDF/RDFS specs:  it might be easier to
"check" if our intuition of what RDF/RDFS should be (in its intended
function as a "fundament" for the further development of the Semantic Web)
coincides with what it currently "is" (by interpreting the specs).

For example, a small concern might be the following:
(I) We talk about resources
(II) Every resource is the subject of (at least) one statement with rdf:type
as its predicate (being imprecise by using rdf:type as a surrogate for the
resource that is the map of rdf:type in an interpretation)
(III) Now, given such a (triplized) structure of resources/type-relations,
we may want to "capture" the concept "class" by saying that every resources
that is used as an object in a statement with a predicate rdf:type is such a
class.

Ok, I could probably agree to this - now, we can speak of classes (when
talking about our universe of resources/relations) and map this unambigously
to our intial graph (with resources and relation among resources) (requiring
the use of projection).
What we could also immediately introduce is the concept
"resource-which-is-not-a-class".

Now, in RDFS, this is a bit more tricky: what is a class intended to be
(which "idea/notion/concept" does it capture)? ("class": the concept
intended to be represented by rdfs:Class).
-- we again talk about resources
-- Also, every resource is the subject of (at least) one statement with
rdf:type as its predicate (apply the closure rules of the MT)
Ok. Hm, so is the (extensional) class-concept outlined above applicable?
Almost...(RDFS wants to help us ;-) - it seems as if the "name" rdfs:Class"
is intended to be mapped to a resource which captures the concept "class" in
the interpretation of an RDFS closure graph. To explain: every "resource
name" that is mapped to a resource (in the interpretation) that is a class
in the above sense (III), will also occur on subject position in a statement
with rdf:type as a predicate and rdfs:Class as an object.

Ok, fine. But...we can also use such statements to type resources with empty
extension as being classes...what's the point of doing this? In the end,
what intuition/idea/notion is the concept "class" in RDFS intended to
capture? And, more importantly, what would be a "useful" intuition? (or,
even more interesting, do we need a prescribed notion for classes at all?
Couldn't we offer a mechanism (LBase+Syntax?) which would allow the schema
"designer" to capture his intentions "on the fly" (by resorting to the usual
concepts of First Order Predicate Calculus, for example - capturing (III)
above is extremely simple)...ok, this is an old discussion...I just intended
to say that stepping back from the spec and thinking about what should be in
them might be interesting sometimes (I know, the core WG worked very hard on
improving things, but they set out their endeavour with the premise to
evolve...sometimes revolutions ahd their use too ;-)

Sorry if this is too much "off topic".
    All the best,
        Wolfram




----- Original Message ----- 
From: "Dieter Köhler" <dieter.koehler@philo.de>
To: <www-rdf-interest@w3.org>
Sent: Thursday, May 08, 2003 12:07 PM
Subject: RE: rdfs:class and rdfs:resource


>
>
> >Thanks to everyone on attempting to clarify this rdfs:class and
> >rdfs:resource issue. But, either I'm missing something, or these
> >explanations are. Specifically, I need to see a careful description of
the
> >classes and *instances* involved.
>
> Perhaps things get clearer by concentrating on the essential statements
> about rdfs:Resource and rdfs:Class in the [RDF Schema] specification. In
> terms of the calculus specified in [RDF Schema] the following RDF
> statements are true (the numbers in brackets refer to the paragraph in the
> specification):
>
> <rdfs:Resource> <rdf:type> <rdfs:Class> . (2.1)
> <rdfs:Class> <rdf:type> <rdfs:Class> . (2.2)
> <rdfs:Class> <rdfs:subClassOf> <rdfs:Resource> . (2.1)
> <rdfs:Resource> <rdf:type> <rdfs:Resource> . (Because all instances of
> rdfs:Class are instances of rdfs:Resource, and rdfs:Resource is an
instance
> of rdfs:Class (2.1 and 3.4).)
>
> But the following is, as far as I can see, *not* true:
> <rdfs:Resource> <rdfs:subClassOf> <rdfs:Class> .
>
> In other words: There may exist instances of rdfs:Resources which are not
> instances of rdfs:Class.  Or again in other words: Not everything must be
a
> class.
>
> Footnote: I think it is unnecessary to talk *here* about
> meta-languages:  One may or may not on a meta-level require that all
> resources are classes (or in terms of scholastic philosophy: that all
> individuals are concepts).  And the question what comes first, resources
or
> classes, might be interesting if we try to form a hierarchy of different
> calculuses based on each other, but the simple answer for [RDF Schema] is
> that it has no hierarchical structure and should be considered as a
> whole.  Of course one could try to reduce the number of its axioms while
> the possible conclusions remain the same, but because of the
> dissimilarities of rdfs:Resource and rdfs:Class neither can simply be
> reduced to the other.
>
> Dieter Köhler
>
> Institute of Philosophy
> University of Karlsruhe
> Germany
>
>

----- Original Message ----- 
From: "Dieter Köhler" <dieter.koehler@philo.de>
To: <www-rdf-interest@w3.org>
Sent: Thursday, May 08, 2003 12:07 PM
Subject: RE: rdfs:class and rdfs:resource


>
>
> >Thanks to everyone on attempting to clarify this rdfs:class and
> >rdfs:resource issue. But, either I'm missing something, or these
> >explanations are. Specifically, I need to see a careful description of
the
> >classes and *instances* involved.
>
> Perhaps things get clearer by concentrating on the essential statements
> about rdfs:Resource and rdfs:Class in the [RDF Schema] specification. In
> terms of the calculus specified in [RDF Schema] the following RDF
> statements are true (the numbers in brackets refer to the paragraph in the
> specification):
>
> <rdfs:Resource> <rdf:type> <rdfs:Class> . (2.1)
> <rdfs:Class> <rdf:type> <rdfs:Class> . (2.2)
> <rdfs:Class> <rdfs:subClassOf> <rdfs:Resource> . (2.1)
> <rdfs:Resource> <rdf:type> <rdfs:Resource> . (Because all instances of
> rdfs:Class are instances of rdfs:Resource, and rdfs:Resource is an
instance
> of rdfs:Class (2.1 and 3.4).)
>
> But the following is, as far as I can see, *not* true:
> <rdfs:Resource> <rdfs:subClassOf> <rdfs:Class> .
>
> In other words: There may exist instances of rdfs:Resources which are not
> instances of rdfs:Class.  Or again in other words: Not everything must be
a
> class.
>
> Footnote: I think it is unnecessary to talk *here* about
> meta-languages:  One may or may not on a meta-level require that all
> resources are classes (or in terms of scholastic philosophy: that all
> individuals are concepts).  And the question what comes first, resources
or
> classes, might be interesting if we try to form a hierarchy of different
> calculuses based on each other, but the simple answer for [RDF Schema] is
> that it has no hierarchical structure and should be considered as a
> whole.  Of course one could try to reduce the number of its axioms while
> the possible conclusions remain the same, but because of the
> dissimilarities of rdfs:Resource and rdfs:Class neither can simply be
> reduced to the other.
>
> Dieter Köhler
>
> Institute of Philosophy
> University of Karlsruhe
> Germany
>
>

Received on Friday, 9 May 2003 10:36:38 UTC