From: Steve Ross-Talbot (steve@enigmatec.net)
Date: 01/28/03
On use would be the following financial service monitoring rule. I think this is the same kind of rule as the email rules that Stephan mentioned which we call in RuleML ECA-rules (a class of reaction rule). "If any 3 of the named analysts report a strong buy on the same stock within the same day and before the market closes, then buy 1000 units of that stock". This rule involves three events occurring in any order within 1 day (the temporal condition) such that the same stock is a strong buy (the condition) and results in an action being executed on behalf of the requester (the action). There are rather a lot of rules of this nature based on situation monitoring represented as composite event and condition pairs linked with temporal clauses and finished off with an action. Many of the current BPM/Choreography standards can be modeled using the same technique - although I am dubious as to the benefit of such an approach. Hope to be on the call but might be a little late getting on. Cheers Steve T On Tuesday, January 28, 2003, at 10:14 AM, Stefan Decker wrote: > Dear all, > > the DAML-Joint Committee has been wrestling with the rules for quite > some time. I suggest to aim at the following documents, and try to > have documents > ready within a defined time period. As a start, I suggest the > following documents > and schedules. > > 1) Use cases and requirements (milestone ready mid of march) > What are use cases we want to tackle? > 2) Language features (milestone ready end of April) > Which language features are required by the use cases? > 3) Syntax+Semantics (milestone ready mid of July) > 4) Usage examples (milestone ready end of August) > > Documents creation is interleaved. > > Tasks for the telecon: > - reach agreement on the documents and schedule > - assign editors for the documents > - If time permits, discuss the use cases below, gathered from > previous telecons. > > Best, > > Stefan > > > ----- > > Possible Use Cases > ----------------- > > (Mike Dean) > 1) rewriting/transformation rules, e.g. [1] in [2] > > 2) matching rules, e.g. [3] in [4] > > 3) equivalence rules, e.g. an instance of Employee in one > ontology is daml:equivalentTo an instance of Member in > another ontology if the values of their socialSecurityNumber > or emailAddress properties match. > > 4) computation rules, e.g. a meal is served on all Flights > over 3 hours, dinner is served on all flights departing > between 5-7pm local time, etc. > > 5) class rules with computation, e.g. a Minor is a Person > whose age is less than 18 (where age is computed based on a > birthDate property, presumably requiring some escape > mechanism to specify invocation of procedural code to do > parsing, conversions, and arithmetic) > > 6) trust rules, e.g. trust all statements coming from > http://www.daml.org and http://www.cnn.com (presumably > involves some form of tagging, reification, or contexts) > > > (Jim Hendler) > 7) Computation of Proofs: rules expressed in various documents. A > system that can put the rules together into a proof document (i.e. an > instantiated proof) that could be checked by some other system. > > (Stefan Decker) > 8) Exchange of email rules: I've a lot of email filter rules in > Eudora, and want to switch to another email tools. > All I need is to export the filter rule base into DAML rules and > then import them again. > > > > [1] http://www.daml.org/2001/02/gedcom-ruleml/gedcom-relations.xml > > [2] http://www.daml.org/2001/02/gedcom-ruleml/ > > [3] http://www.daml.org/2001/06/expenses/match.clp > > [4] http://www.daml.org/2001/06/expenses/ > > > > > > > -- > http://www.isi.edu/~stefan >
This archive was generated by hypermail 2.1.4 : 01/28/03 EST