Linking Systems and Features of Interest

Back to Semantic_Sensor_Network_Ontology.

Problem statement

The fact is that right now sosa/ssn are focused on the observation data but they still lack some features to support other scenarios.

For example, in a discovery scenario we don't have observation data, which is what currently links sensors to properties and features.

Imagine that we want to issue this query to discover sensors: “Which sensors do observe the occupancy of room X?”

This is an example of what sosa can represent in this scenario:

 ns:mySensor a sosa:Sensor ;
   sosa:observes ns:Occupancy .
 ns:Occupancy a sosa:ObservableProperty .

Attaching the location information to the sensor is not a solution; the sensor may be in another location (e.g., in another building) or have an irrelevant location (e.g., simulation software). In other words, we cannot expect a 1-to-1 relationship among a sensor and the feature it senses.

What would be needed to answer the previous query would be something that links a system to the relevant feature of interest:

 ns:mySensor a sosa:Sensor ;
   sosa:observes ns:Occupancy ;
   sosa:xxxx ns:RoomX .
 ns:Occupancy a sosa:ObservableProperty .
 ns:RoomX a sosa:FeatureOfInterest .

In terms of ssn, this is an example of what ssn can represent in this scenario:

 ns:mySensor a sosa:Sensor ;
   sosa:observes ns:Occupancy .
 ns:Occupancy a sosa:ObservableProperty ;
   ssn:isPropertyOf ns:RoomX .
 ns:RoomX a sosa:FeatureOfInterest .

However, this has another strong precondition: that there is a 1-1 relationship among a property and the feature it belongs to, which may not be the case. For example, a photometer can be used to observe occupancy in a room and another photometer can be used to observe occupancy in a building. If we try to represent this in ssn:

 ns:mySensor a sosa:Sensor ;
   sosa:observes ns:Occupancy .
 ns:Occupancy a sosa:ObservableProperty ;
   ssn:isPropertyOf ns:RoomX .
 ns:RoomX a sosa:FeatureOfInterest .

 ns:anotherSensor a sosa:Sensor ;
   sosa:observes ns:Occupancy .
 ns:Occupancy a sosa:ObservableProperty ;
   ssn:isPropertyOf ns:BuildingX .
 ns:BuildingX a sosa:FeatureOfInterest .

From these data, we cannot know which sensor observes the room. We would need something that links the sensors to their respective features (and isPropertyOf cannot help for that):

 ns:mySensor a sosa:Sensor ;
   sosa:observes ns:Occupancy ;
   sosa:xxxx ns:RoomX .
 ns:Occupancy a sosa:ObservableProperty .
 ns:RoomX a sosa:FeatureOfInterest .

 ns:anotherSensor a sosa:Sensor ;
   sosa:observes ns:Occupancy ;
   sosa:xxxx ns:BuildingX .
 ns:Occupancy a sosa:ObservableProperty .
 ns:BuildingX a sosa:FeatureOfInterest .

However, this still has another precondition: that there is a 1-1 relationship among a sensor and the property it observes, which may not be the case. For example, a photometer can be used to observe illuminance in a room and could also can be used to observe occupancy in a building. If we try to represent this in ssn:

 ns:mySensor a sosa:Sensor ;
   sosa:observes ns:Illuminance ;
   sosa:xxxx ns:RoomX ;
   sosa:observes ns:Occupancy ;
   sosa:xxxx ns:BuildingX .
 ns:Illuminance a sosa:ObservableProperty .
 ns:RoomX a sosa:FeatureOfInterest .
 ns:Occupancy a sosa:ObservableProperty .
 ns:BuildingX a sosa:FeatureOfInterest .

From these data, we cannot know which property belongs to which feature. In fact, what we really need it to represent an n-ary relationship between the system, the property and the feature.

 ns:mySensor a sosa:Sensor ;
   sosa:xxxx ns:rel1 ;
   sosa:xxxx ns:rel2 .
 ns:rel1 a sosa:wwww
   sosa:yyyy ns:Illuminance ;
   sosa:zzzz ns:RoomX ;
   sosa:yyyy ns:Occupancy ;
   sosa:zzzz ns:BuildingX .
 ns:Illuminance a sosa:ObservableProperty .
 ns:RoomX a sosa:FeatureOfInterest .
 ns:Occupancy a sosa:ObservableProperty .
 ns:BuildingX a sosa:FeatureOfInterest .

Even if the example deals with sensors, a similar case can be presented for actuators. E.g., “Which systems allow me to actuate on the illumination of building Y?”.

Potential approach

The following classes and properties (in bold in the figures) try to solve the previous issue (disclaimer: let's not discuss the naming, only the pattern).

Proposal 1

The first proposal is to include into sosa a new property that links systems to features: the forFeature property.

 sosa:forFeature a owl:ObjectProperty ;
   rdfs:label "for feature"@en ;
   skos:definition "A relation between some aspect of an entity and a Feature of Interest."@en ;
   rdfs:comment "A relation between some aspect of an entity and a Feature of Interest."@en ;
   skos:example "For example, from a Sensor to the features it can observe or from an Actuator to the features it can act on."@en ;
   schema:domainIncludes sosa:Sensor ;
   schema:domainIncludes sosa:Actuator ;
   schema:rangeIncludes sosa:FeatureOfInterest ;
   rdfs:isDefinedBy sosa: .

This is a minimal change, along with the existing observes and actsOnProperty properties and supports discovery use cases (and I expect that also others).

Why to put it into sosa instead of in ssn? Because sosa already allows representing the relationships among systems and properties and because I think that sosa should support discovery (e.g., a basic feature in the Web of Things where we expect to mainly use sosa).

Non-Proposal 2

The second proposal would be to include the n-ary pattern into ssn. I say "would be" because I don't want to open a can of worms in this moment of time. But just to state that Proposal 1 would be consistent with a further extension.

That is, if someone decides to implement the n-ary relationship, both forFeature and forProperty are a composition of the new properties ("hasScope · coversProperty" and "hasScope · coversFeature", respectively), so we allow for extensibility by implementing proposal 1.