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

Re: SOSA core - procedures vs devices

From: Joshua Lieberman <jlieberman@tumblingwalls.com>
Date: Thu, 14 Jul 2016 12:43:53 -0400
Cc: rob@metalinkage.com.au, janowicz@ucsb.edu, danh.lephuoc@tu-berlin.de, armin.haller@anu.edu.au, public-sdw-wg@w3.org, kerry.taylor@anu.edu.au
Message-Id: <EE41FD24-68E4-406A-89C8-DFE6A59D4B4A@tumblingwalls.com>
To: Simon.Cox@csiro.au
I agree with subclasses as “higher” modules of the core. Specialization is probably the clearest form of vertical addition to the ontology. Less clear are additional classes that may have the effect of more specificity but structurally extend the ontology. I’m wondering specifically about the case of simply adding constraint clauses on to the core classes and their properties in higher modules. Beyond the issue of how to identify the presence or absence of such clauses, it seems like a good idea to encourage by way of description the same usage of the core classes that is enforced “higher up” by constraints. The goal would be to minimize inconsistencies between use of the core vocabulary and use of the same entities with added constraints.

Maybe this means that we should stick with applying the more expressive constraints to subclasses only, not the core vocabulary.

—Josh

  
> On Jul 14, 2016, at 1:42 AM, Simon.Cox@csiro.au wrote:
> 
> Both subclasses (i.e. refinements – e.g. the sub-classes of sensing-devices that you mentioned earlier) and classes for auxiliary concepts that are not subclasses of the core might be added in vertical models (e.g. add ‘site-visit’, ‘study-location’ to the sampling module, or ‘laboratory’ to the observation module). The latter don’t extend the scope of the application, though I guess strictly they extend the scope of the ontology. 
>  
> Subclasses cannot imply a horizontal extension – that’s inconsistent with the set-theoretic definition of subclass.
>  
> The core is as generalized as possible for the classes that are named. Minimum semantics but maximum scope.
>  
> Simon
>  
> From: Rob Atkinson [mailto:rob@metalinkage.com.au] 
> Sent: Thursday, 14 July 2016 2:29 PM
> To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; janowicz@ucsb.edu; jlieberman@tumblingwalls.com; rob@metalinkage.com.au
> Cc: 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
>  
>  
> Can you give an example of a "vertical" adding classes - as opposed to a "horizontal". I guess it applies to blank nodes for owl:restrictions which are technically owl:Classes (?) 
>  
> If its adding sub-classes - wouldnt these be further horizontal (but outside the core) domain extensions?
>  
> Rob
>  
>  
>  
>  
> On Thu, 14 Jul 2016 at 12:11 <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>> wrote:
> 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 <mailto:janowicz@ucsb.edu>] 
> Sent: Thursday, 14 July 2016 10:48 AM
> To: Joshua Lieberman <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>>; Rob Atkinson <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>
> Cc: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>; 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
>  
> 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 <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 <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 <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 <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 <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 <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/~jano/>
> Semantic Web Journal: http://www.semantic-web-journal.net <http://www.semantic-web-journal.net/>

Received on Thursday, 14 July 2016 16:45:14 UTC

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