Re: [UCR] Managing Inter-Organizational Business Policies & Practices: Edited Version.

Chris,

We (Donald, Said and I) assume that requirements others have also asked 
for will be supported:

    * Rule-sets
    * Ability to exchange the structure of the meaning of a rule
    * Ability to exchange both the schema and the population in the fact
      base with which rules are specified

The additional requirements needed to support RIF Use Case 1.5 are:

    1  Ability to make the distinctions in rule metadata between:

        * Whether a rule is immediately executable or requires some
          human action before it can be executed
        * Whether a rule that is marked for human action is about
          organization things or IT artefacts

    2  Compatibility with ISO Common Logic (ISO 24707) which has First
    Order Logic semantics and includes the ability to support:

        * The four modal operators: obligation and permission; necessity
          and possibility
        * Restricted Higher Order Predicate Logic (Henkin semantics) in
          abstract syntax
        * Ability to pass through in the rule exchange 'irregular
          expressions' that are not covered by ISO Common Logic

    3. Ability to exchange, along with their formal specification, the
    natural language:

        * Definitions of concepts in the fact base
        * Statements of rules

    4. Metadata for effective start and end date/times for rules

 We would expect that rule specification systems that comply with the 
OMG's "Semantics of Business Vocabulary and Business rules" (SBVR) 
specification would be considered as target systems for RIF.

Regards,

John


Chris Welty wrote:

>
>
> What I would like to do now is focus on the well-articulated 
> requirements you mentioned at the f2f that this use case describes. My 
> main worry about the use case is that it coudl be interpreted as 
> dictacting requirements for RIF that are out of scope. So most of my 
> reservations woudl be alleviated by focusing on the specific 
> requirements (this is something we should now be doing for all the use 
> cases) and then, as with the other use cases, re-evaluating how well 
> the use case itself captures and reflects these requirements.
>
> -Chris
>