Re: A comment on DAML FAQ

From: pat hayes ([email protected])
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
[email protected] 
http://www.coginst.uwf.edu/~phayes


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