HQDM as Data and Programming Language Types

[twalmsley]

HQDM has no standard form as data. A copy of the original EXPRESS model exists along with the Java classes presented here and the HQDM book that describes the EXPRESS, but there are some errors in it.

HQDM needs a reference copy in some modelling language that can then be used to derive standard formats in, say, RDF, JSON, XML, JSON-LD, graph databases, relational databases, triple stores, etc. as needed, but also as a single source of truth for bindings to Java classes and other programming languages.

MagmaCore data models need access to a copy of HQDM as RDF triples in a Jena database to support queries that need to be aware of the model structure, such as 'find all objects that are of type System or one of its subtypes', and such queries need to work for model extensions describe in #51 .

[ClimbingAl]

This is certainly a challenge! Here's an experiment that I called hqdmAllAsData. The aim was to represent the model HQDM in a format that was consistent with the data that is generated using Magma Core. I have attached the resulting file at the end of this comment.

The result is a graph-like format that holds all the computable information* that it is logically possible to have in a given dataset that is isomorphic to Magma Core and HQDM (assuming that the implementation of the application code is a faithful use of HQDM itself and it references the HQDM entity uuids).

Why did I want to do this?

1. To have consistent, structured data that is not tied to any one implementation of a system for processing it.

2. To allow alternative software implementations of HQDM to that currently with Magma Core (e.g. alternative languages, databases, etc).

3. To allow the type hierarchy to be computable in a format that is consistent with Magma Core and to support HQDM-based data model design through the type and relationship information in this dataset.

The aim of this exercise was to maximise internal consistency with minimal reliance on external definitions. Very little use is made of RDFS as it is a specification external to the dataset that requires interpretation. There are a few (minimal) rules to relate the data to HQDM as documented (originally in the EXPRESS data modelling notation). Only one additional predicate beyond what is in the Magma Core HQDM.java IRI set is needed (has_supertype). The rules are (assuming a IRI prefix of hqdm: for brevity):

TYPE identity: Each node is based on a hqdm:. This is the unique identifier of that node. These should never be changed.

TYPE mapping to HQDM using HQDM type names as docmented. In RDF a HQDM Type is treated as a rdfs:class, with a node being of that type (using a rdf:type declaration**):

    hqdm:<uuid> rdf:type hqdm:physical_object

Subtype - Supertype Declaration. Two predicates, has_supertype and has_superclass, are used to achieve this. For this dataset they are equivalent to the EXPRESS SUPERTYPE declaration. As HQDM has an abstract_object entity type called class with a has_superclass relationship to allow HQDM class extensions this is used as a predicate for the sub-type hierarchy beneath HQDM class. has_superclass is therefore a specialization of has_supertype (similar to rdfs:subPropertyOf if we were using RDFS). Where there is more than one supertype a list of uuids is given of the supertype nodes. The only node that doesn't have a has_supertype predicate is the top level object hqdm:thing. Two illustrations are:

    hqdm:<uuid1> hqdm:has_supertype hqdm:<uuid2>
    hqdm:<uuid3> hqdm:has_superclass hqdm:<uuid4>

HQDM relationships as documented. All the HQDM relationships are predicates in this datasets and are all named as in the HQDM documentation. The inheritance of relationships down the type hierarchy are given.

Binding to the Magma Core (V1.0.0 tag) Java classes. This is done using class_name to declare the Java class that represents each type in Magma Core. This is the only predicate that is implementation-specific and can be safely removed or replaced if an alternative implementation is used.

It is possible to test the V1.0.0 tagged version of Magma Core (and, with class path changes to the class_names it should be compatible with V2.1.0) by using it to generate an instance of every Magma Core HQDM Java Class. The mapping is therefore isomorpic to these Java Classes.

Finally, this was an experiment so there may be wrinkles with it. It has been used in a trial application and works well to compute the type hierarchy from any Magma Core data object to the root hqdm:thing and to determine the relationships required for HQDM-based data model designs.

There may be better ways of doing this but hopefully it shows some potential.

* It isn't necessarily enough to generate new information and add it to the 'graph' but it is enough to allow two or more data to be added and parsed (queried, compared, etc)
** Although this is legal RDF it is the only use of RDFS in the dataset. It arguably results in an ambiguity about whether a node is an instance of a Type or a Type itself. However, using the hqdmAllAsData approach it is both. In TTL rdf:type is expressed as the a predicate.

TTL file:
hqdm_allAsData2.txt