Skip to content

Top Level Type

Thing Entity Type

The root entity type is thing. All other HQDM Entity Types are subtypes of thing. All HQDM data objects, however they are represented, are instances of thing. As we shall see later, HQDM data objects can represent extensions of the originally documented HQDM types and, even, the whole of HQDM (both instances and types, see code examples for an illustration of this).

Supertype Hierarchy

graph TD
  id1([thing]);
  style id1 stroke-width:4px;

Relations

graph TD
  id1([thing]);
  style id1 stroke-width:4px;
  id2([abstract_object]) & id3([spatio_temporal <br> _extent]);
  id1-->|supertype_of|id2;
  id1-->|supertype_of|id3;
  id4([class]);
  id2-->|supertype_of|id4;
  id1-...->|member__of|id4;

Implementation

To use HQDM as an implementation model directly a number of properties are recommended for each record (data object):

Property Required Description
id Yes A unique identifier for this object
record_created Recommended The date-time stamp for the object's creation
record_creator Recommended The user, organisation or system that created the record
entity_name Optional A human readable initial name for the object1

Other properties may be chosen, or added, for additional data management purposes (e.g. logical deletion or data record copying). They are described in the HQDM References below and are provided in the PatternsUtils.java.

Warning

Aside from the role of id, these properties are NOT part of the HQDM data model. They are solely used as data management features and do not ascribe any meaning to the data objects. The id is the only essential property as it is needed to address (refer to or find) each data object. There is a correspondence between the unique identity of a HQDM class or actual material item (in the 'real' world) and the data object that represents it. The id provides the means to ensure this unique correspondence, although careful information management is required to ensure this is preserved (see comments on this throughout the documentation).

Example

Instance of thing generated by the ThingExample.

graph LR
  id1((patterns: <br> 7a14739a-7bdd-49a0- <br> a935-3ef41f0cf955)) --->|patterns-rdl:record_created| p1[2023-08-01T10:40:51.880960800Z];
  id1 --->|patterns-rdl:record_creator| p2[HqdmPatternProject_User1];
  id1 --->|hqdm:EntityName| p3[Example_Thing_As_Instance_Of_ <br> TopLevelHQDM_EntityType_THING];

Thing object in TURTLE
@prefix diag:         <https://apollo-protocol.github.io/ns/2023/diagram-editor/diagram#> .
@prefix hqdm:         <https://hqdmtop.github.io/hqdm#> .
@prefix patterns:     <https://github.com/ClimbingAl/code-for-hqdm-patterns/patterns#> .
@prefix patterns-rdl: <https://github.com/ClimbingAl/code-for-hqdm-patterns/patterns-rdl#> .

patterns:98a7df53-f44f-4bcf-91f6-81636af46743
        a                            hqdm:thing ;
        patterns-rdl:record_created  "2024-01-20T19:00:09.714589442Z" ;
        patterns-rdl:record_creator  "HqdmPatternProject_User1" ;
        hqdm:data_EntityName         "Example_Thing_As_Instance_Of_TopLevelHQDM_EntityType_THING" .
While it is unusual to create instances of the thing entity-type, this is the data object structure that will be used for all its sub-types, with the only addition being relationships (as RDF predicates) that are committed in the HQDM model (and, therefore, its patterns).

Note

The term type is a key feature of the construction of HQDM as a conceptual model. It also corresponds to the term "Entity Type" in data modelling languages such as EXPRESS. However, the way it is used in HQDM differs from the way it is used in many data modelling applications. type has a formal role as it represents a SET-like collection of items that covers all such collections in the model (a type theory). This includes axiomatic SETs within the model as a realm of sub-types (confusingly, the top level SET in HQDM is called class). So a type is not necessarily a SET but can be thought of as a superset of SET.

The choice of many terms in the documentation of HQDM stems from its formal roots (type theory, set theory, mereology, etc). Be prepared for the names for these features to have primacy over implementation specifications and standards such as programming languages (where "data types" and "object classes" are common terms) and notation standards for model storage and query languages (where "set" & "class" can have their own specific use. RDF and UML are examples of this).

References

HQDM book references: 6.3.7, 7.2.1 & 7.3

MagmaCore (Java) reference: HQDM Object, Thing

Other implementation references: MagmaCore Discussion #130

  1. For many uses of HQDM this is not needed and may even be counter-productive, as it is a property that is outside the formal structure of HQDM itself (e.g. what does the property mean? It carries no meaning within HQDM.). However, it aids familiarisation and debugging and will be used in the early worked examples. In the more advanced HQDM patterns this property will play a lesser role. ↩