INTER-LAYER – Data and Semantics to Data and Semantics (DS2DS): Translating data with IPSM

(Getting Ready) Scenario description

Let's assume that we have IoT artifact that publishes messages in its dedicated RDF format, and INTER-IoT ecosystem. The messages are to be consumed and understood by other ecosystem members. To this aim, semantic translation between RDF data models should be performed by Inter-Platform Semantic Mediator (IPSM) component. IPSM performs alignment-based semantic translation of RDF messages.

Recipe ingredients

Prerequisites

(How to Do it)

IPSM performs the translation based on alignments that are part of its configuration. Each alignment defines uni-directional mapping between two RDF graphs. In INTER-IoT, it is assumed that in each ecosystem exists a Central Ontology - a common data model used to enable shared understanding in the ecosystem. When new IoT artifact wants to join the ecosystem it has to create alignment to and/or from Central Ontology depending on one- or two-way communication will be needed. Semantic translation in IPSM uses the concept of translation channels that are created between any two parties that want to communicate. Each channel requires two alignments: 1) from source IoT artifact to Central Ontology, 2) from Central Ontology to target IoT artifact. Note, that IPSM supports IDENTITY alignment, that leaves the RDF graph in the message unchanged.

There are two ways to translate with IPSM: 1) using publish-subscribe communication infrastructure based on Apache Kafka, 2) use REST API (directly or via IPSM Dashboard). The former is recommended for executing translation in production environment, the latter is recommended for testing purposes.

(How it Works)

Translation based on publish-subscribe mechanism means that we need to: 1) configure IPSM, 2) publish message to the input topic, 3) consume translated message from the output topic. IPSM configuration can be done with REST API or through IPSM Dashboard application. First, all necessary alignment need to be uploaded (REST POST post_alignment operation). All uploaded alignments can be listed with REST GET alignments operation. Next, translation channel needs to be created with REST POST channels operation. Creating alignments requires parameters: source and sink topic names (for publish-subscribe communication), input and output alignments names and versions:

{
  "source": "string",
  "inpAlignmentName": "string",
  "inpAlignmentVersion": "string",
  "outAlignmentName": "string",
  "outAlignmentVersion": "string",
  "sink": "string",
  "parallelism": 1
}

When translating message with semantic translation channel first the input and the the output alignments are applied. To translate a message any Apache Kafka client publisher and subscriber can be used.

Translation based on REST can be done with IPSM Dashboard application. The instruction is available here. This method is recommended for testing alignments on single messages, but because of efficiency it is not recommended for handling streams of messages.

Another way, to translate a message is to use REST translation operation directly or via Swagger inetrface. Parameters are list of alignments to be applied and stringified input RDF graph:

{
  "alignIDs": [
    {
      "name": "string",
      "version": "string"
    }
  ],
  "graphStr": "string"
}

Wrapping things up

This recipe describes what is needed and what are the ways to semantically translate messages with IPSM. There are different ways of accessing IPSM, and here references to respective pieces of documentations are given.