The main control screen is where panels appear. These are of the traditional point-and-click GUI requester type, though most act more like multi-threaded windows such that other panels and also the main easel can still receive user actions while they are up. Some act as requesters, in that only they can receive actions.
The parking position of the control screen is where it returns to in order that you can see the main easel. Normally this will be somewhere down the bottom of the viewing area, but you can set it by dragging the screen to a new position using the thin two-pixel screen line and then hitting the funny P gadget.
There is usually one main easel per knowledge base so that if you have two knowledge bases loaded then two main easels are active. In principle a knowledge base can have several easels, but at present no program does so.
As far as the operating system is concerned, the main easel is an Amiga screen in its own right, with screen bar and 'front-behind' gadget in top right corner. It has one window, which is borderless and backdrop, and it is this that detects user activity and generates the IDCMP messsages.
As far as IRKit is concerned (or, rather, User Action Kit) the main easel is operated by one module and owned by either the same module or another. In Istar it is operated by BA module on behalf of its owner, KT, while in Annotator it is operated by DW module on behalf of Ann.
To resize a box, move mouse to over box edge and then press Right-shift and move the mouse. Or else, go into box info (Right-click over box) and enter size manually by figures (pixels).
A boxgroup normally expresses an item and each box in the group normally expresses an attribute of the item. However, in many boxgroups the topmost box expresses the item itself; by this means you can create relationships among the items. Some boxgroups consist of single boxes only. In most such cases, these express free attributes.
You create a new box(group) (and its item) by pressing the LMB onto the easel, dragging to the correct position, and releasing. You can move the boxgroup by pressing the LMB in the middle of one of its boxes and dragging. You can resize a boxgroup as a whole by holding the Right Shift key down as you drag the edge or corner of the boxgroup.
The type of box is indicated by colours, line pattern and size and shape. This can be set for the item or attribute type and also varied for the individual instance.
Boxes on their own (single box in boxgroup) can express either items with no attributes, or free attributes. If they cannot be distinguished by colour, shape, etc., they can be distinguished by clicking on them to see what panel comes up.
Clicking on various boxes (not boxgroups) in Istar gives different actions and according to whether you click with left or right mouse button:
| Semantic Object | LMB Click | RMB Click |
| Item Attribute | Attribute Action Panel | Attribute Details Panel |
| Free Attribute | Attribute Action Panel | Attribute Details Panel |
| Item: Most types | (nothing) | Item Details Panel |
| Item: Text Fragment | Text Panel | Item Details Panel |
| Item: Document | Lays out document on own screen/window | Item Details Panel |
| Item: Form | Override Form | Item Details Panel |
| Relationship | (nothing) | Relationship Details Panel |
Links have no direction arrowheads on them; they normally flow left-to-right by convention, and leave a box by a target point one quarter of the way in from the right, and arrive at a box by a target one quarter of the way in from the left. (If you cannot see clearly which target a link leaves a box by, then move the box around a little, and you will see all its links following it.)
You draw an arrow by pressing LMB over the right or left edge of a box, and dragging the resultant line until it reaches another box. You can insert bends as you draw by hitting the space bar. You can bend an existing link by simply pulling it with the mouse, LMB. You can move a bend by pulling the bend vertex with the mouse, LMB. You can redirect a link from one box to another by holding down the Left Shift and pulling the end of the link over to the new box.
Clicking on a relationship link with RMB brings up its details; see Click Table.
Each item has (can have) a name and meaning. The meaning is a kind of long name, or what is often placed in a comment in a programming language. This allows the precise meaning of the item to be held in the KB and made immediately available, and readily changed as different shades of meaning occur to the knowledge engineer.
Items have a defined type.
There are two classes of item: normal items which represent something in your domain and which have properties held as attributes, and free attribute items whose purpose is merely to support a single attribute.
The KB Panel has a list of item types from which to choose to draw. You create a new item by drawing a box on the easel. Normally free attribute items types are indicated by 'Free' in their name.
Details of each item can be found on the Item Details Panel, on which you can alter the item from normal to free attribute item and back again. With this panel you can alter the attributes of the item, renaming them, recolouring them, removing them, rearranging them and creating new ones.
It is a feature of the IRKit system that you can add new attributes at any time to any item, without having to add them to the item type first. In this way you can add extra information about individual items that pertain only to it and not to all items of its type.
The naming mechanism allows both synonyms and homonyms, though in practice there is no gadget by which you can create a synonym at present.
Names
Anything can be named, individually, though for some things like relationships it makes little sense to name them. (If you wish to name a relationship then hit the 'Treat as Item' button.)
Attributes
Attributes are holders of values. They are often used to represent salient properties of items, but can be free attributes. Each attribute is expressed by a box on the easel, which normally has a label and may give some graphic expression of the attribute's value.
When an attribute is used to hold a property of an item its box is normally held in a boxgroup with those of other attributes. In this case the attribute is in some way subservient to the item, and is equivalent to the attribute in a tuple in a relational database, or to the 'A' part of the OAV triple (object-attribute-value). In some senses such attributes can be seen as a kind of relationship between an item and a value, but in IRKit and Istar they have a much richer structure than this would imply.
Attributes have a domain (or attribute type). This is often little different from a value type but usually implies some domain semantics and constraints. For instance, the Enumeration value type (a member of a set) can be used for weekdays, in which there are seven possible value, or months, in which case there are twelve. It is permissible to change the type (domain) of an attribute, and Istar will attempt to make a reasonable conversion of its value from one type to the other (e.g. an integer 57 will be converted to the string "57"). Sometimes, of course, conversion is not possible. In any case you should check the value after changing the type.
As with items attributes can have names and meanings.
Attributes can have their values derived in a number of ways, the most common ones being:
Attributes normally hold two values, their main one and an override value. The latter allows temporarily changing the value for the purposes of for example what-iffing or fixing.
These and other details of attributes are examined and altered via the Attribute Details Panel.
Unlike much other software, attributes can be treated as items and thus have relationships with other attributes, and even with other items. The main types of relationship between attributes is that of inference, by which an attribute has its value calculated automatically from the values of other attributes. Other relationship types that attributes have include inclusion in a Form Item.
ANSWERED and KNOWN
ANSWERED or not. When ANSWERED they hold a value, when not, they are empty. ANSWERED is different from KNOWN. KNOWN refers to when the attribute has a value, but that value is not known. The difference is illustrated by attempting to fill the attribute HouseNumber with a value by asking the question "What is the number of your friend's house?", to which the reply might be:
ANSWERED and KNOWN,
ANSWERED but not KNOWN, and
ANSWERED, and if you *must* assign a value to it, it will be not (yet) KNOWN.
Concatenate rather than add. A full list of inference methods is available.
To override an attribute, you must:
(There are also other ways of overriding, but that is the official way.)
Note that once an attribute value has been overridden it is not reset by a 'Reset' button; you must de-override it manually. This might be changed in future, to allow some degree of automatic resetting.
Istar makes much use of free attributes for its inference net.
Free attribute items are defined internally has having exactly one attribute and not being expressed by a box of their own.
While attributes have persistence values on their own do not. e.g. HouseNumber is an attribute, but 'seven' is a numeric value. It only persists once it has been placed into an attribute. Attributes can be ANSWERED but values are KNOWN.
Whereas new attribute types can be created, the range of value types is fixed.
You can alter an item type via the Item Type Panel, which is accessed by hitting the 'See' button on the KB Panel Item Type List. You can create a new item type by hitting the 'New' button. You can get rid of an item type by hitting the 'Rid' button - but beware: this will also get rid of all its instances (individual items), though you do get a warning of this.
Each item type can have two standard relationship types, one when drawing relationships from the left edge of itemboxes of this type, and one when drawing from right. This makes it easier when drawing relationships since the user does not have to take trouble to alter the relationship type.
Thus a domain (or attribute type) comprises a name and meaning, a value type, possibly some constraint on permissible values, and possibly a set of names on the permitted values. At present, the only constraint in a domain that is not inherent in the value type itself is that used in enumerated and ordinal types, in which an integer is used to identify members of a set such as weekdays. Each such value is given a value name such as 'Monday'. In addition, each domain in Istar also has details of the attribute box that would express each attribute of this domain.
Attribute types can be examined and altered via the Attribute Type Panel, in which each of these details can be altered.
The intention is that such things as colours, pictures, sound samples and even animations can be treated as values, each with their defined semantics or combination, conversion and comparison.
Most relationships are directional, having an antecedent (or source) and a consequent (or destination). For instance, in "Andy hit Connie" Andy is the antecedent of the 'hit' relationship, and Connie is the consequent. In Istar, Annotator and other programs based on IRKit, all relationships have inverses automatically, so that if you draw in a 'hit' link between items Andy and Connie then you automatically get the two half-links "Andy hit Connie" and "Connie was-hit-by Andy". In a lot of other software you would have to create both links individually - and maintain both too.
To draw a relationship, press the LMB over the left or right edge of a box that expresses an item or an attribute, and drag the moving line over to another box, and release LMB. Then a relationship is created in the background that is expressed by this line. The type of relationship created is defined by the standard relationship types that the item type has.
Lists are ordered sets of things in the knowledge base, and you can use them for various purposes, and in future even more purposes. They are created via the Lists Panel , which is brought up when you hit the Lists button on the KB Panel. Database-aware people will see they are like 'relations' in a relational database, that are produced as a result of a relational operation. (NOTE: In that sentence 'relation' has almost *nothing* to do with relationship! It is a jargon term of the database community.) The purposes for which you might use a List include:
You can add items or attributes manually to lists, one by one by selecting the list as the current goal list and hitting the 'Add Goal' button in the Attribute Action Panel.
Actually, lists are just a certain type of item, of the 'List' type - see in the Item Type List - which are linked via a certain type of relationship, of the 'Contains' type, to the things that are to be included in the list. So, if you wish, you can make up a list by drawing such links, though you would not normally do so.
To operate a Volunteer or Override List, select it as current goal list and hit ResetGoals and InferGoals.
Select 'Form' in the Item Types List and draw - a larger than normal box. Then draw links from this box to each attribute that is to be in the form (not from the attribute to form) and when run all the attributes connected to the form will appear on the single form. (Actually, from version 1.08, only unanswered attributes appear on the form.) The Item Details Panel detects that an item is a form, and allows you to enter text that will be placed at the top of the form.
In future versions we hope to offer a more flexible form, but at present it can hold about half a dozen attributes at a time in a single column. From version 1.08, by virtue of only holding unanswered attributes, if a form has more than it can hold, it will come up repeatedly until all its attributes have been answered.
So inference operates in a cycle until the given ('goal') attribute is answered:
Note however that forward chaining does not stop at a goal; if the goal has any consequents, then it carries on into and through those to all parts of the net that can be reached.
Goal lists are lists of attributes that can be used as goals together; each is used as a goal until answered and then the next unanswered attribute in the list is taken as the new goal. This process stops only when all goals in the list have been answered. You choose one of the existing lists to be the current goal list by means of the Goal List button on the KB Panel.
At the creation of the knowledge base you are supplied with two empty lists automatically, named 'Goal List' and 'Override List' with the former selected as current Goal List.
Goal lists are fully-fledged items, and you can treat them as such. Look at a list's contents by bringing up its item details panel (by hitting the 'S' button next to the Goal List gadget on the KB panel). You can create new ones by selecting 'Lists' item type and drawing a box of that type on the easel (often in an empty space away from the main KB); the two original List items have no easelpiece. You can get rid of a goal list as you would any item by bringing up its item details panel and hitting the 'Delete' button.
You, the knowledge engineer, are responsible for giving goal lists their contents; they do not automatically receive any. There are three ways of doing this, two of which simply add attributes to the current goal list one by one.
There is a two-way data-link between graphics and their semantics. So, given a semantic, we can find and, if we wish to, change all its graphics. Likewise, if you click on a graphic, its semantic can be found easily. In this way your drawing actions can be translated into semantic knowledge. The arrangement in IRKit, on which Istar is based, is similar to the MVC (Model-View-Controller) of Smalltalk fame.
Any semantic can be expressed by more than one graphic, so that, for instance, it is possible for a given item to appear in more than one easel, and even several times on the same easel. Also, in Istar, items can be expressed by a boxgroup and also by the topmost box in the boxgroup.
But each graphic can express only one semantic. Thus when you click on, or drag, a graphic and it signals some action on the underlying semantic, then the action is unambiguous. Or, rather, there is no doubt as to which semantic the action should be directed to.
Developer panels mainly sit on the main control screen and use small e.g. Topaz8 font for their gadgets. They are normally asynchronous (multi-threaded) in operation in that you can have any number up at once and almost all of them will be active and so will the main easel. Their purpose is to allow you to build and refine a knowledge base.
The main developer panels include:
End user panels sit on the main control screen at present, but in future can sit on another screen. They are used while the KB is running, such as to ask user for values during an inference cycle. They are mainly synchronous in operation, in that the user must reply to the current panel, before any other input can be given. But some are asynchronous.
The main end user panels are: