kremer@cpsc.ucalgary.ca

A variation of the Dexter Hypertext Reference Model
Differences from the original

This work is primarily based on:
Halasz, F., Schwartz, M. "The Dexter Hypertext Reference Model." NIST Hypertext Standardization Workshop, Gaithersburg, MD. January 16-18, 1990.
WARNING: Work in progress.

Page Contents

relaxation: Links may be unary

In Dexter, links are required to be at least binary . This is too restrictive to model certain constructs in some knowledge representation languages. For example Conceptual Graphis [Sowa 85] uses unary links to represent what might be termed attributes. In the extended model, this restriction is relaxed to allow for unary links .

relaxation: Links to other hypertexts

Dexter restricts links to refer components of the same hypertext, as seen in the linkConsistent predicate . Dexter1 relaxes this restriction to allow links to refer to components of other hypertexts .

Note that the original Dexter did not disallow the resolver and accessor functions . to return components in other hypertexts: it only constrains the resolver's range to be equal to the accessor's domain and the range of the resolver to include all the components of its hypertext. This does not preclude the accessor returning some other hypertext's components as well.

relaxation: Links may have dangling specifiers

In the original Dexter, the linkConsistent predicate restricted links to refer to existing components in the same hypertext. But sometimes links my be created before the components they refer to are created (an author may want to mark a spot to fill in later) or known (all person-type components have father relations, but sometimes the father filler component is unknown). Dexter1 modifies the linkConsistent predicate to return true if the links' COMPONENT_SPECs that aren't otherwise consistent are explicitly empty (actually, if the COMPONENT_SPEC is the constant NullSpec) .

relaxation: The accessor function can fail

Can probably scrub this one in favour of having the Runtime Layer's FollowLink function fail.

relaxation: Deleting a component deletes all the links that link to it

When a component is deleted, the original Dexter deletes all links which have a specifier refering to the deleted component . This seems rediculous in the case of a n-ary link which may represent a path. Dexter1 does not delete links who's SPECIFIERs refer to the deleted component, but instead modifies the references to refer to NullSpec (i.e. nothing). However, any links that would be left with no actual references are deleted . This schema is considerable more complex than that of the original Dexter Model.

extension: Every HYPERTEXT has a type database

Each Hypertext now has a which contains details (not fleshed out yet) about atom types and link types. Atom types are fairly primative, specifying no more than the type's name and the type hierarchy (each type specifies a parent type). Link types do this but also specify the arity of the link and constrain each of the endpoints to specific atom types. Both the link type hierarchy and the atom type hierarchy have a root type labeled "Undefined".

The PROTO_HYPERTEXT schema is extended to contain a TypeDB .

extension: The concept of type is introduced to all components

A type string is added to every Component (in ComponentInfo) . The type string of an atom must be a string that appears as the name of a type in the atomType hierarchy in the containing hypertext's TypeDB; likewise, the type string of a link must be a string that appears as the name of a type in the linkType hierarchy .

extension: Link types restrict the type of the components that links may reference

In the original Dexter there are no types. But in Dexter1 there are types and links can be restricted to anchor only on atoms of a specific type (which implies some subtype of this type). This restriction forms a new clause in the HYPERTEXT schema.

relaxation: The followLink function can fail

up to index,
kremer@cpsc.ucalgary.ca