The SOSA/SSN Ontology: A Joint W3C and OGC Standard Specifying the Semantics of Sensors, Observations, Actuation, and Sampling

The paper describes the SSN ontology, a recent recommendation by the W3C for modelling sensors and observations, and related data. The new version of SSN that is now also a W3C recommendation has some significant differences compared to the previous version, and in particular the recommendation consists of a set of different modules that build upon each other. For instance, SOSA is the core light-weight pattern for describing sensors and observation data, which is then imported by SSN that adds further axiomatization and extends SOSA in several ways. Additionally, there are also alignment modules, for instance aligning SSN to DUL, and modules for extending SSN in various directions.

As an ontology description paper I think that this paper would make a nice complement to the W3C documentation that is already online. As a W3C recommendation, the ontology obviously fulfils all the usual criteria, such as being accessible online, published according to good practices and with a stable URI, well-documented etc.

However, although the paper is well written and describes SSN in a reasonable and accessible manner, there is a bit of a lack of focus. What exactly is the scope of the paper? The title says "The SOSA/SSN ontology: ...", however, in the paper also other modules are described. It is not exactly clear if the name SSN should be interpreted as covering the whole family of modules or just the actual SSN module itself. If the former is intended, then that should be made more clear, and the reason for denoting both a module and the whole family of modules by the same name should be discussed explicitly, and if it is the latter then it is not clear why the authors chose to also describe several other modules in the paper.

Another issue, and perhaps the most difficult one, is that there is another paper submitted to the JWS, which is currently under review and where I have been one of the reviewers, that describes only the SOSA module separately. Although I clearly see that these two submissions are targeting two different audiences, i.e., since SOSA is a more light-weight vocabulary, and SSN is focusing more on axiomatization, the relation between the papers has not been made explicit. I do think there is sufficient need, and content enough, for two papers, but they need to be put in relation to each other. Since SSN imports and builds on SOSA, I do not see how one could publish a paper about SSN without at least introducing SOSA briefly, but the other way around works fine, since SOSA does not rely on SSN (other than on the old SSN as its origin). Hence, I would like to see this paper, targeting mainly SSN, referencing and building on the other paper, targeting mainly SOSA, for details regarding SOSA - just as SSN imports SOSA and extends it. In the current situation, however, this is impossible, since the other paper is still in review, and may be significantly changed in a revision process due to requests by the reviewers. This is the main basis for my recommendation for a major revision of the submission in question here, i.e., to allow for the other paper to become published before a revision of this paper is made. The reviewers can then also take into account this related paper (in its final form) when reviewing the revision of the paper at hand, and thereby more precisely judge the contribution and appropriateness of scope of this paper.

Some minor issues and questions:
- There are too many acronyms in the paper, some of which are very similar and can easily be confused (for instance O&M and OM, which denote two different things).

- Figure 1 is not clear and notation is not explained, e.g., what do the boxes encompassing several classes denote, and why the different colors? (Since I happen to have read the SOSA paper draft for JWS, there the explanation of these patterns is much better, hence, this would be a perfect place to, in addition to a clarification here, reference the other paper for more examples.)

- Would it be possible to give a joint overview of the examples/example scenario used in the paper in some kind of illustration? I recognise that the examples are online, however, in the paper the reader quickly notices that they relate to each other, but the reader also quickly looses the overview of what they are about. At least I think that they should be numbered so that they can be uniquely referenced in the text. As it is now they are referenced by section, which is not very precise, and sometimes references even seem to be wrong (e.g., on page 7 the authors refer to the example in section 4.2, but there is no example there, potentially they mean 3.2).

- Figure 3 seems quite meaningless without any content in the respective boxes. Remove or detail the illustration.

- Second paragraph in section 5 starts with "It" but it is not clear to what ontology this refers.

- There is some confusion around the focus of various modules it seems. In the third paragraph of section 5, page 6, the core component (of SOSA/SSN?) is claimed to focus on three perspectives: sensor, actuator, sampler, and section 3 is referenced for explanations of these. Although I can see these three concepts in Figure 1 in section 3, the main structure of section 3 instead seems to focus on observations, sampling and actuation. Since I already read a lot about SSN, and the patterns in there, I can understand that these things actually refer to the same three patterns, but another reader may not be so lucky. I suggest the authors select one name for each pattern/perspective, and stick to it throughout the paper.

- What does "certain communities" refer to in the last sentence of 5.1?

- First section of 5.2: what exactly is the kind of property that you refer to as an OWL/RDF property?

- First sentence of second paragraph in 5.2.3 seems strange.

- The acronym QUDT is introduced in 5.4.1 but it has already been used earlier in the text.

- Last sentence of the second paragraph in section 8 (on page 16) is unclear.

- I assume you mean SSNX at the beginning of the first sentence, second paragraph, of conclusions section.

- Some references in the references section are incomplete. In particular many of them lack a publisher, e.g. when referring to proceedings books. Some also lack a volume number, such as when referring to CEUR proceedings. [38] has a last accessed date but no URL.

In the articulated lifecycle of any computational ontology, “design” and “usage” represent two equally important phases. In particular, when great effort is required by practitioners to make use of a well-designed ontology in real-world applications, ontology developers typically intervene by relaxing the initial axioms, addressing the feedbacks of the users, and engineering less stringent, an yet well-structured, ontological characterizations. This paper is an example of this sort of process.

SOSA results from a joint effort made by W3C and OGC to simplify the Semantic Sensor Network ontology in order to increase the model usability in a variety of areas (e.g. as IoT, Geoinformatics, monitoring of industrial systems, citizen science). SOSA represents four core types of entities, namely Sensor, Observation, Sample and Actuation, and is designed as the central lightweight component of a modular framework, which enables the horizontal and vertical integration of more expressive semantic layers. Modularization is important, and an effective tool to keep “front-end” lightweight ontologies separated from “back-end” heavyweight ones.

The paper provides an extensive characterization of the SOSA ontology, but the analysis and discussion of the underlying technical aspects lack of the adequate level of detail and critical evaluation. In the following, I will provide some indications of how to revise the paper.

*At the bottom of page 3 authors claim that SOSA “seems to be a closer match to the view of most practitioners”: this statement is rather vague, and doesn’t really provide any evidence in support of the new model. To substantiate the statement and explain some of the ontological decisions made by the proposers, it’d be relevant to add a section that illustrates how ontology practitioners and designers have interacted: presenting only the outcome of such interaction, and labeling it as “simplification of SSN” doesn’t sounds convincing, especially because some “simplifications” don’t appear as such at a closer examination. In this regards, please find below some open problems I have identified.

*If observations are events, what does it mean that sensors “make” them? (bottom of page 3). And in which sense observations “implement” procedures (top of page 9)? Is there a difference between the “act of observation” and the “observation” (p.7)? Do these lexical definitions (vocabulary) reflect a change in the ontological commitment (domain)?

*By modeling observations as events, and not as descriptions, SOSA would allegedly remove some of the complexity that SSN drags on applications. Still, SOSA’s Procedure, which Observation “implements”, is a subclass of DUL method, ultimately a kind of description. How does this shift generate a simpler ontological commitment, if the modeling pattern still requires descriptions?

*Observations can also be predictions (p.11), where a prediction would have a sosa:resultTime before the sosa:PhenomenonTime. But when that sosa:PhenomenonTime indeed occurs, the result of an actual observation is instantiated: how does this relate with the observation/prediction? This seems to problematic, or at least worth discussing, especially envisioning SOSA being used for spatiotemporal reasoning (when DUL, OGC PROV or other modules are imported).

*If SSNX has been criticized for its partially inconsistent handling of virtual sensors (again: this argument is too vague), it’s hard to see how by modeling Sensor as subclass of Object, and not of Physical Object, things should be simpler. Virtual sensors are often tied to multiple physical sensors, serving the purpose of aggregating data streams on the basis of context requirements. I don’t think that the modeling decision behind SOSA enhances the handling of virtual sensors: rather, what concretely happens is that the difference between virtual and physical sensors is de facto neglected.

* p.4, bottom of second column. Any object can be a sample, and samples don’t necessarily depend on the act of sampling. In this regard, a Kitchen can be a sample, in the context of observing a general property of a house, like temperature. But a Kitchen is also a Object, with a location. SOSA, it’s understood, doesn’t care about delving into the ontological quarrels about rigidity, sortals, roles. But I envision cases where practitioners will have to refer to Kitchen as Place, or as Region of space occupied by the Place, or as Sample: how does SOSA help practitioners to navigate these conceptual diversity?

Additional comments:

* p.5, section 4: Dolce Ultra Lite, and DOLCE in general, was designed as part of a library of ontologies (ref. WonderWeb deliverable cited in the paper), exactly to contrast a monolithic approach to ontology design. In this respect, to claim that DOLCE (or the derived DUL) is a monolithic ontology is inaccurate.

* p.11, before subsection 5.5.2: is mentioned, but the corresponding snippet doesn’t refer to it.

Minor issue:
p.2, end of column two: “not indented” should be “not intended”

Overall, I don’t think that the paper provides compelling arguments in support of SOSA, failing to “act as a primer that motivates the development decisions[…]”.
I’m not claiming that those arguments don’t exist: on the contrary, I believe they were essential in motivating the ontology design changes, and therefore need to be made more explicit to enhance the scientific value of the article.

This paper presents a set of ontologies describing sensors, actuators, samplers, their observations, actuation, and sampling activities,
co-developed by the W3C and OGC.

The authors present the motivation behind such ontologies, contrast them against state-of-the-art one or antecedents version e.g., SSN.
The remaining sections present the ontologies content, their modularization, limitations and (limited) evaluation.

Section 1:
I would recommend the authors to expose implemented (citing "main innovation of this generation") and non-implemented feedback (it would be nice to have a view on them) from the SSN experience.
Modularization and broader context were examples of new requirements but I guess other refinements have been achieved. Could you please expand if any? Which ones have not been implemented? any reason? motivations?

Section 2:
I would have expected a section towards what were missing from the original SSN rather than a brief history of SSNX. Could you expand along those lines?

Section 3:
Could you please motivate the source of these requirements? Were there use case driven? application driven? other? I try to understand the rational of them cf. "Following the working group’s Use Cases and Requirements analysis [26], the scope of the revised ontology has first been reduced by removing the concepts for stimulus, systems, measurement and
system capabilities from the core, then expanded beyond sensors and their observations by including classes and properties for the closely linked concepts of actuation and sampling."

Fig1: could you make clear what is new? amended? vs SSNX? It is always nice to have a visualization of changes.

Not sure what [system] is?

Section 4:
DL book citation missing.

Good chapter overall.

Section 5:
Figure 3 is a bit obscure to me - could you explain the semantics of box's size, coverage. I got this is about the structure but it is difficult to get it fully.

Re: "It consists of 13 classes, 21 object properties and 2 datatype properties." - could you say a bit more when (qualitative / quantitative) comparing with SSNX (apart from the axiomatization part)?

Overall - good coverage of concept and properties in this chapter.

It would be nice to have a table summarizing all facts in Section 5 e.g., old vs new naming in 5.5.1. That will make it easier for readers to parse changes.

Section 6:
Again a table summarizing what changed, in particular harmonized, simplified, generalized - ideally with more description on the how.

Section 7:
Very verbose section - I would recommend to summarize it in a table - difficult to follow otherwise.

Section 8:
Good content.

Section 9:
This is not about evaluation but example of application - needs to be renamed, ideally with more examples.

Examples of applications which would benefit the new version? I mean which features make the ease of SSN easier than SSNX?

Section 10:
OK section.