=Paper=
{{Paper
|id=Vol-2063/sisiot-paper2
|storemode=property
|title=Planned ETSI SAREF Extensions based on the W3C&OGC SOSA/SSN-compatible SEAS Ontology Pattern
|pdfUrl=https://ceur-ws.org/Vol-2063/sisiot-paper2.pdf
|volume=Vol-2063
|authors=Maxime Lefrançois
|dblpUrl=https://dblp.org/rec/conf/i-semantics/Lefrancois17
}}
==Planned ETSI SAREF Extensions based on the W3C&OGC SOSA/SSN-compatible SEAS Ontology Pattern==
https://ceur-ws.org/Vol-2063/sisiot-paper2.pdf
Planned ETSI SAREF Extensions based on the
W3C&OGC SOSA/SSN-compatible SEAS Ontology Patterns
Maxime Lefrançois
Univ. Lyon, Mines Saint-Étienne, CNRS, Laboratoire Hubert Curien UMR 5516,
F-42023 Saint-Étienne, France
maxime.lefrancois@emse.fr
ABSTRACT an internal structure that is consistent and simple enough to be
Mid-June 2017, the ETSI SmartM2M working group voted two work easily mastered by the application developers, who are not experts
items, DTS/SmartM2M-103548 and DTS/SmartM2M-103549, with in Semantic Web technologies.
the goal to enhance and augment the SAREF ontology with some The ITEA2 Smart Energy-Aware Systems (SEAS) project1 aimed
of the design, development, and publication choices that have been at designing and developing a global ecosystem of services and
made in the context of the ITEA2 SEAS (Smart Energy Aware Sys- smart things collectively capable of ensuring the stability and the
tems) project. This paper provides an overview of these choices and energy efficiency of the future energy grid. The choice has been
their rationale. In particular, we describe contributions regarding: made to adopt Semantic Web formalisms to achieve semantic inter-
(i) the design of the ontology as a set of simple core ontology pat- operability between the services and the smart things, and one of
terns, that can then be instantiated for multiple engineering-related the tasks in the project was thus dedicated to the design of an on-
verticals; (ii) the design and publication of the SEAS modular and tology. On top of the fact that the ontology had to cover a large and
versioned ontology in conformance with the publication and meta- heterogeneous set of domains, strict quality requirements stemmed
data best practices, with the additional constraint that every term from the industrial context of its development and use.
is defined under a single namespace. These planned additions to This paper provides an overview of the design, development,
SAREF will ease its adoption and extension by industrial stake- and publication choices that have been made in the development of
holder, while ensuring easy maintenance of its quality, coherence, the SEAS ontologies to meet all those requirements. These choices
and modularity. Finally, because the SEAS ontology generalizes are driven by the following three major goals:
the future W3C&OGC SOSA/SSN (Sensor, Observation, Sensing,
Actuation / Semantic Sensor Network) ontology, these work items Design goal 1. The SEAS ontology must conform as much as
contribute to the convergence of the different reference ontologies possible to the publication and metadata best practices that have been
relevant for the IoT domain. defined by the Semantic Web community. Violation of these best
practices must be detected as soon as possible, and as little work as
possible must be left to the ontology maintainers.
Design goal 2. The SEAS ontology must conform to quality cri-
teria one are used to in open source development projects: it must
be modular, use semantic versioning, its source must be open so that
anyone can be able to comment, raise issues, or contribute.
1 INTRODUCTION Design goal 3. The SEAS ontology users must have a learning
We observe more and more interest from industrial stakeholders curve as short as possible, even though the width and depth of the
into the Semantic Web formalisms and technologies, in particular as domains to be covered is very big. In particular, it must be easy to
they are foreseen as a means to reach semantic interoperability be- map it to some object-oriented programming language. One corollary
tween heterogeneous systems. On the other hand, it is often hard to to this requirementis that every term must be defined under the same
choose among the 600+ ontologies referenced on the Linked Open namespace.
Vocabulary (LOV) the ones that are worth reusing. In fact, there is
a high heterogeneity among these ontologies in terms of adoption, The rest of this paper is organized as follows. Section 2 first
institutional statuses, structure/content/publication/metadata qual- precises the resolution taken in terms of development and publi-
ity, maintenance, extensibility, or even availability. We claim that cation choices for the ontology with respect to these three goals.
ontologies that aim at becoming a reference in the industry and the Section 3 gives an overview of the content of SEAS and its mod-
IoT should meet the highest quality criterias possible, while having ular organization. Section 4 to 7 sequentially introduce the four
engineering-centric core SEAS ontology patterns, and provides an
overview of how they are instantiated to model knowledge from
different vertical domains.
© 2017 Copyright held by the author/owners.
SEMANTiCS 2017 workshops proceedings: SIS-IoT 1 The ITEA2 SEAS project involved 34 partners in 6 countries, and ended in December
September 11-14, 2017, Amsterdam, Netherlands 2016. It received the ITEA2 Award of Excellence 2017. See http://the-smart-energy.com/
SIS-IoT’17, July 2017, Amsterdam, Netherlands Maxime Lefrançois
2 COMBINING BEST PRACTICES, SSN [7] and QUDT [10]. These alignments are defined in external
MODULARITY, VERSIONING, AND A modules, that import both the SEAS ontologies and the existing
UNIQUE NAMESPACE. ontology. One can hence choose between using SEAS only, or SEAS
in conjunction with the existing ontology.
2.1 Best Practices
Design reqirement 1. IRIs must satisfy the following best prac- 2.3 Versioning
tices defined in [3], [1], and [13]. Much like softwares, ontologies evolve. Another ontology, some
Thus: (i) IRIs must not change, and be designed with simplic- dataset, or a piece of software that uses some ontology must not be
ity, stability and manageability in mind [3]; (ii) The description broken whenever it evolves.
of a concept should be accessible by looking up its IRI [1, item 3]; Design reqirement 4. A reference ontology for the IoT must
(iii) Different representations of this description should be served use a versioning mechanism, such as the one defined in [17, §3.3].
depending on who asks [3]. For the stability and manageability
aspect we use the w3id.org redirection service which is an initiative This includes the annotation of the ontology using owl:versionIRI,
of the W3C and is intended to be around for as long as the Web is owl:versionInfo, and potentially owl:priorVersion that points to the
around.2 Also, the sources of the SEAS website are open-source URI of the previous module version. An ontology series O is iden-
and available on GitHub: https://github.com/thesmartenergy/seas, tified by an IRI, and each of the ontology versions O i are also
so anyone can reuse, comment, raise issues, or contribute. Require- identified by IRIs. Design requirement 1 imposes that: An ontology
ment 1 also imposes that resource IRIs must be either 303 IRIs or version O i identified by IRI vi in an ontology series O identified by
hash IRIs, because they are real-world objects. IRI u SHOULD be accessible via the IRI vi . Furthermore, if O i is
the latest version of the ontology series O, then it SHOULD also be
Design reqirement 2. A reference ontology must be a valid accessible via IRI u. Then the version numbers must be meaningful:
OWL 2 DL ontology, satisfy the best practices for OWL documents as
defined in [17, §3], and satisfy the Data on the Web best practices [5] Design reqirement 5. A reference ontology for the IoT must
and the Linked Open Vocabularies best practices [16]. use some adaptation of the Semantic Versioning specification 2.0+ to
the linked vocabularies [12], as already discussed in [9].
SEAS uses recommended metadata for the ontologies, most of
the annotation properties are chosen in vocabulary dct, and term An ontology document is a document, so one may return an
labels and comments systematically have language tags. HTTP code 200 OK when serving it. For instance, seas:BuildingOn-
tology has two versions: seas:BuildingOntology-0.9 and seas:Buil-
2.2 Modularization dingOntology-1.0; the latter being the current latest version.
Numerous use cases are envisioned for the IoT and they need knowl-
2.4 A unique Namespace
edge representations means for very different domains (e.g., use
cases in the SEAS project included Smart Homes, Micro Grids, Elec- There are several reasons why industrial partners wanted to have
tric Vehicles, Electricity market, Distribution and Retail operators a unique namespace for every term in the ontology. The most
and clients, Weather Forecast). Not every part of an IoT reference important ones where: (i) one does not want to have to remember a
ontology will be needed by every implementation. The SEAS on- different randomly chosen prefixes for every term; (ii) one wants to
tology hence consists of a set different ontology modules. The be able to move a term from one module to another without having
choice of the modules is partly driven by a study of use cases and to change its URI; and (iii) the objective of SEAS is to grow with
methodological principle [2]. more and more terms, and to be able to let users define their own
modules on the basis of a coherent set of terms. We hence decided
Design reqirement 3. A reference ontology for the IoT must be to work with a unique namespace:
modular using the mechanism described in [17, §3.4].
Design reqirement 6. All of the resources IRIs in the SEAS
We also chose to annotate every concept with a rdfs:isDefinedBy, ontology must be in the same namespace.
that points to the ontology that defines the concept. Note that
in this paper all the prefixes are those available with the service This solution raises one minor issue in the Linked Open Vocabu-
http://prefix.cc/. lary (LOV) ontology repository [15]. the LOV has been designed
The Semantic Web philosophy also encourages the reuse of ex- with the assumption of 1:1 correspondences between prefixes and
isting ontologies when appropriate. The SEAS Use Cases required vocabularies. So it fails at properly referencing the terms that are
models that are common to numerous other projects (e.g., Prove- defined in the SEAS ontologies: the SEAS vocabulary consists of
nance, Time instants and intervals, Quantities and Units of Measure, several ontologies that have different IRIs but the same prefix.
Time, Sensor/Actuator description, Sensor Observations, Predic-
tions), or that are not actual subdomains of the Energy domain 2.5 Resolution
(e.g., products and offers). There exists some ontologies for some of Let us show how one can combine requirements 1 to 6. Suppose an
these domains, and we chose to import or to define alignments to ontology O with IRI OI defines the class of “systems” R.
them on a per-ontology basis. The SEAS ontologies only imports Hash IRIs. Let RI#fragment be a hash IRI for R. Operating a HTTP
OWL-Time [4] and GoodRelations [8], and defines alignments to GET to RI must return a document with HTTP code 200 (this satis-
2 Thus longer than the website of most institutions or companies, hopefully. fies requirement 1). The returned document should define R. Hence
Planned ETSI SAREF Extensions based on SEAS Ontology Patterns SIS-IoT’17, July 2017, Amsterdam, Netherlands
OI must be equal to RI. For instance, RI = https://w3id.org/seas/ When loading the SEAS ontologies in the Protégé editor from
system#System. Suppose another resource R 2 in another ontology their IRI, and removing imports to external ontologies (OWL-Time
O 2 has a IRI OI2#fragment2. Requirement 6 imposes that string ‘seas:’ and GoodRelations), one currently obtains the following metrics:
be the prefix for both namespaces OI# and OI2#. Which is impossible. 1873 logical axioms, 479 classes, 277 object properties, 7 data prop-
erties, 52 individuals. The modules and how they import each other
The solution is 303 IRIs. Let RI be a 303 IRI for R. Operating is illustrated on figure 1.
a HTTP GET to RI must return a HTTP code 303 See Also that
redirects to a IRI RI2. The definition of R should be accessible via
RI2.
Ontology O defines R. Hence we propose that RI redirects to
OI. For instance, RI = https://w3id.org/seas/System redirects to OI
= https://w3id.org/seas/SystemOntology. Hence Requirement 6 is
satisfied and there exists a unique prefix for ‘seas’, whose extended
version is . This namespace is registered at
the well known service http://prefix.cc/seas.
To sum up, when looking up a IRI RI: (1) If RI identifies an ontol-
ogy series O, then the ontology server redirects to the latest version
of this series with HTTP code 303 See Other; (2) If RI identifies an on-
tology document O, then the ontology server returns O with HTTP
code 200 OK; (3) If RI identifies a resource R, then the ontology
server 303 redirects to the ontology module with the most recent
version that defines R with HTTP code 303 See Other. (4) each
module version is available in the Turtle, RDF/XML, and HTML
formats, with server content negotiation, reference to a unique
canonical URI for each representation, and hint for a filename to Figure 1: Illustration of the modules and their imports.
use if the browser wants to download the file. For example, operat- Green nodes are core modules, pink nodes are vertical mod-
ing a HTTP GET to https://w3id.org/seas/EvaluationOntology with ules, orange nodes are alignment modules, and blue nodes
Accept: text/turtle, one gets an HTTP response with the following are external ontologies.
headers:
These ontologies are published in Turtle, XML, and HTML ac-
Content-Disposition: filename= EvaluationOntology-1.0.ttl; cording to the Web of Linked Open Vocabularies best practices.
Content-Location: https://w3id.org/seas/EvaluationOntology-1.0.ttl
Their documentation is automatically generated in HTML thanks
to a tool we developed.
3 OVERVIEW OF THE SEAS REFERENCE We are also currently reviewing pull requests for extension mod-
ules to model matter flow systems, and city lighting.
ONTOLOGY
The SEAS knowledge model is a modularized and versioned ontol- 4 FEATURES OF INTEREST AND THEIR
ogy with a core of four modules that describe among other physical PROPERTIES
systems and their connections, value association for their proper-
Module seas:FeatureOfInterestOntology borrows the core concepts
ties, and the activities by which such value association is done.
from the SOSA/SSN ontology, and defines ontology patterns to
On top of these core modules, the SEAS ontology defines sev-
describe features of interest (e.g., a light) and their properties (e.g.,
eral “vertical” modules, that instantiate one or more core ontology
its on/off status), which are qualifiable, quantifiable, observable or
patterns, and usually depend on a domain. For example:
actionnable qualities of the feature of interest. More specifically, a
• seas:ElectricPowerSystemOntology defines system types seas:FeatureOfInterest is an abstraction of real world phenomena
(e.g., seas:ElectricPowerLine, seas:ElectricPowerProducer), (thing, person, event, etc), and a seas:Property is an observable or
their connections through which they exchange energy operable Quality of an Event or Object. That is, not a quality of an
(e.g., seas:SplitPhasePowerBus), their properties (e.g., seas:- abstract entity as is also allowed by DUL’s Quality, but rather an
power, seas:voltage), and the classical types of evaluation aspect of an entity that is intrinsic to and cannot exist without the
for these properties (e.g., seas:NominalOperatingEvaluation). entity and is observable by a sensor, or operable by an actuator.
• seas:ZoneOntology defines physical zones and their fron-
tiers, through which these zones can exchange agents, ther- 4.1 Instances of the Ontology Pattern
mic energy, light, or humidity. One can then instantiate the ontology patterns and define for exam-
Other vertical modules are proposed for energy markets, de- ple in ontology ex: that ex:Light is a type of seas:FeatureOfInterest,
mand/response, etc. Labels and comments for the concepts are ex:BooleanProperty is a type of seas:Property, and ex:onStatus is a sub-
available at least in English, but sometimes in French, Finnish, property of seas:hasProperty. One can furthermore state that prop-
and/or Portugese. The ontologies use concepts from external vo- erty ex:onStatus is functional, meaning that features of interest can
cabularies. have only one on/off status property. Then, one can link a specific
SIS-IoT’17, July 2017, Amsterdam, Netherlands Maxime Lefrançois
1. J isPropertyOf new SOSA/SSN ontology specification acknowledges the existence
FeatureOfInterest Property
hasProperty I of these two different ways of modeling properties [7, §7.4], and
discusses their compatibility.
ex:Fridge ex:PowerProperty
ex:consumption I 1. On the other hand, the alignment to DUL in the old SSN on-
tology imposed a disjunction between ssn:FeatureOfInterest and
ssn:Property. The absence of a normative DUL alignment in the
ex:consumption new SSN relaxes this restriction, and enables some of the use cases
that were envisioned in SEAS. For example, an alternating current
Figure 2: Ontology pattern seas:FeatureOfInterestOntology power property has active, apparent, reactive power properties
(in green), its instantiation (in ontology ex:) and some data. which have a quantity dimension of power, and some power factor
property which is dimensionless.
light to its (unique) on/off status property 4.2.2 Property in SAREF. SAREF also has a class that is named
using the following RDF graph: saref:Property. It is defined as anything that can be sensed, measured
or controlled in households, common public buildings or offices. Al-
a ex:Light, seas:FeatureOfInterest ;
ex:consumption .
though in the SAREF specification the concept power is used as an
a ex:BooleanProperty, seas:Property . example of an instance of property,4 we believe that saref:Property
can be aligned to seas:Property (and thus ssn:Property, and benefit
Differentiating in this way the subclasses of seas:Property and
from the ontology patterns defined in this SEAS module.
the subproperties of seas:hasProperty has two main advantages:
(1) It dissociates what is a role with respect to a feature of interest 4.2.3 Property in the WoT TD ontology. The current version of
(e.g., incoming and outgoing electric power), and what is intrinsic the WoT TD ontology [11] has been imported from the EU-H2020
to those properties (e.g., they are seas:PowerProperty and have a VICINITY project and also contains a wot:Property class. This
physical dimension of power). (2) The functional aspect of some is a subclass of wot:InteractionPattern and has no overlap with
of the subproperties of seas:hasProperty ensures they are used ssn:Property, saref:Property or seas:Property.
consistently. For example a light has exactly one value for property
on/off status in a given context. 5 PROCEDURES AND THEIR EXECUTIONS
The current version of SEAS contains 65 subclasses of seas:Prop-
The Procedure Execution ontology (PEP) defines pep:ProcedureExe-
erty and 157 sub-properties of seas:hasProperty, among which
cutors (sensor, actuator, web service, etc.) that implement pep:Proc-
142 are functional. These properties cover (non-exhaustive list):
edure methods (sensing, actuating, forecasting, some algorithm)
(a) time-related properties (event number, state change frequency,
and make pep:ProcedureExecution activities (observation, actu-
state change number, state duration), (b) complex numbers (real,
ation, web service execution, forecast). pep:Procedures may be
imaginary, module, phase); (c) periodic signals (frequency), (d) phys-
linked to some description of the input and/or the output using
ical systems and areas (location, length, width, diameter, shape,
object properties pep:hasInput and pep:hasOutput. Their execu-
speed, area, volume, humidity of various kinds); (e) population and
tions may be linked to some description of the command and/or the
population flow, noise, air pollution of various kinds; (f) power and
result using object properties pep:hasResult and pep:hasCommand.
energy (outgoing, incoming, produced, consumed, stored); (g) elec-
If the command or the result can be modeled as a simple RDF literal
tric systems (resistance, conductance, reactance, susceptance, volt-
(a typed UNICODE string), then one may use datatype properties
age, current); (h) failable systems (checkup, failure, repair, replace,
pep:hasSimpleResult and pep:hasSimpleCommand instead.
unavailability); (i) thermodynamic systems (temperature, thermal
Figure 3 illustrates the Procedure Execution ontology ontology
transmittance, total heat transfer); (j) ecology (carbon footprint),
pattern in green.
(k) financial systems (price, tax, value added tax), (l) lighting (colour,
As they represent very different concepts, classes pep:Procedure,
light reflection and transmission, luminosity, refractive indices)
pep:ProcedureExecutor, and pep:ProcedureExecution, are pairwise
disjoint. Also, a pep:ProcedureExecution is made by at most one
4.2 Alignment with other ontologies pep:ProcedureExecutor using at most one pep:Procedure. A Proce-
4.2.1 Properties in SOSA/SSN. The definition of ssn:Property in dure has at most one input and at most one output, and a pep:Proce-
the previous version of SSN imposed that an instance of ssn:Property dure has at most one command and at most one result. Finally, a
is intrinsic to and cannot exist without a specific instance of procedure execution uses all of the procedures that are implemented
seas:FeatureOfInterest. This is made clear in [7, §5.3.1.3.4]: Ob- by the executor that made it.
servedProperty is defined as a subclass of DUL:Quality. Types of
properties, such as temperature or pressure should be added as sub- 5.1 Instances of the Ontology Pattern
classes of ObservedProperty instead of individuals. The definition
The procedure execution ontology is a simple generalization of
of seas:Property thus conforms to that of the original Semantic
the SOSA/SSN ontology. SOSA describes sosa:Sensors that im-
Sensor Network ontology. On the contrary, some of the referenced
plement sosa:Procedures and make sosa:Observations, which are
datasets that use SSN define types of properties such as temperature
or pressure as instances of ssn:Property.3 A specific section in the
4 In the definition of Unit of Measure: For example, Power is a property and Watt is a
3 See https://www.w3.org/2015/spatial/wiki/What_is_an_instance_of_ssn:Property unit of power that represents a definite predetermined power
Planned ETSI SAREF Extensions based on SEAS Ontology Patterns SIS-IoT’17, July 2017, Amsterdam, Netherlands
activities. In parallel to this, it describes sosa:Actuators that imple- wot:providesInteractionPattern rdfs:subPropertyOf pep:implements .
ment sosa:Procedures and make sosa:Actuations. The Procedure wot:InteractionPattern rdfs:subClassOf pep:Procedure .
wot:hasInputData rdfs:subPropertyOf pep:hasInput .
Execution ontology defines an ontology pattern as a generalization wot:hasOutputData rdfs:subPropertyOf pep:hasOutput .
of these two parallel conceptual models, which accounts for at least
a third use case: Web services exposed on the web may be called to 5.2.4 RDFP. The seas:ProcedureExecution ontology is designed
trigger the execution of some procedure. to be aligned with the RDFP ontology5 , which can be used to de-
When instantiating the PEP pattern, one needs to define three scribe how a request/response message can be validated, lifted to
classes, and potentially properties that link instances of these classes RDF, or generated from a RDF representation of the request/re-
to some properties. Figure 3 illustrates such a pattern instantiation sponse.
in some ontology ex: in blue.
SEAS currently contains several instances of the PEP ontology 6 SYSTEMS AND THEIR CONNECTIONS
pattern, available in the following modules: (a) seas:DeviceOntology
The seas:SystemOntology module defines an ontology pattern to
(actuating and sensing); (b) seas:ForecastingOntology (forecasting,
describe systems that are connected via some connection points.
forecaster, forecast); (c) seas:OptimizationOntology (optimization
This ontology pattern can be instantiated for example to describe
process, executor, and execution); (d) seas:TradingOntology (trad-
zones inside a building (systems), that share a frontier (connections).
ing and balancing); (e) seas:SmartMeterOntology (metering, con-
sumption metering, and more).
6.1 Systems
The seas:SmartMeterOntology and the different concepts it intro-
duces such as seas:ConsumptionMetering and seas:ProductionMe- A system, modeled by class seas:System, is defined as a part of
tering illustrate the fact that combinations can be created between the universe that is virtually isolated from the environment. The
ontology patterns: given a set of n instances of the properties on- system properties are typically state variables (e.g., consumed or
tology pattern and a set of m instances of the PEP ontology pattern, stored energy, agent population, temperature, volume, humidity).
one can define n × m instances of a new ontology pattern that com- Figure 4 illustrates classes and properties that can be used to define
bines the two. We are currently investigating methods to ensure connected systems and their sub-systems.
instances of such pattern combinations can be generated automati- A system may be connected to other systems that are part of
cally, and means to filter out those that would be irrelevant. its environment. This is modeled by property seas:connectedTo,
which is symmetric. For example,
5.2 Alignment to other ontologies seas:connectedTo
.
5.2.1 SOSA/SSN. The alignment between PEP and SOSA/SSN is
defined in an external document pep:SSNAlignment. The naming of Connected systems interact in some ways. The exact meaning
classes and properties in the PEP module has been changed to reflect of interact is defined by sub properties of seas:connectedTo. For
the latest SOSA/SSN developments. In particular, new version 1.1: example, for the electricity to directly flow between an electric
(i) defines pep:hasResult and pep:hasSimpleResult; (ii) uses term vehicle service equipment and
“made” instead of “executed”; (iii) uses term “procedure” instead of an electric vehicle , then they must be linked by
“process”. On the other hand, SOSA defines only the input, output, property seas:exchangesElectricityWith:
result and simple result. PEP introduces two additional concepts seas:exchangesElectricityWith
for commands and simple commands. Change from PEP v1.0 to .
PEP v1.1 are still to be propagated to the other SEAS modules that
imported PEP v1.0. On the other hand, nothing broke with this A system can be a sub-system of a unique other system. This is
change of version because the ontology series and the individual modeled using property seas:subSystemOf, which is asymmetric
ontology versions are clearly identified and kept published online. and functional. For example,
This illustrates the robustness of an ontology that adopts the quality seas:subSystemOf .
criterions defined in section 2.5.
Properties of subsystems somehow contribute to the properties
5.2.2 SAREF. Both classes saref:Function (i.e., functionalities of the super system. The exact meaning of this contribution is
that devices can perform to accomplish their tasks) and saref:Service defined by sub properties of seas:subSystemOf. For example, if one
(i.e., representation of these functions offered by the device over an wants to model the fact that the consumption power of a fridge
IT network), along with their hierarchies (e.g., saref:SensingFunc- contributes to the consumption power of the kitchen,
tion, saref:ActuatingFunction, saref:EventFunction, saref:Metering- , then one may use a sub-property of seas:subSystemOf
Function, saref:SwitchOnService) may be used as subclasses of the named seas:subElectricPowerSystemOf:
seas:Procedure class. SAREF also proposes the class saref:Command seas:subElectricPowerSystemOf .
with a set of predefined instances (saref:onCommand saref:offCom-
mand) that could be used both as input description of a procedure, Property seas:subSystemOf is functional, and should be asym-
and as command of its execution. metric. In fact, this would prevent a system from being its own
sub-system. But OWL 2 DL prevents a non-simple property (e.g., a
5.2.3 The WoT TD ontology. The following alignments can be functional property) from being asymmetric, see [17, §11]. If it was
proposed between PEP and the WoT ontology:
5 RDF Presentation Ontology - https://w3id.org/rdfp/
SIS-IoT’17, July 2017, Amsterdam, Netherlands Maxime Lefrançois
ProcedureExecutionContainer
owl:Thing 1. J hasCommand ldp:member H madeBy I 1. implements I
1. J hasSimpleCommand
rdfs:Literal J made hasInput I 1.
1. J hasResult ProcedureExecution ProcedureExecutor Procedure
owl:Thing hasOutput I 1.
1. J hasSimpleResult usedProcedure I 1.
rdfs:Literal
ex:Forecast ex:Forecaster ex:Forecasting
H ex:forecastsProperty H ex:forecastsProperty
Property
forecasts H H isPropertyOf 1.
FeatureOfInterest
Figure 3: The Procedure Execution ontology ontology pattern and a possible instantiation.
connectedTo I connectedTo I
J connectedTo J connectedTo
System System System System
subSystemOf I 1. con
nec ugh
Jc ted «qualifies» T hro
onn Thro ed I
ugh ect tem
Figure 4: Module seas:SystemOntology: connected systems ect
sSy I c onn tsSys
and sub-systems. ste J nec
m con
Connection
possible that both the fridge and the kitchen were sub-systems of a Figure 5: Module seas:SystemOntology: connections be-
common super system, say, the house, then the consumption power tween systems.
of the fridge would contribute twice to the consumption power of
the house. The functional aspect of property seas:subSystemOf System System
prevents this undesired effect. Due to the open world assumption connectedThr
ough I
J connectsS Connection
1.
of RDF, it is not possible to model the closed set of sub systems of ystem
co nne
I
J
gh
nn cti
co
a system using property seas:subSystemOf. rou t
ec on
h
mT
tsA Po
A
ste ystem
Sy
t I intO
«qualifies»
e cts ectsS
6.2 Connections con
n
con
n
J
f
A connection between two systems, modeled by seas:connectedTo, ConnectionPoint
describes the potential interactions between connected systems.
A connection can be qualified using class seas:Connection. For Figure 6: Module seas:SystemOntology: connection points
example, one can then associate this connection with properties of a system.
that describe the interactions between the connected systems (e.g.,
population flow, exchange surface, contact temperature). Figure 5
illustrates classes and properties that can be used to qualify con- For example, an electric vehicle charging station may have three
nections between systems. connection points: two plugs of different kind to which electric
vehicles can connect, and a three phase connection point to the
seas:connectsSystem , public grid:
.
seas:connectedThrough . seas:connectsAt ,
seas:connectedThrough , .
.
One can then associate a connection point with properties that
describe it (e.g., position and speed, voltage and intensity, thermic
6.3 Connection points transmission coefficient).
A system connects to other systems at connection points. A connec-
tion point belongs to one and only one system, and can be described 6.4 Instances of the Ontology Pattern
using the class seas:ConnectionPoint. Figure 6 illustrates the classes This ontology pattern can be instantiated for different domains. For
and the properties that can be used to describe connection points example to describe zones inside a building (systems), that share
of a system. a frontier (connections). Properties of systems are typically state
Planned ETSI SAREF Extensions based on SEAS Ontology Patterns SIS-IoT’17, July 2017, Amsterdam, Netherlands
variables (e.g., agent population, temperature), whereas properties Property rdfs:Literal
of connections are typically flows (e.g., heat flow).
The current version of the SEAS ontology contains 173 sub- "20 Wh"^^cdt:ucum
classes of seas:System, 42 subclasses of seas:Connection, and 32 sub-
evaluation 1. H H 1. evaluatedSimpleValue
classes of seas:ConnectionPoint. The use cases that are covered are:
(a) seas:ThermodynamicSystemOntology defines thermodynamic
systems that can exchange heat with one another, and that have evaluation Evaluation evaluatedSimpleValue
sub-thermodynamic systems. (b) seas:CommunicationOntology
defines communication devices that can have multiple communica-
tion connection points with various protocols, and exchange infor- AverageEvaluation
mation when they are connected through a communication con- hasValidityContext hasValidityContext
nection; (c) seas:ArchitectureOntology models the concepts from
the SRAM SEAS Reference Architecture Model [6]: an extension hasTemporalContext H H hasSpatialContext
1. 1.
of SmartM2M that allows for the distribution of group managers. hasTemporalContext
This module defines group managers that can directly manage time:TemporalEntity hasSpatialContext
geo:SpatialThing
field entities, and core entities that can directly access field entities.
(d) seas:ZoneLightingOntology defines light sources that can illumi-
nate illuminable zones, which can then transmit light to other illu- some interval some geo:SpatialThing
minable zones. (e) seas:TradingOntology defines electricity traders
that can trade electricity with one another, or trade electricity on var- Figure 7: Illustration of module seas:EvaluationOntology
ious electricity markets. (f) seas:ElectricPowerSystemOntology de- and its use.
fines electric power systems that can exchange electricity with other
electric power systems via electric power connection points. This
7.2 Quantified evaluations.
module is the biggest and most detailed SEAS module. It has been
developed in collaboration with researchers from GECAD/ISEP in Because property values may evolve in space and time, or because
August 2016, and allows to describe precisely the typology of elec- they can be approximate measures or forecasts, class seas:Evaluation
tric grids, the electric power systems that compose it (transmission qualifies the link seas:value. In particular, an instance of seas:Eval-
systems, transformers, producers, consumers, storage systems), and uation may hold metadata about: (1) The type of evaluation is defined
the configuration in which they are connected via Power buses they by the hierarchy of seas:Evaluation sub classes. SEAS currently con-
can share that depends on the current type of the connected system. tains 92 such classes, among which: (a) seas:MaximumComfortable-
Evaluation: the given value is the maximum value for a property
that is considered comfortable for the associated agent; (b) seas:Time-
7 PROPERTY EVALUATIONS MaximumEvaluation: the given value is the maximum of the quan-
Module seas:EvaluationOntology defines ontology patterns to de- tity over the temporal context. (2) The context of validity of the
scribe evaluations (qualification or quantification) of properties, evaluation. The W3C&OGC Spatial Data on the Web Working
and to qualify these evaluations: (i) what kind of evaluation: (e.g., Group defined best practices for describing the validity context of
maximum tolerable temperature, forecasted temperature, mean entities [14, Best Practice 11]: Spatial data should include metadata
temperature), (ii) in a validity context (e.g, between 10 am and that allows a user to determine when it is valid for. In SEAS, an eval-
12 am tomorrow). uation validity context is described using functional sub properties
of seas:hasValidityContext. This property can be aligned with SSN
property ssn-system:inCondition, which describes the prevailing en-
7.1 Direct evaluation vironmental Conditions for SystemCapabilites, OperatingRanges and
A seas:Property may be directly associated with a quality or quan- SurvivalRanges. We defined two such properties as shown in Fig-
tity value, which is then unique and constant. This association is ure 7: (a) seas:hasTemporalContext links an entity to its temporal
asserted using object property seas:value or using datatype property validity context, a time:TemporalEntity; (b) seas:hasSpatialContext
seas:simpleValue. links an entity to its spatial validity context, a geo:SpatialThing.
A quantity value may use external vocabularies such as QUDT (it (3) Provenance information or any other data. Other metadata may
would then be qudt:Quantity), or OM (it would then be a om:Measure be added to describe an evaluation instance. For example the W3C
or om:Point), or be directly encoded as a literal using an appropri- PROV Ontology enables to describe the activity that generated the
ate datatype such as cdt:ucum. For example, the following triples evaluation, or its generation time. Other vocabularies may be used
quantify the consumption of a fridge using cdt:ucum literals: to further describe evaluations.
For example, the following graph states that the maximum com-
fortable value of is 27.0 °C for agent , but this
seas:simpleValue "50.1 Hz"^^cdt:ucum .
seas:simpleValue "231 V"^^cdt:ucum . value peaked at 35.8 °C during time interval 12:00-13:00.
seas:simpleValue "1.68 seas:evaluation [
RAD"^^cdt:ucum . a seas:TemperatureEvaluation , seas:AgentComfortEvaluation,
seas:MaximumComfortableEvaluation ;
seas:relativeToAgent ;
SIS-IoT’17, July 2017, Amsterdam, Netherlands Maxime Lefrançois
seas:evaluatedSimpleValue "27.0 DEG"^^cdt:ucum ] ] . instantiation with filters (ongoing work), and an enhanced docu-
mentation and publication platform for the ontology with enhanced
seas:evaluation [
a seas:TemperatureEvaluation , seas:TimeMaximumEvaluationn ; management of user-requested terms and modules.
seas:evaluatedSimpleValue "35.8 DEG"^^cdt:ucum ;
seas:hasTemporalContext [ ACKNOWLEDGMENTS
a time:Interval ;
time:hasBeginning [ time:inXSDDateTimeStamp This paper has been partly financed by the ITEA2 12004 SEAS
"2017-08-10T12:00:00Z"^^xsd:dateTimeStamp ] ;
time:hasEnd [ time:inXSDDateTimeStamp
(Smart Energy Aware Systems) project, the ANR 14-CE24-0029
"2017-08-10T13:00:00Z"^^xsd:dateTimeStamp ] ] ] . OpenSensingCity project, and a bilateral research convention with
ENGIE R&D. The author would like to thank animators and par-
ticipants of the first SEAS knowledge engineering workshop that
7.3 Properties vs Evaluation: choice criteria
kicked-off this work, and especially domain experts from ENGIE
When properties seem similar and inter-dependent, one requires R&D, ISEP/GECAD, CNR, ARMINES, IMT, INNOVA, VTT, ASEMA.
precise criteria to decide how to represent them best:
(A) distinct properties. If properties can be independent, one REFERENCES
represent each of them distinctly, as functional sub-properties of [1] 2005. Linked Data. Published online at http://www.w3.org/DesignIssues/
property seas:hasProperty. This is how length and width are mod- LinkedData.html. (2005). W3C Design issue.
[2] Jie Bao, George Voutsadakis, Giora Slutzki, and Vasant G. Honavar. 2009. Package-
eled for example. One can then give independent evaluation for Based Description Logics. In Modular Ontologies: Concepts, Theories and Tech-
each of these properties. (B) a single property and different sub- niques for Knowledge Modularization, Heiner Stuckenschmidt, Christine Parent,
classes of seas:Evaluation. If the property is unique, but one quali- and Stefano Spaccapietra (Eds.). Lecture Notes in Computer Science, Vol. 5445.
Springer-Verlag, 349–371.
fy/quantify it differently, then one only define a single functional [3] Tim Berners-Lee. 1998. Cool URIs don’t change. W3C Note. W3C. https://www.
sub-property of property seas:hasProperty, and several sub-classes w3.org/Provider/Style/URI.html
of seas:Evaluation. This is how a length, and the evaluation of its [4] Simon Cox and Chris Little. 2017. Time Ontology in OWL. W3C Candidate
Recommendation. W3C. https://www.w3.org/TR/2017/CR-owl-time-20170606/
minimum and maximum can be modeled. Note that the physical [5] Bernadette Farias Lóscio, Caroline Burle, and Newton Calegari. 2017. Data on
dimension given to a property must be the same as the physical the Web Best Practices. W3C Recommendation. W3C.
[6] Guillaume Habault, Jani Hursti, and Jean-Marie Bonnin. 2017. Defining a Dis-
dimension of each of its evaluation. (C) a property and several prop- tributed Architecture for Smart Energy Aware Systems. In Complex Systems
erties of this property. If one wants to model a unique property Design & Management. Springer, 83–94.
that itself has several properties with different quantity dimensions. [7] Armin Haller, Krzysztof Janowicz, Simon Cox, Danh Le Phuoc, Kerry Taylor, and
Maxime Lefrançois. 2017. Semantic Sensor Network Ontology. W3C Candidate
This is how the consumed energy, with its active, reactive, apparent, Recommendation. W3C. https://www.w3.org/TR/2017/CR-vocab-ssn-20170711/
and the power factor, are modeled. [8] Martin Hepp. 2008. Goodrelations: An ontology for describing products and
Using OWL axioms (or rules), one may express an equivalence services offers on the web. Knowledge Engineering: Practice and Patterns, 329–
346.
between options (A) and (C) above. [9] Diane I Hillmann, Gordon Dunsire, and Jon Phipps. 2014. Versioning vocabularies
in a linked data world. (2014).
8 CONCLUSION [10] Ralph Hodgson, Paul J Keller, Jack Hodges, and Jack Spivak. 2014. QUDT-
quantities, units, dimensions and data types ontologies. (2014). USA, Available
In this paper we described the design and publication choices that from: http://qudt.org [March 2014].
[11] Sebastian Kaebisch and Takuki Kamiya. 2017. Web of Things (WoT) Thing De-
were adopted in the development of the SEAS ontology with the scription. W3C First Public Working Draft. W3C. https://www.w3.org/TR/
goal of making it a high-quality, modular and versioned, ontology, wot-thing-description/
with a homogeneous, predictible, and extensible structures thanks [12] Preston-Werner, Tom. 2013. The Semantic Versioning specification. Technical
Report. http://semver.org/
to the simple core SEAS ontology patterns and the way they can [13] Leo Sauermann and Richard Cyganiak. 2008. Cool URIs for the Semantic Web.
be instantiated. The coverage of SEAS can be extended for the W3C Note. W3C. https://www.w3.org/TR/cooluris/
modeling and the description of any kind of engineering-related [14] Jeremy Tandy, Linda van den Brink, and Payam Barnaghi. 2017. Spatial Data on
the Web Best Practices. W3C Working Group Note. W3C. https://www.w3.org/
data/information/systems, without giving up on any of the recom- TR/2017/NOTE-sdw-bp-20170511/
mended best practice def ined by the Semantic Web community. [15] Pierre-Yves Vandenbussche, Ghislain A Atemezing, María Poveda-Villalón, and
Bernard Vatant. 2017. Linked Open Vocabularies (LOV): a gateway to reusable
Together with the SAREF and the ETSI SmartM2M momentum, semantic vocabularies on the Web. Semantic Web 8, 3 (2017), 437–452.
SEAS represents a potential additional step towards large adop- [16] Pierre-Yves Vandenbussche and Bernard Vatant. 2012. Metadata recommenda-
tion of the Semantic Web formalisms by industry stakeholders of tions for linked open data vocabularies. Web document. https://lov.okfn.org/
Recommendations_Vocabulary_Design.pdf
multiple verticals, meaning a step closer to actual semantic inter- [17] W3C OWL Working Group. 2012. OWL 2 Web Ontology Language Structural
operability on the IoT. Specification and Functional-Style Syntax (Second Edition), W3C Recommenda-
Future work on the SEAS content include extensions for multiple tion 11 December 2012. Technical Report. W3C. http://www.w3.org/TR/2012/
REC-owl2-syntax-20121211/
engineering-related verticals such as Smart Home, Smart Building,
Electric Mobility, Industry of the Future/Industry 4.0, including all
their field devices/processes/systems, measurements, environment,
actors/players and their relations, as well as flexibility/trading/busi-
ness related aspects.
Future work on the SEAS development ecosystem includes de-
velopment of continuous integration tools that automatically check
the quality of pull requests on gitHub; declarative description of
ontology patterns instantiations and compound ontology pattern