LINCKS Overview



next
Next: Documents & Views Up: An WWW Front End Previous: Introduction

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:

  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-centeredgif 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:

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



next
Next: Documents & Views Up: An WWW Front End Previous: Introduction



Martin Sjolin
Thu Sep 15 17:52:35 MET DST 1994