PLINTH is written entirely in Pop11, a procedure-oriented programming language comparable in power and basic functionality to Common Lisp, but syntactically more akin to Pascal or C. As mentioned in the introduction, the lowest layer in PLINTH is a library called CONNEKT. So when we talk of PLINTH's data storage and retrieval we are really referring to CONNEKT.
(Note that where there is text associated with a node, this is just represented as an ordinary attribute of the node, along with all its other application attributes. There is nothing special about text nodes as far as CONNEKT is concerned, and how the text fragment itself is actually represented is not important here. However, the issue of text format and representation is very important in other respects to PLINTH, and is discussed in detail elsewhere [6])
CONNEKT represents nets, nodes, links and their attribute slots as record classes (cf. defstruct in Lisp, or struct in C). Figure 1 shows simplified versions of the declarations of these records in Pop11, with comments showing the type and contents of each field. It should be noted (following the distinction described in section 2.1) that Pop11 records define dynamic classes of which instances are constructed at run-time, rather than static types used for compile time checking.
We can see at once from the record class definitions that CONNEKT data items are indeed complex objects: instances of these records could be regarded as ordered lists of name/value tuples (although their actual representation is of course more efficient than that).
There is also object sharing. For example, each node structure can be referred to both by its net's list of nodes, and by each link connecting to or from it. This is straightforward in Pop11 since all non-numeric data items are implicitly treated as pointers to structures (in C terms) and therefore they have an object identity distinct from their value.
CONNEKT includes extensible node and link class hierarchies and inheritance, but because Pop11 records do not at present support subclassing directly, the node or link class has to be represented as ordinary field in the record, and the CONNEKT system has to represent the hierarchies and manage inheritance itself. However, a new objectclass facility is about to be introduced into Pop11, which extends defclass to provide subclassing, inheritance with overriding, overloading, and late binding, and also data encapsulation. PLINTH will very probably make internal use of these objectclass facilities, so its external data storage should ideally provide them too.
In summary then, although PLINTH is not written in a conventional object-oriented language, it most certainly is an object-oriented application, which makes use of complex objects, object identity, extensible class hierarchies and inheritance, and which would benefit from the other object-oriented features described in section 2.1. Object-oriented database technology would therefore seem to provide the ideal answer to PLINTH's external data storage and access requirements. On reflection, given that OODBs were originally developed for use in design support environments, of which computer assisted authoring tools are another good example, along with CAD and CASE, this should come as no great surprise.
OODB features required by PLINTH...