We'll begin by specifying the buffer contents. Double-click on either of the buffers (Vertebrates or Invertebrates). The window in which you earlier named the buffer should reappear. Like many of the other windows, it has a number of modes which provide different views of the information associated with the buffer. The window corresponding to the Vertebrates buffer (with the Mode menu pulled down) is shown below.
We want to set this buffer up so that it will initially contain the names of a number of vertebrates. These names can then be checked by Classification Rules in order to establish if a given animal is a vertebrate. We add a buffer element by right-clicking in the Initial Contents pane of the buffer's window. The pane will invert (indicating that it is selected) and a menu will appear:
Select Buffer Element from the menu. The window will revert to its former colour (i.e., white), and a further window will appear (this is the buffer element editor):
We create an initial element by entering its details in this editor. Once again, there is space for a comment. In the text field labelled "Buffer element:" type the name of a vertebrate. This name is actually used as data by the execution engine hiding beneath COGENT, and thus must conform to a number of rules of syntax. For present purposes, these rules require that you use only lower case letters (and no spaces). It is also very important (as in any computational work) that you be consistent. Hence, make sure that all buffer elements refer to animals in the same way (e.g., all using singular terms, such as cat and dog, rather than mixing singular and plural, as in cats and dog). You might end up with something like the following:
Click on the Done button and the editor will close. The new element should now appear in the Initial Contents pane of the Vertebrates buffer. Use the same procedure to add a few more animals to the Vertebrates buffer. Also add some to the Invertebrates buffer. You might end up with something like the following bufferful of vertebrates:
Note that when editing, if you right-click between two elements, the area between those elements is highlighted, and the new element is added between the two existing elements. If you right-click on an existing element, you can add the new element either before or after the selected element, depending on which menu option you select. You'll also see a variety of other menu options. These allow you to, for example, edit or delete existing elements.
When you close an element editor, your input is checked for syntax errors. This won't be obvious it you've only used lower case letters in your element names. If you've typed names which do not conform to COGENT's syntax rules, a warning message will appear and COGENT will attempt to correct your input. Of course, if you don't like the correction, you can always re-edit the element and specify an alternate (valid) element.
When you are happy with the specification of the initial contents of the two buffers, close them (using their Done buttons) and open the data source, Test Cases. This window shares many similarities with the buffer windows, but the main pane is labelled Input Data. To specify some input data, right-click in the pane and select Create->Input Data from the menu that appears. Again, an editor window appears, but this window is tailored for specifying the information necessary for data elements within message sources (as opposed to elements in buffers). The editor should initially be empty:
Pull down the Add Element menu by right-clicking on it. In this case you can add an element corresponding to sending a message to a process (by right-clicking on the Process sub-item and then send) or you can add an element that will stop processing (by right-clicking on STOP). The other options (relating to buffers, networks and sinks) are greyed out because, according to our diagram, this data source can only write to the process named Classification Rules.
As an exercise, add a write arrow to the main diagram from Test Cases to one of the buffers. Now go back to the data editor and look at the menu that appears when you right-click on Add Element. You'll notice that the option for buffer is no longer greyed out. The data source can now send messages to the buffer, and the editor knows that this means that buffer messages are now valid outputs from the data source. Go back to the main diagram and delete the arrow from the source to the buffer.
We'll now add a series of messages to Test Cases. Pull down the menu from Add Element and select process->send. The data element editor should now appear as:
When the model is running, this element will cause a message to be sent from Test Cases to Classification Rules. The content of that message is currently unspecified. Type one of the animal names into the text region between send and to. Add a descriptive comment and close the window. The Test Cases window should now look something like:
Once again, add a few more source elements and then close the data source's window
The next step is to specify the contents of Classification Rules. These rules specify how data is processed, and take the form of "triggered productions". The following diagram shows the two rules which we're going to specify for this model.
Both rules are triggered. This means that whenever a message is received by Classification Rules, both rules will be activated. This is what we want because Test Cases will be generating animal names and sending them to Classification Rules. The first rule checks if the animal is a vertebrate (by seeing if it is in the buffer named Vertebrates), and if so sends the message vertebrate to Output. The second rule does the analogous thing for invertebrates.
When a message is received by Classification Rules, it is "matched" with each rule's trigger. Each rule is considered separately (but in parallel).
In the current case, this means that the trigger of the first rule -- which is X -- is equated or unified with the message. Note that X is in upper case. Upper case terms correspond to variables. If the message is spider, X will be unified with spider (i.e., the value of X will be set to spider), and, if spider is in Vertebrates, then the rule's conditions will be satisfied and the message vertebrate will be sent to Output. Of course, spiders are invertebrates, so spider should not be in Vertebrates. However, the second rule, which is evaluated in parallel with the first rule, should handle this case. The trigger of the second rule (also X, but a different instance of X to that used in the first rule, because the rules are considered separately) is similarly unified with the message, and Invertebrates is checked to see if it contains spider. If it does, then the second rule will fire. That is, the message invertebrate will be sent to Output.
In passing, compare the unification of X and spider with the attempted unification of x and spider (where both terms are lower case). In the second case, the terms cannot be unified as both terms have values that are inconsistent with each other. Unification is explained in more detail in a later section.
Let's see how these rules are created and edited. Open Classification Rules (by double-clicking on its box in the main canvas) and open the rule editor by right-clicking on the pane labelled Rules and Condition Definitions and selecting Create->Rule from the menu that appears. The following window should appear:
This is COGENT's rule editor. It is designed to simplify the process of creating and editing rules. As in the case of the other editors, there is space for a one-line description of the rule. Beneath this are two options, for triggered or refracted rules. Our rules are triggered, so the Rule is triggered? check-box should be checked. The refracted property, which for these rules should not be set, is discussed in detail elsewhere. Note that checking the triggered check-box causes the refracted check-box to become unchecked, and the Triggering pattern text field to become active. The triggering pattern can be typed directly into this field. In both rules here, the triggering pattern is just X. More complex triggering patterns will be seen later.
The Conditions panel and the Actions panel allow the specification of the conditions under which the rule should fire (given that it is triggered) and the resulting actions that should be carried out.
In general, the conditions of a rule may be very complex. However, the current rules only require matching elements in a buffer. To specify the conditions for the first rule, right-click on the Add Condition button to pull down a menu of different condition types. Select match -- the top-most condition type -- in order to add a condition that will attempt to match something in a buffer. A template match condition will appear in the conditions panel. Type X (i.e., the variable that is also the trigger) in the initial field, and select Vertebrates from the menu button at the right side of the condition. Note that because there are two buffers readable by Classification Rules, the condition may match against either Vertebrates or Invertebrates.
Actions of rules are just like messages generated by data sources, and they can be created and edited in the same way. To create the send action, select sink->send from the Add Action menu and type vertebrate into the text field between send and to. Note that, as in the case of the data source above, COGENT is able to guess the intended destination of the message. This is because there is only one sink that may receive messages from Classification Rules.
At this stage, the rule editor should appear as in the following diagram:
Close the rule editor (using the Done button) and repeat the above operations for the second rule. In order to cut down on typing similar information, you may like to use the Copy option from the menu within the process' main pane (instead of the Create option). To do this, right-click on the rule you wish to copy (i.e., the first, and in this case only, rule) and select Copy. A copy of the rule will appear in the process' main pane. This can then be edited by right-clicking on the copy of the rule and selecting Edit.
The specification of these two rules completes the initial specification of the model. We are now virtually ready to run the model and see what happens. Before moving on though, there are a couple of other useful points to note: