W3C home > Mailing lists > Public > www-webont-wg@w3.org > February 2002

Re: Antwort: Re: Fwd: logics of RDF

From: Ian Horrocks <horrocks@cs.man.ac.uk>
Date: Sun, 3 Feb 2002 22:51:05 +0000
Message-ID: <15453.48857.566490.256419@cs.man.ac.uk>
To: Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>
Cc: www-webont-wg@w3.org
On February 2, Frank van Harmelen writes:
> "Peter F. Patel-Schneider" wrote:
> > 
> > Unfortunately, RDFS has precisely the class that prevents layering,
> > rdfs:Class.  Modifying RDFS to a layered theory might help, but this would
> > be a significant modification of RDFS, as much of the justification for
> > RDFS is precisely that it has classes like rdfs:Class.
> I think your last sentence exactly points at the heart of at least one of our problems with RDF:  
> "much of the justification for RDFS is precisely that it has classes like rdfs:Class."
> I wonder if that is really true. Yes, it is important for RDFS that we can form classes of classes (and this feature is actively), but it is really necessary that rdfs:Class is an instance of >*itself*< (ie breaking the layered theory?)
> I would suggest that most (if not: all) of the usage of rdfs:Class would still work within a layered theory. (This is certainly the case in our own tools and 
> Question: would anyone care to confirm or deny that people do not rely on 
>           rdfs:Class being member of itself
>          (in particular the RDF experts in this group)
> Question: is it really true that this would be all that much of a change to RDF?
>           Syntactically? (My guess is no)
>           Semantically?  (more so, but the model theory is still up for grabs)
> I would suggest that getting RDFS to accept a layered theory would solve many of our problems with building OWL on top of RDFS.

I agree - we even went so far as to design such an architecture
(RDFS(FA)). Moreover, I think the proposal to have some triples tagged
as being "not asserted" more or less amounts to a simple implementation
of the same idea.


> Frank.
>    ----
Received on Sunday, 3 February 2002 17:52:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:26 UTC