INTER-LAYER — Data and Semantics to Data and Semantics (DS2DS): Mapping data models via alignment

(Getting Ready) Scenario description

Lets assume we have an RDF representation of IoT artifact data and some second data model that is used by other communication side. We want to define mapping rules between these model to enable shared understanding. The mapping rules should later serve to perform semantic translation. The set of mapping rules (correspondences) is persisted in the form of an alignment. In this recipe we show how to compare two data models and identify correspondences.

Within INTER-IoT we have proposed IPSM-AF - an alignment format that can be consumed by IPSM semantic translation component. In Recipe 5 - Representing alignment in IPSM-AF we explain how to use this format to represent alignments.

Note that in INTER-IoT we use central ontology - common data model, that is deployment specific and allows to represent data exchanged in the INTER-IoT ecosystem. Central ontology is in most cases based on GOIoTP. When new IoT artifact is connected to the INTER-IoT ecosystem, an integrator should establish if one or two-way communication should be supported. Depending on this one or two unidirectional alignments (to and/or from central ontology) need to be defined.

Recipe ingredients

Source (IoT artifact's) data model in RDF (if IoT artifact uses other data format then RDF data model should be designed as in Recipe 2 - Translating data model to RDF). The presented data model was proposed for device description originally expressed in JSON according to FIWARE NGSI specification. Prefix fw stands for http://inter-iot.eu/syntax/FIWAREv2.

Source data model in RDF

Target data model to we want to translate to. Since translation is done in INTER-IoT ecosystem we may assume that the other data model is already represented in RDF. In this recipe, we assume target data model is based on GOIoTP. Prefixes used in the diagram are iiot, iiotex respectively for http://inter-iot.eu/GOIoTP and http://inter-iot.eu/GOIoTPex.

Target data model in RDF

Tools for analyzing and matching data models (for more, see Tools for Ontology Matching - Practical Considerations from INTER-IoT Perspective.
Tools for RDF visualization.

Prerequisites

Analysis of IoT artifact's data model according to Recipe 1 - Understanding data model.

(How to Do it)

The first step when defining tha alignment between two data models is to visualize and analyze each model. In case of RDF it is quite natural to depict data models as directed graphs where nodes correspond to entities and data values, and edges correspond to properties. You need to understand the meaning and usage context of each element. Basing on this, correspondences can be identified. There are two ways to proceed:

Use one of the available tools that help in extracting simple correspondences, e.g. using syntactic or structural comparators. Summary of tools is available in Tools for Ontology Matching - Practical Considerations from INTER-IoT Perspective.
Analyze both data models "manually" and identify alignments. This approach requires knowledge of both data models, but gives more control over the correspondences identified.

The output of data models mapping via alignment should be a specification how elements from one data model can be expressed in the other data model. That kind of specification can be in any form, e.g. table, in which we identify source RDF pattern, target RDF pattern, and optionally any transformations required on the way. The following table contains three sample correspondences, in which prefix var denotes a variable that is a placeholder for entity or value that can be reused in transformation or target pattern. Normally, such table should be extended to cover all correspondences between data models.

Source pattern	Target pattern	Transformation
var:Device a fw:Entity ; fw:hasName var:Name .	var:Device a fw:Entity ; iiot:hasDescription var:Name .
var:Device a fw:Entity ; fw:hasId var:Id .	var:Device a fw:Entity ; iiotex:hasLocalID var:Id .
var:Device a sosa:Sensor ; fw:hasAttribute [ a fw:Attribute ; fw:hasName "controlledProperty" ; fw:hasValue [ a fw:Array ; fw:hasElement [ a fw:ArrayElement ; fw:hasNumber var:nr ; fw:hasValue var:value ]]] .	var:Device a sosa:Sensor ; sosa:observes var:Property .	var:Property is URI generated from _http://inter-iot.eu/GOIoTPex#_ as prefix and var:value e.g. "temperature" should be _http://inter-iot.eu/GOIoTPex#temperature_.

Note that not all information expressed in one model, can always be translated to the other data model e.g. the concept of brand may be missing from the target data model. In such case, this data is ommitted in mappings. The IPSM semantic translator follows the principle that no data is lost, so even though it will not be translated, it will be kept in the message in it's original form.

Wrapping things up

The result of this recipe is conceptual mapping of two data models that can be later expressed according to IPSM-AF alignment format proposed in INTER-IoT and consumable by IPSM semantic translation tool. Such mapping can be treated as a an input to implementing translation process.