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