RE: SOSA core - procedures vs devices

In order to accomplish this, the core would be essentially just a short list of classes, and a short list of the basic properties that might link them plus other key properties (e.g. “result”).
Some subclassing, but no domains/ranges or owl:Restrictions.
Think of them as stub classes or abstract classes covering the core application, primarily to get everyone onto the same page when talking about sensing, observing, actuating and sampling.

Lightweight applications might go no further.

Vertical modules would add constraints (global and/or local), further sub-classes, and additional classes and properties.

Simon

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

but I am presuming that the core vocabulary "carries" similar semantics to the intensive (vertical) additions

IMHO, vertical modules are further restricting the interpretation of SOSA-core terms while horizontal modules further broaden the domain of discourse.

Best,
Krzysztof.

On 07/13/2016 04:44 PM, Joshua Lieberman wrote:
All of the possible extensive modules may be hard to predict and plan, but I am presuming that the core vocabulary "carries" similar semantics to the intensive (vertical) additions, just as description instead of prescription.

--Josh

Joshua Lieberman, Ph.D.
Principal, Tumbling Walls Consultancy
Tel/Direct: +1 617-431-6431
jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>

On Jul 13, 2016, at 18:33, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:

As long as the core is designed and explained in the context of the set of modules necessary.  normally not working out these scopes in advance tends to lead to an ugly kitchen sink model, but we are fortunate to have enough experience available to keep the core skinny :-)

On Thu, 14 Jul 2016 7:09 am Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:
>  we need something separate to handle the fact that different types have very different deployment description requirements, and this may require subclassing to handle in-situ sensors, vs location being part of the observation, and maybe vs sensors whose location can be calculated (e.g. satellite in orbit)?

Of course. But this won’t be in the core.

Agreed.




On 07/13/2016 01:43 PM, Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> wrote:

>  we need something separate to handle the fact that different types have very different deployment description requirements, and this may require subclassing to handle in-situ sensors, vs location being part of the observation, and maybe vs sensors whose location can be calculated (e.g. satellite in orbit)?

Of course. But this won’t be in the core.

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Wednesday, 13 July 2016 4:26 PM
To: janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; 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>; 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

That all makes sense to me,  but still missing something I thin:  a deployed device has its own spatio-temporal context related, but not the same as the feature of interest, and a simulation or model will generate observations. So i am happy with sensor as a general term but we need something separate to handle the fact that different types have very different deployment description requirements, and this may require subclassing to handle in-situ sensors, vs location being part of the observation, and maybe vs sensors whose location can be calculated (e.g. satellite in orbit)?






On Wed, 13 Jul 2016 at 15:25 Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:
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