See also: Built-in Conditions
A (rule-based) process is a box whose behaviour is defined in terms of a set or rules. A rule is just a condition/action pair. The conditions of a rule evaluate to true or false. The actions are a list of messages that should be sent to specified destinations if the rule's conditions are true.
In general a process will produce output, either by scanning and acting on information in one or more buffers, or by reacting to an input message (or by a combination of the two). The rules which define a process' behaviour are of two basic sorts: autonomous (or active) rules, and triggered (or passive) rules. Autonomous rules scan the contents of buffers and fire when appropriate conditions are met. Triggered rules fire only when they are triggered by the arrival of an appropriate message. Autonomous and triggered rules may be mixed freely within a single process.
The precise behaviour of processes is determined by the rules they contain and two properties:
Recurrent (possible values: Yes/No; default: No)
Recurrent processes are able to send messages to themselves. By default processes just take in information, process it, and send it on, but recurrent processes are able to feed their output back into themselves. The value of the property can be set by right clicking on the menu button beside the property and selecting the appropriate value.
Firing Rate (possible values: 0.0 -- 1.0; default: 1.0)
This property gives the probability or a process's rules firing when their conditions are satisfied. Normally a rule will fire whenever its conditions hold, but by setting a process's firing rate to (for example) 0.5, we can specify that rules should only fire on half of the occasions that firing is possible.
The rule editor is the most complex part of COGENT, since it permits the user to create rules of arbitrary complexity, using a full-featured programming language based on the logic programming language Prolog. A full description of Prolog is beyond the scope of this manual; however, the rule editor makes the process considerably easier than standard Prolog programming, since it handles much of the syntax checking and provides many functions through a series of pull-down menus, so non-programmers should find it fairly easy to use.
The rule editor is invoked from a process's Rules & Condition Definitions window by either inserting a rule into a process (by right-clicking on the canvas) or by double-clicking on an existing rule (on the canvas). Three boolean options are displayed at the top of the rule editor window. These options control the firing properties of the rule. By default, rules will attempt to fire as many times as they can on each cycle; basically, they fire only if their conditions are satisfied. Each option further constrains the default firing behaviour of the rule:
Rule is triggered
If this box is checked, the rule will not attempt to fire unless it receives a message which matches its Triggering pattern. The Triggering pattern field is only active if the Rule is triggered box is checked, otherwise it is greyed out. If Rule is triggered is not checked, the rule will attempt to fire on each cycle.
Rule is refracted
A refracted rule will fire only once with each pattern of instantiations of its variables during a given trial. Thus, each time it fires, it will produce a new solution. Note, however, that if multiple different solutions are possible, the rule will fire once for each possibility, and moreover, if more than one possibility exists on a given cycle, it will fire as many times as are possible on that cycle.
Rule fires once per cycle
If this option is checked, the rule will fire a maximum of once on any given cycle. If Rule is refracted is also checked, different solutions will always be produced on different cycles.
A special trigger, system_quiescent, is automatically generated by COGENT whenever, during processing, no rules are applicable. Rules can be built that fire only when COGENT reaches quiescence by specifying that such rules are triggered (i.e., by checking the first of the above options) and that their trigger is system_quiescent.
The remainder of the rule editor is concerned with defining the conditions and actions of the rule. New conditions can be added by clicking on the Add condition button, in which case the new condition will be added to the condition list at the bottom. Similarly, new actions can be added by clicking on the Add action button, and again the new action will be added at the bottom of the list of already defined actions.
By default, new conditions will be of the type match, which attempts to match a specified item with an item in an accessible buffer. The list of accessible buffers can be viewed by clicking on the pull-down menu at the right-hand side of the condition; the user must specify the item to be matched in the text field. A pull-down menu at the left-hand side of the condition permits a variety of modifications to the default, such as changing the type of the condition, deleting it, qualifying it or adding a new condition above or below it. The Change type, Add above and Add below options each have a system of submenus which permit a large range of built-in condition types to be selected, including conditions dealing with list processing, term comparison, arithmetic and general prolog. It is possible, therefore, to create compound conditions of arbitrary complexity and power. Note, however, that further conditions are being added to COGENT with each new release, and so your version may offer more options than those listed here.
The Add qualifier option permits control over the precise operation of the condition, for example by negation or quantification. By default, conditions are universally quantified, that is, they will re-satisfy as many times as they can, but they can be forced to satisfy only once in the present invocation of the rule by using the once qualifier. Using the not qualifier makes the compound condition satisfy only if the subcondition is not met. It is possible to add subconditions within the scope of a qualifier, by using the pull-down menu directly to the right of the qualifier. As with top-level conditions, this menu permits adding subconditions above or below, adding (or deleting) further qualifiers, or changing or deleting the subcondition.
Finally, the rule editor permits the user to specify the actions which are to be carried out if the rule's conditions are met. The specification of a rule's actions follows exactly the specification of messages within a data source. This is possible because actions are just message lists.
The condition editor is invoked whenever the user attempts to create or modify a condition. Conditions should only be found within processes, and can be edited by following the general procedure for editing all box elements (i.e., double clicking on the condition, or selecting Edit... from the menu that appears after right-clicking on the condition). New conditions can be created by either copying existing ones (by selecting Copy from the menu that appears after right-clicking on the condition) or by pulling the menu down from Create and selecting Condition Above or Condition Below as appropriate.
Conditions are basically raw Prolog. Some of their more advanced uses, especially those involving recursion, definitely require a reasonable understanding of Prolog. However, it is worth noting that if several rules have the same sequence of subconditions in common, then the process of rule writing can be made easier, and the rules themselves made simpler and clearer, by defining a compound condition separately from the rules and then calling the compound condition in each rule.
The condition editor is designed to simplify the process of writing Prolog conditions by forcing the appropriate structure on those conditions and preventing common syntax errors.
Each condition consists of one or more clauses, and each clause is composed of a head, which is a Prolog structure, with a functor and zero or more arguments, and optionally a body, composed of subconditions. The Functor field in the condition editor allows the user to modify the functor name, and changes here are reflected in all clauses of the condition. Similarly, the number of arguments is controlled by the Arguments widget; changing this value will change the number of argument fields available in the head of each clause.
As well as a head, each clause may have a body, which is composed of subconditions. A pull-down menu at the left of the clause allows the user to add, delete, change or qualify subconditions in a manner already familiar from the Rule Editor, and this menu makes the same built-in conditions available.
Any conditions which the user defines become available for selection through the pull-down condition-editing menus in both the Rule Editor and Condition Editor.