Re: SOSA core - procedures vs devices

ps - i am agreeing with Krzysztof !


On Thu, 14 Jul 2016 at 11:05 Rob Atkinson <rob@metalinkage.com.au> wrote:

>
> 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
>>>
>>>