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

Ian Horrocks <horrocks@cs.man.ac.uk>:
>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).

There is a third way. Imagine an engine which is designed to be 
suspicious of cycles (and maybe a bunch of other valid-but-odd 
constructs) and goes looking for them. It draws no conclusions (other 
than private ones it might need to find the oddities), so it doesn't 
come to any harm, and it doesnt barf; but it does cough discreetly 
and draw its owner's attention to the mess in the corner that might 
need cleaning up. There is nothing in the DAML spec which prevents 
such a thing being constructed, and it might even be found useful by 
people who are trying to merge realistic DAML ontologies. Just 
because a DAML inference is valid doesnt mean that every DAML engine 
*has* to draw that conclusion, only that the semantics warrants that 
conclusion if it does decide to draw it; but an engine might be 
conservative about cycles and still be DAML-compliant.

Pat

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 5 March 2001 13:47:59 UTC