Conceptual modules of the SSN ontology

This page describes the different conceptual modules of the SSN ontology.

These conceptual modules do not intend to represent how the OWL implementation of the ontology should be split into files (in fact, all these modules are included in a single OWL file in the current version of the ontology). However, they can support the discussion of how to split the OWL implementation of the ontology into different files.

The starting point has been the different figures appearing in the SSN XG Final Report [1] and the figures included here are subsets of those figures.

Feature of Interest module

This module allows describing features of interest and their properties.

Issue:

[SJDC] Feature of interest is a role, so might better be used as the name of the property linking a Feature to an observation. A Feature will exist separately to an observation, and only becomes of interest in the context of the observation.

[RGC] That's a good comment. Right now in the SSN ontology the class is named "FeatureOfInterest", which fits with what you say because it is in the context of an observation. However, the class is documented as follows:

A feature is an abstraction of real world phenomena (thing, person, event, etc).

which refers to any feature in general.

Right now between the Observation and FeatureOfInterest classes there already exists a featureOfInterest property.

Therefore, we may need either to change the documentation or to make explicit the differentiation using two classes for feature + feature of interest or to rename the FeatureOfInterest class into Feature.

Stimulus-Sensor-Observation pattern module

This module allows describing observations following the SSO pattern.

Issue:

Currently it is required that a sensor output has at least one observation value. This restriction is too strong, since the output of every sensor could not have a direct value. As an example, a sensor that produces as its output an image (or an audio file) is producing a specific sensor output (which is an information object) but such output does not have a direct observation value.

[SJDC] Don't quite understand this. Is the problem that the type of the result is 'image' and somehow this is not commensurate with the observed property? If so, then I disagree that the problem is the cardinality constraint - rather, the issue is mis-identification of the observed property.

[RGC] Let's try with an example. Imagine that I have a sensor that captures people's pictures (e.g., in an airport). The sensor just captures the raw data (i.e., the image of a person) and not any other data that could be extracted from it. I would represent this as follows:

ns:myObs a ssn:Observation ;
    ssn:observedBY ns:ImageSensor001 ;
    ssn:featureOfInterest ns:Person001 ;
    ssn:observedProperty ns:Depiction ;
    ssn:observationResult ns:Person001Depiction2016 .
    
ns:Person001Depiction2016 a ssn:SensorOutput .

Now, if I have to add the ssn:hasValue property to the previous sensor output, I cannot think of any way of doing that doesn't seem artificial.

[SJDC] Maybe another place where role and classification are being confused? SensorOutput looks like the role of the ObservationValue with respect to the Sensor, and observationResult is the role of the same ObservationValue with respect to the Observation. But maybe I'm misunderstanding the SSO pattern.

[RGC] If we take into account the mapping with DUL, a SensorOutput is a dul:InformationObject and an ObservationValue is a dul:Region. So they are intended to represent different things.

[sjdc] I would suggest that anything with "value" in its name must be an information object. The goal of making an observation is to increase our knowledge of the world, not to change the world. I also know that DUL introduces a few unhelpful disjoint axioms, though maybe that's not the problem in this case, it is the mapping that is in error.

Sensor

This module allows describing sensors.

Issue:

The declaration of the sensingMethodUsed property adds redundancy to the ontology (i.e., the same information could be represented through the sensor class). From the modularization point of view, this is not good because it increases coupling between modules (i.e., the number of dependencies between modules). My suggestion is to remove the sensingMethodUsed property from the ontology; it does not affect its representational capabilities and the (conceptual) module would be cleaner (i.e., if I want to describe a sensor I don’t need to know about observations).

[Kerry] The "same information" instances are not necessarily the same thing. A sensor can have multiple "Sensing"s, ie can implement multiple sensing methods, while an observation can have (quite rightly) only (and exactly) one sensing method. What we could do instead is ensure that the SensingMethodUsed for an Observation is uniquely defined by observedBy composed with implements, which would require only one sensing method per Sensor. This is achievable as if any Sensor can have only one Sensing method we can just create a new Sensor for each different Sensing method. This redefines Sensor a bit, and is not backwardly compatible, but maybe not too much. The advantage of this rewrite is that it keeps that nice multiple viewpoints property of ssn -- you can come at it from the point of view of a sensor or an observation and it still makes sense. On the other hand, I think it is better left as is.

[SJDC] In my experience a sensor only implements one sensing method - that is pretty much definitional - else it is a 'platform' or compound-sensor of some kind.

Device module

This module allows describing devices (and sensing devices).

Device deployment module

This module allows describing device (system) deployments.

Device property module

This module allows describing device properties (i.e., survival and operating ranges).

Sensor property module

This module allows describing sensor properties (i.e., measurement capabilities).

Issue:

Even if I see that these measurement capabilities are related to the sensing process and not to a specific device, taking into account a broad perspective of sensors (e.g., including humans, algorithms) I don’t know if these capabilities will be naturally applied to any type of sensor (or even if some of them are only specific to sensing devices, such as drift).

Condition module

This module allows describing conditions.

Overview of the conceptual modules

The following figure presents an overview of the conceptual modules and their dependencies. In theory, when placing these modules into OWL files in a concrete implementation of the ontology these conceptual modules should not be split.

The figure below presents the same modules and also highlights those vocabulary terms (only concepts) that are reused from one module to another.

SSN Observations and Feature of Interest

(Sefki Kolozali) The SSN Ontology provides a vocabulary for describing concepts such as sensors, outputs, observation value and feature of interests. However, sensor observations can be in different format and shape. Therefore, there is room for improvement in the representation of sensor observations taking into account the multimodal sensory data, such as audio, video as well. I have developed an ontology called SAO Ontology (http://iot.ee.surrey.ac.uk/citypulse/ontologies/sao/sao), which enables people to annotate the observations as data streams (as a matrix), points, and segments based on TimeLine Ontology, PROV-O ontology, and SSN Ontology. This kind of conceptualisation can help the SSN Ontology to represent temporal features as well as different size and shape of data streams. I also think that feature of interest concept needs clarification as it often triggers a lot of discussions among the researchers.