From: Deborah McGuinness (dlm@ksl.stanford.edu)
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 reasoning.) 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. Deborah 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 > phayes@ai.uwf.edu > http://www.coginst.uwf.edu/~phayes -- ======================= Deborah L. McGuinness Associate Director and Senior Research Scientist Knowledge Systems Laboratory Stanford University Stanford, CA 94305 dlm@ksl.stanford.edu voice 650 723 9770 fax 650 725 5850
This archive was generated by hypermail 2.1.4 : 04/02/02 EST