INTER-LAYER – Data and Semantics to Data and Semantics (DS2DS): Understanding data

(Getting Ready) Scenario description

Lets assume that as an IoT integrator we have an artifact that should be connected to the INTER-IoT ecosystem. This artifact may publish and/or consume data. Obviously, IoT artifacts already connected to the ecosystems use own data models internally, whereas the central data model is used in the INTER-IoT ecosystem to exchange messages between artifacts.

The first step in the integration process is understanding data models, specifically:

• What data should be exposed to the outside word? Does it cover whole data model or only part of it?

For example, IoT artifact may store data about machinery configuration, status, maintenance and measurements, however only the latter should be published to the outside world. In such case, there is no need to analyze whole data model for integration, but one can focus only on the subset related to measurements.

• What is the data format used?

Data format used internally for parts of the model that is to be exposed to the outside needs to be determined.

• How is the semantics expressed? is it formally modelled?

Depending on the data format (syntax) it should be verified if semantics (meaning and relations of entities) are formally expressed e.g. we can have XML data with XSD as formal data model documentation, or JSON with JSON Schema. On the other hand, we may have JSON but only with informal descriptions of usage.

Here, lets assume that we have an IoT platform (based on FIWARE) that gathers data about sensors that should be available in the INTER-IoT ecosystem. Each sensor is characterized by id, producer data, type and controlled properties. In this recipe, we show how to analyze such data when JSON format is internally used by the platform.

Recipe ingredients

• Editor or data vizualization tool depending on the data format used.

Prerequisites

• Part of the data model that is considered for integration and should undergo detailed analysis should be selected.

(How to Do it)

Assuming that internal platform data is persisisted in JSON, there may or not exists a documented model according to which this JSON is structured. In case of FIWARE-based IoT platforms, a popular approach is to use FIWARE Device Model. A sample sensor description can look like:

{
    "id": "myDevice-wastecontainer-sensor-345",
    "type": "DeviceModel",
    "category": {
        "value": ["sensor"]
    },
    "function": {
        "value": ["sensing"]
    },
    "modelName": {
        "value": "S4Container 345"
    },
    "name": {
        "value": "myDevice Sensor for Containers 345"
    },
    "brandName": {
        "value": "myDevice"
    },
    "manufacturerName": {
        "value": "myDevice Inc."
    },
    "controlledProperty": {
        "value": ["fillingLevel", "temperature"]
    }
}

After an inspection of such sensor description we can identify main concepts and relations among them. Here, a key concept is a device that is characterized with properties such as category, name, function, etc.

Wrapping things up

Uunderstanding data is a preliminary step to set up data interoperability. Once a relevant part of data model is selected, it needs to be analyzed to understand concepts with their meanings and relations between them.