W3C home > Mailing lists > Public > public-sdw-wg@w3.org > July 2016

RE: SOSA core - procedures vs devices

From: <Simon.Cox@csiro.au>
Date: Tue, 19 Jul 2016 04:01:20 +0000
To: <janowicz@ucsb.edu>, <armin.haller@anu.edu.au>, <jlieberman@tumblingwalls.com>
CC: <danh.lephuoc@tu-berlin.de>, <public-sdw-wg@w3.org>, <kerry.taylor@anu.edu.au>
Message-ID: <e6f4eebb07e841869aff0b4e98381cb3@exch1-mel.nexus.csiro.au>
I would suggest that a Platform is also a Device, but which only hosts other devices.
A Platform could host any or all of Sensors (Sensing-devices) or Observers , Actuators, or Sampling-devices.


From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
Sent: Saturday, 16 July 2016 12:49 AM
To: Armin Haller <armin.haller@anu.edu.au>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; jlieberman@tumblingwalls.com
Cc: danh.lephuoc@tu-berlin.de; public-sdw-wg@w3.org; Kerry Taylor <kerry.taylor@anu.edu.au>
Subject: Re: SOSA core - procedures vs devices

Hi Amin,

I agree. However, I think you mean Instrument or SensorPlatform, i.e., the physical object on which one or more sensors are mounted. I agree that we should have this in SOSA core but not via subclassing Sensor. This seems to be about /mereotopology/, not subsumption, i.e., a Sensor is part of a Platform or mounted on  Platform but the Platform is not a specific kind of Sensor.

What do you think?


On 07/14/2016 07:28 PM, Armin Haller wrote:
Agree with all of the points Krzysztof makes here and that represents the intention of the SANDA core proposed on Webprotege, noting that some rdfs:comments were misleading.

I can live with *Sensor* as a name for the Thing that carries out the procedure. I do believe, though, that we need a SensingDevice in the core, which then could be a subclass of Sensor or if we decide differently in the richer outer layers just a class on its own, but there would be a relation as proposed in the SANDA core usedDevice that relates the Senor to the SensingDevice. I believe we need this, because most observing/sensing/actuating being described with our lightweight newly proposed core will be done by smartphones. When you post for example location information in any social media platform, this hopefully will be annotated by tools with our core ontology. The SensingDevice will probably only have a label “Samsung Galaxy S7”, the “Sensing Act” would be the geolocation information, while the SensingDevice itself can have different contextual information as Rob was requesting. But they can be described using other vocabularies and/or our outer layers if needed. I would not introduce the concept of Human in the core. I would see Human observations as something where you will use our richer outer cores.

From: Krzysztof Janowicz <janowicz@ucsb.edu><mailto:janowicz@ucsb.edu>
Reply-To: "janowicz@ucsb.edu"<mailto:janowicz@ucsb.edu> <janowicz@ucsb.edu><mailto:janowicz@ucsb.edu>
Date: Wednesday, 13 July 2016 3:25 pm
To: "Simon.Cox@csiro.au"<mailto:Simon.Cox@csiro.au> <Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au>, "jlieberman@tumblingwalls.com"<mailto:jlieberman@tumblingwalls.com> <jlieberman@tumblingwalls.com><mailto:jlieberman@tumblingwalls.com>
Cc: "danh.lephuoc@tu-berlin.de"<mailto:danh.lephuoc@tu-berlin.de> <danh.lephuoc@tu-berlin.de><mailto:danh.lephuoc@tu-berlin.de>, Armin Haller <armin.haller@anu.edu.au><mailto:armin.haller@anu.edu.au>, "public-sdw-wg@w3.org"<mailto:public-sdw-wg@w3.org> <public-sdw-wg@w3.org><mailto:public-sdw-wg@w3.org>, Kerry Taylor <kerry.taylor@anu.edu.au><mailto:kerry.taylor@anu.edu.au>
Subject: Re: SOSA core - procedures vs devices


I would propose the following:

1. A Procedure describes the *workflow* used to perform (carry out) the act of observing/sensing. The simplified example I used today was temperature. One procedure will require to mount a thermometer 2m above ground in an area that is neither directly exposed to sun or wind. Another procedure will use the very same sensor type (thermometer) but explain how to place it within a certain layer of soil. In the first case, the observed property is air temperature; in the second case, it is soil temperature. Procedures are key to interoperability and the *reproducibility* of results. This notion of a procedure aligns well with Gil's work on workflows as well as provenance work more broadly. In the SSN-SSO pattern we stated that an Observation /satisfies/ a (observation) Procedure and that a Sensor /implements/ such Procedure. There are several types (subclasses) of Procedure. I can think of at least two: SamplingProcedure and ObservationProcedure.While this may sound trivial, please note that a single procedure is used to carry out *millions* of observations in the same way as one uses the same recipe over and over again to bake a chocolate cake.

2. The act of using a Sensor to arrive at a Result for an ObservedProperty of a FeatureOfInterest by receiving some Stimulus is what I would call Sensing/Observing (see also https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensing).  IMHO, we do not need that level of detail in SOSA-core but certainly in other (vertical  & horizontal) modules. The *most* important aspect here is that every single use of a sensor creates a new (and unique) Sensing. This is why Procedure and Sensing are very different. There are thousands of (popular) procedures but billions of sensing acts. Why would one care about the act of sensing? One example would be to use it to capture contextual information, e.g., about the weather and its potential impact on a certain observation, other observations required to interpret the results, and so on. If I am not mistaken, this particular context is also known as ObservationContext.

3. So what Thing is carrying out this Sensing by following a certain Procedure? I believe that we should call this the *Sensor* and very explicitly state that humans can be sensors, devices can be sensors, simulations can be sensors, and so forth. This leads to the interesting question of whether we should subclass sensor and I would propose not to do so in SOSA-core. Given that we merely have the expressivity of RDF at our disposal, we do not want to end up with statements such as Human subClassOf Sensor.  Even more importantly, I would not try to find a better name than Sensor. Terms such as Device will exclude humans and simulations and thus are too specific. Terms such as System are too broad. Sensors are things that perform sensing and humans clearly do so, e.g., with their eyes.

4. Try to avoid terms such as process and event whenever possible.

What do you think? Does this make sense?


On 07/12/2016 04:50 PM, Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> wrote:
Yes, but I think we were thinking more that a procedure uses a device, during an activity.

When describing the agents of observation, it depends how close you want to look. There are multiple layers of encapsulation. That was probably the motivation for bundling them together in SensorML and O&M, but SSN chose to be more careful about distinguishing physical devices from workflows – which I certainly understand as well.

The word ‘process’ is overloaded, and in particular is used in contradictory ways in BFO and O&M, and SensorML uses it in both ways. So now I prefer to avoid it altogether.

From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
Sent: Wednesday, 13 July 2016 9:10 AM
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au>
Cc: danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>; kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>
Subject: Re: SOSA core - procedures vs devices

Sorry I missed the call today. So a device “runs” (l:n) a procedure in / during (1:n) a process?


On Jul 12, 2016, at 6:39 PM, simon.cox@csiro.au<mailto:simon.cox@csiro.au> wrote:

I’ve put some notes and a diagram explaining my understanding of the consensus from today’s call here https://www.w3.org/2015/spatial/wiki/SOSA_Ontology#Procedures_vs_Devices


1.      I have adjusted the names of the classes to avoid ambiguity between the re-usable things and the events when they are used

2.      I have not yet implemented this in SOSA-Core – its just a proposal for now.



Krzysztof Janowicz

Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/<http://geog.ucsb.edu/%7Ejano/>

Semantic Web Journal: http://www.semantic-web-journal.net


Krzysztof Janowicz

Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/

Semantic Web Journal: http://www.semantic-web-journal.net

Received on Tuesday, 19 July 2016 04:03:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:23 UTC