- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 13 Jul 2016 17:48:25 -0700
- To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Rob Atkinson <rob@metalinkage.com.au>
- Cc: Simon.Cox@csiro.au, danh.lephuoc@tu-berlin.de, armin.haller@anu.edu.au, public-sdw-wg@w3.org, kerry.taylor@anu.edu.au
- Message-ID: <5786E159.7060306@ucsb.edu>
> 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>; >>> <mailto:public-sdw-wg@w3.org>public-sdw-wg@w3.org >>> <mailto:public-sdw-wg@w3.org>; >>> <mailto:kerry.taylor@anu.edu.au>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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 14 July 2016 00:49:00 UTC