SmartEnv as a Network of Ontology Patterns

Tracking #: 1777-2989

Marjan Alirezaie
Karl Hammar
Eva Blomqvist

Responsible editor: 
Aldo Gangemi

Submission type: 
Ontology Description
In this article we outline the details of an ontology, called SmartEnv, proposed as a representational model to assist the development process of smart (i.e., sensorized) environments. The SmartEnv ontology is described in terms of its modules representing different aspects including physical and conceptual aspects of a smart environment. We propose the use of the Ontology Design Pattern (ODP) paradigm in order to modularize our proposed solution, while at the same time avoiding strong dependencies between the modules in order to manage the representational complexity of the ontology. The ODP paradigm and related methodologies enable incremental construction of ontologies by first creating and then linking small modules. Most modules (patterns) of the SmartEnv ontology are inspired by, and aligned with, the Semantic Sensor Network (SSN) ontology, however with extra interlinks to provide further precision and cover more representational aspects. The result is a network of 8 ontology patterns together forming a generic representation for a smart environment. The patterns have been submitted to the ODP portal and are available on-line at stable URIs.
Full PDF Version: 


Solicited Reviews:
Click to Expand/Collapse
Review #1
By Marta Sabou submitted on 24/Jan/2018
Review Comment:

This manuscript was submitted as 'Ontology Description' and should be reviewed along the following dimensions: (1) Quality and relevance of the described ontology (convincing evidence must be provided). (2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology.

Review #2
By Maxime Lefrançois submitted on 01/Feb/2018
Minor Revision
Review Comment:

The authors greatly improved the paper and took into account most of the comments I made in my original review. I have only a few main remaining issues with the paper and the ontologies, that it should be easy to overcome. I therefore suggest to require minor revision.

== Main remaining issues in the paper ==

Qualified cardinality axioms and existential axioms are often subject to discussion, and somehow contradict the statement in the introduction that the ontology makes very little ontological commitments.

- why a situation is expressedby exactly one featureofinterest, one state, and for one property ? can't there be more complex situations ?
- why a sensor implements exactly one configurationprocedure ?
- why a sensor is expressed by exactly one state ?
- why a configurationprocedure is implemented by exactly one sensor ? can't many sensors implement a configurationprocedure ?
- why a smartenvironment must have a section ? can't there be simple smartenvironments ?
- why a section must be location of a physicalobject? can't there be empty sections?
- why a network must have a node station as subsystem ? can't it be empty ?
- why a nodestation must have a node as subsystem ?
- why must a agent have constituents ?
- why must agent be participant in some event ?
- why an event must have an agent as participant ?

I don't see how with the network pattern one may represent pub/sub communication paradigms. If every publisher is linked to every subscriber for every topic they are interested in, then non desirable path between publisers and subscribers may exist when there is more than one topic. Maybe it should be explicitly mentioned that only req/res communication paradigm is covered.

== Small remaining issues on the paper ==


- section2 -> section 2


- IoT-O ([26]) is cited but not explicitly mentioned from the paragraph where it's cited, one may think [26] refers to IoT-Lite. This paragraph is unclear
- footnote 3 may be replaced, as reference [12] is actually the recommendation
- editors of a W3C rec are the authors, not contributors.
--> authors of [12] are Armin Haller, Krzysztof Janowicz, Simon Cox, Danh Le Phuoc, Kerry Taylor, Maxime Lefrançois
--> authors of [10] are Simon Cox, Chris Little


- unsure se-time:TemporalEntity is really a subclass of owl-time:TemporalEntity, or it should be other way around


- times-tamp --> time-stamp
- a "situation" illustrates to a specific --> illustrates a specific ?


- and be as the basis of --> and be the basis of ?
- se-sensingse-sensing --> sen-sensing
- introductory sentence of se-sensing:Sensor must be made clearer, the second paragraph for that concept also


- prefix dul or DUL ?
- some differences in the fonts in axiom (15)
- (19) is not in the ontology
- first paragraph of NodeStation must be rewritten (unclear)


- some differences in the fonts in axiom (22, 23)
- aslo -> also
- refer to the Object patter -> \textbf{Object} pattern


- defines a movable object can -> that can
- is a observable property -> is an observable property
- allows us to represents inhabitants -> to represent
- can own, as its constituents, at least one --> can own some, or must own at least one ?
- some differences in the fonts in axiom (31)


- see Figure. 1 --> see Figure 1
- as well as the monitoring the other features -> monitoring of other


- Table 1 line with Place - Network: a prefix is missing for inDeployment
- coach occupancy -> couch occupancy
- nodeStateion1 -> nodeStation1 (3 times)


- font size inconsistence for dul:InformationObjet and se-situState (that should be written se-situ:State)


Reference [10] and [12] should read something like

Simon Cox, Chris Little. Time Ontology in OWL. W3C Recommendation, W3C, October 19 2017, URL: (2017)

Armin Haller, Krzysztof Janowicz, Simon J D Cox, Danh Le Phuoc, Kerry Taylor, and Maxime Lefrançois. Semantic Sensor Network Ontology. W3C Recommendation, W3C, October 19 2017, URL: (2017)

== Remaining issues in the ontologies ==


- all terms are actually defined with namespace (prefix ":")
- there is still prefix "se-event:" defined as
- uses concepts from Time without importing it (se-time:Interval and se-time:TemporalDistance)
- vann:preferredNamespacePrefix should not have a language tag
- vann:preferredNamespacePrefix ""@en ; --> should be preferredNamespaceUri and be a URI (or preferrably a literal with type xsd:anyURI)
- cpannotationschema:coversRequirements may have @en
- :Event has its definition as rdfs:label


- uses concepts from without importing it


- all terms are actually defined with namespace (prefix ":")
- cpannotationschema:coversRequirements may have @en
- there is no preferredNamespaceUri
- some typo (e.g., confuguration, decsribes), but that's not really an issue
- terms:created should be a xsd:date (not a Language-tagged string)
- axiom (19) is not in the ontology
- some labels are missing (ReceiverNodeStation, SenderNodeStation, DataReceiverNode, DataSenderNode, receivesDataFrom, sendsDataTo)
- some comments/definitions are missing (receivesDataFrom, sendsDataTo)


- all terms are actually defined with namespace (prefix ":")
- comment, definition, coversRequirements, title, on the ontology can be @en
- preferredNamespacePrefix should not be xsd:date
- there is no preferredNamespaceUri
- location has no label and definition


- all terms are actually defined with namespace (prefix ":")
- comment, definition, coversRequirements, title, on the ontology can be @en
- preferredNamespacePrefix should not be xsd:date
- there is no preferredNamespaceUri


- vann:preferredNamespacePrefix should not have a language tag
- preferredNamespaceUri should have a hash '#'
- ConfigurationProcedure not defined as in (13) (no card restriction)
- Sensor not defined as in (11) (no isExpressedBy)


- preferredNamespacePrefix should not have a language tag
- there is no preferredNamespaceUri
- isSpecializationOf shoud be a URI


- imports ???
- preferredNamespacePrefix should not have a language tag
- preferredNamespaceUri should have a hash '#'
- there is a qualifiedcardinality 2 on an anonymous individual that should be deleted, along with the declaration that owl:qualifiedCardinality is an annotatinoProperty


- vann:preferredNamespacePrefix is sh ? (not se ?)
- there is no preferredNamespaceUri
- preferredNamespacePrefix and title should not be a date

== Publication and documentation issues ==

The ontologies are not published and documented according to the best practices.

at each of their URIs, one should be able to access a HTML documentation in addition to the RDF/XML document (and potentially a Turtle document)

for example, instead of having URI, the event pattern should have URI , and depending on the Accept header the client sends, the server could serve the document located at, or redirect to some html documentation at for example.

For ontology networks, it is possible, if desired, to make all module define terms under the same namespace. This is the SEAS innovative publication scheme first publised in [1]. Then all the modules would define terms under a unique namespace @prefix se: (for example)

An example of apache htaccess configuration to use that publication scheme can be found in the GitHub sources of the S3N ontology (Semantic Smart Sensor Network ontology, ) --> the sources are available at

[1] Maxime Lefrançois. Planned ETSI SAREF Extensions based on the W3C&OGC SOSA/SSN-compatible SEAS Ontology Patterns. In Proceedings of Workshop on Semantic Interoperability and Standardization in the IoT, SIS-IoT,, July 2017.

Review #3
By Valentina Presutti submitted on 24/Feb/2018
Review Comment:

The authors have addressed my concerns and significantly improved the paper content. Hence I recommend its publication.

I add a minor suggestion:

Section 5.1 shows how to populate the ontology. It's not clear if the population also includes a process of extension of the ontology. In the example, some classes are defined e.g. BedRoom. Aren't those classes already in the ontology? I recommend to clarify if the ontology needs to be extended for allowing its population.