The Internet of Things promises several exciting opportunities and added value services in several industrial contexts. Such opportunities are enabled by the interconnectivity and cooperation between various things. However, these promises are still facing the interoperability challenge. Semantic technology and linked data are well positioned to tackle the heterogeneity problem. Several eforts contributed to the development of ontology editors and tools for storing and querying linked data. However, despite the potential and the promises, semantic technology remains in the hands of the few, a minority of experts. In this paper, we propose a model driven methodology and a software module (OLGA) that completes existing ontology development libraries and frameworks in order to accelerate the adoption of ontology-based IoT application development. We validated our approach using the ETSI SAREF ontology.
The Internet of Things (IoT) is expected to interconnect, at massive
scale, numerous sensors, devices, gateways, and systems to tackle
many challenges in the industry [
Designing IoT applications requires a shared understanding of
the exchanged data among those connected things. Semantic
technology, is one of the most promising fields in the knowledge
representation domain, expected to enable interoperability in the IoT.
The World Wide Web Consortium (W3C) defines a set of standards ,
such as RDF, OWL and SPARQL [
In addition to the W3C standardization activities, several
efforts contributed to the development of the ontology editors [
Despite its potential and promises, semantic technology and
ontology-based IoT applications still remain in the hands of a
minority, the ontology experts, being too dificult to be adopted and
applied by industrial practitioners. We attribute such retention
among other factors to the absence of adequate methodology and
tools involving several major actors participating in the design
lifecycle of an IoT application, who are typically non-ontology experts.
Thus, we propose in this work a model driven methodology along
with a software module approach that aim at removing barriers
for IoT developers and accelerating the adoption of semantic
technologies. Our proposed module is validated based on the SAREF [
The rest of this paper is organized as follows, first, we depict some of the existing frameworks for developers in the related work section. Then, we share our experiences while working on IoTbased solutions with our internal teams and outline the motivation behind this work. In sections 4 and 5, we propose our methodology along with a software module OLGA to accelerate the ontologybased IoT development. Section 6 provides the implementation and evaluation of our solution. Finally, we conclude and discuss future work in section 7. 2
We split the available libraries and frameworks in various programming languages for ontology-based development in two categories, i.e., serializers and Object Relational Mappers (ORMs). 2.1
Serializers provide reading/writing from/to an ontology file, a SPARQL
endpoint, or a persistent RDF store. RDF Serializers are
implemented in various programming languages, such as OWL API [
We discuss in the following the serializers ofering basic code generation through a plugin which takes an ontology as an input and generates some code facilitators or stubs.
The Protégé code generation plugin [
AutoRDF [
ORMs are built on top of serializers and provide an object
oriented abstraction layer allowing developers to manipulate objects
instead of RDF concepts. Several ORMs are available in various
programming languages, such as KOMMA [
We discuss in the following the ORMs providing some code generation features.
AliBaba [
KOMMA relies on the Eclipse Modeling Framework (EMF) [
In the following, we depict our industrial context, the feedback from our teams regarding ontology-based development, and the lessons learned. 3
This section briefly outlines our industrial context capturing part of our lessons learned while prototyping with several of our internal teams applying semantic technologies in several domains such as the Smart Buildings and Smart Factories.
Schneider Electric is a world leader in Energy Management and
heavily involved in the IoT and the digitization of its various
products. The EcoStruxure1 program proposed by Schneider Electric, is
an open, interoperable, IoT-enabled system architecture and
platform. EcoStruxure serves our business units which are grouped
according to the following six domains of expertise [
Two main factors captured the curiosity and the interest of our internal teams and communities regarding ontology-based IoT applications development.
First, the proven technical feasibility of ontology-based vertical
and horizontal solutions in our industrial context. Several
ontologybased proof of concepts have been designed demonstrating the
added value in two operating modes: vertical and horizontal
deployments. The vertical silo mode is the classical sensor to gateway
or device/system to cloud combined with a domain specific
application [
Second, the emergence of domain specific ontologies in the
industry and standardization bodies. For example, in the Smart
Buildings domain, ontologies such as SAREF [
have been proposed regarding energy modeling and access such as
Siemens Work [
Based on these two factors, we started an internal Ontology
Workshop [
We outline the lessons learned from these workshops in relation
to this work:
(1) Learning curve is a luxury: relying on ontologies is powerful
to represent internal systems topology such as the
interconnectivity between the devices and sensors, their physical
locations, and their functional interactions. However, using a
serializer requires knowing in detail the ontology languages.
The Object Relational Mappers provide a very interesting
abstraction, however, a mapping is still required through code
decoration. Thus, there is a necessary learning curve to use
the ontologies in the IoT development that most of the teams
do not have. IoT developers would leverage a Just Instantiate
and Link library that they can import into their development
environment, where the concepts and relationships of the
ontology model (T-Box) are provided. Once such library is
imported, they can instantiate the ontology concepts and
link them together (A-Box). Such library can rely on the
existing SDKs and libraries presented in the related works
section.
(2) Programming Languages: the diversity of our business units
and ofers translates into the diversity of the skill set of our
teams which rely on diferent programming languages to
implement IoT-based applications ranging from embedded
devices (c, c++, python), systems (c++, .net, java) to cloud
applications. Therefore, such Just Instantiate and Link library
must support various dependencies to third party libraries
and programming languages.
(3) Query Language: storing and retrieving data on a system
or cloud is considered essential. The IoT development
community is often seen divided regarding the query language
between pro and anti SPARQL. Some developers are familiar
with query languages such as SQL or LINQ and advocate for
their reuse in the IoT ontology-based development. Other
developers embrace the power of SPARQL and the necessity of
evolving the query language since the underlying structure
has also evolved and is no longer tabular. Alternatives such
as simple query languages in SQenIoT [
In the rest of this paper we propose our approach facilitating the ontology-based application development focusing on the first two items depicted earlier. 4
Based on the feedback gathered from our internal teams, we propose the following model driven methodology, shown in Fig. 2, for ontology-based IoT application development. We identify the three following major roles involved in the IoT development and leverage their expertise and strength: (1) Ontology Expert: is an ontology practitioner. Has experience in the ontology development tools, languages, and storage infrastructure. His main tasks consist in assisting the domain expert in capturing the concepts to be used in an IoT application deployed in a specific domain. He creates the ontology concepts and relations (T-Box), and proposes an ontology. (2) Domain Expert: is a product owner and/or a technical architect. Has a global and specific knowledge on how a specific system is deployed, commissioned, and operated, such as the Building Management System. She articulates the main concepts and the relations of a system to the Ontology Expert. (3) IoT Developer: implements an application following the ontology model previously defined by the Experts. Imports a library containing the concepts and possible relations previously defined to instantiate the model. Her implementation is integrated in a cloud application or an embedded device.
The methodology shown in Fig. 2 is initiated by both the
Ontology and Domain Experts (Product Owner and Architect). They
ifrst identify and draw the scope of the IoT application based on the
gathered requirements from end clients and users. Then, the main
concepts and relations of the application are extracted, for example,
in a Smart Buildings domain, a Floor and a Room are two diferent
concepts related to each other with the contains object property
which can be declared as transitive. The experts can reuse or extend
existing ontologies, after several iterations [
The Ontological model is then provided to an Ontology Library GenerAtor (OLGA), detailed in the next section. OLGA takes an ontology and its imported ontologies along with a selection of the desired library or framework depicted in section 2. The output of OLGA is a generated library conforming to the Ontology Model previously defined and ready to be used by an IoT developer.
The generated library hides all the ontology complexity and
enables IoT developers to instantiate and link the ontology classes and
relations previously defined by the Ontology and Domain Experts.
The generated library can depend on a serializer or an object
relation mapper library. It is used by any IoT developer and is embedded
into a device, system, or an IoT cloud application. Once integrated
into an existing system or device, it can have several usage. For
example, in a commissioning software of a Building Management
System [
This methodology enables the separation of aspects and roles, and places the complexity in areas where it can be solved by relying on adequate tools and domain expertise. A domain expert has both an overall and specific knowledge about a specific system and domain. An ontology expert is modeling practitioner but lacks the overall system’s vision and domain knowledge expertise. And ifnally, IoT developers can now select the programming language and the framework of their choice to implement ontology-based IoT applications by relying on the generated library which conforms to the ontological model without the complexity of the ontology languages.
In the following section, we detail the Ontology Library GenerAtor (OLGA). 5
OLGA is a multi-library code generator, as shown in Fig. 3, it takes two parameters as input: one or more ontologies since an ontology 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 an object relational mapper. Thus, OLGA completes already existing libraries and frameworks, those depicted in section 2 by providing IoT developers with the variety of choice for the development of ontology-based IoT applications. OLGA enables the possibility for an IoT developer to choose and reuse existing open source libraries (serializers or ORMs) while ofering an abstraction and a simpler library to use which conforms to an ontology model previously specified by the experts. <#if consolidatedImports??> <#list consolidatedImports as import>
using ${import}; </#list> </#if> namespace ${Zclass.getPackageName()} { [Class("${Zclass.Iri()}")] public interface I${Zclass.ClassName()} <#if Zclass.SuperZClassList()??> <#if Zclass.SuperZClassList()?has_content> : <#list Zclass.SuperZClassList() as
SuperZClassCurrentElementOfList>
I${SuperZClassCurrentElementOfList.ClassName()}<#sep> , </#list> <#else>: IEntity </#if> </#if> { <#if listDataProperties??> <#list listDataProperties as DataPropertyList> [Property("${DataPropertyList.DataProperty()}")] ${DataPropertyList.RangeXSDType()} ${DataPropertyList
.DataPropertyShortForm()?capitalize}{ get; set; } </#list> </#if> } } <#if listObjectProperties??> ... </#if>
Importer: loads into memory one or more ontologies and merges them into one ontology easier to visit.
Visitor: traverses all the elements of a given ontology provided by the Importer. The visitor crosses the following elements: Classes, ObjectProperties, DataProperties, Individuals, Literals, and the various axioms to populate the internal model shown in Fig. 4.
Model: allows capturing the ontology information (T-Box)
independent of any targeted library or programming language.
Separating the model from any targeted implementation ofers OLGA
a huge flexibility making the support for an additional language
or a dependent library simply a matter of adding templates. The
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. [
Each Class can have none (owl:Thing) or multiple super classes populated by the visitor based on the owl:SubClassOf. The namespace, packageName, and className are extracted based on the Class IRI for the code generator .
A Class may have none or several ObjectProperties, as shown in Fig 4. The visitor populates the following parameters for each ObjectProperty: a restriction type (owl:AllValuesFrom), an optional restriction cardinality (owl:minCardinality), a restriction number associated with the cardinality, a possible one or more characteristic of the property (owl:TransitiveProperty), and an optional expression (owl:UnionOf). An ObjectProperty associates the following concepts: • 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 depending on the restriction type and the Expression. For example, a TemperatureMeasure Class hasUnit Degree_Celsius Individual. • Individual-to-Individual: the restriction type, cardinality, expression, and characteristic are not populated by the visitor when an individual is associated to another individual. For example, a Building1 contains Floor1. Only the name parameter is used in the ObjectProperty for the code generation.
An Individual is an instance of a class. The visitor fills the namespace and the packageName for the code generator based on its IRI.
When a DataProperty is associated with an Individual, the visitor populates only the range (Literal). However, when the DataProperty is associated with a class, the visitor populates in addition to the previous parameters, the restriction type and the restriction cardinality.
Templates: are arranged by library dependency, a serializer
(Jackson-Jsonld [
Generator: based on the selected library dependency, adequate templates are loaded into memory to initiate the code generation from the populated model. The Generator injects the information from the model into the templates. The separation between the model and the templates provides flexibility and makes supporting an additional library a matter of templates extension.
In the case of a selected ORM dependency, each Class and Individual of the ontology will be generated into an interface. In fact, an ORM library provides a factory allowing developers to instantiate the interfaces into objects. OLGA handles multiple inheritance and composition by generating interfaces extending other interfaces. This makes the code generation simpler since only the interfaces need to be generated. Developers will rely on the factory to instantiate their objects based on the generated interfaces, therefore, the ORM’s factory will handle multiple extensions of the interfaces and their declared functions.
In the case of a selected serializer dependency, interfaces and their implementations are generated since a serializer do not provide a factory to instantiate/implement a class. OLGA handles multiple inheritance and composition by propagating the functions’ implementations from the extended interfaces into the implemented classes and by relying on the Override annotation in Java (or similar) annotations in other programming languages.
Compiler & Packager: once the code is injected into the templates, the generator creates files containing the expected code. Then, the compilation and packaging phase can start. According to the selected library and its programming language a compiler is loaded. Once the compilation ends successfully, the packaging is triggered to prepare the adequate format (.jar, .dll, .whl, or others).
Once the generated library is packaged, it can be imported and ready to be used by any IoT developer. An example of a SAREF generated library is provided in Listing. 2, where an IoT developer can Just Instantiate and Link, an Idegree_Celsius is refereed to, then an indoor measurement is created and linked to a specific instance of a Temperature Sensor.
The code implemented by the IoT developer can be deployed on a
cloud connected device or gateway such as in [
OLGA is implemented in Java 8 and relies on the OWL API [
The list of supported dependent libraries is expected to grow
with time based on the adoption and requests from our internal
teams. So far, OLGA supports the java-based serializer
JacksonJsonld [
The Smart Appliances REFerence ontology (SAREF) [
SAREF example. (4) An instantiation and usage examples for each of the generated SAREF libraries (Jackson-Jsonld, RDF4J, RDFAlchemy, and RomanticWeb). The examples demonstrate how any IoT developer can import the generated packages and use them in his development without any knowledge regarding ontologies. The provided examples show the instantiation of a SAREF temperature sensor8 with a measurement temperature in degree Celsius, and other information such as the manufacturer and the model number, as shown in listing. 2.
OLGA is deployed on a 64 bit windows machine with an I7 Code and 32 GB of RAM with a JVM of 512 MB of maximum heap size. Table 1 depicts the code generation evaluation for SAREF with a dependency on RomanticWeb, RDFAlchemy, RDF4J, and on JacksonJsonld where the values represent an average of 10 executions. The table depicts the overall generation time from import until packaging. It also details the code generation, compilation, and packaging time. The overall time for a serializer is longer than an 4github.com/kaspersorensen/dotnet-maven-plugin 5maven-compiler-plugin on mvnrepository.com 6http://www.mojohaus.org/exec-maven-plugin 7www.w3.org/TR/owl-time 8ontoloдy .t no.nl /sar ef /sar efT emper atur eSensor .html public static void Create_SAREF_Topology() { string clientURI = "http://www.saref.instance/example"; //refer to the unit Idegree_Celsius degreeCelius = context .Create<Idegree_Celsius>(new Uri(clientURI + "#1")); //Create a measurement from the factory IMeasurement indoorTemperature = context .Create<IMeasurement>(new Uri(clientURI + "#2")); indoorTemperature.AddIsmeasuredin_Only_UnitOfMeasure .Add(degreeCelius); indoorTemperature.Hasvalue = 32; indoorTemperature.Hastimestamp = DateTime.UtcNow; //Link it to Temperature ITemperature temperature = context .Create<ITemperature>(new Uri(clientURI + "#3")); temperature.AddRelatestomeasurement_Only_Measurement .Add(indoorTemperature); //Create a Temperature Sensor ITemperatureSensor temperatureSensor = context .Create<ITemperatureSensor>(new Uri(clientURI + "#4")); temperatureSensor.Hasmanufacturer = "CompanyA"; temperatureSensor.Hasmodel = "M321"; temperatureSensor .Hasdescription = "Low range Zigee temperature sensor"; //add its measurement temperatureSensor.AddMakesmeasurement_Only_Measurement .Add(indoorTemperature); } // commit data to factory context.Commit();
ORM since for a serializer OLGA generates interfaces and their implementation classes while for an ORM only the interfaces are needed, the instantiation goes through the factory. In the case of the RDF4J, the compilation and packaging phase takes longer since it pulls several RDF4J dependencies. Package optimization will be part of our future work. 7
In this paper, we presented a model driven methodology which relies on the separation of concern between two aspects. The first aspect is the model creation and its instantiation. The second aspect is the distinction between the three diferent actors and their skills set in the IoT development. We proposed a methodology which highlights and leverages the expertise of each actor and places it in its adequate posture in order to accelerate the ontology-based IoT application developments.
In addition, based on the requirements gathered from our
industrial context and internal development teams, we propose OLGA,
an Ontology Library Generator which completes existing libraries
and frameworks in the ontology development arena. OLGA is an
enabler and a facilitator for the adoption of libraries and frameworks
depicted in the related work section. It complements and does not
competes with the efort put by the ontology community regarding
the software tools suite. OLGA leverages this such software suite
by automatically providing a bridge towards its usage in an abstract
and more adequate manner for IoT developers. OLGA takes an
ontology previously defined by the domain and ontology experts
and generates a library hiding all the complexity of ontology based
development. We validated OLGA by relying on the existing Smart
Appliances REFerence Ontology [
For now, OLGA is in its minimum viable product and will evolve over time based on our internal teams requirements. In our future work, we intend to extend the list of the dependent libraries to support the diversity of our internal teams’ technical choices and environments. In addition, the query formulation part depicted earlier, might be partially solved by LINQ for .Net developers, however, it still needs to be tackled for other programming environments. More over, constraints handling from the ontology model to the generated code will be part of our next steps.