RE: Where DAML+OIL deviates from the RDF-Schema spec.

At the last DAML PI meeting, in the demo session, we showed a number of
examples of loops. Our particular interest was in detecting unintentional
loops. They are quite tricky to detect, although very easy to insert by a
simple mistake (inverse dependencies). Tool support is then needed, no
matter whether the language uses loops to define equivalence or not. But, on
the other hand, as Ian points out, DAML has a mechanism for that. And by the
way, just for comparison, UML disallows subclass cycles.

==Mitch



Mieczyslaw M. Kokar
Associate Professor
Department of Electrical and Computer Engineering
Northeastern University
360 Huntington Avenue
Boston, MA 02115,USA
phone: (617) 373-4849
fax: (617) 373-8970
e-mail: kokar@coe.neu.edu
URL: http://www.coe.neu.edu/~kokar


> -----Original Message-----
> From: www-rdf-logic-request@w3.org
> [mailto:www-rdf-logic-request@w3.org]On Behalf Of Ian Horrocks
> Sent: Saturday, March 03, 2001 12:45 PM
> To: Jim Hendler
> Cc: Dan Brickley; Tim Berners-Lee; Frank van Harmelen; Graham Klyne;
> www-rdf-logic@w3.org
> Subject: Re: Where DAML+OIL deviates from the RDF-Schema spec.
>
>
> On March 1, Jim Hendler writes:
> > At 1:37 PM -0500 3/1/01, Dan Brickley wrote:
> > >I agree with [2] and [3], and could live with [1]. My main
> concern w.r.t.
> > >using loops in the class and property hierarchies to indicate
> synonyms is
> > >with end-user comprehensibility and with user interface
> generation. I can
> > >see that there's a _logical_ story to tell about why loops are
> OK; I'm not
> > >so sure there's a modelling and usability story. But then it's
> not up to
> > >the core RDFS system to guarantee that folk can't make goofy modelling
> > >decisions, I guess.
> > >
> > >Dan
> > >
> >
> > I'm with DanB on this one.  I originally proposed that if we wanted
> > to use loops to assert equality, we'd lose the ability to (1)
> > distinguish intentional from unintentional loops, and (2) force
> > developers to understand the logical relationship (which I know from
> > experience ain't always easy). In fact,
> > I was reminded later by one of my former postdocs that this situation
> > has come up in practice in our experience -- we developed some of our
> > KBs for the Parka-DB project using web-scrapers from online
> > taxonomies and thesauri.  We saw a number of cases where loops
> > existed - unintentionally, so we had to write loop breaking code in
> > our systems -- under [1] we'd have trouble distinguishing the
> > accidental from the intentional.
> >
> >   I argued we should have a language construct that was explicit to
> > assert equality.  I was overruled
>
> Err, hang on a minute. Let me quote from daml+oil.daml:
>
> <Property ID="sameClassAs">
>   <rdfs:label>sameClassAs</rdfs:label>
>   <comment>
>     for sameClassAs(X, Y), read X is an equivalent class to Y.
>     cf OIL Equivalent
>   </comment>
>   <rdfs:subPropertyOf rdf:resource="#equivalentTo"/>
>   <rdfs:subPropertyOf
> rdf:resource="http://www.w3.org/2000/01/rdf-schema#subClassOf"/>
>   <rdfs:domain rdf:resource="#Class"/>
>   <rdfs:range rdf:resource="#Class"/>
> </Property>
>
> So we don't want/need to use subClassOf cycles to assert
> equality. However, we have to decide what to do with such cycles when
> they are detected - it is no use just saying that they are "forbidden",
> because by the standard argument they will occur out there on the
> web. The choices are either:
>
> a. barf - declare the ontology to be illegal/broken
>
> b. accept the facts as presented and draw the appropriate conclusions
> (and possibly issue some kind of warning as to the consequences).
>
> I much prefer b. Here are just a few reasons:
>
> 1. There is no semantic justification for declaring such an ontology
> to be broken - we are just guessing that it contains one or more
> errors. This seems to be setting a very dangerous precedent - we could
> declare many other DAML+OIL constructions illegal on the grounds that
> they are often used in error.
>
> 2. It is not, in general, possible to "fix" cyclical ontologies
> automatically as there is no way to know where the cycle should be
> broken. So it is hard to do anything sensible when a cycle is detected
> other than to just reject the ontology.
>
> 3. Given that we have to detect cycles anyway, surely it is much
> better to deal with them and simply warn users that a two or more
> classes have collapsed into a single class.
>
> 4. In DAML+OIL we can easily create ontologies with cycles that
> include implicit subClassOf relations that cannot be detected
> syntactically. Are these kinds of ontology also illegal?
>
> Ian
>
> > on the grounds that having two ways
> > to do the same thing in a language was bad (Dan Connolly) and that
> > DAML+OIL had to have the cycles for their associated logic engine  to
> > handle this stuff (Ian Horrocks/Peter Patel-Schneider) -- as a
> > result, my personal theorem prover was faced with
> >   a. Two equivalent solutions are bad
> >   b. We had to have solution [1]
> > and therefore, using the stuff that will power the semantic web
> > I was forced to conclude
> >   c. We should have [1] and only [1]
> >
> > If someone is willing to remove assumption a or b, I would think we'd
> > end up with something that makes more sense to the logically
> > challenged folks (like me) who really want to use this stuff do to
> > "frame"-like reasoning more than logical inference, or who would make
> > errors that would cause whole chains of subclass relationships to
> > collapse by accident.
> >    cheers
> >   Jim H
> > p.s. Parka-DB: http://www.cs.umd.edu/projects/plus/Parka/parka-db.html
> >
> >
> > At 11:53 PM +0100 2/24/01, Frank van Harmelen wrote:
> > >
> > >[1]
> > >"Warning: The RDF Schema specification demands that the
> > >subclass-relation between classes
> > >must be acyclic. We believe this to be too restrictive, since a
> > >cycle of subclass
> > >relationships provides a useful way to assert equality between
> > >classes. Consequently,
> > >DAML+OIL places no such restriction on the subClassOf relationship
> > >between classes;"
> >
> > Dr. James Hendler		jhendler@darpa.mil
> > Chief Scientist, DARPA/ISO	703-696-2238 (phone)
> > 3701 N. Fairfax Dr.		703-696-2201 (Fax)
> > Arlington, VA 22203		http://www.cs.umd.edu/~hendler
> >
>
>

Received on Saturday, 3 March 2001 14:31:48 UTC