Another class of domain policy assertion anomalies, and a reservation about Dave Orchard's call for use cases.

So far it may seem that anomalies of the "Absence is
Nonapplicability/Negation" [AIN] principle is tied to mutually exclusive
policy assertions, empty policy assertions, or perhaps intersections
involving policies with different policy vocabularies.


However, there are lots of other logical relations among policy
assertions that can cause problems when combined with current
definitions of vocabularies and AIN.


Policy assertions may form a range from logically stronger to logically
weaker. That is, there may be a policy A that is the strongest policy.
And any number of weaker policy assertions B through N that are implied
by A. In some cases, implication may linearly order the assertions or
more general partial orders (dags) or tree orders may exist. 


But just imagine that there is a policy A that implies a weaker policy
assertion B. An example might be a policy
IntegrityCheckSOAPBodySHA224OrGreater and IntegrityCheckSOAPBodySHA512.
The stronger policy involves SHA512 and implies the less strong one let
us suppose.


It would be natural for a very accommodating service to provide a policy
that would permit any of the assertions in a policy range. 


<wsp:Policy xmlns:i=""




            <i:IntegrityCheckSOAPBodySHA224OrGreater/> <!-B -->



            <i:IntegrityCheckSOAPBodySHA512/> <!-A -->






Unfortunately given the AIN principle, the second policy alternative has
a model world (over policy alternative vocabulary set { A, B} ) of


{A, -B}


But A implies B. So the model (negation complete world over vocabulary)
is inconsistent because both B and -B are implied by it.


We can continue to try to patch up vocabulary definitions to restrict
applicability of AIN. But I think that in many cases where domain
authors want semantic relations among their policy assertions, the AIN
principle is more likely to produce anomalies than it is to be domain


Finally, I want to consider Dave Orchard's point which tries to work
from some principles for deciding what belongs in a framework and what
can be omitted. I think this is a good idea overall. But I don't think
Dave Orchard's call for use cases in itself will show that AIN belongs
in the framework. Undoubtedly there will be some cases where it doesn't
lead to trouble. 


However, it is more appropriate that a framework principle be generally
useful and not just useful for a certain case.  To be sure, a principle
might still deserve to be part of the framework, and have some anomalies
for bizarre logical situations. But I don't think the anomolies so far
are edge cases. Certainly, domains where policy assertions form a range
from stronger to weaker, or a policy domain where there are mutually
exclusive policy assertions are common kinds of semantic constraints in


The AIN principle is a close cousin of the closed world assumption that
was once of interest in computer science inference models.


It turns out we use a closed world assumption in relatively few kinds of
problem solving situations. A good example is reading a train schedule,
where we assume that there are no trains at unlisted times. Yet as the
academic records willl show though a bit abstractly, freight trains are
not listed on the schedule; so, using a train schedule to decide when to
cross the tracks could lead to some nasty surprises.


[1] Do a search starting with keywords like "circumscription" or
"non-monotonic" to get started. This is not recommended reading btw, but
just if you are curious and think we have encountered something new
whose solution will be simple.

Received on Wednesday, 25 April 2007 21:42:09 UTC