[RuleML-all] Re: RE: [Jdrew-all] Questions regarding RuleML status

[Boley, Harold]

Hi Bart and All,

Grouping rules into named or unnamed sets (rulesets, modules, scopes)
has been planned as a RuleML feature for a while. Modules could also be
parameterized as in TRIPLE.
So perhaps there could be cross-fertilization between the development of
your <Policy> element and a general RuleML <Module> notion.

Since some policies can be expressed as derivation rules, it may be
good,
also for policies, to distinguish these from reaction (active) rules.
For a "course of actions" you may even need some workflow/choreography.

Prioritizing RuleML rules may be adaptable to prioritizing
'alternatives'.
For this, RuleML uses 'overrides' facts over rule labels, as in
courteous
logic program. (Your 'alternatives' also remind me of guarded commands.)

Please keep us up-to-date on your interesting work.

Best,
Harold


-----Original Message-----
From: ruleml-all-bounces at ruleml.org
[mailto:ruleml-all-bounces at ruleml.org] On Behalf Of Bart Orriens
Sent: April 7, 2006 2:00 PM
To: ruleml-all at ruleml.org
Subject: [RuleML-all] Re: RE: [Jdrew-all] Questions regarding RuleML
status


Hello Harold, and everybody,

thanks for your reply concerning nested modalities. I agree with the
point you make that a generic syntax is required, as there can
potentially exist a wide variety of modalities depending on the specific
needs. For now i will adopt the style you suggest, and try to figure out
how to actually enforce such modalities during rule application,
consistency
checking, and so on.

On a different matter I have been working on extending RuleML with
policy constructs. Before I detail these constructs let me first put
forth the requirements I identified thus far (also based on analysis of
related works like ws-policy, wspl, legal xml, initial work from policy
ruleml, and so on):

- first there is a need to group rules into logically related sets, as
users tend to think in terms of a collection of rules accomplishing some
action (like a sales policy) than in terms of individual rules.

- one option would be to group rules directly into policies. However, I
think it would be wise to introduce an intermediate construct called
policy alternative (akin to e.g. ws-policy). This allows specification
of different course of actions to handle different scenarios; or the
same scenario but where one course of action is preferred.

- the latter also implies the need to be able to prioritize
alternatives, so it is clear what alternative to apply from a policy. At
this moment I feel static definition using some sort of ranking
attribute suffices, as the number of alternatives within a policy will
be limited; and as such we can enforce that each alternative is uniquely
ranked. 

- to ensure that at least one alternative is always applied (unless the
policy is empty of course), I'm thinking to use a 'default' attribute;
which when set to 'yes' indicates that this alternative is the default
one

- alternatives are then grouped into policies, where they are mutually
exclusive; that is, only one alternative from a policy can be applied
(i.e. only one course of action can be taken).

Following the above I came up with the following syntax:


<Policy>
<plab><Ind>name here</Ind></plab>
<PolicyAlternative default="" rank="">
<palab><Ind>name here</Ind>
<Implies>
<rlab><Ind></Ind></rlab>
</Implies>
<Implies>...</Implies>
</PolicyAlternative>
<PolicyAlternative>...</PolicyAlternative>
</Policy>


In this notation <plab> and <palab> are labels to identify policies and
alternatives. Each <PolicyAlternative> contains one or more <Implies>
statements. These can specify full rules, or perhaps only the name of a
rule; thus enabling reuse of rules across alternatives. Similarly,
alternatives can be reused across policies via their <palabel>.
Interesting in this regard are issues like policy extension, restriction
and so on. However, I have not explored these in depth yet.

I'm interested to hear everyone's thoughts on the above. A generic
policy language in combination with RuleML will, needless to say almost,
provide a powerful tool for policy/rule specification.

Cheers,
Bart

=======================================
Drs. Bart Orriens          
B704, Tilburg University 	
PO Box 90153, 5000 LE Tilburg, 	 
The Netherlands
Phone : +31 13 4662779 
Fax   : +31 13 4663069                 
Email : b.orriens at uvt.nl
Web   : http://infolab.uvt.nl/~borriens   
=======================================
_______________________________________________
RuleML-all mailing list
RuleML-all at ruleml.org
http://mail.ruleml.org/mailman/listinfo/ruleml-all