W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2001

Re: subclass loops was: Re: Draft Minutes 2001-08-24

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Wed, 29 Aug 2001 14:12:16 +0100 (BST)
To: Frank Manola <fmanola@mitre.org>
cc: RDFCore Working Group <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.31.0108291405180.11376-100000@mail.ilrt.bris.ac.uk>
On Wed, 29 Aug 2001, Frank Manola wrote:

> As a data point here, an important reason why OO languages typically
> disallow subclass loops is that "subclass" in many (not all) OO
> languages defines a code inheritance relationship between classes, not a
> "subset of" relationship between sets of instances ("class" in many OO
> languages has a different meaning from its usage in DAML+OIL).  If what
> you're defining is (effectively) a dispatch path for invoking method
> code, you don't want cycles in it.  However, in DAML+OIL "subclassOf" is
> really a logical assertion, and cycles, while they might indicate a
> mistaken design, make sense in this context (since they might NOT
> indicate a mistaken design).  I'd be in favor of taking the DAML+OIL
> approach myself, but it seems to me that the immediate and main issue is
> deciding what we think RDFS "classes" ought to mean *for the intended
> purposes of RDF*.  I think that decision ought to be somewhat
> independent from how easily the resulting semantics are implemented in
> Java (or whatever), since I think what we mean ought to govern the code,
> rather than the other way around.

I'd have to support Frank's view (in addition, while 'traditional' OO
languages* may support inheritance of implementation, modern designs
tend to use techniques like delegation to more loosely couple objects
(allowing runtime modification of behaviour)).

I have heard (privately and on RDF IG) complaints from programmers that
RDF's class mechanisms are nonintuitive when viewed from the OO
programming point of view. This might just be due to a clash of
nomenclature leading to odd expectations - the (proposed) RDFS class
mechanisms are much closer to my intuition of classes than, say, C++'s
OO is.

And as Pat pointed out, permitting cycles then creating a specialisation
of the subClassOf property that forbids cycles is a much more natural
way to go than the reverse route. In particular, lemmas that you've
proved about the cyclic version will still be true of the noncyclic one.


jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Scrabble gematria: "BIBLE" = "DOGMA"
Received on Wednesday, 29 August 2001 09:13:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:03 UTC