Information model meta model: Difference between revisions

From Endeavour Knowledge Base
No edit summary
No edit summary
Line 11: Line 11:
#A set of maps creating mappings between published concepts and the core ontology as well as structural mappings between submitted data and the data model. This uses a context class.
#A set of maps creating mappings between published concepts and the core ontology as well as structural mappings between submitted data and the data model. This uses a context class.
#A set of form generators that are used by the IM application to create forms for the creation and editing of the IM entities which are instances of a meta model class.
#A set of form generators that are used by the IM application to create forms for the creation and editing of the IM entities which are instances of a meta model class.
<br />
== General approach ==
The information model language uses RDF triples as its basic grammar i.e. subject, predicate, and object with graph making up quadruples of an RDF data set.
Thus, RDF is used for the meta model and the W3C language used for the metal model is SHACL. In other words, SHACL is used to define all the meta classes, and the meta classes are used to hold the instances which are the content of the model.
The paradox of the information model content is that the instances of the meta model classes are themselves considered classes in the real world. For example when noting that a patient has 'chest pain' this is recorded as a concept which is an instance of the concept model. But 'chest pain' is also the class of all chest pains, so the same identifiers can be used for subsumption query. Likewise a clinical event in a health record is an instance of a data model meta class, but the clinical event is also a class of all clinical events!
The model itself can be exchanged in JSON-LD, but JSON-LD can be somewhat tedious (as RDF predicates cannot directly map to standard programming language class properties) , so the use of 'local names' for business related APIs (e.g. query) is supported. In this case the JSON field names can use the local names without the full IRI, as long as the JSON complies with the model classes as described here.
Consequently, in order to make the documentation clearer, local names are used in this documentation also with links to the IM viewer or W3C equivalent.
This documentation is auto generated from the information model folders and shapes themselves, and thus the shapes can also be viewed more fully in the Information Model Directory viewing application
== Types and shapes ==
Types (as represented as the value of the rdf: type predicate), are used to indicate the structure of an object in the model. Thus each meta model class is marked as an RDF TYPE.
Shapes are made up of SHACL node shapes and property shapes. A 'type' is defined in the form of a shape.
Shapes are also classes (i.e. also are rdf:type -> rdf:Class), so that any shape that is a subclass of another shape inherits its properties unless overridden by sub properties, or subclass values of the parent properties.


<br />
<br />

Revision as of 16:11, 20 September 2022

Scope of the meta model

The model meta model consists of a small set of specialised classes or 'shapes', made interoperable via the use of the semantic web languages which use RDF grammar and syntax.

The classes cover the following areas:

  1. An ontology of terminology concepts, which is a vocabulary and definitions of the concepts used in healthcare, or more simply put, a vocabulary of health. The ontology is made up of the world's leading ontology Snomed-CT, with a London extension and supplemented with additional concepts for data modelling. Whether concepts or Snomed-CT concepts, or the London extension, or any legacy code based concept (e.g. ICD10 or EMIS local codes or Read codes), the class structure is the same.
  2. A data model, which is a set of classes and properties, using the vocabulary, that represent the data and relationships as published by live systems that have published data to a data service that uses these models. The data model is part of the overall ontology and there is seamless boundary between the data model shapes and the terminology concepts, as both use RDF. The data model meta model uses SHACL shapes and thus conforms to the W3C SHACL recommendation.
  3. A library of business specific concept and value sets, which are expression constraints on the ontology for the purpose of query. This uses a specialised "query" or "set definition" class, and encompasses the Snomed-CT expression constraint language with which it is compatible, using a simple translation API
  4. A catalogue of reference data such as geographical areas, organisations and people derived and updated from public resources.
  5. A library of Queries for querying and extracting instance data from reference data or health records. This uses a more extended class model than 3) but fundamentally is a set definition which is mapped to mainstream query languages to get actual data.
  6. A set of maps creating mappings between published concepts and the core ontology as well as structural mappings between submitted data and the data model. This uses a context class.
  7. A set of form generators that are used by the IM application to create forms for the creation and editing of the IM entities which are instances of a meta model class.


General approach

The information model language uses RDF triples as its basic grammar i.e. subject, predicate, and object with graph making up quadruples of an RDF data set.

Thus, RDF is used for the meta model and the W3C language used for the metal model is SHACL. In other words, SHACL is used to define all the meta classes, and the meta classes are used to hold the instances which are the content of the model.

The paradox of the information model content is that the instances of the meta model classes are themselves considered classes in the real world. For example when noting that a patient has 'chest pain' this is recorded as a concept which is an instance of the concept model. But 'chest pain' is also the class of all chest pains, so the same identifiers can be used for subsumption query. Likewise a clinical event in a health record is an instance of a data model meta class, but the clinical event is also a class of all clinical events!

The model itself can be exchanged in JSON-LD, but JSON-LD can be somewhat tedious (as RDF predicates cannot directly map to standard programming language class properties) , so the use of 'local names' for business related APIs (e.g. query) is supported. In this case the JSON field names can use the local names without the full IRI, as long as the JSON complies with the model classes as described here.

Consequently, in order to make the documentation clearer, local names are used in this documentation also with links to the IM viewer or W3C equivalent.

This documentation is auto generated from the information model folders and shapes themselves, and thus the shapes can also be viewed more fully in the Information Model Directory viewing application

Types and shapes

Types (as represented as the value of the rdf: type predicate), are used to indicate the structure of an object in the model. Thus each meta model class is marked as an RDF TYPE.

Shapes are made up of SHACL node shapes and property shapes. A 'type' is defined in the form of a shape.

Shapes are also classes (i.e. also are rdf:type -> rdf:Class), so that any shape that is a subclass of another shape inherits its properties unless overridden by sub properties, or subclass values of the parent properties.