LINCKS Overview

LINCKS [PL93][LSP93] is based upon a client server, multi-users architecture, where the database resides on a single server machine and the clients are on workstations connected to the server by a local area network. LINCKS is made up of essentially four separate software layers:

1. The first layer, the NODE database layer, resides on the server machine and is made up of three processes:
   • The monitor process serializes creation of objects, imposes access control (it allows you to define which groups of objects a particular user has read and write access to), and implements notification upon object creation.

   • The netserv process handles connections from clients and user validation before creating the `dbs' process.

   • The dbs interacts with a client - one per connected workspace. It retrieves and stores objects in files using the monitor (to ensure unique object identifiers, etc). The dbs has the same lifetime as the client.

2. The second layer, the NODE workspace layer, is encapsulated in the liblincks library (described in [LIN88]) and works together with layer 1 to form the basic object-centered database management system which we refer to as NODE [Pad88].

3. The third layer, the Composition Management (CIM) layer, filters out substructures in the database and represents these as a finer grained structure of items. The central data structure of this layer is what we call the reference structure, see section 3.

4. The last layer (4), the Interface layer, displays the leaf items of the reference structure in a window display. It provides the interface to the editing of the reference structure and via that, the information components. Currently the main user interface for editing xlincks [IIS93] is built using X11 and where editing of the leaf items is done directly on the display using emacs-like commands. The WWW front end is also built on top of the third layer.

LINCKS Data Model

An object in LINCKS is represented by two kinds of nodes [Pad88] versions and a history structure node. Versions represent the actual appearances of objects at certain times. The history structure nodes contain object information and historical information of the objects. The historical information is represented by different partial orders (see section 2.2). A node has three distinct parts [Pad88] which are:

• the image, which contains uninterpreted information (textual, graphic, audio information etc.) which is application dependent,

• a number of attributes with values (reminiscent of a frame-like representation or semistructured objects [MGL+87]). Attributes are single valued and describe the object's properties,

• and a number of links which describe the object's relationships to other objects. Links can have multiple values, (in a document each section is implemented as 'section link'). Links are used to build composite objects, or to simply establish a connection or a relation (e.g. a hypertext link).

Historical Information

NODE [Pad88] maintains information regarding the history of objects, composite objects and actions within the system. Past versions of objects can be accessed and reactivated. The development history informs us about what version of an object is used to create a new version of a (possibly different) object (also in ObjectStore [LLOW91], Iris [BM88], and Ontos [Cat91]). The temporal history of an object is an order between the different versions of that object and reflects the order of the versions' creation time. We allow several users to take out an object at the same logical time and to create new versions of that object. In this case we say that logically all the new versions come after the latest common version, but there is no order between the new versions. Versions that cannot be ordered following creation time are said to be parallel.

The command history [Hal92] is a partial order which gives information regarding the temporal relation between commands that have been issued by various users of the system. It also contains information about what objects are affected by each command.

Linking

LINCKS supports both dynamically bound links and statically bound links. A dynamically bound link is between a source object and a target object where the binding to a particular version of the target object occurs on demand (by default the most recent version). Thus, it is not necessary to introduce new links every time the target object changes. We also have statically bound links which link directly to a particular version of a target object. Link resolution is in this case neither needed nor wanted.