[RIFRAF] Proposal - new discriminators for RIFRAF

I added Paula[s criteria to the questionnaire,
resolving the following action item:

http://www.w3.org/2005/rules/wg/track/actions/91

Find the updated version at:

http://www.w3.org/2002/09/wbs/38457/RAFQuestionnaire/



Remarks/Open questions:

1. I reordered and reformulated the questions from Paula slightly, where 
I found this in order. Please re-check!


2. I was not sure about this one:

 > 1. Does the language support conditions on variables that occur in
 >    event specifications?
 > 1.1 Yes
 > 1.2 No

The answer of this one obviously depends on
"5. Can variables be used in event specifications (so as to select data
     from events that have occurred)?"
The reason why I was wondering is that some more fine-grained condition 
would be in order here? e.g. Variables may be allowed or not in the 
condition, whether or not they are allowed in event specifications.
... However ,this is in dome sense already covered by questions in 
Section 2.

  In general maybe a pointer is in place that some of the questions 
previous to Section 5. in the questionnaire apply to the condition part.
  It is a bit hard though to formulate this properly...

I suggest to solve this as follows: When not specified other we view the 
terms body and head synonymously with condition and action in ECA rules. 
Thus, I added the following disclaimer in the beginning of section 5:

"The following section contains discriminators which particularly apply 
to Event-Condition-Action Rules. Note that, for such rules, also the 
discriminators of the previous sections may apply where 'action' may be 
viewed synonymously with 'head' and 'condition' may be viewed 
synonymously with 'body'."


3.
 > 2. It is possible to express conditions on the state before/after
 >    the change?
 > 2.1 Just after the change
 > 2.2 Before and after the change

Made this multiple option instead of choice and added a third option:

   Throughout the change (intermediate state constriants)

It might be useful to specify such constraints which state that the 
action only will take place correctly if a general condition holds 
throughout the execution of the action.
  Concretely, I think here of specifying a web service as an action,
which might only work correctly, if a certain condition is fullfilled 
throughout its exectution.


4.
 > Which type of event specification is used in the language? Only needs 
 > to be answered if "expicit" was chosen for question 5.2.2
 >
 >    * Algebraic
 >    * Linear temporal logic
 >    * Event calculus
 >    * Other (Please specify!)

I think it might be useful to add a wiki page which clarifies these 
notions a bit with examples and references!


Opinions please!

axel

Paula-Lavinia Patranjan wrote:
> Hi,
> 
> the analysis of the requirements we moved to RIFRAF during F2F3 and the 
> discriminators of the current RIFRAF
> http://lists.w3.org/Archives/Public/public-rif-wg/2006Jul/0027
> has shown that events and actions, which are needed for production and 
> Event-Condition-Action (ECA) rules, are not covered by the current 
> RIFRAF. This email proposes such discriminators and hopes to start 
> discussion on this for determining the ones that should be added to RIFRAF.
> 
> Regards,
> Paula
> 
> ------------------------------------------------------------------------------------------------------------------- 
> 
> Proposal: Discriminators related to events and actions in reactive rules
> 
> This is a proposal made by REWERSE (Paula-Lavinia Patranjan and Michael 
> Eckert)
> 
> A few comments on the proposal before starting with the discriminators:
> We propose discriminators which are classified into categories (events, 
> actions, conditions, general) but we need to find a suitable place for 
> them in the RIFRAF structure when they are accepted by the group.
> The discriminators are given in the form of questions so as to ease 
> extending the RIFRAF questionnaire.
> We start at a higher, more general level of discriminators and stepwise 
> go into details.
> The focus is here more on ECA rules, it would be good to check whether 
> important issues for production rules are missing here.
> 
> 
> Events
> -------
> 
> 1. Does the language offer support for programming reactive behaviour 
> (automatically react to situations of interest)?
> 1.1 Yes
> 1.2 No
> 
> The following questions are for the case that 1 is answered positively:
> 
> 2. Are the event specifications (which express classes of events to 
> react to) implicit (conditions only on the state of the data, as is the 
> case for production rules) or explicit (conditions on events changing 
> the state, as is the case for ECA rules)?
> 2.1 Implicit
> 2.2 Explicit
> 
> 3. Which is the conflict resolution used for rules (in case that the 
> occurrence of an event triggers more than one rule)?
> 3.1 non-determinstic: all rules fire
> 3.2 non-deterministic: one rule fires
> 3.3 deterministic: priority-based selection of rules
> 3.4 other approach, namely ....
> 
> If 2.2 is chosen for the question 2:
> 
> 4. Does the language support only atomic events or also composite events 
> (combinations of more than one event such as temporal or sequence)?
> 4.1 Only atomic events
> 4.2 Both kinds of events
> 
> 5. Can variables be used in event specifications (so as to select data 
> from events that have occurred)?
> 5.1 Yes
> 5.2 No
> 
> 6. Event specifications can also refer to events that have occurred in 
> the past (i.e. before the event specification has been registered) or 
> are they forward-looking?
> 6.1 Refer also to the past
> 6.2 Just forward-looking
> 
> 7. Does the language support internal and/or external events (i.e. 
> events that occur at remote nodes/entities)?
> 7.1 Just internal events
> 7.2 Internal and external events
> 
> 8. Which is the approach to event consumption used in the language 
> (consumption for a single rule)?
> 8.1 Events are consumed (events are used once in an event specification)
> 8.2 Events are not consumed (same event can be used to match different 
> parts of an event specification)
> 8.3 Different modes are provided for event consumption so as to use the 
> approach suitable for the chosen application
> 
> 
> 9. Which type of event specification is used in the language?
> 9.1 Algebraic
> 9.2 Linear temporal logic
> 9.3 Event calculus
> 9.4 Other approach, namely ...
> 
> 
> Conditions
> ------------
> 
> 1. Does the language support conditions on variables that occur in event 
> specifications?
> 1.1 Yes
> 1.2 No
> 
> 2. It is possible to express conditions on the state before/after the 
> change?
> 2.1 Just after the change
> 2.2 Before and after the change
> 
> 
> Actions
> --------
> 
> 1. Which types of actions are supported (multiple choices possible here)?
> 1.1 updates to data
> 1.2 updates to rule base (e.g activating or deactivating rules. 
> inserting or deleting rules)
> 1.3 raising and sending events
> 1.4 procedural attachements
> 1.5 control of transactions (e.g commit, abort)
> 
> 
> 2. Does the language support internal and/or external actions (e.g 
> raising and sending events to external entities)?
> 2.1 Just internal actions
> 2.2 Internal and external actions
> 
> 
> 3. Does the language support the execution of complex actions  (such as 
> sequences of updates on data) specified in a rule?
> 3.1 Yes
> 3.2 No
> 
> 4. Can variables used in the condition part/condition and event part 
> also be used in the action part of a rule?
> 4.1 Yes
> 4.2 No
> 
> 
> 
> General
> ---------
> 
> 1. Is language coherency one of the design principles followed during 
> the language's development (meaning that same paradigms are used for all 
> components of a rule, same language for all components of a rule)?
> 1.1 Yes (homogenity)
> 1.2 No (heterogenity, e.g. Event part specified in Snoop, Condition part 
> in XQuery, and Action part in XUpdate for an ECA rule)
> 
> 2. Are the different parts of a rule (e.g. Event, Condition, Action 
> parts for a ECA rule) clearly separated (separation of concerns)?
> 2.1 Yes
> 2.2 No
> 
> 
> 
> 
> 
> 
> 


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Monday, 28 August 2006 14:22:49 UTC