Foreword

Let us consider interoperability on the highest level of software stack. In other words, let us deal with a situation when deployed artifacts "speak different languages" (have different data syntax and semantics), but have to understand each other. For the purpose of this section, without loss of generality, we assume that exchange of information is implemented as messages (message streams). The question we address is: how can we facilitate comprehension of received messages?

Let us now list assumptions that we should be kept in mind when reading this material:

  • No assumption is made about semantics and representation of data in either artifact involved in information exchange
  • We focus only on the process of message translation; in other words, we start from a message that has been formed within the source artifact and conclude when it has been received by the target artifact, in format that it can understand -- we focus on translation of data streams
  • Translation process should allow translation between any number of artifacts that have to communicate in a given context
  • It should be possible to easily add new "topics of conversation" to the served ecosystem
  • Translation may concern information related to the IoT aspects of the ecosystem (e.g. sensors, actuators), as well as domain knowledge (e.g. temperature, humidity, etc.)

Under these assumptions, to achieve semantic interoperability between artifacts the following steps have to be undertaken:

  1. Establish what information is going to be exchanged in each "conversation" that is to take place taking into account "current state" of the ecosystem,
  2. Instantiate modular central ontology, which will cover all "topics of conversation" that are identified in step 1,
  3. Establish ontologies representing data within each joining / data exchanging artifact:
    1. Make sure that complete representation of used explicit ontology is available,
    2. Create from scratch if none is available,
    3. Accept/adapt existing ontology,
    4. Use one of existing tools to facilitate lifting of local data representation to explicit formal ontology,
  4. Within the context of each "conversation" align semantics between ontology of each artifact participating in it and central ontology (i.e. create set(s) of alignments for each upcoming data translation),
  5. Implement syntactic translators,
  6. Configure IPSM, which is the software artifact that will actually perform translation.

Assuming successful completion of the above described steps, the following figure illustrates process of sending a single message from the source to the target artifact. This message is syntactically (twice) and semantically and translated. Obviously, if either source or target artifacts used explicit semantic data representation then appropriate step(s) performing syntactic translation would not be needed.

translation process

Products

Semantic recipes rely on specific software components. Although not all recipes require all software to be installed, it is recommended to use a quick Docker image deployment that includes all components. At the very least, the IPSM core should be installed, with REST and Kafka ports open, to enable its operation. Installation and configuration of each software component can be found in the respective documentation (also liked below for each component specifically).

The semantic software offered by DS2DS layer of INTER-IoT is composed of:

IPSM Core

IPSM is a component for performing semantic translation that can be use in a standalone mode or internally by other products e.g. INTER-MW. It has a REST interface for configuration, and both publish-subscribe and REST interfaces for translation. Performing semantic translation means sending input RDF message, and receiving output RDF message. Client can publish message to input topic of semantic translation channel, and consume message from output topic of semantic translation channel. Another possibility is to use REST API for performing a synchronous semantic translation. Here, client in a request sends input RDF graph, and a sequence of alignments that should be applied. The response contains translated RDF graph. IPSM core installation and configuration is documented here.

IPSM Dashboard

IPSM Dashboard is a web application that covers IPSM REST API with a user-friendly interface. It allows to monitor selected communication channels, and inspect messages transmitted through them. Moreover, it can be used for debugging since it provides interface for synchronous translation with IPSM REST interface. Documentation can be found here.

IPSM-AFE

IPSM Alignment Format Editor (IPSM-AFE) is a CASE tool (web application) supporting the creation and modification of alignments in IPSM-AF format in graphical environment. IPSM-AFE prototype version runs as standalone web application that allows to read, edit, export and validate alignments that later can be used by IPSM in the translation process.

GOIoTP

Generic Ontology for IoT Platforms (GOIoTP) is a core ontology for IoT. Developed as part of the INTER-IoT project, it offers modular data structures for description of entities most commonly appearing in IoT in the context of interoperating various different IoT artifacts (platforms, devices, services, etc). At the same time, GOIoTP is the reference meta-data model proposed by INTER-IoT. The ontology files and documentation are available online.

INTER-MW semantic messaging

A product from another layer of INTER-IoT, namely the middleware interoperability solution INTER-MW comes bundled with IPSM. Internally, INTER-MW uses a semantic messaging library to give access to any RDF message from a Java interface. Although INTER-MW comes preconfigured with GOIoTP as its ontology, the platforms are not restricted in terms of what ontologies they use. Because the semantic components were designed and implemented to be generic and extendable, deeper modifications of INTER-MW are possible, including using a central ontology different from GOIoTP. For more information about INTER-MW see its documentation , and section within this document.