The Storage Layer

The storage layer describes the structure of a hypertext as a finite set of components together with two functions: a resolver function and an accessor function. Both functions are jointly responsible for "retrieving" components, i.e. mapping specifications of components into the components themselves.

The fundamental entity and basic unit addressability in the storage layer is the component. A component is either an atom, a link, or a composite entity made up from other components. Atomic components are primitive in the (storage layer of the) Dexter model. Their substructure is the concern of the within-component layer. Atomic components are what is typically thought of as a "node" in a hypertext system, e.g. a card in NoteCards, a frame in KMS, a document in Intermedia, a statement in Augment,...

Links are entities that represent relations between other components. They are basically a sequence of two or more "endpoint specifications" each of which refers to (a part of) a component in the hypertext. Links can be directional (one endpoint is a FROM, the other a TO) or bidirectional (the endpoints are called BIDIRECT) or completely undirected. However, links between more than two endpoints must have at least one "destination", i.e. a "TO" endpoint.

Composite components are constructed out of other components. The composite component hierarchy created when one composite component contains another composite is restricted to be a direct-acyclic graph (DAG), i.e., no composite may contain itself either directly or indirectly. Composite components were relatively rare in the generation of hypertext systems that were available in 1990, but are becoming more common. Note that composites containing composites were not mentioned in the Trellis reference model.

Every component has a globally unique identity, which is captured by its unique identifier (UID). UIDs are primitive in the Dexter model, but they are assumed to be uniquely assigned to components across the entire universe of discourse (not just within the context of a single hyperdocument). The accessor function of the hypertext is responsible for "accessing" a component given its UID, i.e., for mapping a UID into the component "assigned" that UID.

UIDs provide a guaranteed mechanism for addressing any component in a hyperdocument. But the use of UIDs as a basic addressing mechanism in hypertext may be too restrictive. Some systems have a query or search mechanism that allows the creation of links to answers of a query, like "create a link to the component(s) containing the word "pollywog". When such a link is followed the component specification must be "resolved" to a UID (if one exists), which then can be used to access the correct component. This is the task of the resolver function.