IRKit KT Module Reference Documentation

This page is still under construction.

Main Control Screen

Global variable aIRKitScreen. This control screen usually takes the same resolution and scan frequency as the main Workbench screen, but it normally overscan in order that the large main easel can be smoothly scrolled. It is usually 8 colours or more, normally grey. It normally comes up as the program opens, often about half way up the monitor screen, and typically shows at the start a small initial control panel and a naming strip along the top.

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.

Naming Strip

The naming strip lies along the top of the main control screen and has an area in the middle in which the meanings of items and attribute are displayed when the mouse passes over them. It also has a number of buttons:

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.

Main Easel

In many programs built under IRKit there is a large main easel on which you can 'draw' knowledge. This is usually larger than the main monitor area and smoothly scrollable. It is your main work area, and sits just behind the control screen and its various panels which help control details of your work.

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.

Boxes on Main Easel

On the main easel are either boxes or boxgroups, linked by lines that are arrows. A boxgroup is a group of boxes that move together, and are usually arranged in a vertical column. Boxes can have labels in them.

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

Arrows, Links, Lines

Arrows, links, lines between boxes, express relationships. Links are drawn only between boxes, and not between boxgroups. (This is why if an item is to have relationships, it must be expressed by its own box.) What this means is that inference relationships, for instance, can exist between the attributes of items - which is not easy in some software.

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.

Items

Items are conceptual things that represent important in your domain of knowledge, and are expressed on the main easel by boxgroups and, sometimes, their own boxes. Items can have attributes and can form relationships with other items.

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.

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.)

The naming mechanism allows both synonyms and homonyms, though in practice there is no gadget by which you can create a synonym at present.

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

Attributes have a state of being 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:

Inference Method

Each attribute can carry an inference method, which is used when the derivation is 'inferred'. Istar offers a host of these, from simple arithmetic like adding or subtracting, through probabilistic and Bayesian algorithms, to administrative ones like finding the first known attribute and how many have been answered. What inference methods are valid depends on the attribute's value type; for instance, you can add two integers, two floating point numbers, two angles, but it doesn't make sense to try to add two booleans. Sometimes an inference method seems to make half sense, such as adding two strings to mean concatenation, but whether this is allowed or not depends on the precise combination; in this case, you must use the inference method Concatenate rather than add. A full list of inference methods is available.

Overriding an Attribute

Overriding an attribute means (temporarily) replacing its main value with one supplied by you. It is useful particularly when you distrust the inference that the KB has made - perhaps because you know you are working in an exceptional situation for which the normal knowledge is not entirely suitable. You can force the value to be something of your own choice.

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.

Free Attributes

Free attributes are single attributes within an item whose only purpose is to hold the attribute. Thus such items are de-emphasized and have no box to express them. It is inappropriate to consider such attributes as merely part of a relational tuple or as the 'A' of an OAV triple. They are more like global variables in a programming language, but without many of the problems of global variables since their relationships are explicit rather than implicit.

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.

Values

Values are the contents of attributes. They can be quantitative, of various kinds, or qualitative. When they are expressed this is often by a line drawn in an attribute box.

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.

Item Types

Each item is of a certain type. That is, it is linked internally to a type block, which defines some things about it. Item type blocks are also used in the creation of new items, and therefore hold the list of attributes that items of that type should have when first created. Item types are normally not expressed visually on the easel.

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.

Domains

Domains are attribute types. The word 'domain' comes from relational database theory, and means the set of values that an attribute can take. With some domains, such as of integers, the set is infinite, but with enumerated types, it is limited.

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.

Value Types

Value types are built-in. e.g. integer, floating-point number, probability, proportion, string, bayesian, boolean, etc. Each value type has some means of internal storate, plus some defined operational semantics for how it is manipulated. For instance, while integers can take any value, probabilities can only be between 0 and 1, so adding two probabilities of 0.7 together does not give 1.4. There is automatic conversion between value types as far as possible. See value.types.html for those currently available.

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.

Relationships

Relationships are deliberate links between items, and also anything treatable as an item. In inference attributes are treated like items and have an inference relationship between them. Some are visible, expressed as lines on the easel. Others are normally invisible, created for various administrative purposes.

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

(Not to be confused with Panel lists, below.)

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.

Volunteer and Override Lists

These are similar to Goal Lists, but while Goal Lists normally comprise attributes to the right hand side of the Easel, Volunteer Lists comprise questions and other attributes to the left and Override Lists comprise attributes from the middle. They are actually treated all the same as far as Istar is concerned, it is just that to the knowledge engineer and user they have slightly different purposes:

To operate a Volunteer or Override List, select it as current goal list and hit ResetGoals and InferGoals.

Forms

Forms are a type of item to which Istar accords special meaning - they take effect during the inference process and allow several attributes to be grouped together so that the user answers them all before hitting the 'OK' button. This reduces the feeling of randomness the user might get if all questions are asked one by one.

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.

Inference

Inference is the process of calculating the value of one attribute from those of others that are its antecedents. It is more than just doing the calculation since the antecedent attributes might not yet be answered, so their values must be obtained. Also, the antecedents might themselves have antecedents, to any degree.

So inference operates in a cycle until the given ('goal') attribute is answered:

Backward Chaining

Backward chaining is the process of searching from a goal attribute through its antecedent links to find an attribute that has yet to be answered (if any). It will normally only search over the Inference type of relationship. In Istar the goal is normally over the right hand side of the easel and backward chaining searches to the left. Note that the search might be over a network rather than a strict tree.

Forward Chaining

Forward chaining is the process of propagating the value of an attribute forward through all its consequents, until all reachable parts of the consequent net have been visited. At each attribute so visited it calculates a new value for it from its immediate antecedents (at least one of which will have received a new value), then if the new value differs from the old one it will do the same thing for all of its immediate consequent attributes. And it will keep on doing this until all have been visited. Simple depth- and breadth-first searching will sometimes fail, and we had to devise a special algorithm for Istar that would ensure that all antecedents of an attribute were visited before the attribute itself.

Goals

Goals are attributes which are the starting point for an inference cycle. That is, backward chaining starts from a goal.

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.

Expression of Knowledge by Graphics

In Istar and similar software, what you see on the main easel is usually an expression of some piece of knowledge or information. That is, there is a thing (object) that is the graphic and some internal thing (object) that the graphic expresses. Thus, normally, boxes express items or attributes and links between the boxes express relationships. Some lines inside boxes express values. The items, attributes, relationships and values are the semantics of the knowledge base. The graphic can be a group of others, as in a boxgroup.

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.

The Meaning of a Thing

Items, attributes, relationships and their types can all have meanings attached to them. This is a kind of long name. For items and attributes it flashes up in the naming strip when the mouse passes over it.

Panels

Panels are windows that handle detail, and usually appear on the control screen which is raised to let the panel be seen. There are two main types of panel - those designed for use by developers of a knowledge base and those designed for use by end users of the knowledge base - i.e. those who run it.

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:

Copyright (c) Andrew Basden 13 February 1998.