Re: rdfs:class and rdfs:resource

(Below, I will (indirectly) argue that rdfs:Resource was born first... ;-)

I very much agree with Jon's nice explanation. Sometimes, it is a bit
problematic to resort to explanations with terms that invoke certain
preoccupations. So, please, allow me to give it a different (but
complementary) "abstract" twist:

Assume you have a universe U, consisting of distinguishable entities.

You can also form collections of entities, pairs of entities, and
collections of pairs.

One such collection of pairs is already given, let's call it E

Now, you have the following "axioms":

(1) There exists a member of U, say e, such that (u,e) is a
   member of E for all u that are members of U.

(2)     There exists a member of U, say c, such that (u,c) is a
   member of E for all u for which a member v of U exists such that (v,u) is
a member of E.


Now, if we have found such a universe U and such a collection E of pairs,
which satisfy (1) and (2), we can deduce a bit from the rules:

(a) (e,e) is a member of E  [from (1)]
(b) (e,c) is a member of E  [Because (e,e) is a member of E and therefore,
        e is such an u for which a v (again our e)
        exists with (v,u) is a member of E]
(c) (c,e) is a member of E  [Because C is not empty (see above), hence c
exists,
        and with (1), the claim follows]
(d) (c,c) is a member of E  [from (b) and (2)]

Now, let's give our abstract consideration some more familiar names:
call collection of pairs "relations"
call members of collections "elements"
call the relation E a "Type" relation (our call it "element", to make
you completely nervous ;-)

So, given the structure we have here, consisting of U and E, fullfilling (1)
and (2),
we may want to call it a "typed" Universe

Let's check if we can give it some intuition:
(1) says: every "thing" in U is of "Type" e.
(2) says: every "thing" in U that gives a "thing" in U a "Type" is
 itself of "Type" c.

Ok, let's introduce some more terminological convention:
 For any member u of U, all elements of U that are of "Type" u
 form a collection that we may call the EXTENSION of u.
 [Note that the extension of e is precisely U, e "E-represents" U]

From an extensional point of view, we may want to call something that
has an extension a class (be careful here, if you "identify" the thing
that has an extension with its extension, you will be in big trouble!
(here "identify" is meant in the sense that you can "write" the
extension whereever the thing with the extension is "written" - for example,
try to do it with c = {e,c} ... but note that the above structure is not
paradoxical - ones expectation may trick one into this believe ;-))
So, the above axioms lead us to a distinction among classes and there
extensions - keep this in mind.

Now, you already see that (2) does not contribute a lot...it allows us to
make the property "being a class" explicit (in fact, it does it
"automatically" for all members of U with non-empty extensions, in
addition it allows us to "declare" "classes" with empty extensions (if you
(or me)
should like this, I don't know)). When I say "automatically",
I mean the following: whenever we have found a structure
consitsing of some U and some E (as subset of UxU), that satisfies (1) and
(2),
we KNOW FOR SURE that every "thing" in U (= every "element" of the extension
of e) that has a non-empty extension is also in the extension of c (and,
possibly, some more "things" without extensions (= empty extension)).

[Note for the patient reader: the above paragraph explains, why e was born
before c...you will later see (sorry, of course, you have notived this
already! ;-), that this means "indirectly" that rdfs:Resource (and rdf:type)
(should) have been born before rdfs:Class]

What you also see is that you can easily introduce
further relation/concepts, that are all derivable from E (like range,
domain,
subclass - though, if you do not only want to "describe" them with "logical"
rules (such as (1),(2)), but to make them explicit, you will have the same
problems as above with the property "being a class").

Ok, if you've read to this point, you will certainly have recognized
some of the concepts "behind" RDFS ;-)

Now, if we want to talk about such structures, we may use certain syntactic
constructs which will be mapped to our structure later. RDF/RDFS syntax
gives
us a possible way to talk (I left out the stuff about predicates,
which would make it somewhat more awkward but not substantially different,
but this, of course, limits the analogy): "rdfs:Resource" -> e,
"rdfs:Class" -> c,
E represents the [subject "rdf:type" object]-constructs.

Ok, if you accept (1) and (2) as being useful, (a)-(d) follow as a
logical consequence. This also answers Theresa's questions (at least I hope
so).

Let me summarize: syntactical constructs are "interpreted" (mapped to a
Universe with
relations), in the universe, certain rules have to be fulfilled to make the
interpretation
"meaningful" (a model... ;-), in our case, (1) and (2) have to be fulfilled.
Note, that
(1) and (2) make a distinction among "class representatives" (or classes
above) and
their extension usefull (if we want to speak about our structure and their
properties
on a meta level).

The explanation may also give some incentive to read the Model theory ;-)
If you have further questions or want to make additions, go ahead.

All the best,
 Wolfram







----- Original Message ----- 
From: "Francesco Cannistrà" <fracan@inwind.it>
To: "Jon Hanna" <jon@spin.ie>; "Www-Rdf-Interest" <www-rdf-interest@w3.org>
Sent: Wednesday, May 07, 2003 9:59 PM
Subject: Re: rdfs:class and rdfs:resource

>...

> What is sure is that to define rdfs:Class as an instance of rdfs:Resource
> (that makes presume that the concept of "Resource" is earlier than that
one
> of "Class") and then assert that rdfs:Resource is of type rdfs:Class in
> order to fix the concept of "Resource" is a little bit confusing and
> circular.
> This does not mean that it's a logical paradox.
> But my question is: what resource was born first, rdfs:Resource or
> rdfs:Class ?
>
>

Received on Wednesday, 7 May 2003 17:20:14 UTC