The base data models are useful as a starting point but some enumerated values or attributes will be redundant other required fields will be missing. The base models will therefore need to be modified to create proper digital twins specific to the scenario we are modelling.
Many attributes within data models are optional, and not all options will be valid for our scenario. Take for example, the category attribute within the Building model - this offers over 60 types of building useful in multiple domains such as Smart Cities and Smart Agriculture, it is therefore safe to exclude certain options from our own @context file since they are unlikely to be used. For example a Building categorised as cathedral is unlikely to be found on a farm.
It is logical to remove bloat before committing to using a particular model as it will help reduce the size of payloads used.
Looking at the Building model, it is obvious that we will need a Building entity of category="barn", however the base Building model does not offer additional attributes such as temperature or fillingLevel - these would need to be added to the base Building so that the context broker is able to hold the context - i.e. the current state of the building.
Many types of device reading (i.e. context data attributes) have been predefined within the SAREF ontology - so it is reasonable to use the URIs defining these attributes as a basis of extending our model.
temperature (https://w3id.org/saref#temperature)fillingLevel (https://w3id.org/saref#fillingLevel)
Many measurement attributes are defined within the SAREF ontology, but other ontologies could equally be used. For example, the iotschema.org schema contains equivalent term URIs like http://iotschema.org/temperature which could also be used here, the additional data can be added to the @graph to show the equivalence of the two using Simple Knowledge Organization System terms SKOS.
The key goal in designing NGSI-LD data models (as opposed to a generic hierarchy of ontologies), is that wherever posssible, every Property attribute of a model represents the context data for a digital twin of something tangible in the real world.
This formulation discourages deep nested hierarchies. A Building has a temperature, a Building has a fillingLevel - anything else is defined as a Relationship - a Building has an owner which links the Building entity to a separate Person entity.
However just holding the values of properties is insufficient. Saying that temperature=6 is meaningless unless you also obtain certain meta data, such as When was the reading taken? Which device made the reading? What units is it measured in? How accurate is the device? and so on.
Therefore supplementary metadata items will be necessary to ensure that the context data is understandable. This will mean we will need things such as:
The Units of measurement, Which sensor provided the measurement, When was the measurement taken and so on.
({
"temperature": {
"type": "Property",
"value": 30,
"unitCode": "CEL",
"providedBy": "urn:ngsi-ld:TemperatureSensor:001",
"observedAt": "2016-03-15T11:00:00.000"
}
},
{
"fillingLevel": {
"type": "Property",
"value": 0.5,
"unitCode": "P1",
"providedBy": "urn:ngsi-ld:FillingLevelSensor:001",
"observedAt": "2016-03-15T11:00:00.000"
}
})
Each one of these attributes has a name, and therefore requires a definition within the @context. Fortunately most of these are predefined in the core NGSI-LD specification:
unitCode is specified from a common list such as the UN/CEFACT List of measurement codesobservedAt is a DateTime a well-defined temporal property expressed in UTC, using the ISO 8601 format.providedBy is an example recommendation within the NGSI-LD specification.