From: pat hayes (phayes@ai.uwf.edu)
Date: 06/05/01
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
This archive was generated by hypermail 2.1.4 : 04/02/02 EST