An atomic object in LINCKS (see figure 2) is represented by two kinds of nodes : versions and a history structure node The versions represent the appearance of the object at particular points in time. The history structure node contains the historical information of the object (see also section 5).
A node contains three sections: attributes , links , and image . The attribute and link sections are further divided into groups, fields, and values, while the image is only a value. Figure 6 outlines the hierarchy:
Thus, for example, ``attribute value'' means the value of some field in some group in the attribute section of some node.
All but the three main sections ( Attributes, Links, and Image) are ``repeating fields'' indexed by tags. We talk about ``group tags'' and ``field tags'' . We have adopted a policy to use capital letters for group tags, while field tags are capitalised words.
The structure of link values is defined to be varying length arrays with start index one (1). Each entry in such an array is called a link item , and it refers to either an object or an object version. In the first case we call the link unbound . In the second case we have a bound link (see also section 4.3).
An application program refers to objects through a data structure called a label (see also section 4.3). The labels should, generally, be treated as handles to objects and nodes, and thus be set and reset only through calls to LIBLINCKS functions.