From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 06/06/01
On June 5, pat hayes writes: > 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.) Pat, I feel a bit embarrassed about always seeming to be advertising FaCT, but surely by using FaCT you would be able to detect inconsistencies in DAML. Or maybe I have not clearly understood what it is you are trying to achieve. The question of discovering the cause of the inconsistencies is a bit more tricky. Some work has been done in this area (Deb's thesis for one thing, and some subsequent work she did with myself and others), but its a long way from being mature. If the reasoner is fast enough you could consider doing some sort of search on the original set of axioms in order to find the smallest inconsistent sets and/or the largest consistent ones - the results could be informative if not definitive. In order to save excessive traffic on this list perhaps you could mail me directly if I can be of any help with this. Regards, Ian > 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 >
This archive was generated by hypermail 2.1.4 : 04/02/02 EST