LISSU: Integrating Semantic Web Concepts into SOA Frameworks

Johannes Lipp

1,3 a

, Siyabend Sakik

1 b

, Moritz Kr

oger

2 c

and Stefan Decker

1,3 d

Chair of Information Systems, RWTH Aachen University, Aachen, Germany

Chair for Laser Technology LLT, RWTH Aachen University, Aachen, Germany

Fraunhofer Institute for Applied Information Technology FIT, Sankt Augustin, Germany

Keywords:

Semantic Web Services, Service-oriented Architecture, Semantic Web, Internet of Things.

Abstract:

In recent years, microservice-based architectures have become the de-facto standard for cloud-native applica-

tions and enable modular and scalable systems. The lack of communication standards however complicates

reliable information exchange. While syntactic checks like datatypes or ranges are mostly solved nowadays,

semantic mismatches (e.g., different units) are still problematic. Semantic Web Services and their derivatives

tackle this challenge but are mostly too ambitious for practical use. In this paper, we propose Lightweight

Semantic Web Services for Units (LISSU) to support Semantic Web experts in their collaboration with do-

main experts. LISSU allows developers specify semantics for their services via URI ontology references, and

automatically validates these before initiating communication. It automatically corrects unit mismatches via

conversions whenever possible. A real-world demonstrator setup in the manufacturing domain proves that

LISSU leads to a more predictable communication.

1 INTRODUCTION

In the last decades, the Semantic Web (Berners-Lee

et al., 2001) has gained much popularity. Its extension

called Semantic Web Services (McIlraith et al., 2001),

or SWS in short, captures many types of information

for services, such as data, metadata, properties, ca-

pabilities, interface, and pre- or post-conditions. Re-

searchers proposed a variety of challenges and so-

lutions related to these goals especially during its

golden age starting around 2007. Most of the solu-

tions were never properly used in practice because

other challenges had to be solved there ﬁrst. Service-

oriented architectures (SOA) and its sub-ﬁeld remote

procedure calls (RPC) are promising application areas

for SWS, but had to tackle issues with connectivity,

data availability, and syntax validation at interfaces

during that time. We argue on the one hand that the

SOA research community has overcome most of these

basic challenges and needs semantic information now.

On the other hand, the design of SWS is too complex

and needs to be simpliﬁed to be used in practice.

https://orcid.org/0000-0002-2639-1949

https://orcid.org/0000-0002-5190-5753

https://orcid.org/0000-0001-7476-6226

https://orcid.org/0000-0001-6324-7164

We see our work in the area of SWS but have a

smaller scope, because we aim for concrete and feasi-

ble solutions. Our goal is to resolve real-world prob-

lems in an example scenario from the engineering do-

main, in particular when client and server have a se-

mantic mismatch (e.g., different units). State-of-the-

art solutions do not solve such mismatches and de-

velopers try to tackle this via unstructured, human-

readable data such as comments or documentations.

Existing syntax validations at service interfaces must

be extended with machine-readable semantic ones to

make communication more predictable.

We propose Lightweight Integration of Seman-

tic Web Services for Units (LISSU) as a backwards-

compatible extension to RPC frameworks that, in ad-

dition to syntactic details like datatypes, allows con-

ﬁguration of semantic information including units.

Our extended validation workﬂow detects unit mis-

matches between client and server and even corrects

these via automatic conversions if possible. This pro-

vides an interoperable and consistently predictable

communication among all components, which we

prove in a real-world demonstrator setup with ma-

chine components of a laser system.

The remainder of our paper is structured as fol-

lows. The next section gives a motivating example

and deﬁnes our goals. Section 3 investigates related

Lipp, J., Sakik, S., KrÃ˝uger, M. and Decker, S.

LISSU: Integrating Semantic Web Concepts into SOA Frameworks.

DOI: 10.5220/0010481408550865

In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 1, pages 855-865

ISBN: 978-989-758-509-8

855

work with a special focus on ontologies and SWS.

Section 4 presents our approach and Section 5 shows

a real-world implementation. We conduct an evalua-

tion based on this setup in Section 6 via a demonstra-

tor and ﬁnally conclude in Section 7 with a summary

of our work and possible future work in this ﬁeld.

2 MOTIVATING EXAMPLE

This section motivates the extension of SOA with

semantic capabilities based on SWS by presenting

an example from USP laser system development and

showcasing concrete challenges that we tackle in this

work, particularly unit mismatches.

2.1 Semantic Mismatch (Units)

Within the research project ”Internet of Production”

(Pennekamp et al., 2019), Semantic Web experts and

laser experts collaboratively build a ultrashort pulse

(USP) laser system based on SOA. This includes to

assemble machine parts from different manufacturers

and subsequently achieve an interoperable communi-

cation between these. The very basic idea of USP

could be referred to as ”revers 3D printing”, which

incrementally removes material with high amplitude

laser pulses to form a ﬁnal product. A USP laser

is divided into multiple components such as scan-

ner, movement system, and camera. Client applica-

tions (e.g., a central controller) call remote services

on these components to conﬁgure the laser and exe-

cute actions. The syntax of service calls is validated

with the help of Protocol Buffers (Protobuf), but se-

mantic mismatches are not detected and therefore ig-

nored.

A so-called scanner moves the laser to (x,y)

coordinates based on received ﬂoat values for

position.x and position.y, but the interpretation

of the units is left to the respective implementation of

that service. Figure 1 illustrates a dangerous scenario

of a component change: The former scanner hardware

and its respective service interprets position values as

millimeter and thus moves the laser to an x-position of

2 millimeter. A new component and its respective new

service however could interpret the same data value

as 2 centimeter and thus move the laser wrongly or

even damage the product. Other examples from that

use-case are laser heating temperatures (e.g., Celsius

vs. Fahrenheit) or laser speeds (e.g., millimeter per

seconds vs. kilometer per hour).

The details of that real-world motivating exam-

ple are the following. The currently existing project

uses gRPC (Google, 2016) for the communication

Client

Scanner

Service (old)

Scanner

Service (new)

USP

Position = 2

Move 2 mm Move 2 cm

Figure 1: Unit mismatch we observed during a component

swap at a USP laser system. The new server implementation

internally uses different units and hence moves the laser for

2 centimeters instead of 2 millimeters.

in the network. This allows the serialization of data

with Protobuf, a Data Description Language made by

Google (Google, 2015b). Additionally, the system

uses Bazel (Google, 2015a) as the utilized build tool

to manage dependencies, build the source ﬁles and ex-

ecute the code. The Protobuf ﬁles contain syntactical

descriptions for all the relevant service and messages

for the client server communication by strictly deﬁn-

ing input and output parameters of service calls and

the data types of these parameters in so called mes-

sage deﬁnitions. In the process of utilizing gRPC,

these ﬁles will then be compiled into new ﬁles in the

desired programming language like Python or Java for

the corresponding application, allowing the client and

server to access the deﬁnitions made in Protobuf ﬁles.

There is currently no way to properly include seman-

tics like units into these deﬁnitions.

Developers in this research project have cho-

sen comments and variable names in their Proto-

buf ﬁles as temporary solutions so that the units be-

come visible to the reader. However, this approach

is error-prone and also not machine-readable. The

above-mentioned motivating examples demonstrates

the need to avoid semantic mismatches by properly

deﬁning and validating units at service interfaces.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

856

2.2 Requirements and Goals

The ultimate goal of this work is to overcome se-

mantic mismatches in SOA frameworks by integrat-

ing Semantic Web components into these. In partic-

ular, we aim to extend the existing syntax-only val-

idation to also cover semantics and units in partic-

ular. Developers must be able to conﬁgure this in-

formation for both clients and servers to make ser-

vice calls more predictable. These need to automat-

ically validate the given semantic information before

initiating the actual communication. This additional

veriﬁcation must be backwards-compatible, because

SOA frameworks are usually distributed systems, and

one developer can only modify some of the services.

All interactions with the novel solution must be eas-

ily accessible for domain experts, which are typically

non-experts in the Semantic Web. The manual effort

should be minimized by automating as much as pos-

sible, e.g., validation or correction of used units. Fol-

lowing the Semantic Web best practices, we should

reuse as much as possible, for example units from

well-known ontologies. The proposed solution should

be ﬁeld-proven and easily adoptable to new use-cases.

3 RELATED WORK

This section investigates relevant ontologies and se-

mantic enrichment including Semantic Web services.

3.1 Relevant Ontologies

A basic representation of units of measurement is al-

ready a big step forward. We argue that this is an opti-

mal trade-off between semantic value and complexity

overhead, and analyze relevant ontologies on sensors,

units, and measures. Our analysis reuses existing con-

cepts when possible like proposed in (Gyrard et al.,

2015). We aim for ontology terms that we can reuse

in a modular approach without unwanted side effects

as described in (Lipp et al., 2020). Table 1 presents

the metrics we applied and the ﬁnal ranks for all on-

tologies we analyzed. The metrics are the following.

Relevance determines how well the ontology scope

matches our work, and coverage rates the applicabil-

ity of the ontology’s concepts to our needs. The met-

ric evaluates available programmatic extensions such

as unit conversions. Flexibility rates how well one can

tailor the concepts from the ontology to speciﬁc ap-

plications, e.g., being able to build custom units with

preﬁxes like ”milli”. Note that this rating is speciﬁc

to our requirements and should not be interpreted as a

universal ontology rating.

3.1.1 Sensor Ontologies

The article (Schlenoff et al., 2013) reviews existing

sensor data ontologies to decide if they can be reused

for a manufacturing perception sensor ontology. The

outcome of their work is a review and also an ontol-

ogy. Relevant ontologies mentioned are the Sensor

Data Ontology (SDO) (Eid et al., 2007), which uses

SUMO (Niles and Pease, 2001) as upper ontology,

the OntoSensor ontology (Russomanno et al., 2005)

and especially the Semantic Sensor Network (SSN)

ontology (Compton et al., 2012). The SSN ontology

appears promising for our work and has multiple fea-

tures: Data discovery and linking, device discovery

and selection, provenance and diagnosis, and device

operation, tasking, and programming (Compton et al.,

2012). It allows to focus on sensors, observed data,

system, or feature and property. The SSN ontology

describes sensor networks well but needs to be com-

bined with other ontologies for describing units, like

the ontology Library for Quantity Kinds and Units

(de Koning, 2005).

3.1.2 Unit Ontologies

The Ontology of Units of Measure (OM) (Rijgersberg

et al., 2011; Rijgersberg et al., 2013) allows descrip-

tions of units with all their details and relations to

each other and was developed during the development

of the Ontology of Quantitative Research (Rijgers-

berg et al., 2009). It is based on existing standards

for units of measure such as (Taylor, 1995) and con-

tains units of measure, preﬁxes, quantities, measure-

ment scales, measures, system of units, and dimen-

sions. Any quantities are deﬁned by a measurement

scale, which is a mapping from categories and points

to quantities. Units can then be further scaled with

preﬁxes, making it easier to represent particular val-

ues for a base unit. The unit millimetre for example

is deﬁned as a preﬁxed unit with the unit metre and

the preﬁx milli. Quantities and units have dimensions

and systems of units for their organization. A system

of units deﬁnes a set of base dimensions, which can

then be used to express every other possible dimen-

Table 1: Evaluation of relevant ontologies based on our re-

quirements from Section 2.2 with OM and QUDT ranked

highest. Note that the rating (- / o / +) is speciﬁc for our

requirements and is not a universal ranking.

Ontology Relevance Coverage Features Flexibility

SDO - o - -

OntoSensor - o - -

SSN o + + o

OM + + + o

QUDT + + + +

UCUM + o + o

LISSU: Integrating Semantic Web Concepts into SOA Frameworks

857

sion as a combination of certain base units, like the

International System of Units (Thompson and Taylor,

2008). All other dimensions can then be computed

from these base units.

The Quantities, Units, Dimensions, and Types On-

tology (QUDT) (QUDT, 2014) follows a similar ap-

proach and modularly builds on multiple ontologies.

It covers fewer quantity kinds and units per applica-

tion area than OM, but it allows more ﬂexible conver-

sion multipliers and offsets.

The Uniﬁed Code for Units of Measure (UCUM)

was published in (Eid et al., 2007; Schadow and

McDonald, 2009) covers practically all units used

in science and engineering, while every unit has a

unique identiﬁer. It is possible to validate and convert

datatypes via the UCUM web service https://ucum.

nlm.nih.gov/ucum-service.html#conversion. UCUM

unit codes are referenced in the above-mentioned

QUDT ontology and supports these unit conversions.

UCUM however speciﬁes units and scales less com-

prehensive compared to OM.

We conclude that many ontologies for units in sci-

entiﬁc applications exist. Following the rating de-

picted in Table 1, QUDT and OM are both promis-

ing for work due to their completeness and relevance.

QUDT provides a mature SPARQL Protocol and RDF

Query Language (SPARQL) integration and provides

ﬂexibility by linking to OM and UCUM via additional

identiﬁers within the ontology. OM provides a more

comprehensive structure and has potential to ﬂexibly

adopt to future requirement changes, while the SSN

ontology primarily supports sensors and service calls

instead of units.

3.2 Communication and Service

Description

SWS (McIlraith et al., 2001), their organized peer-

to-peer extensions (Schlosser et al., 2002), and simi-

lar approaches semantically enrich web services and

provide machine-readable markups. Needed descrip-

tions can be written in the Web Service Description

Language, which in (Kopeck

y et al., 2007) was ex-

tended with Semantic Annotations. These annota-

tions refer to ontologies and support lifting and low-

ering mappings between XML messages. A complex

feature set including information, functional, behav-

ioral, and non-functional semantics however compli-

cates lightweight application, which we in fact aim

for. Our approach is even more lightweight than the

lightweight Semantic Web Service descriptions pro-

posed in (Fensel et al., 2011) and (Roman et al.,

2015), which are also available as W3C submission

(Fensel et al., 2010), as they still include functional,

non-functional and behavioral semantics. (Bennara,

2019) introduces a so-called descriptor that adds op-

eration, link, non-functional and service descriptions

to RESTful services via an ontology-based approach.

RPCs allow remotely calling services and passing

parameters (Birrell and Nelson, 1984). Note that this

concept was introduced nearly four decades ago but

has become an active research topic again recently.

Google offers gRPC (Google, 2016), an open-source

high performance RPC framework that has gained a

lot of popularity. Beneﬁts include high scalability,

low latency distributed systems, and developed pro-

gramming languages support. It is recommended to

use Protobuf to describe the syntax of services’ ex-

pected inputs and outputs (Google, 2015b).

One concrete example is an extension of a closed-

source platform for deployment, integration, and or-

chestration digital services with semantic unit infor-

mation (Mart

ın-Recuerda et al., 2020). Proposed fea-

tures include data contextualization by enriching data

with (semantic) information facilitating the under-

standing of the data and its context.

We summarize that the SWS was a very active re-

search area between 2001 and around 2008 but lost

some of its drive. We argue that this is mainly due to

very ambitious goals that could not yet be applied in

practice. Later developments based on RPC solved

crucial basic problems and therefore the chance to

properly combine these research ﬁelds is now.

4 CONCEPT

This section presents our concept to integrate ontol-

ogy terms into a microservice-based SOA system to

handle unit mismatches. That includes an extended

architecture for SOA, novel semantic conﬁgurations,

and an extended communication workﬂow. Our ap-

proach is backwards-compatible and enables a mod-

ular system in which programmatic features and se-

mantic descriptions (e.g., units) can be implemented

in parallel.

Figure 2 depicts a current state-of-the-art setup

building on gPRC on the left, which acts as communi-

cation technology and interface deﬁnition, e.g., stored

in Protobuf ﬁles. In the baseline setup on the left, a

client contacts a server with a service call, which trig-

gers the server to validate the call’s syntax and ﬁnally

execute the service if its checks were successful. We

overcome the lack of semantic validations presented

in the previous sections by extending the SOA frame-

work, as shown on the right side of Figure 2. We

add semantic units to both client and server, which

link to ontologies and use ontology URIs to spec-

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

858

Calls service

Client

Executes service

Server

gRPC + Protobuf

Calls service

Client

Executes service

Server

gRPC + Protobuf +

Semantic checkup

Ontology

links to

Semantic

unit

Semantic

unit

Figure 2: The prior communication on the left only includes a syntactic validation via Protobuf only. Our contribution on the

right adds novel semantic components to both client and server, and upgrades the validation.

ify units in their conﬁgurations. Our extended pre-

communication validation also includes a semantic

check, which compares the ontology URIs from both

communication partners, and only allow service exe-

cution if they match. The following sections present

further details on the architecture and workﬂow.

4.1 Adding Lightweight Semantic

Components to SOA Frameworks

This section explains more details on the components

depicted in Figure 2, namely the semantic unit conﬁg-

uration, ontology references, and novel semantic val-

idations. Section 4.2 then gives even more details on

the semantic validation workﬂow.

As we plan to validate semantic information such

as units between client and server, we add deﬁnitions

to them, which map each entry of their interface def-

initions (e.g., gRPC) to respective units in form of

ontology terms (URIs). The semantic units can later

compare these URIs and only initiate communication

if they match. Note that different other cases such as

mismatches or partial matches exist. Our approach in

this work uses publicly accessible URIs as ontology

links, but one could easily adapt this design to custom

local unit references, too.

Semantic check

service

Return

report

Start

communication

Load server config

Unit conversion

Service

Unit conversion

1.3

1.2

Request

validation

1.1

Server

Client

Figure 3: A client contacts up to two semantic services to

make the subsequent communication more predictable.

We implement an additional step in the workﬂow of

the SOA communication, which is illustrated in Fig-

ure 3. A client initiating a service call ﬁrst undergoes

a semantic check, which compares the client’s seman-

tic speciﬁcations with the server’s one. The client

(1.1) requests validation at the semantic check ser-

vice by transmitting its semantic conﬁguration. That

service (1.2) polls the respective conﬁguration from

the server, matches these and (1.3) returns a valida-

tion report to the client. The client subsequently in-

terprets this report, for details please see the next sec-

tion. If the report includes issues, the client needs to

ﬁx these or abort communication. It can, for instance,

(2) contact a unit conversion service to correct unit

mismatches. Finally, (3) the client starts the actual

communication with the server.

4.2 Semantic Validation Workﬂow in

Detail

A client receives a validation report from the semantic

check service while preparing communication. De-

pending on that report, one or more of the following

actions can be required at the client, as illustrated in

Figure 4.

• Client Conﬁguration Incomplete: The provided

conﬁguration is missing properties required from

the server. The client has to correct it by adding

missing deﬁnitions, usually manually.

• Unit Dimension Mismatch: Correct the dimen-

sions and units used, and try again. Hard mis-

match, e.g., speed in m/s used but temperature in

Celsius expected. Usually ﬁx manually.

• Unit Mismatch: Used the correct dimension but

the wrong unit, e.g., m/s instead of km/h. Use our

proposed unit conversion service to automatically

convert units.

• All Semantics Match: Start the communication.

This workﬂow detects all relevant possible issues

w.r.t. semantic mismatches. While fatal issues such as

LISSU: Integrating Semantic Web Concepts into SOA Frameworks

859

Load server config

Receive client

request

Yes

Client config

complete?

Add missing defintion

Yes

Unit dimension

correct?

Correct dimension

and unit (manual)

Yes

Units correct?

Convert unit

(automatic/manual)

Figure 4: Proposed semantic validation workﬂow, which detects and recovers from semantic mismatches to ﬁnally establish

a predictable communication.

incomplete conﬁgurations or dimension mismatches

usually need to be solved manually, we can automat-

ically resolve unit mismatches within the correct di-

mensions.

5 REALIZATION

In this section, we demonstrate our realization of the

concept proposed above. This includes justifying a

selection of concrete tools based on our requirements.

We then present in detail the implementation of the

two new components: First, the semantic validation

service including a method to specify semantics at

both client and server. Second, a unit conversion

service that allows automatic correction for unit mis-

matches that only reside in the same dimension. Fi-

nally, we suggest a user interaction and workﬂow with

the new system.

5.1 Tool Selection based on

Requirements

As discussed in previous sections, there are multiple

ontologies, data description formats, and additional

software available. For our realization, we choose the

following tools. We use Protocol Buffer and gRPC

to model the interface of services syntactically, and

introduce semantic descriptions (e.g., for units) via

additional JSON ﬁles stored at the client and server.

The reason for additionally using JSON was mostly

because of higher expressiveness and increased hu-

man readability, plus easy integration into many pro-

gramming languages. We integrate Bazel to automate

building and testing of these descriptions.

We select QUDT as the main ontology for the se-

mantic representation of the units of measure, while

keeping the support for OM. We do not require SSN

or any of the other ontologies in our current use-case,

since QUDT and OM already cover all necessary con-

cepts. However, the semantic descriptions do link to

{

" s c an n e r s e r v ic e ": {

" Po s i ti o n " : {

" x " : " q u d t : M i l liM " ,

" y " : " q u d t : M i l liM "

" T i m e " : {

" ti m es t am p " : " wiki : Q 1 4 6 5 4 "

}

Listing 1: Sample of a server conﬁguration that adds

semantic information via ontology URIs to Wikidata and

QUDT, which we shortened to improve readability.

additional ontologies for certain types of data, for ex-

ample the representation of a UNIX timestamp. We

chose QUDT, because it satisﬁes all relevant units of

measure we need and offers a good support for unit

conversions via SPARQL queries. This can be done

by using the Python library rdﬂib (Krech, 2002) or via

other programming languages like Java or Go.

5.2 Extending a Real-world System

with a Service for Semantics

This section introduces implementation details about

the semantic check. The main idea is it to write client

applications with the semantic check in mind. The

client establishes a connection to the semantic server

before it connects to the server it actually plans to

communicate with. The semantic check receives the

client’s conﬁguration together with the service call

and then loads the server conﬁguration ﬁle from the

respective server. All the above-mentioned service

calls and message types are deﬁned through proto

ﬁles while the client and server conﬁguration can be

found in JSON ﬁles.

The conﬁguration of client and server have both

the same unique format consisting of different levels.

These levels can be seen in Listing 1. The ﬁrst level is

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

860

the name of the proto ﬁle which is being considered,

an example for this would be scannerservice. The

next level within the scanner service is then the name

of the message. So far everything is structured like

the corresponding proto ﬁle. The next and ﬁnal level

covers the variables within a message type with the

variable values being URIs linking to the according

ontology and describing the unit of measure belong-

ing to that speciﬁc variable. In case of OM this would

be the URI om:millimetre. In case of QUDT however,

we use qudt:MilliM, since this is the unique identiﬁer

within the Resource Description Framework (RDF)

graph of QUDT and hence can be used for SPARQL

queries to access more details about that speciﬁc unit.

We validate all relevant ﬁelds in the conﬁguration

ﬁles of the server and the client against each other

and build our response to the client accordingly. We

include a new proto ﬁle into the system speciﬁcally

for all the semantic capabilities implemented, includ-

ing the semantic check and the later explained unit

conversion. The semantic check is a gRPC call and

requires the contents of the conﬁg ﬁle as a string as

input and then returns a response message consisting

of multiple parts. A server response with the results of

the check in form of a Boolean, a detailed description

of what exactly went wrong in form of a string and ad-

ditional lists, containing the previously assigned units

and the actually desired units by the server.

5.3 Implementing a Unit Conversion

Service

If the response of the semantic check includes a non-

empty conversion list, the client proceeds by calling

the unit conversion service.

We implement the conversion service with QUDT

units by querying the ontology to extract various

properties of the units which were stored in the con-

ﬁguration ﬁles. While libraries offering unit con-

version functionalities for OM are only available for

Java and Python, we can query data directly from

QUDT via SPARQL with many more programming

languages, giving us even more ﬂexibility.

While the semantic check service only links to the

utilized ontologies, the new unit conversion service

extensively uses QUDTs structure. We know from the

related work section that QUDT uses multiple con-

cepts for the information it provides. For the unit con-

version, the conversionMultiplier as well as the con-

versionOffset form the most important properties. A

unit can only be converted from a speciﬁc source unit

to a destination unit, if the dimensions are the same.

SI base units are used for the dimensions, like in OM.

Especially the dimension property is valuable, by pro-

viding a mean to determine the base unit or to deter-

mine if we are dealing with a measure or scale. This

ensures that conversions are both syntactically and se-

mantically correct and avoids, for example, conver-

sions from pounds (force) to kilograms (mass).

The unit conversion service takes as its input the

lists that were returned with the semantic checks out-

put. This includes for each list entry its identiﬁers,

the source to convert from, and the destination to con-

vert to. Additionally, the client sends its initial values

for these variables. The query extracts the multiplier

and offset of the previously assigned unit to its cor-

responding base, converts the value to the base unit

and then converts the value from the base unit to the

unit desired by the server. The conversion service ﬁ-

nally returns the same input it got previously back to

the client but this time with the converted values. The

client can then proceed to a new semantic check or

start the communication with the server.

5.4 User Interaction and Workﬂow

Adding these new services adds a certain workﬂow

to the system, when designing and implementing new

applications. First, the system needs a server conﬁg-

uration for each server that is running available and

on top of that every client that is being added to the

system needs its own client conﬁguration ﬁle. When-

ever someone implements a new client, they also need

to ﬁll out their conﬁguration ﬁle and have a section

in their code where they load their own conﬁgura-

tion and call the semantic check service with it. The

normal client functionality is then be executed after-

wards if no mismatches occurred. If there were errors

however, the client aborts communication and the de-

veloper needs to adjust the conﬁguration ﬁle and ac-

cording values based on the displayed error message.

Since our error messages show precise details, it is

easy to track down the error and correct it accord-

ingly. This process can be repeated until there are no

errors or mismatches left. Since all errors are shown

immediately all mismatches can be removed in one

iteration.

6 DEMONSTRATOR SETUP

This section evaluates the differences to the previ-

ous state of the system after including the semantic

components, the practical usability of the extended

architecture, and its performance in form of a tech-

nical evaluation of the tools we used. The beneﬁts

will be explained on demo scenarios, showing the sys-

tems behavior before and after including the semantic

LISSU: Integrating Semantic Web Concepts into SOA Frameworks

861

Table 2: Real-world variables with their corresponding

units in ontologies.

variable name type unit of measure

preheatingTemp double qudt:DEG C

laserSpeed ﬂoat qudt:MilliM-PER-SEC

position.x/y ﬂoat qudt:MilliM

shotTime int64 wiki:Q14654

components. We ﬁnish this section with a conclusion

regarding the beneﬁts of semantically enriching such

systems in general.

6.1 Implementation Evaluation

Above we speciﬁed multiple requirements for the ex-

tended state of the USP system. The semantic de-

scription of the utilized data was taken care of by

using ontologies like QUDT and linking to them in

the conﬁguration ﬁles. QUDT and OM sufﬁciently

cover the support for units of measure. The only ex-

ception here are abstract values, for example the time

values utilizing the UNIX stamp instead of regular

time measurement. Hence, the ﬁrst two points are al-

ready covered by the inclusion of the conﬁguration

ﬁles. The unit conversion is taken care of by adding

the unit conversion service utilizing SPARQL queries

on QUDT to the USP system. The new unit conver-

sion service allows the conversion of units as long as

source and destination are both in the same dimen-

sion. Table 2 shows the information that can be found

for every variable after the inclusion of the semantic

capabilities. The unit of the position values being mil-

limeter can now be seen within the system.

In addition to these points, the human understand-

ing of the system is also increased. Someone with

access to the code will be able to much easier under-

stand certain variables just by inspecting their deﬁni-

tion, since everything is linked to a semantic descrip-

tion within an ontology. While this could have been

covered in comments already, an ontology provides

much more in-depth knowledge about certain con-

cepts and even descriptive comments within the ontol-

ogy and additional links to other concepts or even full

ontologies. To conclude we can state that the above-

mentioned requirements are fully satisﬁed by our im-

plementation.

On the technical side of the implementation, how-

ever, there are consequences of our approach. A gen-

eral consequence of including semantics is ﬁrst of all

the increase in data size that has to be dealt with and

slower processing time. Semantic data is included in

text form and contains more data than just telling the

system that a variable has a certain data type. A vari-

able temperature does not just have a value such as

45 and the assigned datatype anymore but instead a

link to an ontology in form of an URI, stored in mul-

tiple conﬁguration ﬁles containing information about

all the important variables across the system. The dis-

tribution and management of these conﬁguration ﬁles

however has still room for improvement as mentioned

in the previous sections and can still change in the fu-

ture. Even in the current form however, the difference

in execution time and used space is barely noticeable.

Querying the ontology takes up most of the additional

time and can be improved by adjusting the ontology

to just our needs in the future. One ﬁnal aspect of

our technical evaluation is backwards compatibility.

Since the usage of the services for the semantic ca-

pabilities is not strictly required, one can still develop

applications without using any semantic services.

6.2 Demonstrating Semantic

Functionalities in Demo Scenarios

The advantages of the extended system with the se-

mantics can be emphasized if we directly compare

the previous state of the system with the new one by

creating and executing a client application with the

old standard and one with the new workﬂow of go-

ing through a semantic check followed by an auto-

matic unit conversion. For this reason, we create three

client applications for a demonstration of the system

capabilities. All three applications have the same goal

of accessing the scanner service in order to call the

JumpToPosition function, which orders the scanner to

move the laser beam to the speciﬁed location on the

scan ﬁeld. For this purpose, the service takes a posi-

tion argument consisting of x and y variables as input

and returns the completion time when the execution

of the service is ﬁnished. The existing server now has

different understandings for the two components of

this communication. The ﬁrst component is the posi-

tion argument with its two values having the units mil-

limetre, while the returned completion time is given in

UNIX stamp. While all three applications eventually

do exactly this, their behavior prior to the actual com-

munication differs indeed.

Scenarios 1 and 2: Only Syntax Deﬁned. The ﬁrst

and second demo applications immediately connect

to the scanner server and request the JumpToPosition

service. The syntactic side is taken care of because of

the strict deﬁnitions of the variables in the proto ﬁles

but for any kind of semantic information the client

must assume that the server uses the same speciﬁca-

tions. In our demo scenario the client sends values

with the knowledge of them being in centimetre and

this then results in the server still interpreting it as a

millimetre value and hence, moving the laser beam by

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

862

a smaller amount than the user wanted.

Scenario 3: Syntax + Matching Semantics. The

second application now uses our semantic compo-

nents. This means the developer of the client appli-

cation also provides a conﬁguration ﬁle with their un-

derstanding of the variable semantic, which explic-

itly states their understanding of the positional argu-

ments being understood as centimetre on the client

side. Since now the ﬁrst thing the client does is con-

necting to the semantic server and making a service

call for the semantic check service, the difference in

the semantic understanding will be spotted and the

client notiﬁed to ﬁx this. However, since the problem

here is a positional argument, taking a length unit, we

identify this speciﬁc problem within the conﬁguration

ﬁle as a problem that can be solved with the unit con-

version service and hence, proceed by calling it with

the position arguments as values to convert and then

proceed with the communication to the scanner with

the converted value. In this scenario we did not just

catch the error but instead also corrected it and pro-

ceeded with the execution of the initial goal without

any problems. In this ideal scenario the developer of

the client application does not need much knowledge

of the server-side semantics himself, instead they can

just program their client by following the workﬂow

proposed in the previous chapter.

Scenario 4: Syntax + Mismatching Semantics. The

third scenario is created by a client application us-

ing the semantic components but with an incomplete

client conﬁguration ﬁle. Even in such a case the se-

mantic check provides its advantages by telling the

user what exactly is wrong with their conﬁguration

and what is missing, while the ﬁrst case would not

even realize the error and just proceed with the faulty

values and cause a more vital error during the exe-

cution on the hardware, resulting in an error in the

production.

Table 3 compares the different scenarios based on

the standards of the system. The ﬁrst and second are

the previous state of the system where only the syn-

tax was taken care of, and still work in every scenario,

since our implementation does not change the Proto-

buf base of the system. However, we improve feed-

back by warning the user that only the syntax is vali-

dated, but there is no semantic information to validate.

The third represents conﬁgurations where the system

has to check for both syntactic and semantic compat-

ibility of client and server before initiating a commu-

nication. In the ﬁrst case we cannot give any informa-

tion on this and start the communication with a risk of

errors caused by an misunderstanding of the system

semantics, while the second case manages to identify

these semantics as correct and initiate the communi-

Table 3: The scenarios compared to each other based on

different standards for the communication in the system.

Scenario Expected Baseline LISSU

1 (y / -) warn comm. warn

2 (n / -) block block block

3 (y / y) comm. comm. comm.

4 (y / n) block comm. block

cation. The third case does give us information by

identifying the semantics in the system as wrong and

blocking the communication. The system should only

initiate a client-server communication when they have

a mutual understanding of the system. The results are

here the same as in our approach, further proving the

advantages of our implementation.

The semantic component mainly plays a role dur-

ing two critical scenarios. The ﬁrst one is when a

newly written client application is introduced into the

system. The developer of the application might have

insufﬁcient knowledge of the system, resulting in a in-

complete conﬁguration ﬁle or the usage of the wrong

units for the arguments within the code. The seman-

tic check would identify this and notify the developer.

The second and more common scenario is a changed

hardware component within the system. The compli-

cations of this were already explained with an exam-

ple in the introduction section of this work. If we

change the hardware of the scanner, we might have

to write a new server code using a different server

semantic, suiting the new hardware. A client code

speciﬁcally written for the old server with no seman-

tics included like our ﬁrst demo application would fail

in such a scenario but the second and third application

would in the worst case at least catch the error and

notify the user that something is wrong and that the

client must update its deﬁnition in order to satisfy the

new system requirements coming with the new hard-

ware.

To conclude the evaluation, LISSU automatically

avoids and corrects unit mismatches, and therefore

leads to a more predictable communication in a SOA

framework. Its backwards-compatibility allows a

ﬂexible integration even into large existing systems.

Unclear cases, where only syntax but no semantic is

deﬁned, yield a warning but still operate. LISSU re-

ports semantic mismatches between client and server

to the calling client and prevents communication if

needed. Although LISSU is completely backwards-

compatible, we recommend applying it to all compo-

nents of a SOA system to improve overall communi-

cation predictability.

LISSU: Integrating Semantic Web Concepts into SOA Frameworks

863

7 CONCLUSION AND FUTURE

WORK

The goal of this work was to handle semantic mis-

matches between services in a SOA framework. We

focused on unit mismatches, as these can already lead

to critical results in practice. We proposed LISSU,

lightweight Semantic Web Services for units, which

allows developers specify semantics (e.g., units) for

their services via URI ontology references. In addi-

tion to existing syntactic validations, we added a se-

mantic validation that detects and corrects unit mis-

matches automatically. The correction can be done

via an automatic unit conversion service that we built

on top of the QUDT ontology in this work.

We demonstrate our approach in a real-world

use-case based on gRPC in the USP laser domain.

Core ﬁndings are that our approach is backwards-

compatible with existing gRPC and other SOA so-

lutions, but adds an additional validation layer based

on semantics. We thereby avoid semantic mismatches

including unit mismatches, and guarantee a more pre-

dictable communication in SOA setups.

There are possibilities to extend our implemen-

tation. First of all the distribution and management

of the conﬁguration ﬁles could be improved. Using

external tools here would come with multiple bene-

ﬁts including easier access to the conﬁguration ﬁles

with possibly even a graphical user interface provid-

ing means to ﬁnd and edit the various conﬁguration

ﬁles in the system. Storing the conﬁguration ﬁles in

databases would, however, require an adaption of the

implementation so far regarding loading and sending

data within the system. Another possibility is to in-

ject these conﬁgurations into microservice orchestra-

tion systems like Kubernetes or Openshift.

Not only the management of the conﬁguration

ﬁles could be further improved, but also their genera-

tion. Instead of manually creating the semantic con-

ﬁguration ﬁles, a conﬁguration generator could guide

developers while creating these, and instantly validate

their structure and completeness. Further improve-

ments could use additional ontologies in the system,

or even introduce domain ontologies to also cover

other semantic mismatches besides units. So far we

only utilize unit conversion capabilities but current

solutions offer more features that could be utilized.

We conclude that LISSU provides a backwards-

compatible semantic extension for SOA frameworks

that is based on Semantic Web Services and leads to

a more predictable communication.

ACKNOWLEDGEMENTS

Funded by the Deutsche Forschungsgemeinschaft

(DFG, German Research Foundation) under Ger-

many’s Excellence Strategy – EXC-2023 Internet of

Production – 390621612.

REFERENCES

Bennara, M. (2019). Linked Service Integration on the Se-

mantic Web. PhD thesis, Universit

e de Lyon.

Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The

Semantic Web. Scientiﬁc American, 284(5):34–43.

Birrell, A. D. and Nelson, B. J. (1984). Implementing Re-

mote Procedure Calls. ACM Trans. Comput. Syst.,

2(1):39–59.

Compton, M., Barnaghi, P., Bermudez, L., Garc

ıa-Castro,

R., Corcho, O., Cox, S., Graybeal, J., Hauswirth, M.,

Henson, C., Herzog, A., et al. (2012). The SSN Ontol-

ogy of the W3C Semantic Sensor Network Incubator

Group. Journal of Web Semantics, 17:25–32.

de Koning, H. P. (2005). Library for Quantity Kinds

and Units: Schema, Based on QUDV Model OMG

SysML(TM), Version 1.2. https://www.w3.org/2005/

Incubator/ssn/ssnx/qu/qu.

Eid, M., Liscano, R., and El Saddik, A. (2007). A Uni-

versal Ontology for Sensor Networks Data. In 2007

IEEE International Conference on Computational In-

telligence for Measurement Systems and Applications,

pages 59–62.

Fensel, D., Facca, F. M., Simperl, E., and Toma, I.

(2011). Lightweight Semantic Web Service Descrip-

tions, pages 279–295. Springer Berlin Heidelberg,

Berlin, Heidelberg.

Fensel, D., Fischer, F., Kopeck

y, J., Krummenacher, R.,

Lambert, D., and Vitvar, T. (2010). WSMO-Lite:

Lightweight Semantic Descriptions for Services on

the Web.

Google (2015a). Bazel. https://bazel.build/.

Google (2015b). Protocol Buffers. https://developers.

google.com/protocol-buffers/.

Google (2016). gRPC. https://grpc.io/.

Gyrard, A., Serrano, M., and Atemezing, G. A. (2015). Se-

mantic Web Methodologies, Best Practices and On-

tology Engineering Applied to Internet of Things. In

2015 IEEE 2nd World Forum on Internet of Things

(WF-IoT), pages 412–417.

Kopeck

y, J., Vitvar, T., Bournez, C., and Farrell, J. (2007).

SAWSDL: Semantic Annotations for WSDL and

XML Schema. IEEE Internet Computing, 11(6):60–

67.

Krech, D. (2002). RDFLib. https://rdﬂib.dev/.

Lipp, J., Gleim, L., and Decker, S. (2020). Towards

Reusability in the Semantic Web: Decoupling Nam-

ing, Validation, and Reasoning. In 11th Workshop

on Ontology Design and Patterns (WOP2020) co-

located with 19th International Semantic Web Con-

ference (ISWC 2020), Virtual Conference, November

01-06, 2020.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

864

Mart

ın-Recuerda, F., Walther, D., Eisinger, S., Moore, G.,

Andersen, P., Opdahl, P.-O., and Hella, L. (2020). Re-

visiting Ontologies of Units of Measure for Harmon-

ising Quantity Values–A Use Case. In International

Semantic Web Conference, pages 551–567. Springer.

McIlraith, S. A., Son, T. C., and Zeng, H. (2001). Semantic

Web Services. IEEE intelligent systems, 16(2):46–53.

Niles, I. and Pease, A. (2001). Towards a Standard Upper

Ontology. In Proceedings of the international con-

ference on Formal Ontology in Information Systems-

Volume 2001, pages 2–9.

Pennekamp, J., Glebke, R., Henze, M., Meisen, T., Quix,

C., Hai, R., Gleim, L., Niemietz, P., Rudack, M.,

Knape, S., et al. (2019). Towards an Infrastructure

Enabling the Internet of Production. In 2019 IEEE In-

ternational Conference on Industrial Cyber Physical

Systems (ICPS), pages 31–37. IEEE.

QUDT (2014). QUDT. http://www.qudt.org/.

Rijgersberg, H., Top, J., and Meinders, M. (2009). Semantic

Support for Quantitative Research Processes. IEEE

Intelligent Systems, 24(1):37–46.

Rijgersberg, H., van Assem, M., and Top, J. (2013). Ontol-

ogy of Units of Measure and Related Concepts. Se-

mant. Web, 4(1):3–13.

Rijgersberg, H., Wigham, M., and Top, J. (2011). How Se-

mantics Can Improve Engineering Processes: A Case

of Units of Measure and Quantities. Advanced Engi-

neering Informatics, 25:276–287.

Roman, D., Kopeck

y, J., Vitvar, T., Domingue, J., and

Fensel, D. (2015). WSMO-Lite and hRESTS:

Lightweight semantic annotations for Web services

and RESTful APIs. Journal of Web Semantics, 31:39–

58.

Russomanno, D. J., Kothari, C., and Thomas, O. (2005).

Sensor Ontologies: From Shallow to Deep Models. In

Proceedings of the Thirty-Seventh Southeastern Sym-

posium on System Theory, 2005. SSST’05., pages 107–

112. IEEE.

Schadow, G. and McDonald, C. J. (2009). The Uniﬁed Code

for Units of Measure. Regenstrief Institute and UCUM

Organization: Indianapolis, IN, USA.

Schlenoff, C., Hong, T., Liu, C., Eastman, R., and Foufou,

S. (2013). A Literature Review of Sensor Ontologies

for Manufacturing Applications. pages 96–101.

Schlosser, M., Sintek, M., Decker, S., and Nejdl, W. (2002).

A Scalable and Ontology-based P2P Infrastructure for

Semantic Web Services. In Proceedings. Second In-

ternational Conference on Peer-to-Peer Computing,,

pages 104–111. IEEE.

Taylor, B. (1995). Guide for the Use of the International

System of Units (SI): The Metric System. DIANE Pub-

lishing.

Thompson, A. and Taylor, B. N. (2008). Guide for the Use

of the International System of Units (SI). Technical

report.

LISSU: Integrating Semantic Web Concepts into SOA Frameworks

865