subclass loops and proper subclasses (was: Re: Draft Minutes 2001-08-24)

>I was already convinced that it should be <= instead of <
>i.e. that we should allow rdfs:subClassOf loops.
>I can also backup that position with running code.

OK, I agree, but just to keep the discussion straight, there are 
actually two distinct (but related) issues here, which I have gotten 
mixed up.

1. Should we understand rdfs:subClassOf to mean *proper* subclass in 
the semantics?
2. Should subClassOf loops be forbidden in the language?

If we say YES on 1 then we must say YES on 2., but if we say NO on 1 
then 2 is an open issue.

The real issue is 2. The only possible answer to 1., I now see all 
too clearly, thanks to Peter Patel-Schneider, is NO, so I propose to 
alter the MT to reflect this. In an ideal world that issue would ever 
have arisen in the first place. So let us (please) agree that NO is 
right on 1., since that arose only from my folly, and focus instead 
on 2.

Pat



>--
>Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
>
>
>
>
>
>pat hayes <phayes@ai.uwf.edu>@w3.org on 2001-08-28 11:54:44 PM
>
>Sent by:  w3c-rdfcore-wg-request@w3.org
>
>
>To:   Brian McBride <bwm@hplb.hpl.hp.com>
>cc:   w3c-rdfcore-wg@w3.org
>Subject:  Re: Draft Minutes 2001-08-24
>
>Brian, could we put this item on the agenda for the next telecon,
>please.  I would like to get this issue settled before we publish the
>model theory, if possible.
>
>---------------
>
>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.) I was to report this feedback to the DAML JC and get their
>reaction, which I did today and here it is, summary first and more
>details later.
>
>Summary
>1. DAML+OIL absolutely requires subclass loops, and cannot operate
>with the current rdfs:subclassof restriction.
>
>2. Therefore, if RDFS retains its current no-loops restriction, the
>only viable option for DAML+OIL would be to remove subClassOf from
>the rdfs namespace and to adopt its own daml:subClassOf with the
>DAML+OIL interpretation.
>
>3. But this would have the unfortunate effect of breaking the only
>remaining substantial link between RDFS and DAML+OIL, which would be
>unfortunate for a number of reasons.
>
>4. Therefore, DAML+OIL respectfully urges the RDFCore WG to
>reconsider the matter more carefully.
>------
>
>Elaborations.
>1. DAML+OIL requires subclass loops because:
>1a. When merging information from several sources, one needs to be
>able to discover during the reasoning process that two classes are
>equal (even when nobody has explicitly said they are). This ability
>is central to the class-heirarchy reasoning that is at the core of
>DAML+OIL.
>1b. In any case there is no effective way to limit the language so
>that such conclusions (that one subclass is identical to another) are
>somehow forbidden.
>1c. It is also not feasible to consider the no-subclass-loops
>restriction a syntactic wellformedness constraint (as it is in Java
>and OO more generally) since to check it requires general inference
>machinery. Since it can't be parse-time checkable in any reasonably
>expressive class-inference language, there is no advantage to
>imposing it as a semantic constraint.
>
>2. If DAML+OIL introduces its own subClassOf, the only relationship
>between daml:subClassOf and rdfs:subClassOf would be that the latter
>entails the former. But this means that RDF/S engines would not be
>able to make any use of DAML subclass information, in effect
>rendering the  DAML class heirarchies invisible to RDFS. (DAML could
>make use of rdfs:subClassOf information, but only by also using other
>information which is not expressible in RDFS, eg that A is *not* a
>subclass of B. ) It would set up a one-way flow of information from
>RDFS into DAML. In practice, one would expect that DAML+OIL usage
>would simply become detached, in practice, from information expressed
>in RDFS, since the class heirarchy is the only nontrivial semantic
>connection between DAML+OIL and RDFS.
>
>3. The development of DAML+OIL was predicated on the assumption that
>the languages would be 'layered' in some sense, so that each layer
>provided more expressive functionality than lower layers. The
>possible option in which DAML+OIL uses a more inclusive notion of
>subclass but RDFS uses a more restictive notion would make this
>'layering' so distant as to be effectively meaningless. Moreover,
>this is not an arbitrary or capricious decision, since almost any
>reasonably expressive extension of RDFS is going to have similar
>properties.
>
>5. As a postscript, the JC offers the following observations.
>
>5a. In general, the ability to say that one class is identical to
>another is valuable, and probably essential when putting together
>information from several different sources. Allowing subclass loops
>is an elegant way to anable the language to say this without
>introducing any new primitives. (This was one of the main motivations
>for the DAML+OIL usage, in fact, but the reasoning seems to apply to
>RDFS with just as much force.)
>
>5b. DAML+OIL inference engines would need to detect subclass loops
>during their normal inference operations, and could (and indeed
>currently often are) be required to flag such loops when detected,
>allowing other engines, or users, to take aappropriate actions if
>required. In other words, don't feel that all is lost if the language
>allows subclass looping.
>
>-----
>
>Pat Hayes
>---------------------------------------------------------------------
>(650)859 6569 w
>(650)494 3973 h (until September)
>phayes@ai.uwf.edu
>http://www.coginst.uwf.edu/~phayes

---------------------------------------------------------------------
(650)859 6569 w
(650)494 3973 h (until September)
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Wednesday, 29 August 2001 19:42:52 UTC