Skip to content

Top Level Data Structure

GCHQDeveloper42 edited this page May 18, 2021 · 1 revision

Top-Level Data Structure

While the details of the TLDM are explained in detail in Dr West's book we shall introduce the top level structure of the model here and illustrate how the structure is suited to the implementation we chose. This page inevitably glosses over many of the ontological choices that led to the structure of the model. However, as a reminder, the objective of the Dr West's model (referred to as "HQDM" after the book's title) was to ensure that it could be used as a framework to model anything (that is, or could be, real) and that it would be stable in the face of change. The start point for the model is, therefore, necessarily abstract.

A stripped-down diagram of the roots of the HQDM data model is shown below. Its author presents it as an Entity-Relationship model and we shall use the term "entity" for the moment until we switch to discussion on its implementation. The root entity (or primary supertype) is "thing". All entities in the HQDM model are subtypes of "thing"; it is the entity that represents the universe(s) in which the model and its extension (all Reference and User data) exists. This is very useful from a data management point of view because the root attributes of the data model are assigned to this entity and are therefore inherited by all its subtypes. A key attribute at this level is a unique identifier; analogous to a primary key in a SQL table but in our case there is, at least conceptually, only one (rather busy and distributed) table.

HQDM Top Level

The only two subtypes of "thing" indicate a key structural separation in the model. The representation of things that are 'real' in the model is based on a ontological/metaphysical stance that commits to everything having existence (and distinct identity) as distinct portions (parts) of space-time (See temporal parts for an introduction). This choice can be referred to as Four Dimensionalism (or, even more specifically, Perdurantism). It can appear to be rather abstract initially but it is key to the structure of HQDM and is fundamental to the one-to-one mapping of anything that exists (or could exist) in the 'real' world to their representation in data. An example will be used later to illustrate how this can lead to a more natural view of what is being modelled (in the Analytic Realm. In HQDM it is the entity spatio_temporal_extent and all of its subtypes that are used to create records of 'real' things (e.g. particulars such as "my car", "this watch", the actual "Person B", etc.). The dotted relationship looping back to this entity indicates that a representation of a spatio-temporal extent can be composed of one or more temporal parts. This is another key feature of the model that ensures that if I want to represent the existence of my car while it was parked in a car park on a particular morning that is just a temporal part (a state of) the existence of the 'whole-life' of that car. It is worth noting that the dotted lines don't mean that there is circularity in the data model structure (it may look from the notation that a spatio_temporal_extent can be part of itself) but the diagram represents that an instance of that entity can be a temporal_part_of another instance of that entity (and there is the prospect of Set Theoretic - compatible axioms that formalise the correct use of these relationships. Interested readers can look at this introduction to Mereology for some guidance to the general study of wholes and parts).

The other branch of the model at this level is used to construct the universal sets, called "abstract objects", that the particulars are members of. This is where the notion of "class" comes into the model. The subtypes of "class" are the sets that are important to the system users so that the collections of 'real' things that they have access to can be arranged or organised by being members of one or more "class". For example, "my car" is likely to be a member of a class named "CAR". The class "CAR" may be a sub-type of class "MOTOR-VEHICLE" that in turn may be a sub-type of class "FUNCTIONAL_SYSTEM". By declaring the spatio-temporal extent of "my car" to be a member of class "CAR" it is also a member of all of the sub-types of class "CAR". The has_superclass relationship is available to allow new sub-types to be created as sub-types of one or more existing classes. The "relationship" sub-type of abstract_object provides a mechanism for new relationships to be created as an extension of the data model itself, a form of reification, but we will leave that aside as being of specialist interest only. However, hopefully the simple example of "my car" illustrates why the notion of "class" has a distinct meaning within the HQDM model.

In total there are 229 entities in the HQDM data model but this introduction to the top level structure of just five of the entities provides some key elements that led to the implementation approach covered in the next page. For reference, as it will be useful for the following pages, the next level of expansion of the HQDM data model is provided below.

HQDM Next Level

Next: Code Introduction Part 1

Clone this wiki locally