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

Re: SOSA core - procedures vs devices

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Thu, 14 Jul 2016 10:01:17 -0700
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Simon.Cox@csiro.au
Cc: rob@metalinkage.com.au, danh.lephuoc@tu-berlin.de, armin.haller@anu.edu.au, public-sdw-wg@w3.org, kerry.taylor@anu.edu.au
Message-ID: <5787C55D.2080700@ucsb.edu>
Hi,

This is actually fine and there will be no problem with doing this 
(also) on the SOSA-Core classes as long as we use subclassing as 
alignments and hence do not try to change the semantics of core classes 
after the fact. Vertical modules introduce new/finer distinctions to the 
same domain of interpretation, horizontal modules broaden the domain of 
interpretation.

Jano

On 07/14/2016 09:43 AM, Joshua Lieberman wrote:
> 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 
>> <mailto: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 
>> <mailto:Simon.Cox@csiro.au>>; janowicz@ucsb.edu 
>> <mailto:janowicz@ucsb.edu>; jlieberman@tumblingwalls.com 
>> <mailto:jlieberman@tumblingwalls.com>; rob@metalinkage.com.au 
>> <mailto:rob@metalinkage.com.au>
>> *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
>> 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]
>>                     *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
>>                         alsohttps://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
>>                         <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/%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
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 14 July 2016 17:01:53 UTC

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