RE: SOSA core - procedures vs devices

In the cases you describe, I’m comfortable with them all being called Platforms. But there are fuzzy boundaries on a lot of these things, and common practice in the communities that use them are not always clean.

Even the relationships between procedures (workflows, plans, algorithms) and devices can be nested both ways. A procedure can use a device, such that the involvement of the device is only part of the procedure (e.g. a complete procedure involves other processing steps, or maybe other devices). And a device can implement a procedure, else have a procedure embedded inside it (most modern instruments). How much the data provider chooses to tell us about that is kinda up to them – it can be a black-box, or completely transparent, but usually some place in between.

Some of the simplest devices actually have multiple processing steps involved if you look close enough – e.g. measuring the temperature using a mercury-in-glass thermometer depends first on observing the level of the meniscus, then comparing that level with the scale printed on the glass, then reading or inferring the number that matches the graduation mark, etc etc. Usually we don’t bother breaking it down of course. And semiconductor sensors probably generating a voltage or resistance change, then there are multiple processing steps to convert this into a number. There are various ways that you could decompose this, which may or not be of interest, and may or may not be information that is actually divulged by the provider. In O&M we didn’t distinguish procedures and devices because of this complexity, though I can see the case for it. I’m imagining that the object of the usedProcedure property will often be a very lightweight object, which merely wraps a link to the Device, the identity (or type) of which will often be enough for most users.

The case of ‘humans’ is interesting, as they combine sensors and procedures, and can also be actuators, and sampling devices, and also platforms. I wouldn’t want to put ‘human’ explicitly in the hierarchy in any one place.

Simon

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

Hi Simon,

Fine with me. So how do we call the things that carry sensors and that are not restricted to man-made (physical) devices? Examples would be humans and their senses, drones with GPS and camera sensors, and so forth. We need a neutral term. Carrier?

Jano


On 07/18/2016 09:01 PM, Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> wrote:
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.

Simon

From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
Sent: Saturday, 16 July 2016 12:49 AM
To: Armin Haller <armin.haller@anu.edu.au><mailto:armin.haller@anu.edu.au>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au>; jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>
Cc: danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>; 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

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?

Krzysztof

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

Hi,

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?

Best,
Krzysztof



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?

—Josh

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




Note

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.

Simon







--

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/<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