A pattern language for smart home applications

This article introduces an ontology for describing the Smart Home environment, and the related measures, situations, or states. It is developed as a network of ontology modules, all registered as Ontology Design Patterns at http://ontologydesignpatterns.org/ .
Most of these ontology modules extend the product of the W3C Semantic Sensor Networks Incubator Group (SSN-XG), that was strongly anchored on the DUL upper level ontology, and is currently being reworked by the W3C Spatial Data on the Web Working Group.

The use of the Ontology Design Pattern paradigm is indeed an interesting choice to design a big ontology formed by multiple weakly coupled simple ontology modules. On the other hand, the authors adopted some editing and publishing choices that make the ontology hard to reuse in practice:

- the ontologies are not published according to the vocabulary best practices recommended by the W3C [16].
- the ontologies have none of the recommended metadata (dc, dcterms, vann, voaf,..)
- the terms have none of the recommended metadata (at least rdfs:label, rdfs:comment). Let us note the exception of SmartHomeSection that has a rdfs:comment without a language tag.
- most of the classes IRI fragments are prefixed by "SmartHome". This is quite confusing and might prevent some of the modules to be reused outside of this application domain. For example, if I need to represent temporal intervals for the Smart Agriculture domain, why would I reuse the SmartHome_TimeInterval ontology and its main classes SmartHomeTimeInterval and SmartHomeTemporalDistance?
- there is no prefix defined to shorten the term IRIs, which makes it hard to reuse these terms, and also hard to browse in Protégé for instance.
- the ontologies are not registered to the Linked Open Vocabulary, which makes them hard to find and reuse.
- this ontology does not import SSN, but instead imports an ontology with IRI http://ecareathome-ontology.mpi.aass.oru.se/patterns/ssn.owl . It is unclear if this version is the same as the original.

Section 1.1. Overview on Sensor-Related Ontologies

There is very limited comparison and reuse of the related work.

The authors cite just a few related ontologies, namely SSN, SAREF, iot-light. No reference is given for SAREF. No comparison is provided to iot-light and SAREF. There exists other ontologies that aim at covering the Smart Home applications [18], or the domains targeted by each individual module.

In section 1.1, the authors use qualifier 'many' to refer to the ontologies suggested to regognising daily activities, but only give two references. No comparison is made with the ontologies used in these papers.

Given the modular aspect of the ontology, I would have expected that each module description includes a short related work section, with a list of related ontologies. For example the OWL-Time ontology should be mentioned as a related ontology for module SmartHome_TimeInterval, or simply used instead of defining this (inconsistent, see below) new ontology.

Section 1.2. SSN Representational Issues

The authors identified more or less correctly some representational issues in the SSN ontology, and the developed modules attempt to overcome these issues. However each of the identified representational issues falls into at least one of the following categories:
(a) it is incorrect and shows some misunderstanding of how SSN works;
(b) it has been discussed by the W3C Spatial Data on the Web Working Group and will no longer be true in the next version of SSN; and, or
(c) SSN is not designed to cover the representational need, and other existing ontologies should have been considered instead.

Issue 1 - category (a). Authors argue that differentiating between the class ssn:Observation and ssn:Sensing is not straightforward. They then avoid using ssn:Observation, and rely and extend ssn:Sensing instead.

Yet, instances of the ssn:Sensing class are not meant to be linked to some observed property. Instead, they represent a generic method/procedure that can be implemented in various sensors, each being potentially able to observe various features of interest. The ssn:Observation class applies this generic method/procedure to a specific property of a feature of interest, and has for result a ssn:SensorOutput.

It may be clearer in O&M [17], to which the new SSN will be aligned:

> Observation: An observation is an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a phenomenon. It involves application of a specified procedure, such as a sensor, instrument, algorithm or process chain. The procedure may be applied in-situ, remotely, or ex-situ with respect to the sampling location. The result of an observation is an estimate of the value of a property of some feature. Use of a common model allows observation data using different procedures to be combined unambiguously.

> Observation Procedure: method, algorithm or instrument, or system of these, which may be used in making an observation.

The SmartHome_Sensing pattern hence creates more confusion in conflating two terms that are originally very different in SSN.

Issue 2 - category (a). The authors seem to have understood ssn:Property as aligned with "O&M Property type" (pressure, luminosity, colour, are property types). Yet, ssn:Property is explicitly defined as exactly matching the concept "O&M Property" (e.g., pressure of the couch x, luminosity of the room y, colour of the light bulb z). Its definition is: "An observable Quality of an Event or Object. That is, not a quality of an abstract entity as is also allowed by DUL's Quality, but rather an aspect of an entity that is intrinsic to and cannot exist without the entity and is observable by a sensor.".
The examples of use of ssn:Property in [19, sections 5.3.1.2.4, 5.3.1.3.4, and 5.4.3.6] make this even clearer.
This confusion is common, see also one of the wiki page of the W3C Spatial Data on the Web Working Group: https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_...

A ssn:Observation is linked not only to the feature of interest it observes, but also to the exact property of that feature of interest it observes. Hence, I don't see the need for introducing the module SmartHome_FeatureOfInterest and the new concept SmartHomeFeatureOfInterest.

Issue 3 - category (b/c). The old SSN does import DUL. On the other hand, the W3C Spatial Data on the Web Working Group decided that the new version of SSN, i.e., the one that shall be standardized, will no longer import DUL. This fact should not directly play against the work presented in this article, but it does raise the question of the size of the set of arguments that are raised in this article and will become invalid in the near future.

Issue 4 - category (c). The IT network of sensors, their failures and reconfigurations, is not in the scope of the SSN ontology. Other existing ontologies may be interesting to model the IT network of sensors though, such as the oneM2M base ontology, or the Thing Description ontology that is under development by the W3C Web of Things working group.

Issue 5 - category (c). Describing spatial relations is indeed not in the scope of the SSN ontology. I don't see why this should be mentioned as a representational issue of SSN. The Web of Linked Vocabularies contains several other vocabularies that can potentially cover this representational need. The solution the authors propose is to reuse GeoSPARQL and specialize it for the SmartHome GeoFeatures. Other vocabularies could have been considered, such as the Open Time and Space Core Vocabulary Specification (see below).

Issue 6 - category (c). Again, describing events and states is is not in the scope of the SSN ontology. But the authors should have considered reusing or extending other vocabularies instead.

Issue 7 - category (b/c). Describing complex events and the situations that are their preconditions is not in the scope of SSN. The way the authors deal with this "representational gap" is one of the most interesting aspects of this article to me.

As a matter of fact, it has been decided in Sept. 2016 that there will no longer be a disjunction between ssn:Observation and ssn:Event. More specifically, in order for SSN to be aligned with O&M, ssn:Observation now denotes a kind of dul:Event instead of dul:Situation:
- See the third Resolution in the minutes of the 2016-09-20 F2F meeting: https://www.w3.org/2016/09/20-sdw-minutes
- The subsequent related thread in the public SDW mailing list: "Side effects of ssn:Observation being a kind of dul:Event instead of dul:Situation" at lists.w3.org/Archives/Public/public-sdw-wg/
- And the latest proposed resolution: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0425.html

This resolution does not play in favor of the rejection nor the acceptance of this article. Note however that you should let your work known to the group to make sure it will remain compatible with the new SSN ontology.

Section 2. Use Case

"frequently reported in literature" --> should at least cite more than just [1].
Also, does the SmartHome ontology enable more use cases than what is achieved in [1]? There lacks some comparison with the related work here.

The project description and the competency questions are relevant and convincing, but I hardly see how they are addressed in the rest of the article. In particular, I don't see how one can represent the fact that a property is static or dynamic with this ontology.

Section 3. Then the article continues with the description of the 10 modules:

1. Module SmartHome_TimeInterval extends DUL without importing it. It defines time intervals and temporal distances. It is also unclear why the authors did not consider to reuse another more specialized ontology such as OWL-Time.

As of Mar. 7th 2017, the following axioms in the SmartHomeTimeInterval ontology make it inconsistent:

hasUpperTimestampValue rdfs:range xsd:dateTime .
SmartHomeTemporalDistance rdfs:subClassOf [
owl:onProperty hasUpperTimestampValue ;
owl:someValuesFrom xsd:long ] .

The former axiom must be deleted.

It is not clear what the lower and upper timeStampValue represent if they are xsd:long literals. Unix timestamp ? number of ms since the sensor is on ? number of periods ?

2. Module SmartHome_Geometry extends GeoSPARQL without importing it directly. Terms from GeoSPARQL are used and a super-property is given for some of its object properties.

It is not justified why the authors chose to subsume the basic RCC-8 topological relations in GeoSPARQL, and not the DE-9IM topological relations.

The module then defines multiple directional relations based on the points of the compass. I am not convinced that using the cardinal directions is the most natural way to describe the relative direction from e.g., a kitchen to a dining room.

Other vocabularies could have been considered, such as the Open Time and Space Core Vocabulary Specification, which already defines directional relations based on the points of the compass, among other.

In (3), the following axioms is useless due to the fact that hasDirectionalRelation is a sub property of hasSpatialRelation:

SmartHomeGeoFeature rdfs:subClassOf [ owl:onProperty hasDirectionalRelation ; owl:someValuesFrom SmartHomeGeoFeature ] .

Similarly, in (4) the domain and range axioms for hasDirectionalRelation are useless.
Also, the domain and range axioms that are written in (4) are not found in the ontology.
In the presence of these axioms, any two instances that are related by a gsp:sfContains or any of the GeoSPARQL RCC-8 object properties would become instances of SmartHomeGeoFeature. This is obviously a non-desired consequence.

3. Module SmartHome_Property extends SSN and uses DUL without importing them, and defines SmartHomeProperty as a subclass of the class of `ssn:Property`ies that are properties of physical objects. To me this ontology alone is of limited interest.

4. Module SmartHome_FeatureOfInterest extends SmartHome_Property.
See main comment on SSN representational Issue 2 above.

Also, the concept SmartHomeFeatureOfInterest uses the same name than ssn:FeatureOfInterest to describe a totally different concept, that is furthermore partly incompatible (dul:PhysicalObject is disjoint from dul:InformationObject).

In (6), ssn:forProperty is defined as a relation between some aspect of a sensing entity and a property. It is not clear to me why using this property is justified here to link a dul:InformationObject to a ssn:Property.

5. Module SmartHome_Situation extends SmartHome_FeatureOfInterest.

There is a conceptual problems with the use of property ssn:isProxyFor here:

- it is defined in SSN as a "Relation from a Stimulus to the Property that the Stimulus is serving as a proxy for."
- The authors use it to link SmartObjectSituation to SmartObjectSituation.
- Problem 1: a ssn:Stimulus is a kind of dul:Event, which is disjoint from dul:Situation.
- Problem 2: a ssn:Property is a kind of dul:Quality, which is disjoint from dul:Situation.

6. Module SmartHome_Sensing extends SmartHome_FeatureOfInterest.
See main comment on SSN representational Issue 1 above.

7. Module SmartHome_Place extends SmartHome_Geometry.
It defines SmartHome as kind of both dul:PhysicalPlace and ssn:Platform.
It defines SmartHomeSection as kind of dul:PhysicalPlace
It describes the deployment of a Smart Home sensor network within a Smart Home.
The description of this module seems sound to me.

8. Module SmartHome_Network reuses SSN without importing it.
See main comment on SSN representational Issue 4 above.
Beside the fact this module could have been replaced altogether by any existing ontology, it seems sound to me.
Sentence "extends the class Deployment and indicates a platform upon which a system (e.g., a network) is deployed" is not consistent with the existential property restriction used in (14).
Rephrase: "extends the class Deployment and indicates a platform upon which a network is deployed"

9. Module SmartHome_Object

I'm really at odds over the statement that the heart of a person can be modeled as a SmartObject.

10. Module SmartHome_Event
an event can have an agent as its participant is incoherent with the axiom in (28), which states: "an event \emph{has} an agent as its participant".

Section 4 and 5.

DUL and SSN are not in the OWL 2 EL profile, so how can the Smart Home ontology be in the OWL 2 EL profile ?

Sections 4 and 5 do not help to understand how usefull the ontology is in practice, or how it's use in practice.

- What are the use cases the ontology helped to deal with?
- What kind of specialization (i.e., subclasses) of the ODP classes and individuals is there in the PEIS-Home deployment lab ?
- What kind of reasoning can you do (apart from the envisioned use cases of tracing the number of inhabitants)?
- What are the pros and cons of choosing the OWL 2 EL profile with respect to other profiles. In other words, could it be worth providing a another profile of the ontologies in OWL DL for instance?

The future work that is mentioned (i.e., tracking the number of agents located in the smart home), seems unrelated to the use case and the competency questions that are described in section 2.

A few minor comments:

The style for properties and classes is not consistent. For example p 11. between (21) and (22): DataSenderNode is in normal font, whereas sendsDataTo is both emphasized and underlined.

Some modules import other modules. There lacks a figure that illustrates that the module network and their imports.

Examples should be generalized and extended to fully describe the use case.

p. 5: hyper-link --> shortened IRI.
p. 5: indicating object properties -> indicating positive object property assertions (see https://www.w3.org/TR/owl2-syntax/#Positive_Object_Property_Assertions)
Footnote 14: the subsumption relations are inversed.
Typo p. 9: "state.In" -> "state. In"
Typo p. 9: "SenisngProcess" -> "SensingProcess"
Typo p. 9: "two class of" -> "two classes"
Typo p. 11: "cabinet" -> "cupboard (UK) or closet (US)" ? (not sure about this one)
Footnote 20 should be deleted.

References:

[16] Berrueta D., Phipps J., Miles A., Baker T., State G., Swick R. (2008) Best Practice Recipes for Publishing RDF Vocabularies, W3C Working Group Note 28 August 2008 - https://www.w3.org/TR/swbp-vocab-pub/
[17] OGC, Topic 20: Observations and Measurements version 2.0, available at http://www.opengeospatial.org/standards/om
[18] Bonino D., Corno F. (2008) DogOnt - Ontology Modeling for Intelligent Domotic Environments. In: Sheth A. et al. (eds) The Semantic Web - ISWC 2008. ISWC 2008. Lecture Notes in Computer Science, vol 5318. Springer, Berlin, Heidelberg
[19] Lefort L., Henson C., Taylor K., Barnaghi P., Compton M., Corcho O., Castro R. G., Graybeal J., Herzog A., Janowicz K., Neuhaus H., Nikolov A., Page K. (2011) Semantic Sensor Network XG Final Report, W3C Incubator Group Report 28 June 2011, available at http://www.w3.org/2005/Incubator/ssn/XGR-ssn/

This paper describes ten patterns that constitute the SmartHome ontology designed for use in smart home environments. As this is an ontology-type paper, I evaluated it from the perspective of the two criteria suggested by SWJ guidelines.

(1) Quality and relevance of the described ontology (convincing evidence must be provided). - High

The SmartHome ontology is highly relevant for environments equipped with smart sensing capabilities. This includes ambient assisted living applications which are used as an example application area in the paper, but also the emerging smart environments in the area of smart factories (e.g., smart shop-floors in Industry 4.0 settings). Therefore, the publication of this work is timely and relevant for several emerging research areas.

The presented patterns are of high quality. They have been created using design methodologies focused on ontology design patterns and reuse several established ontologies wherever possible (e.g., DUL, SSN). Each pattern is well justified, formally defined, represented in OWL for immediate reuse and exemplified in a selected use case setting.

As requested by SWJ guidelines, the described patterns are free, open, and accessible on the Web through the http://ontologydesignpatterns.org website.

In terms of comparison with other ontologies on the same topic, the paper does mention relevant ontologies in the area, however, I would expect a more thorough comparison in terms of how aspects covered by the SmartHome ontology are handled by other, key ontologies. A tabular summary would suffice.

(2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology. – Good.

Generally, the paper is logically structured, well written and explained. There are two exceptions to this:
-Firstly, the introduction is too long and already goes into details about related ontologies and technical shortcomings of SSN that are addressed by this work (Sections 1.1 and 1.2). Authors should consider restructuring the material so that the more technical content is moved from the introduction (for example, to a background and motivation section).
-Secondly, presenting all shortcomings of SSN in the introduction and then all proposed solutions in Section 3 increases the cognitive load of reading the paper. Ideally, shortcomings of SSN should be presented in the same section as the pattern that solves them, as a motivation for the pattern, whenever possible.

Last, but not least, authors should reconsider whether the term “pattern language” best describes their work. In my opinion, the terms “ontology” (as it is often used in the paper), pattern collection or pattern catalogue would be much more suitable to describe the presented material. My reservation with respect to the term “language” is that it has a rather clear meaning in the area of computers science/mathematics involving an alphabet of symbols, syntax and semantics. As this is clearly not the case for this paper, the title is likely to mislead the audience. Therefore, the use of this term should be reconsidered. If the authors still choose to use it, then more clear definitions should be given about what the term means for this paper and how it differs from the more widely spread concept of language.

Typos and smaller omissions:
•Running title differs from paper title
•Sect 1.1. “our our approach”
•Sect 1.2 “clashed in” => “clashes in”
•Sect 3: “they all lack the desirable properties of a network of module” => please list some of these properties
•There is not much point to have a section 3.1, since there is no section 3.2. Patterns could be introduced in sections 3.x rather than 3.1.x
•Sect 3.1.5: “and indicate a specific” => “and indicates a specific”
•Sect 3.1.6: “SenisngProcess” => “SensingProcess”; “two class of” => “two classes of"
•Sect 3.1.8: “variety of which” => “variety which”
•Sect 3.1.9: ”to the the”
•Sect 3.1.9 and Sect 5: “to be as the” => “to be the”

The paper describes a set of patterns composing an ontology network for the smart home domain of application. The ontology is developed by following a pattern-based approach and each pattern is motivated and illustrated in detail.
The work deserves to be published also because it insists on a very important domain which is of timely interest. Nevertheless, the paper would benefit from some intervention.

(1) Quality and relevance of the described ontology (convincing evidence must be provided). - Good

The ontology meets a good level of quality. It is open, freely available and designed by following a pattern-based approach, which is (in my opinion) a recommendable practice.
The authors take into account existing efforts in the same domain and among these decided to reuse the SSN ontology.
I would appreciate a richer discussion on related ontologies: what were they build for? how related ontologies can be linked to this one? Are there complementary ontology to SmartHome?

(2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology. – Good.

I think that the authors should avoid using the term "pattern language". Although in architecture its meaning is the one probably intended by the authors, in computer science it would easily cause ambiguity: I would refer to SmartHome as an ontology network, which I think is what it is.

The motivation why certain design choices have been made, especially when they refer to the way SSN was reused, are not easy to follow. The authors should illustrate the considered alternatives and discuss such motivations in the same place where they describe the corresponding pattern.

The authors introduce a working example and then show how certain axioms would look like in that context. They only present the axioms without explaining what the axioms encode and how they are expected to be used by a possible application. I recommend to accompany the axioms by illustrating these aspects otherwise the examples lack of usefulness.

I think the authors should enrich the discussion about the ways the ontology has been used and its possible additional and future uses. They briefly mention that the ontology is populated by the observation process, and that the result of such population enables e.g. configuration planning, context recognition. How does the ontology population work? Is the history of the observations kept? Is there any reasoning/process performed on the different observations over time? Can you make an example of a process performed thanks to the data collected (e.g. configuration planning)? What is the advantage that this ontology brings to these processes?