Re: SOSA core - procedures vs devices

I'm afraid disagree somewhat here - the requirements and scope discussion
should allow us to decide what set of extensions we need and the governance
for these (i.e. do we point to something external, identify a need to
create something common, recommend communities create their own standards
or create the module and manage it ass part of SSN).

The "core" is starting to become a problematic term too - is it a single
module or a set of modules - and if its the set of modules that identify
the concepts then deployment and frame of reference of sensors what makes
SSN distinct from vanilla O&M.  IMHO it doesnt need to define the content
model for these descriptions, allowing specialised sub-domains to work out
what they need to do, but it needs to define where such descriptions are
attached and a mechanism to find out what form the description is in.

Also I'm not sure that "carries similar semantics" gels for me - the
"vertical modules" define additional semantics using languages of greater
expressivity - to me this is quite dissimilar to "similar" - i think
vertical modules use identical semantics (through import?) and express
additional semantics.

I'm probably being both ignorant and pedantic here :-)  but from the
perspective of someone coming in from outside and trying to work out "what
use is this thing" I think clear and precise descriptions of the role of
each component is the first step, and then consistent use of the
terminology and language in the detail is required.

IMHO the conversation is being useful in teasing out some subtle
differences in expectation and/or language amongst the team - and I look
forward to being able to read the module descriptions (embedded as rdf
statements) - which should be sufficient for me to understand the scope and
use of each, and hence what commitment is being made when we use a specific
term from within a module.

Rob





On Thu, 14 Jul 2016 at 09:44 Joshua Lieberman <jlieberman@tumblingwalls.com>
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
>
> On Jul 13, 2016, at 18:33, Rob Atkinson <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> 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 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
>> <rob@metalinkage.com.au>]
>> *Sent:* Wednesday, 13 July 2016 4:26 PM
>> *To:* janowicz@ucsb.edu; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
>> <Simon.Cox@csiro.au>; jlieberman@tumblingwalls.com
>> *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
>>
>>
>>
>> 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>
>> 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>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 [ <jlieberman@tumblingwalls.com>
>> mailto:jlieberman@tumblingwalls.com <jlieberman@tumblingwalls.com>]
>> *Sent:* Wednesday, 13 July 2016 9:10 AM
>> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>
>> *Cc:* <danh.lephuoc@tu-berlin.de>danh.lephuoc@tu-berlin.de;
>> janowicz@ucsb.edu; armin.haller@anu.edu.au; <public-sdw-wg@w3.org>
>> public-sdw-wg@w3.org; <kerry.taylor@anu.edu.au>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 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
>>
>> Webpage: http://geog.ucsb.edu/~jano/
>>
>> 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
>>
>>