Change prefLabel of sosa:Sensor to 'Observer'

[dr-shorthair]

The Sensor class is an abstract concept, whose extension includes all agents, devices, software etc that is capable of implementing a procedure in order to evaluate the state of some property. However, the name 'Sensor' is usually only associated with a subset of this conceptual space - i.e. mechanical and electronic sensors. While there is no need to change the URI, it would be helpful and informative to modify the annotation so that users get a better immediate indication of the scope of this class.

Note that the revision of ISO 19156 currently underway in ISO/TC 211 is adopting many of the innovations from SSN/SOSA/SSN-ext into the UML version of this model. They have already decided to name the corresponding class 'Observer' instead of Sensor.

[kjano]

Thanks Simon. From my perspective this (very useful suggestion) rather calls for a super-class 'Observer' with 'Sensor' being a sub-class (also because it is such a common term).

Best Jano

On 6/9/20 8:28 PM, Simon Cox wrote:

The |Sensor| class is an abstract concept, whose extension includes all agents, devices, software etc that is capable of implementing a procedure in order to evaluate the state of some property. However, the name 'Sensor' is usually only associated with a subset of this conceptual space - i.e. mechanical and electronic sensors. While there is no need to change the URI, it would be helpful and informative to modify the annotation so that users get a better immediate indication of the scope of this class.

Note that the revision of ISO 19156 currently underway in ISO/TC 211 is adopting many of the innovations from SSN/SOSA/SSN-ext into the UML version of this model. They have already decided to name the corresponding class 'Observer' instead of Sensor.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw-sosa-ssn/issues/29, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANMP5QHIJH5BECEQS3VYW3RV34XJANCNFSM4NZ7HNTQ.

-- Krzysztof Janowicz

Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net

[rob-metalinkage]

I agree that a superclass is preferable.

I think a possible key difference between an Observer and an Sensor is that the Sensor has a discrete and predeterminable sensor type - even if its not known.

[dr-shorthair]

The label and definition of the madeBySensor predicate must be kept aligned.

[kjano]

On 6/9/20 9:16 PM, Simon Cox wrote:

The label and definition of the |madeBySensor| https://www.w3.org/TR/vocab-ssn/#SOSAmadeBySensor predicate must be kept aligned.

In this case we could consider an owl:equivalentClass relation between Sensor and Observer.  I am just unsure whether relabeling is a good idea (also from a semantics perspective), particularly because the term Sensor is so well established. We would then also have to rename FeatureOfInterest into 'Observed' or 'Observable' or something like this (which also reminds me of the corresponding software design pattern).

Jano

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw-sosa-ssn/issues/29, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANMP5WJYTCZMCKQKQZY5BTRV4CLBANCNFSM4NZ7HNTQ.

-- Krzysztof Janowicz

Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net

[dr-shorthair]

sosa:Sensor rdfs:subClassOf sosa:Observer . 
sosa:madeBySensor rdfs:subPropertyOf sosa:madeByObserver . 

But what other subclasses of sosa:Observer do we know about?

[maximelefrancois86]

Dear all,

Long time no talk :-)

There is currently no such axiom in SOSA. In the philosophy of SOSA, if I got it right, subClassOf and subPropertyOf axioms were banned so as to facilitate the integration in schema.org. There already is a super-class of sosa:Sensor, but it's in SSN: ssn:System.

Also, sosa:Sensor, even if the name refers to a subset of the conceptual space you mention, is perfectly suitable for non-electronic and mechanical devices such as humans.

I would preferably keep SOSA lightweight and simple, and update the definition of sosa:Sensor to explicitly state this concept is aligned with the "Observer" one in ISO 19156

[KathiSchleidt]

related to w3c/sdw-sosa-ssn#43

[dr-shorthair]

In #56 it has been resolved that there is no need for a new class Host since it is functionally identical to Platform. The fact that SOSA Platform implements OMS Host can be indicated through annotation and documentation, and by adding an alternative label 'Host'.

The case of Sensor vs Observer is very similar. If people are OK understanding (for example) that humans can be classified as Sensors when they are implementing an observation procedure, then there is no need for a new class.

On the other hand, if we really wish to enable the creation of a hierarchy of Observer subclasses, with Sensor being the one that we already know about, then having the class Observer could have some utility. However, I'm not sure in practice that any other subclasses are commonly used, or that there are any general differentia to justify a new class?

This issue did not originally propose a new class, merely that the labeling and documentation could be improved to indicate that SOSA Sensor implements OMS Observer. Perhaps we should just stick with that?

[dr-shorthair]

We could also put a xxx:Observer class in a SOSA-OMS alignment graph, separate from the SOSA graph. And put the subclass to Sensor axiom there.

[maximelefrancois86]

The OMS standard defines "Observer" as: "identifiable entity that can generate observations pertaining to an observable property by implementing a procedure"

The can here is problematic, as it relates to a capability more than an intrinsic characteristic.

As a parallel, it would be equivalent to define "Genitor" as: "identifiable entity that can generate an offspring" (not talking about the procedure here)

Naively, I would say that "Observer" refers more to the role some entity has with respect to an observation, rather than an intrinsic characteristic of an entity:

• You aren't an observer until you make an observation.
• A sensor is intrinsically a sensor, but only becomes an observer when it makes an observation.

Therefore to me "observer" would best be used to name an Object Property, such as sosa:madeByObserver that would generalize sosa:madeBySensor.

[dr-shorthair]

Observer is the name of the class in OMS. However, the definition is essentially the same as sosa:Sensor, and there is no separate Sensor class in OMS, and thus no subclass relationship.

So I think we just need to say in the SOSA-OMS mapping that OMS Observer is implemented by sosa:Sensor.

The definition of sosa:Sensor makes it clear that it is fully general:

Device, agent (including humans), or software (simulation) involved in, or implementing, a Procedure.

Perhaps the appropriate action from this issue is to change the prefLabel of sosa:madeBySensor to 'made by Observer' ?