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

[Bart Orriens]

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   
=======================================