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

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.

--Frank

pat hayes wrote:

snip
> 
> rdfs:subClassOf loops and consistency with DAML+OIL.
> 
> At the F2F we discussed a number of pieces of feedback from the DAML+OIL 
> JC. The only one that gave rise to any  significant discussion was their 
> recommendation that the M&S be modified to allow subclass loops, ie that 
> combinations such as
> 
> A rdfs:subclassof B
> B rdfs:subclassof A
> 
> not be considered illegal, but be thought of as a way to assert that A 
> and B are the same class.  Two voices were raised against this proposed 
> change. One was the opinion that  disallowing subclass loops was 
> accepted practice in the OO community, the other was that it would be 
> incompatible with Java usage, and that if subclass loops were permitted 
> then Java-based RDFS engines would need to perform expensive 
> loop-detection checks to avoid syntax errors when mapping RDFS to Java. 
> (I hope I have this more or less right, it is based on memory.) 
snip

-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Wednesday, 29 August 2001 08:56:16 UTC