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> 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]
> *Sent:* Thursday, 14 July 2016 10:48 AM
> *To:* Joshua Lieberman <jlieberman@tumblingwalls.com>; Rob Atkinson <
> rob@metalinkage.com.au>
> *Cc:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>;
> 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
>
>
>
> 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
>
>
> 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 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
> <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; janowicz@ucsb.edu;
> armin.haller@anu.edu.au; public-sdw-wg@w3.org; 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
>
>
>
>
> --
>
> 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
>
>