- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Wed, 13 Jul 2016 04:34:07 +0000
- To: Simon.Cox@csiro.au, jlieberman@tumblingwalls.com
- Cc: danh.lephuoc@tu-berlin.de, janowicz@ucsb.edu, armin.haller@anu.edu.au, public-sdw-wg@w3.org, kerry.taylor@anu.edu.au
- Message-ID: <CACfF9Lw5XXdWGubTS7eE8wTu8CXn=KD7AAMHRKbTikUK4FeOsA@mail.gmail.com>
Probably going to rehash an old debate here, but given there is an active conversation trying to make the model more easily understood to outsiders I'll dive in to check my comprehension... This description ( sensor->procedure->activity) is helpful to me at least to quickly understand the basic concerns. It introduces a requirement on the modularity IMHO: because procedures are not unique to sensing, its is necessary to allow procedures to be independent of sensors - because there are numerical models that generate similar looking results to sensing. Sensing appears to be bound up in the spatio-temporal frame of reference of the observer, whereas the spatio-temporal frame of reference of the phenomena is common to sensing, models, statistical operations (are these just models). I would expect the model module structure to reflect this: its a way of attaching such sensing related metadata to a general observation process. Is a deployed sensor just a sampling feature (being a sensor within a specific spatio-temporal context but also within a context where what it observes indirectly to a property of the feature of interest?) cheers Rob On Wed, 13 Jul 2016 at 09:50 <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> > *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 > > >
Received on Wednesday, 13 July 2016 04:34:50 UTC