- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Mon, 18 Jul 2016 21:08:34 -0700
- To: Simon.Cox@csiro.au, armin.haller@anu.edu.au, jlieberman@tumblingwalls.com
- Cc: danh.lephuoc@tu-berlin.de, public-sdw-wg@w3.org, kerry.taylor@anu.edu.au
- Message-ID: <578DA7C2.2050505@ucsb.edu>
Hi Simon, Fine with me. So how do we call the things that carry sensors and that are not restricted to man-made (physical) devices? Examples would be humans and their senses, drones with GPS and camera sensors, and so forth. We need a neutral term. Carrier? Jano On 07/18/2016 09:01 PM, Simon.Cox@csiro.au wrote: > > I would suggest that a Platform is also a Device, but which only hosts > other devices. > > A Platform could host any or all of Sensors (Sensing-devices) or > Observers , Actuators, or Sampling-devices. > > Simon > > *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu] > *Sent:* Saturday, 16 July 2016 12:49 AM > *To:* Armin Haller <armin.haller@anu.edu.au>; Cox, Simon (L&W, > Clayton) <Simon.Cox@csiro.au>; jlieberman@tumblingwalls.com > *Cc:* danh.lephuoc@tu-berlin.de; public-sdw-wg@w3.org; Kerry Taylor > <kerry.taylor@anu.edu.au> > *Subject:* Re: SOSA core - procedures vs devices > > Hi Amin, > > I agree. However, I think you mean Instrument or SensorPlatform, i.e., > the physical object on which one or more sensors are mounted. I agree > that we should have this in SOSA core but not via subclassing Sensor. > This seems to be about /mereotopology/, not subsumption, i.e., a > Sensor is part of a Platform or mounted on Platform but the Platform > is not a specific kind of Sensor. > > What do you think? > > Krzysztof > > On 07/14/2016 07:28 PM, Armin Haller wrote: > > Agree with all of the points Krzysztof makes here and that > represents the intention of the SANDA core proposed on Webprotege, > noting that some rdfs:comments were misleading. > > I can live with **Sensor** as a name for the Thing that carries > out the procedure. I do believe, though, that we need a > *SensingDevice* in the core, which then could be a subclass of > *Sensor * or if we decide differently in the richer outer layers > just a class on its own, but there would be a relation as proposed > in the SANDA core *usedDevice* that relates the Senor to the > SensingDevice.**I believe we need this, because most > observing/sensing/actuating being described with our lightweight > newly proposed core will be done by smartphones. When you post for > example location information in any social media platform, this > hopefully will be annotated by tools with our core ontology. The > SensingDevice will probably only have a label “Samsung Galaxy S7”, > the “Sensing Act” would be the geolocation information, while the > SensingDevice itself can have different contextual information as > Rob was requesting. But they can be described using other > vocabularies and/or our outer layers if needed. I would not > introduce the concept of Human in the core. I would see Human > observations as something where you will use our richer outer cores. > > *From: *Krzysztof Janowicz <janowicz@ucsb.edu> > <mailto:janowicz@ucsb.edu> > *Reply-To: *"janowicz@ucsb.edu" <mailto:janowicz@ucsb.edu> > <janowicz@ucsb.edu> <mailto:janowicz@ucsb.edu> > *Date: *Wednesday, 13 July 2016 3:25 pm > *To: *"Simon.Cox@csiro.au" <mailto:Simon.Cox@csiro.au> > <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>, > "jlieberman@tumblingwalls.com" > <mailto:jlieberman@tumblingwalls.com> > <jlieberman@tumblingwalls.com> <mailto:jlieberman@tumblingwalls.com> > *Cc: *"danh.lephuoc@tu-berlin.de" > <mailto:danh.lephuoc@tu-berlin.de> <danh.lephuoc@tu-berlin.de> > <mailto:danh.lephuoc@tu-berlin.de>, Armin Haller > <armin.haller@anu.edu.au> <mailto:armin.haller@anu.edu.au>, > "public-sdw-wg@w3.org" <mailto:public-sdw-wg@w3.org> > <public-sdw-wg@w3.org> <mailto:public-sdw-wg@w3.org>, Kerry Taylor > <kerry.taylor@anu.edu.au> <mailto:kerry.taylor@anu.edu.au> > *Subject: *Re: SOSA core - procedures vs devices > > 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>; 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 > > > > > -- > 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 Tuesday, 19 July 2016 04:09:10 UTC