=Paper=
{{Paper
|id=Vol-2063/sisiot-paper4
|storemode=property
|title=A Model Driven Approach Accelerating Ontology-based IoT Applications Development
|pdfUrl=https://ceur-ws.org/Vol-2063/sisiot-paper4.pdf
|volume=Vol-2063
|authors=Charbel El Kaed,Andre Ponnouradjane
|dblpUrl=https://dblp.org/rec/conf/i-semantics/KaedP17
}}
==A Model Driven Approach Accelerating Ontology-based IoT Applications Development==
https://ceur-ws.org/Vol-2063/sisiot-paper4.pdf
A Model Driven Approach Accelerating Ontology-based IoT
Applications Development
Charbel El Kaed André Ponnouradjane
Schneider Electric, IoT & Digital Transformation Schneider Electric, IoT & Digital Transformation
first.last@schneider-electric.com first.last@schneider-electric.com
ABSTRACT Despite its potential and promises, semantic technology and
The Internet of Things promises several exciting opportunities and ontology-based IoT applications still remain in the hands of a mi-
added value services in several industrial contexts. Such opportuni- nority, the ontology experts, being too difficult to be adopted and
ties are enabled by the interconnectivity and cooperation between applied by industrial practitioners. We attribute such retention
various things. However, these promises are still facing the inter- among other factors to the absence of adequate methodology and
operability challenge. Semantic technology and linked data are tools involving several major actors participating in the design life-
well positioned to tackle the heterogeneity problem. Several efforts cycle of an IoT application, who are typically non-ontology experts.
contributed to the development of ontology editors and tools for Thus, we propose in this work a model driven methodology along
storing and querying linked data. However, despite the potential with a software module approach that aim at removing barriers
and the promises, semantic technology remains in the hands of for IoT developers and accelerating the adoption of semantic tech-
the few, a minority of experts. In this paper, we propose a model nologies. Our proposed module is validated based on the SAREF [5]
driven methodology and a software module (OLGA) that completes ontology.
existing ontology development libraries and frameworks in order to The rest of this paper is organized as follows, first, we depict
accelerate the adoption of ontology-based IoT application develop- some of the existing frameworks for developers in the related work
ment. We validated our approach using the ETSI SAREF ontology. section. Then, we share our experiences while working on IoT-
based solutions with our internal teams and outline the motivation
behind this work. In sections 4 and 5, we propose our methodology
KEYWORDS
along with a software module OLGA to accelerate the ontology-
Internet of Things, Ontology, Model Driven Engineering based IoT development. Section 6 provides the implementation and
evaluation of our solution. Finally, we conclude and discuss future
work in section 7.
1 INTRODUCTION
The Internet of Things (IoT) is expected to interconnect, at massive
2 RELATED WORK
scale, numerous sensors, devices, gateways, and systems to tackle We split the available libraries and frameworks in various program-
many challenges in the industry [15]. Such inter-connectivity will ming languages for ontology-based development in two categories,
play an essential part in designing industrial systems with added i.e., serializers and Object Relational Mappers (ORMs).
value services which are more energy efficient with lower costs
while contributing to a better environment. These promises pro- 2.1 Serializers
moted by the emergence of the industrial Internet of Things (IoT) Serializers provide reading/writing from/to an ontology file, a SPARQL
have surged the importance of interoperability among the things endpoint, or a persistent RDF store. RDF Serializers are imple-
to turn this vision into reality. mented in various programming languages, such as OWL API [25],
Designing IoT applications requires a shared understanding of RDF4J [26], and Jackson-Jsonld [18] in Java, dotNetRDF [30] in
the exchanged data among those connected things. Semantic tech- .Net, Redland [28] in C, and RDFLib [27] in Python. The serializers’
nology, is one of the most promising fields in the knowledge rep- APIs provide low level classes and functions to manipulate con-
resentation domain, expected to enable interoperability in the IoT. cepts directly mapped to the Rdf language without any higher level
The World Wide Web Consortium (W3C) defines a set of standards , abstractions. Therefore, it is required by any IoT developer to be
such as RDF, OWL and SPARQL [11, 38, 42], to represent semantics aware of the technical aspects and theory of the RDF concepts and
and query linked data, offering an ideal ecosystem and opportunity principals in order to implement ontology-based IoT applications.
to tackle the heterogeneity challenge in the IoT. In industrial envi- We discuss in the following the serializers offering basic code
ronments and automation domains, semantic technology has been generation through a plugin which takes an ontology as an input
used to solve data interoperability issues [14, 24] and to provide and generates some code facilitators or stubs.
context aware applications and services. The Protégé code generation plugin [34], which can be easily
In addition to the W3C standardization activities, several ef- integrated in Protégé [7] provides generation of Java code based
forts contributed to the development of the ontology editors [7], on the OWL API [25]. However, the code generation is partial
storage [6], inference engines, as well as graphical tools to repre- where only the class name and interface are provided along with
sent, edit, and query linked data. Furthermore, serializers such as an empty constructor. Then, it is up to the developer to complete
RDF4J[26] and Object Relational Mappers such as RomanticWeb [33] the generated code by relying on the OWL API which requires a
are available for developers that are not ontology experts. learning curve since it is directly mapped to the RDF concepts.
Figure 1: Part of the Ontology Representation [9, 19]
The RDF4J Schema generator [36] extends the RDF4J [26] API which enables dynamic queries execution. In fact, compared to
and provides an automatic generation of an RDF schema from an other ORMs, this feature is similar to invoking SPARQL queries in
ontology. The generated output of the ontology is contained in the implementation methods. AliBaba highlights a java code gener-
one java file which contains only the IRI of each concept of the ator which seems to handle simple ontologies, it failed to generate
ontology. In other words, the code generation is flat, there are no code when tested with the SAREF ontology [32]. AliBaba provides
classes, associations, or constraints between the generated elements. interesting concepts for ontology based development, however, it
It is up to the developer to implement the association, mapping, is clearly targeting ontology and not IoT developers since RDF and
and constraints manually. SPARQL are part of its APIs and design.
AutoRDF [4] extends the Redland [28] library and proposes a KOMMA relies on the Eclipse Modeling Framework (EMF) [10]
generator which takes an ontology and generates C++ object ori- and is inspired by AliBaba’s design. KOMMA provides a unified
ented code to manipulate RDF concepts. The generated code is an framework with the following three layers: an object mapping per-
abstraction layer which consists in a set of functions based on the sistence layer, visualization tool, and an ontology editor based on
ontology classes and relations available to be used by developers the capabilities of the EMF. KOMMA mentions a code generator
to generate ontology instances (A-Box). plugin, however, it is not integrated in visualization and editing
layers, therefore, the mapping and implementation of the interfaces
2.2 Object Relational Mappers (ORMs) remain manual. KOMMA’s unified approach clearly targets ontol-
ogy developers with the integration of the three layer in a common
ORMs are built on top of serializers and provide an object ori- framework. A learning curve is expected from an IoT developer for
ented abstraction layer allowing developers to manipulate objects both the ontology editing and the object mapping which consists
instead of RDF concepts. Several ORMs are available in various in decorating the code with concepts from the ontology.
programming languages, such as KOMMA [23], Empire [17] and In the following, we depict our industrial context, the feedback
AliBaba [29] in Java, RomanticWeb [33] and TrinityRDF [40] in .Net, from our teams regarding ontology-based development, and the
and RDFAlchemy [35] in Python. ORMs rely on the code decoration lessons learned.
where a developer annotates her code with tags referencing IRIs
from the ontology terminology (T-Box). Most of the Java ORM rely 3 INDUSTRIAL CONTEXT & LESSONS
on the Java Persistence API (JPA) [16] while the .Net ORMs rely
on the Entity Framework [8]. During the code implementation of
LEARNED
an application, the developer requests a factory to instantiate the This section briefly outlines our industrial context capturing part of
ontology (A-Box) and can formulate SPARQL queries by relying on our lessons learned while prototyping with several of our internal
SPARQL query builders or adapters such as the LINQ to SPARQL teams applying semantic technologies in several domains such as
in the .Net domain. the Smart Buildings and Smart Factories.
We discuss in the following the ORMs providing some code Schneider Electric is a world leader in Energy Management and
generation features. heavily involved in the IoT and the digitization of its various prod-
AliBaba [29] offers the three following interesting features for ucts. The EcoStruxure1 program proposed by Schneider Electric, is
ontology developers. a) The object server exposes the object factory an open, interoperable, IoT-enabled system architecture and plat-
through a REST API putting the available objects as resources on form. EcoStruxure serves our business units which are grouped
the web for manual annotation. b) The aspect behaviors which according to the following six domains of expertise [2] : Building,
allow each object of the factory to intercept a method call and ex- Power, IT, Machine, Plant, and Grid. Our innovation department is
ecute a specific behavior. Annotation such as precedes provides involved in the EcoStruxure program and accompanies any team
the developer with a better control with the behavior execution 1 http://www.schneider-electric.com/en/download/document/998-19885906_
flow. c) SPARQL queries decoration on the getter/setters of objects GMA-US_ESX/
2
Figure 2: Proposed Methodology
from the six domains in their IoT and digitization journey. Part have been proposed regarding energy modeling and access such as
of our mission is to investigate new technology and apply it to Siemens Work [24], SPITFIRE [12], and the Optique Platform3 .
our industrial context in any of the domains of expertise. Seman- Based on these two factors, we started an internal Ontology
tic technologies is one the most promising approaches to provide Workshop [37] targeting our teams across business units. The aim
interoperability in the IoT domain. Therefore, we collaborate with is to demystify the ontology development for our internal prod-
those internal teams to enable faster IoT interoperable solutions by uct owners, architects, and developers by providing a theoretical
applying semantic technologies such as in [9, 19, 21]. presentation and two hands on lab sessions. The first lab session
Two main factors captured the curiosity and the interest of our involves modeling a simple ontology (T-Box) in Protégé [7], similar
internal teams and communities regarding ontology-based IoT ap- to the ontology shown in Fig. 1. The second session handles the in-
plications development. stantiation of the model (A-Box) and formulating queries to extract
First, the proven technical feasibility of ontology-based vertical data, as shown in Fig. 1 (Ontology Instance), by relying on one of
and horizontal solutions in our industrial context. Several ontology- the available RDF development libraries depicted in the previous
based proof of concepts have been designed demonstrating the section.
added value in two operating modes: vertical and horizontal de- We outline the lessons learned from these workshops in relation
ployments. The vertical silo mode is the classical sensor to gateway to this work:
or device/system to cloud combined with a domain specific applica- (1) Learning curve is a luxury: relying on ontologies is powerful
tion [20, 21]. The horizontal mode consists of integrating different to represent internal systems topology such as the inter-
silos (verticals) driving cross domains interoperability among sys- connectivity between the devices and sensors, their physical
tems and devices. For example, in [9, 19] two industrial systems, a locations, and their functional interactions. However, using a
building management and a power solution systems, are connected serializer requires knowing in detail the ontology languages.
to the cloud. Then, an adaptation layer exposes the two systems The Object Relational Mappers provide a very interesting ab-
information through an ontology representation to be consumed by straction, however, a mapping is still required through code
a business intelligence layer to extract advanced buildings insights. decoration. Thus, there is a necessary learning curve to use
Furthermore, FOrTÉ [9] a cloud based federated query ontology the ontologies in the IoT development that most of the teams
and timeseries engine is deployed enabling big data queries for do not have. IoT developers would leverage a Just Instantiate
business and machine learning applications. and Link library that they can import into their development
Second, the emergence of domain specific ontologies in the environment, where the concepts and relationships of the
industry and standardization bodies. For example, in the Smart ontology model (T-Box) are provided. Once such library is
Buildings domain, ontologies such as SAREF [5] and its exten- imported, they can instantiate the ontology concepts and
sions2 , Haystack [3], and Brick [1] have emerged. In addition, efforts link them together (A-Box). Such library can rely on the
2 http://ontoology.linkeddata.es/publish/saref4bldg/ 3 http://optique-project.eu
3
existing SDKs and libraries presented in the related works which can be declared as transitive. The experts can reuse or extend
section. existing ontologies, after several iterations [13], they converge on
(2) Programming Languages: the diversity of our business units a stable model (T-Box).
and offers translates into the diversity of the skill set of our The Ontological model is then provided to an Ontology Library
teams which rely on different programming languages to GenerAtor (OLGA), detailed in the next section. OLGA takes an
implement IoT-based applications ranging from embedded ontology and its imported ontologies along with a selection of the
devices (c, c++, python), systems (c++, .net, java) to cloud desired library or framework depicted in section 2. The output of
applications. Therefore, such Just Instantiate and Link library OLGA is a generated library conforming to the Ontology Model
must support various dependencies to third party libraries previously defined and ready to be used by an IoT developer.
and programming languages. The generated library hides all the ontology complexity and en-
(3) Query Language: storing and retrieving data on a system ables IoT developers to instantiate and link the ontology classes and
or cloud is considered essential. The IoT development com- relations previously defined by the Ontology and Domain Experts.
munity is often seen divided regarding the query language The generated library can depend on a serializer or an object rela-
between pro and anti SPARQL. Some developers are familiar tion mapper library. It is used by any IoT developer and is embedded
with query languages such as SQL or LINQ and advocate for into a device, system, or an IoT cloud application. Once integrated
their reuse in the IoT ontology-based development. Other de- into an existing system or device, it can have several usage. For
velopers embrace the power of SPARQL and the necessity of example, in a commissioning software of a Building Management
evolving the query language since the underlying structure System [9, 19], it enables to instantiate an ontology model of a
has also evolved and is no longer tabular. Alternatives such system for a given facility. The ontology instance captures several
as simple query languages in SQenIoT [21] or visual query aspects of the system as shown in Fig. 1 (A-Box). It can then be
builders such as in [41] can be proposed to handle queries sent along with the model to a cloud storage where a business
or to generate SPARQL through a visual tool and use it in application layer or an IoT cloud-based application can query and
the IoT development. extract information about a specific Smart Building to drive better
In the rest of this paper we propose our approach facilitating the insights as detailed in [9, 19]. At the cloud level, a developer would
ontology-based application development focusing on the first two also import a library generated by OLGA supporting his choice of
items depicted earlier. the programming language and technology. The generated library
conforms to the same ontology defined by the experts and will be
4 A MODEL DRIVEN METHODOLOGY used to interact with the RDF store to load and query instances of
the model to fulfill the cloud application requirements.
Based on the feedback gathered from our internal teams, we pro-
This methodology enables the separation of aspects and roles,
pose the following model driven methodology, shown in Fig. 2, for
and places the complexity in areas where it can be solved by relying
ontology-based IoT application development. We identify the three
on adequate tools and domain expertise. A domain expert has both
following major roles involved in the IoT development and leverage
an overall and specific knowledge about a specific system and
their expertise and strength:
domain. An ontology expert is modeling practitioner but lacks
(1) Ontology Expert: is an ontology practitioner. Has experience the overall system’s vision and domain knowledge expertise. And
in the ontology development tools, languages, and storage finally, IoT developers can now select the programming language
infrastructure. His main tasks consist in assisting the domain and the framework of their choice to implement ontology-based IoT
expert in capturing the concepts to be used in an IoT applica- applications by relying on the generated library which conforms
tion deployed in a specific domain. He creates the ontology to the ontological model without the complexity of the ontology
concepts and relations (T-Box), and proposes an ontology. languages.
(2) Domain Expert: is a product owner and/or a technical archi- In the following section, we detail the Ontology Library Gener-
tect. Has a global and specific knowledge on how a specific Ator (OLGA).
system is deployed, commissioned, and operated, such as the
Building Management System. She articulates the main con-
cepts and the relations of a system to the Ontology Expert. 5 OLGA: AN ONTOLOGY LIBRARY
(3) IoT Developer: implements an application following the on-
GENERATOR
tology model previously defined by the Experts. Imports a
library containing the concepts and possible relations previ- OLGA is a multi-library code generator, as shown in Fig. 3, it takes
ously defined to instantiate the model. Her implementation two parameters as input: one or more ontologies since an ontology
is integrated in a cloud application or an embedded device. can depend on other ontologies and a choice of a library dependency.
In fact, the generated library will depend either on a serializer or a
The methodology shown in Fig. 2 is initiated by both the On-
an object relational mapper. Thus, OLGA completes already existing
tology and Domain Experts (Product Owner and Architect). They
libraries and frameworks, those depicted in section 2 by providing
first identify and draw the scope of the IoT application based on the
IoT developers with the variety of choice for the development of
gathered requirements from end clients and users. Then, the main
ontology-based IoT applications. OLGA enables the possibility for
concepts and relations of the application are extracted, for example,
an IoT developer to choose and reuse existing open source libraries
in a Smart Buildings domain, a Floor and a Room are two different
(serializers or ORMs) while offering an abstraction and a simpler
concepts related to each other with the contains object property
4
Figure 3: OLGA’s Architecture
library to use which conforms to an ontology model previously Model: allows capturing the ontology information (T-Box) inde-
specified by the experts. pendent of any targeted library or programming language. Sepa-
rating the model from any targeted implementation offers OLGA
a huge flexibility making the support for an additional language
<#if consolidatedImports??>
<#list consolidatedImports as import>
or a dependent library simply a matter of adding templates. The
using ${import}; model is populated by the visitor, consists of a representation layer
which captures all the elements of an ontology, it is inspired by the
work of Kalyanpur et al. [22]. The model is shown in Fig. 4. All the
namespace ${Zclass.getPackageName()} elements inherit from the super class Node which is identified by
{ an IRI and a name parameter.
[Class("${Zclass.Iri()}")]
public interface I${Zclass.ClassName()} Each Class can have none (owl:Thing) or multiple super classes
<#if Zclass.SuperZClassList()??> populated by the visitor based on the owl:SubClassOf. The names-
<#if Zclass.SuperZClassList()?has_content> :
<#list Zclass.SuperZClassList() as
pace, packageName, and className are extracted based on the Class
SuperZClassCurrentElementOfList> IRI for the code generator .
I${SuperZClassCurrentElementOfList.ClassName()}<#sep> , A Class may have none or several ObjectProperties, as shown
<#else>: IEntity in Fig 4. The visitor populates the following parameters for each
ObjectProperty: a restriction type (owl:AllValuesFrom), an op-
tional restriction cardinality (owl:minCardinality), a restriction
{
<#if listDataProperties??> number associated with the cardinality, a possible one or more
<#list listDataProperties as DataPropertyList> characteristic of the property (owl:TransitiveProperty), and an
[Property("${DataPropertyList.DataProperty()}")]
${DataPropertyList.RangeXSDType()}
optional expression (owl:UnionOf). An ObjectProperty associates
${DataPropertyList the following concepts:
.DataPropertyShortForm()?capitalize}{ get; set; }
• Class-to-Class(es): one or several range classes depending
on the restriction type and the expression. For example, a
Building contains Some Floor.
}
• Class-to-Individual(s): one or several range individuals de-
<#if listObjectProperties??> pending on the restriction type and the Expression. For exam-
...
ple, a TemperatureMeasure Class hasUnit Degree_Celsius
} Individual.
• Individual-to-Individual: the restriction type, cardinality, ex-
Listing 1: Part of the template used by OLGA to generate pression, and characteristic are not populated by the visitor
RomanticWeb-based C# code when an individual is associated to another individual. For
example, a Building1 contains Floor1. Only the name pa-
rameter is used in the ObjectProperty for the code genera-
OLGA consists of the following modules: tion.
Importer: loads into memory one or more ontologies and merges An Individual is an instance of a class. The visitor fills the names-
them into one ontology easier to visit. pace and the packageName for the code generator based on its
Visitor: traverses all the elements of a given ontology provided IRI.
by the Importer. The visitor crosses the following elements: Classes, When a DataProperty is associated with an Individual, the visitor
ObjectProperties, DataProperties, Individuals, Literals, and the var- populates only the range (Literal). However, when the DataProp-
ious axioms to populate the internal model shown in Fig. 4. erty is associated with a class, the visitor populates in addition to
5
Figure 4: OLGA Internal Model - UML Object Diagram
the previous parameters, the restriction type and the restriction In the case of a selected serializer dependency, interfaces and
cardinality. their implementations are generated since a serializer do not pro-
Templates: are arranged by library dependency, a serializer vide a factory to instantiate/implement a class. OLGA handles mul-
(Jackson-Jsonld [18], RDF4J [26]) or ORM (RomanticWeb [33], RD- tiple inheritance and composition by propagating the functions’
FAlchemy [35]). As shown in listing 1, each template contains a implementations from the extended interfaces into the implemented
code snippet written according to a programming language syntax classes and by relying on the Override annotation in Java (or simi-
(Java, C#, Python, or others) and holds several information awaiting lar) annotations in other programming languages.
to be filled from the model such as the imports declaration of pack- Compiler & Packager: once the code is injected into the tem-
ages related to the dependent library, name of the class/interface plates, the generator creates files containing the expected code.
to be generated. In addition, each of the data and object property Then, the compilation and packaging phase can start. According
will be transformed into a parameter with getter/setter functions. to the selected library and its programming language a compiler is
These templates will be loaded in memory by the Generator and loaded. Once the compilation ends successfully, the packaging is
the code snippets will be completed according to the information triggered to prepare the adequate format (.jar, .dll, .whl, or others).
populated in the model. Once the generated library is packaged, it can be imported and
Generator: based on the selected library dependency, adequate ready to be used by any IoT developer. An example of a SAREF
templates are loaded into memory to initiate the code generation generated library is provided in Listing. 2, where an IoT developer
from the populated model. The Generator injects the information can Just Instantiate and Link, an Idegree_Celsius is refereed to, then
from the model into the templates. The separation between the an indoor measurement is created and linked to a specific instance
model and the templates provides flexibility and makes supporting of a Temperature Sensor.
an additional library a matter of templates extension. The code implemented by the IoT developer can be deployed on a
In the case of a selected ORM dependency, each Class and Indi- cloud connected device or gateway such as in [20, 21]. However, on
vidual of the ontology will be generated into an interface. In fact, an systems with more abundant resources such as a Building Manage-
ORM library provides a factory allowing developers to instantiate ment Server, a generated library dependent on an object relational
the interfaces into objects. OLGA handles multiple inheritance and mapper can be used since such systems can host local applications
composition by generating interfaces extending other interfaces. which can interact with a local RDF store such as in [19].
This makes the code generation simpler since only the interfaces
need to be generated. Developers will rely on the factory to instan- 6 IMPLEMENTATION & EVALUATION
tiate their objects based on the generated interfaces, therefore, the OLGA is implemented in Java 8 and relies on the OWL API [25]
ORM’s factory will handle multiple extensions of the interfaces and to import and merge one or more interdependent ontologies. The
their declared functions. visitor module relies on the OWL API as well to traverse the merged
6
Lib/Time Overall Code Gen. Compile (ms) public static void Create_SAREF_Topology()
{
RomanticWeb 14 sec 201 ms 516 ms 05 sec 317 ms string clientURI = "http://www.saref.instance/example";
RDF4J 45 sec 109 ms 680 ms 39 sec 59 ms
//refer to the unit
Jackson-Jsonld 24 sec 187 ms 639 ms 19 sec 05 ms Idegree_Celsius degreeCelius = context
RdfAlchemy 16 sec 544 ms 526 ms 9 sec 122 ms .Create(new Uri(clientURI + "#1"));
Table 1: Code Generation Evaluation for SAREF by OLGA //Create a measurement from the factory
IMeasurement indoorTemperature = context
.Create(new Uri(clientURI + "#2"));
indoorTemperature.AddIsmeasuredin_Only_UnitOfMeasure
.Add(degreeCelius);
ontology and populate the model shown in Fig. 4. The Generator indoorTemperature.Hasvalue = 32;
depends on the FreeMarker [39] Template Engine and the templates indoorTemperature.Hastimestamp = DateTime.UtcNow;
are written in the FreeMarker Template Language. FreeMarker
//Link it to Temperature
offers a powerful and flexible mechanism to inject parameters from ITemperature temperature = context
our model into the templates to generate code files. The Compiler .Create(new Uri(clientURI + "#3"));
temperature.AddRelatestomeasurement_Only_Measurement
and Packager module relies on three Maven plugins depending on .Add(indoorTemperature);
the selected programming language, .Net4 , Java5 , and Python6 . In
fact, OLGA generates the adequate pom.xml file which is then used //Create a Temperature Sensor
ITemperatureSensor temperatureSensor = context
with the correspondent Maven plugin to compile and package. .Create(new Uri(clientURI + "#4"));
The list of supported dependent libraries is expected to grow temperatureSensor.Hasmanufacturer = "CompanyA";
with time based on the adoption and requests from our internal temperatureSensor.Hasmodel = "M321";
temperatureSensor
teams. So far, OLGA supports the java-based serializer Jackson- .Hasdescription = "Low range Zigee temperature sensor";
Jsonld [18], RDF4J [26], and the ORMs RomanticWeb [33] and RD-
//add its measurement
FAlchemy [35]. temperatureSensor.AddMakesmeasurement_Only_Measurement
The Smart Appliances REFerence ontology (SAREF) [5] was .Add(indoorTemperature);
selected to validate the generated libraries. SAREF imports the Time
// commit data to factory
Ontology7 . The two ontologies are loaded and merged by OLGA, the context.Commit();
merged ontology contains 117 classes, 63 Object Properties, 31 Data }
Properties, and 55 Individuals. Four libraries are generated based on
SAREF with a dependency to Jackson-Jsonld, RDF4J, RDFAlchemy, Listing 2: Example of SAREF instantiation code [31] in C#
and RomanticWeb. For each of the generated library, the following by an IoT developer
is provided on the external github [31]:
(1) Packaged generated library in .dll and .jar formats.
(2) Generated source code in C#, Java, and Python. ORM since for a serializer OLGA generates interfaces and their
(3) Generated ontology instance (A-Box) of an instantiation implementation classes while for an ORM only the interfaces are
SAREF example. needed, the instantiation goes through the factory. In the case of
(4) An instantiation and usage examples for each of the gener- the RDF4J, the compilation and packaging phase takes longer since
ated SAREF libraries (Jackson-Jsonld, RDF4J, RDFAlchemy, it pulls several RDF4J dependencies. Package optimization will be
and RomanticWeb). The examples demonstrate how any IoT part of our future work.
developer can import the generated packages and use them
in his development without any knowledge regarding on- 7 CONCLUSION
tologies. The provided examples show the instantiation of In this paper, we presented a model driven methodology which
a SAREF temperature sensor8 with a measurement temper- relies on the separation of concern between two aspects. The first
ature in degree Celsius, and other information such as the aspect is the model creation and its instantiation. The second aspect
manufacturer and the model number, as shown in listing. 2. is the distinction between the three different actors and their skills
OLGA is deployed on a 64 bit windows machine with an I7 Code set in the IoT development. We proposed a methodology which
and 32 GB of RAM with a JVM of 512 MB of maximum heap size. highlights and leverages the expertise of each actor and places it in
Table 1 depicts the code generation evaluation for SAREF with a its adequate posture in order to accelerate the ontology-based IoT
dependency on RomanticWeb, RDFAlchemy, RDF4J, and on Jackson- application developments.
Jsonld where the values represent an average of 10 executions. In addition, based on the requirements gathered from our indus-
The table depicts the overall generation time from import until trial context and internal development teams, we propose OLGA,
packaging. It also details the code generation, compilation, and an Ontology Library Generator which completes existing libraries
packaging time. The overall time for a serializer is longer than an and frameworks in the ontology development arena. OLGA is an en-
abler and a facilitator for the adoption of libraries and frameworks
4 github.com/kaspersorensen/dotnet-maven-plugin
depicted in the related work section. It complements and does not
5 maven-compiler-plugin on mvnrepository.com
6 http://www.mojohaus.org/exec-maven-plugin competes with the effort put by the ontology community regarding
7 www.w3.org/TR/owl-time the software tools suite. OLGA leverages this such software suite
8 ont oloдy .t no .nl /sar e f /sar e f
T emper atur eSensor .html by automatically providing a bridge towards its usage in an abstract
7
and more adequate manner for IoT developers. OLGA takes an Processing, 2011.
ontology previously defined by the domain and ontology experts [21] Charbel El Kaed, Imran Khan, Hicham Hossayni, and Philippe Nappey. SQenIoT:
Semantic Query Engine for Industrial Internet-Of-Things Gateways. In IEEE 3rd
and generates a library hiding all the complexity of ontology based World Forum on Internet of Things, 2016.
development. We validated OLGA by relying on the existing Smart [22] Aditya Kalyanpur, Daniel Jiménez Pastor, Steve Battle, and Julian A Padget.
Automatic mapping of owl ontologies into java. In SEKE, 2004.
Appliances REFerence Ontology [5], the generated libraries depend [23] Wenzel Ken. Ontology-driven application architectures with komma. In 7th
on four existing libraries in three different programming languages International Workshop on Semantic Web Enabled Software Engineering. Springer,
and paradigms. Such flexibility and easy of extensions is possible 2011.
[24] Evgeny Kharlamov et al. How semantic technologies can enhance data access at
thanks to OLGA’s internal model which captures the ontology in- siemens energy. In The International Semantic Web Conference. Springer, 2014.
formation independent of any targeted library or programming [25] Lib. Owl api. https://github.com/owlcs/owlapi/wiki, Online; accessed 9-July-2017.
language. Separating the model from any implementation offers [26] Lib. Rdf4j. http://rdf4j.org, Online; accessed 9-July-2017.
[27] Lib. Rdflib. https://rdflib.readthedocs.io, Online; accessed 9-July-2017.
OLGA a huge flexibility making supporting another language or [28] Lib. Redland. librdf.org, Online; accessed 9-July-2017.
library a matter of adding templates. [29] Lib. Alibaba. https://bitbucket.org/openrdf/alibaba, Online; accessed 9-July-2017.
[30] Lib. dotnetrdf. http://www.dotnetrdf.org, Online; accessed 9-July-2017.
For now, OLGA is in its minimum viable product and will evolve [31] OLGA. Saref generated by olga. https://github.com/InnovationSE/
over time based on our internal teams requirements. In our future SAREF-Generated-By-OLGA, Online; accessed 9-July-2017.
work, we intend to extend the list of the dependent libraries to [32] Ontology. Saref. http://ontology.tno.nl/saref, Online; accessed 9-July-2017.
[33] ORM. Romanticweb. http://romanticweb.net, Online; accessed 9-July-2017.
support the diversity of our internal teams’ technical choices and [34] Protege. Code generator plugin. https://github.com/protegeproject/
environments. In addition, the query formulation part depicted ear- code-generation, Online; accessed 9-July-2017.
lier, might be partially solved by LINQ for .Net developers, however, [35] python. Rdfalchemy. http://rdfalchemy.readthedocs.io, Online; accessed 9-July-
2017.
it still needs to be tackled for other programming environments. [36] RDF4J. Rdf4j schema generator. https://github.com/ansell/
More over, constraints handling from the ontology model to the rdf4j-schema-generator, Online; accessed 9-July-2017.
[37] SchneiderElectric. Internal workshop. https://github.com/InnovationSE/Ontology-
generated code will be part of our next steps. Workshop, Online; accessed 9-July-2017.
[38] Bechhofer Sean, van Harmelen Frank, Hendler Jim, Horrocks Ian, McGuinness
Deborah, Patel-Schneider Peter, and Andrea Stein. Web ontology language.
REFERENCES http://www.w3.org/TR/owl-features/, 2004.
[1] Balaji Bharathan et al. Brick: Towards a unified metadata schema for buildings. In [39] Template Engine. Freemarker. http://freemarker.org, Online; accessed 9-July-
Proceedings of the 3rd ACM International Conference on Systems for Energy-Efficient 2017.
Built Environments, BuildSys. ACM, 2016. [40] Trinity. Semiodesk. https://bitbucket.org/semiodesk/trinity, Online; accessed
[2] Brochure. Ecostruxure. http://www.schneider- 9-July-2017.
electric.com/en/download/document/998-19885906_GMA-US_ESX/, Online; [41] VSB. Visual query builder. https://leipert.github.io/vsb, Online; accessed 9-July-
accessed 9-July-2017. 2017.
[3] V. Charpenay, S. Käbisch, D. Anicic, and H. Kosch. An ontology design pattern [42] W3C. Resource description framework. http://www.w3.org/RDF, 1999.
for iot device tagging systems. In 2015 5th International Conference on the Internet
of Things, 2015.
[4] Fabien Chevalier. Autordf - using owl as an object graph mapping (ogm) spec-
ification language. In The Semantic Web: ESWC 2016 Satellite Events. Springer,
2016.
[5] Laura Daniele, Frank den Hartog, and Jasper Roes. Created in close interaction
with the industry: the smart appliances reference (saref) ontology. In International
Workshop Formal Ontologies Meet Industries, 2015.
[6] DB. Stardog. http://www.stardog.com, Online; accessed 9-July-2017.
[7] Editor. Protege. http://protege.stanford.edu, Online; accessed 9-July-2017.
[8] EF. Entity framework. https://github.com/aspnet/EntityFramework6, Online;
accessed 9-July-2017.
[9] Charbel El Kaed and Matthieu Boujonnier. Forte: A federated ontology and
timeseries query engine. In The 3rd IEEE International Conference on Smart Data.
IEEE, 2017.
[10] EMF. Eclipse modeling framework. eclipse.org/emf, Online; accessed 9-July-2017.
[11] Prudhommeaux Eric and Seaborne Andy. Sparql query language for rdf.
www.w3.org/TR/rdfsparql-query, 2004. SPARQL Query Language for RDF, W3C.
[12] D. Pfisterer et al. Spitfire: toward a semantic web of things. IEEE Communications
Magazine, 2011.
[13] Mariano Ferndndez and Natalia Juristo. Methontology: From ontological art
towards ontological engineering. In In Proceedings of the AAAI Spring Symposium,
1997.
[14] A. Gyrard, S. K. Datta, C. Bonnet, and K. Boudaoud. Cross-domain internet of
things application development: M3 framework and evaluation. In 3rd Interna-
tional Conference on Future Internet of Things and Cloud, 2015.
[15] Kagermann Henning, Wahlster Wolfgang, and Helbig Johannes. Recommenda-
tions for implementing the strategic initiative industrie 4.0, 2013.
[16] JPA. Java persistence api. http://www.oracle.com/technetwork/articles/javase/
persistenceapi-135534.html, 2007.
[17] JPA. Empire. https://github.com/mhgrove/Empire, Online; accessed 9-July-2017.
[18] jsonld. Jackson-jsonld. https://github.com/io-informatics/jackson-jsonld, Online;
accessed 9-July-2017.
[19] C. E. Kaed, B. Leida, and T. Gray. Building management insights driven by a
multi-system semantic representation approach. In 2016 IEEE 3rd World Forum
on Internet of Things, 2016.
[20] C. El Kaed, Y. Denneulin, and F. G. Ottogalli. Dynamic service adaptation for plug
and play device interoperability. In Proceedings of the 7th International Conference
on Network and Services Management. International Federation for Information
8