Re: rdfs:Class vs. daml:Class ?

>Please excuse another naive newby question....
>
>In the DAML language definition, it looks like rdfs and rdf are being
>used as the metamodel: daml:Class, for example, is an instance of
>rdfs:Class. But if that is the case, I would expect that the Class
>definitions in a DAML ontology would be instances of daml:Class.
>Instead, the sample ontologies that I've seen use rdfs:Class either
>exclusively or (as far as I can tell) interchangeably with daml:Class.
>
>I understand from the Pan and Horrocks paper at
>http://img.cs.man.ac.uk/jpan/Zhilin/download/Paper/Pan-Horrocks-rdfsfa-2001.pdf
>that there is a layering problem in the RDF/RDF(S) definition that
>prevents a clean division between successive metamodel levels. Is the
>relationship between rdfs:Class and daml:Class somehow connected to
>this?

Your message made me take a closer look at this paper, and I have to 
say that it seems to be filled with an astonishing number of 
mistakes, assertions made with no supporting evidence, and what are 
essentially aesthetic opinions stated as though they were facts. I 
will list a few here.

1. Some elements in RDFS have 'dual roles'.
2. rdfs:Class is used to define concepts.
3. RDFS properties are regarded as sets of binary relationships.
4. rdf:type is regarded as a special predefined property, different 
from other properties.
5. rdf:type does not have an rdfs:domain.
6. RDFS uses some modelling primitives to define other modelling primitives.
7. The RFDS specification is very difficult to read and formalize.
8. It is confusing that modelling primitives and user-defined 
ontology terms are defined similarly. (Speaking for myself, it would 
be very confusing if they were defined differently, since they are 
logically indistinguishable: Pan and Horrocks provide no basis for 
this "modelling/user-defined" distinction, which they seem to think 
is accepted by everyone without question.)
9. The reason that people make a certain 'layer mistake' when writing 
DAML is because RDFS doesn't incorporate the DAML restrictions on 
class membership, and this is 'not appropriate' (section 2.3). (Pan 
and Horrocks do not actually define the 'layer mistake' precisely, 
but it seems to be the misapplication of a DAML property to a 
predefined DAML term, which is illegal according to the DAML rules of 
formation. This seems to me to be entirely a DAML matter, having 
nothing to do with RDFS. As the authors point out, the 'mistake' is 
in fact a true assertion, which is probably why people tend to write 
it. The problem here, if there is one, seems to me to lie with DAML 
rather than with RDFS: why would a language be defined so that 
simple, obviously true, assertions - such as that daml:maxCardinality 
satisfies the property daml:UniqueProperty - are considered 
ill-formed?)
10. RDFS has an unclear semantics.
11. This is why Brickley and Guha didn't give it one (section 2.3)
12. RDFS relies on DAML+OIL to give semantics to its modelling primitives.
13. RDFS is not yet a 'fully qualified' schema layer SW language.
14. RDFS has a non-fixed metamodelling architecture. (This may be 
true, for all I know.  Pan and Horrocks do not define this 
fixed/non-fixed distinction anywhere, although much of their 
discussion seems to depend on it.)
15. the fact that rdfs:Class can be an instance of itself is a "problem"
16. This problem is vaguely Russell-paradoxical. (Pan and Horrocks do 
not actually say where they think a paradox arises, however. I think 
this feeling - for it is nothing more than that - arises from a 
failure to grasp some of the basic issues in foundations of set 
theory. The Russell paradox arises when *open sentences* are assumed 
to *always* define corresponding sets, as in the phrase  "the set of 
all things such that .. ". That is called the general comprehension 
principle, and is definitely a bad idea. The axiom of foundation is 
another matter altogether, one arising from a certain constructivist 
view of sets, where one starts with individuals and imagines layers 
of sets, sets of sets, sets of sets of sets, etc. . built up from 
those; and then insists that all sets *must* be built up in this way. 
That certainly avoids the Russel paradox, but rather in the way that 
living a coal-mine avoids sunburn. RDFS does not make this 'layered' 
assumption; but I would guess that Pan and Horrocks do, and find it 
unsettling and 'inappropriate' that other possibilities are allowed 
to exist.)
17. The fact that rdfs:subClassOf is used to make assertions about 
both the RDFS vocabulary and other ontology vocabularies "makes the 
semantics unclear and makes it very difficult to formalize RDFS".
18. RDFS has no clear semantics.
19. RDFS has infinite layers of classes. (The truth of this is 
debateable. RDFS does not enforce well-foundedness, hence allowing 
loops of class membership. If one insists on thinking of class 
membership in terms of 'layers', the only way to describe this 
freedom is to say that there can be infinitely many 'layers'. 
However, it is also possible to simply abandon the 'layer' metaphor 
altogether, and the syntactic flexibility of RDFS has a precise 
semantics based on non-well-founded set theory, formalized (and 
proved consistent relative to ZFS) by Peter Aczel about 15 years ago.
RDFS does not itself mandate the existence of infinitely many layers 
of anything. To illustrate: suppose a class S is a member of itself. 
That is a single finite assertion about a single object; but if you 
insist on 'unwrapping' it to find out how many 'layers' it has, you 
will be in a nonterminating loop, and may get the impression that 
there are infinitely many of them. Also, to emphasize: RDFS *allows* 
this kind of looping, but it does not *require* it. It is quite 
consistent to have a class in RDFS all of whose members are tidily 
'layered', as DAML illustrates.  RDFS is just open-minded on the 
issue, is all. )
20. The reason why 19 is true is that rdfs:Class is used to define 
infinite layers of classes. (This is just backwards.)
21. The fact that rdfs:Resource is both an instance and a superclass 
of rdfs:Class is a "problem".
22. Point 21 illustrates that we need two distinct notions of 'class' 
. (This is a matter of mathematical style rather than fact, but it 
seems to me that there is no intuitive or formal justification for 
having more than one notion of class membership. All of mathematics 
manages to get by with only one, so surely it should be enough for us 
too.)
23. Being similar to UML is synonymous with being easy to understand.

I could go on, but that is probably enough. It seems clear that Pan 
and Horrocks think that UML is just dandy, is 'almost global' in its 
use, and has the clearest semantics possible, and that all web 
languages should be based on it. That is a coherent opinion, and I 
respect their right to hold it; but they should not confuse that 
opinion with fact. I myself find UML over-elaborate, confused, 
confusing and awkward, and think that its semantics has all the kerb 
appeal of a Renault 2CV; but that is just my opinion.

BTW, although it is impossible to read the model-theory equations in 
the paper (many of the characters seem to be missing), I can guess 
what they are; and if my guesses are correct, the reverse mapping 
from RDFS(FA) to RDFS which is gotten by simply ignoring all the 
various prefix distinctions that Pan and Horrocks have burdened the 
language with, is truth-preserving. So (if my guesses are right) then 
as matter of fact, RDFS(FA) essentially *is* legal RDFS, transcribed 
into a new namespace, with the very same meaning. All they have done 
is impose a 'layered' syntax onto RDFS, thereby defining a subset of 
the language, presumably because they find layered syntaxes more 
reassuring. Fine: the RDFS model theory has been designed to be 
accommodating in this way. If you impose syntactic restrictions on 
the language, the RDFS MT will adapt to them smoothly, preserving the 
meanings of the expressions that you want to restrict yourself to. 
That is exactly what a 'base layer' language  should be like: as 
flexible as possible, placing as few restrictions as possible on 
higher layers, but providing a single notion of common meaning which 
accommodates to any 'higher' constraints imposed by other layers. It 
is a kind of semantic mud. If you want to build a wall with it, you 
first have to bake your own bricks.

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 Thursday, 4 April 2002 12:24:32 UTC