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>
> *Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
> *Date: *Wednesday, 13 July 2016 3:25 pm
> *To: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, 
> "jlieberman@tumblingwalls.com" <jlieberman@tumblingwalls.com>
> *Cc: *"danh.lephuoc@tu-berlin.de" <danh.lephuoc@tu-berlin.de>, Armin 
> Haller <armin.haller@anu.edu.au>, "public-sdw-wg@w3.org" 
> <public-sdw-wg@w3.org>, Kerry Taylor <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
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net