ECAassertion

An ECAassertion has the following structure (the syntax is described in section A.3).

$ x,y/Proposition z/Class
  ON event
  IF condition
  DO action1, action2
  ELSE action3
$

The first line contains the declaration of all variables used in the ECAassertion. The specified classes of the variables (here: Proposition and Class) are only used for compilation of the rule, during the evaluation of the rule it is not tested if the variables are instances of the specified classes. The variables are bound to objects by event, condition or action statements.

Possible events are the insertion (Tell) or deletion (Untell) of attributes (A), instantiation links (In), or specialization links (Isa). For example, if the rule should be executed if an object is inserted as instance of Class, then the event statement is: Tell(In(x,Class)). Furthermore, an event may be a query, e.g. if you specify the event Ask(find_instances[Class/class]) the ECA rule is executed before the evaluation of the query find_instances with the parameter Class. It is possible to use a variable as a placeholder for a parameter.

The event detection algorithm takes only extensional events into account. Events that can be deduced by a rule or a query are not detected. However, the algorithm cares about the predefined Telos axioms, e.g. if an object is declared as an instance of a class, the object is also an instance of the super classes of this class.

The condition is a query to the object base. It can be either a normal literal (A, In or Isa) or a query. For example, if you want to check that the variable x is an instance of Class you can either evaluate the query x in find_instances[Class/class] or evaluate the more simple literal x in Class.

If the condition contains a free variable the actions of the 'DO' block are executed for each result for this variable. If the condition contains only constants or bound variables and can be evaluated to 'TRUE', the 'DO' action block is executed once. Otherwise the 'ELSE' block is executed.

By default, queries are evaluated on the old state of the object base before the transaction started. If you want to take into account new information you have to use the new literal, e.g. use new(In(x,Class)) instead of In(x,Class).

Actions are specified in a comma-separated list. The syntax is similar to that one of events, except that you can also ask queries (Ask) and call PROLOG predicates (CALL). In Tell and Untell actions all variables must be bound. The insertion of an attribute A(x,ml,y) is only done, if there is no attribute of category ml with value y for object x. Then, a new attribute with a system-generated label is created. If an attribute A(x,ml,y) should be deleted, then all attributes of category ml with value y for object x are deleted. In Ask actions, you can have one free variable. In that case, the rest of the action block is executed for each result of this variable.

There exists two builtin-predicates which may be called within a ECArule, other predicates can be defined in a LPI-file (see Counter example below).

CreateIndividual(Prefix,ID):

A new individual object with the given prefix and a system generated suffix is created. The object identifier of the created object is returned in the second argument, which must be therefore a free variable. The prefix must be an existing object name (e.g. the class name) otherwise the ECA rule compiler will report an error.

CreateAttribute(AttrCat,x,y,ID):

This predicate creates a new attribute for object x with value y in the given attribute category (e.g. Employee!salary). The attribute will get a system-generated label. In contrast to the action Tell(A(x,ml,y)) the attribute is also created, if an other attribute with the same value already exists.

Furthermore, there are two simple builtin actions: commit finishes the execution of the current ECArule, and reject aborts the current transaction.