Re: A comment on DAML FAQ

From: Deborah McGuinness (
Date: 06/06/01

Thanks for the complement.
The tutorials really came out of self preservation  - trying not to get
so many questions on use.  I figure FAQs are just a way to protect the
guru's time....

on detecting the inconsistencies
There would be expected to be many daml reasoners that could detect the
inconsistencies depending upon the exact way you model the info.  As Ian
points out, FACT could detect them.  Even an incomplete reasoner would be
likely to get the issue you are looking to find.  Even Ontolingua
(without its associated theorem prover) would find the inconsistency you
mention for the disjoint partition.  (Ontolingua does some simple checks
while it relies on the theorem prover to do the more extensive
Chimaera in its diagnostic mode would also detect the inconsistency as
well even though chimaera is far from a complete reasoner.

On using a daml reasoner to find inconsistencies, I think this is a good
use, and in fact one that at least some of us would have intended.  Jim
has consistently said that we should not expect all daml reasoners to be
complete   thus one should not expect all daml reasoners to find all
logical inconsistencies.  However one could choose a complete daml
reasoner  to solve the problem if completeness is required.  Also, if one
could be satisfied finding SOME of the inconsistencies, I would expect a
lot of reasoners to be able to find things that are say instances of two
disjoint partitions.

On finding the source of the problem...  yes this is definitely something
near and dear to my heart.  Not a simple issue and as Ian also has
pointed out, although some of my thesis was implemented in CLASSIC and
although some followon work has gone on for other styles of description
logics, we can not claim it is really ready for mass usage.  I think the
foundation is there however.  We also have a similar approach embedded in
our reasoning systems at Stanford for explaining deductions.

I think this is one place that we will see daml reasoners being pushed.
This would also go along the lines of the proof direction that tim and
dan are interested in.
I think however we are going to see a massive need for pruning in order
to have an implemented system that "normal" people can use.  We clearly
can not provide "traces" of the deductions and finding the level of
abstraction and pruning appropriate for an answer is part of the art of
the solution.
I had some framework for declaratively specifying both which helped in
our configuration applications at AT&T.

I am also happy to followup on these issues in a smaller discussion group
if that is desired.
I think this discussion may take a few rounds of interaction.


pat hayes wrote:

> Deb, you write great tutorials. Maybe you (or anyone) can tell me how
> to deal with the following issues/questions that have come up in
> local attempts to use DAML.
> The context is an ontology for checking agent policies, which we are
> mapping into DAML by the classes of 'events' which they classify as
> obligated (required) and as forbidden (complement of permitted).
> (Never mind exactly what an event is, that gets rather complicated.)
> Several policies can be combined into one,  basically by taking the
> unions of their restrictions on these two classes. The aim of the
> game is to detect 'policy clashes' which, it turns out, are signalled
> by one of three conditions when the conditions from more than one
> policy are combined into a single policy): either something is both
> obligated and not obligated, or it is both forbidden and not
> forbidden; or it is both forbidden and obligated. All of these are
> 'impossible' intersections of classes that have no intersections, the
> way we had set things up, and so they all appear as DAML
> inconsistencies. But now, we need to not just detect the
> inconsistencies (what kind of DAML engine would detect them?) but
> also know what particular attempt to do some impossible intersecting
> produced the inconsistency. (What kind of DAML engine would tell us
> that?)
> All eyes turned to me, the resident DAML, er, guru, and I had to say
> that I have absolutely no idea. That seems almost to be a meta-DAML
> question rather than a DAML question. So after some quick thinking,
> we decided to weaken the specs so that for example the 'forbidden'
> and 'permitted' classes were not defined to be complimentary, but
> merely disjoint; to detect the case when their mutual complement
> becomes non-empty, then use non-DAML machinery to trace back from the
> things we find in the 'illegal' complement to the policies that gave
> rise to them.  Our hackers will probably be able to make this work,
> but I have to report a feeling of having let the side down. The
> actual role of DAML in this system is shrinking all the time, largely
> because we can't (ie don't know how to) actually USE it to DO
> anything. All it is doing is simple inheritance (and even there its
> inability to handle defaults is a major liability, largely because
> the intended domains of application are rich in default phenomena;
> but that is another issue.)
> Maybe we are simply trying to use DAML for a purpose for which it was
> not really intended? (For example, as you can see, we were thinking
> of inconsistency detection as a kind of event, like establishing a
> Prolog goal. Maybe this is too much of programming-in-logic way of
> thinking for a class language??)
> Or using it too naively? (At one point I thought of having an
> ontology of policies and actions, rather than an ontology of actions,
> so that we could explicitly ask whether a policy was in the
> clashing-policy class; but the relationships between the policies as
> entities and the classes they require/forbid seemed to be too hairy
> to contemplate, and to talk of clashes explicitly required things
> like lists of policies being policies, and we found ourselves
> inventing data structures, and the hackers all agreed they would
> rather use Java, or in fact just about anything, rather than DAML.)
> Any help/advice would be appreciated. No details, just a general
> sense of whether I am going up a dead-end here, or missing something
> fundamental.
> Pat
> ---------------------------------------------------------------------
> IHMC                                    (850)434 8903   home
> 40 South Alcaniz St.                    (850)202 4416   office
> Pensacola,  FL 32501                    (850)202 4440   fax

Deborah L. McGuinness
Associate Director and Senior Research Scientist
Knowledge Systems Laboratory
Stanford University
Stanford, CA 94305
voice  650 723 9770
fax 650 725 5850

This archive was generated by hypermail 2.1.4 : 04/02/02 EST