- From: Luis Bermudez <bermudez@sura.org>
- Date: Tue, 22 Dec 2009 13:51:09 -0500
- To: "Laurent.Lefort" <Laurent.Lefort@csiro.au>
- Cc: "Michael.Compton" <Michael.Compton@csiro.au>, public-xg-ssn <public-xg-ssn@w3.org>
- Message-ID: <56b27e7e0912221051g326ebc38y50f1094a7a218405@mail.gmail.com>
Hi Laurent, et al Thanks for the summary. I think will be useful for the meeting to have all the statements in etherpad or something similar, so we can make progress while at the meeting. I created this if we think is a good idea to use it at the meeting http://etherpad.com/zyMhasUHgf And, added the summary statements from Kerry and Michael.. Please all feel free to add or edit if I missed something, cheers, -luis On Tue, Dec 22, 2009 at 8:32 AM, <Laurent.Lefort@csiro.au> wrote: > Hi, > > Let me try to complete Michael's attempt to wrap it up. > I have tried to capture everything which has been said and I use a twitter > style to keep it short. > > Read it as: > - My inputs RT (re-tweet) @someone something copied and paste from the > previous email written by someone) > - @someone look at this, you may be interested > > I hope this helps > Laurent > > > ---------------------------------------------------------------------------- > > @luis: SensorML defs are sometomes tricky, especially Process (see > http://www.w3.org/2005/Incubator/ssn/wiki/SWE_terms) > > +1 RT: @Manfred: wants a "natural way" (for lack of a better > term) of modeling a domain > > @Manfred: human "sensors" are tricky - I can see many "sensor" properties > that they don't have (e.g. it is hard to "calibrate them") and I would not > necessarily use an OGC-originated framework to model them. > > @Simon: one way to handle social sensing in O&M is to place the human in > the role of the SamplingFeature (the sensor is the device thru which the > observations are transmitted) :-) > > My answer is because it is natural to put a name at multiple levels of a > part-whole hierarchy of sensing components (easier to define simple things > than complex things) RT @jgraybeal: why have systems at all? > > Yep! Process is the tricky one to define! RT @jgraybeal: Incidentally, my > notion of processes would informally consist of the same list. I am also > having trouble drawing the distinction. > > No! We also want to characterise services! RT @jgraybeal: As I understood > it, the group was originally constructed to model hardware sensors. > > In this case, the IT process is doing the sensing job RT @Manfred: If I > want to detect user activity / inactivity on a computer in an experiment, > one of my sensors may be a the keyboard, another one running processes (not > waiting for user input), etc. > > My 2cts: okay as long as we are targeting the process of experimentally > obtaining one or more quantity values that can reasonably be attributed to a > quantity (VIM) RT @Manfred: Essentially I convert an X into a Y and Y should > be usable in a computer. Whether X a is a physical phenomenon or not depends > on the domain, IMHO. > > Yes VIM! see http://www.w3.org/2005/Incubator/ssn/wiki/SWE_terms RT > @jgraybeal Do we have a set of definitions by any chance, so we can all use > these (or some) terms the same way? > > > ---------------------------------------------------------------------------- > > measuring system > -- measuring chain > ---- measuring instrument > ------ sensor > -------- detector (device or substance) > ---------- measuring transducer > > (read measuring system --has-part-- measuring chain > and not measuring chain --are-- measuring system) > > Note: device is a generic term roughly a subclass of Thing and a superclass > of all the others. > > > ---------------------------------------------------------------------------- > > This Process = a measuring system RT @jgraybeal Yes, a Process can use > Sensors as you say. So can a Device. There is no inconsistency that I can > see. This suggests a Device is in fact a type of Process. > > Yes and users are sometimes included in it as well RT @Manfred systems > would be defined as I do and a system would consist of software and hardware > > This process = a IT process RT @Manfred the processes would clearly be > "inside" the system as part of the software, so there is a clear distinction > between "system" and "process" (other CS/IS people - please feel free to > contradict me) > > @Manfred for an Information Systems ontology check the FRISCO report > http://www.mathematik.uni-marburg.de/~hesse/papers/fri-full.pdf<http://www.mathematik.uni-marburg.de/%7Ehesse/papers/fri-full.pdf> > > @Manfred: Does your definition of process correspond to Definition E8: > State-transition structure? > > @laurent Note Frisco Definition E26: A model is a purposely abstracted, > clear, precise and unambiguous conception. > > @laurent Frisco Definition E26 (2) A model denotation is a precise and > unambiguous representation of a model, in some appropriate formal or > semi-formal language (see Fig. 3.6-1) > > Device = subclass of thing (hardware union software) RT @Manfred If you see > software as a Device, I would agree to it, but then again Device has the > connotation of hardware. > > Device not to be put in the same inheritance hierarchy as Process or as > measuring Instruments RT @Manfred Sorry, but I don't understand how a Device > can be a Process. > > RT @luis +1 RT: @Manfred: wants a "natural way" (for lack of a better > term) of modeling a domain > > Can be modelled does not mean should be sub-classes of RT @luis Sensors and > sensor system can be model as process (they can get some input and can > produce some output). We are mainly interested in the output, this is why > "process" is important > > Think you're talking of IT process here @luis Sensors and sensor system can > be model as process (they can get some input and can produce some output). > We are mainly interested in the output, this is why "process" is important > > Why should we use any sub-class relationships for this? I prefer nested > has-part relationships (see above) RT @luis System and Process are two > independent concepts. Maybe we should leave them that way and say sensor is > subclass of both. > > @laurent: FRISCO Definition E30: System, System denotation, System > component, System environment, System viewer, System representer > > A system is a special model, whereby all the things contained in that model > (all the system components) are transitively coherent, i.e. all of them are > directly or indirectly related to each other form a coherent whole. A system > is conceived as having assigned to it, as a whole, a specific > characterisation (the so-called "systemic properties"). > > @laurent; in Frisco: System is composed of sub-systems, component (and some > of them have processors) > > These defs may not belong/be mappable to the same categories of abstract IT > concepts (difference between State-transition structures and other > approaches) RT @manfred Hmm, in my domain, process is an active component, > whereas what you describe, I would describe as a data stream (processing) > system. > > Why should we use any sub-class relationships for this? I prefer nested > has-part relationships (see above) RT @luis System and Process are two > independent concepts. Maybe we should leave them that way and say sensor is > subclass of both. > > See the definition above - stop defining the world just by using sub-class > relationships ! RT @manfred Am I misunderstanding "system"? RT @luis A > system on the other hand can consist of sensors and processes. > > +1 RT @jgraybeal Well, it can certainly be modeled as a system, and it > certainly has components. (See, I bet you thought 'component' meant > hardware. But I didn't.) > > s//device//instrument// RT @jgraybeal I found the only way it made sense to > have a word 'sensor' that was different from a word 'device' was if the > sensor was performing an atomic operation. > > @jgraybeal VIM defines sensor as a "element of a measuring system that is > directly affected by a phenomenon, body, or substance carrying a quantity to > be measured" This is what you say with "atomic operation" > > 1st reading: sensor embeds an IT process RT @jgraybeal I think this is > still implementing a process, though. > > 2nd reading: sensor is-part-of a measuring-system (or measuring-chain) RT > @jgraybeal I think this is still implementing a process, though. > > A measuring-chain can include both sensors and IT processes - okay, but > need some unambiguous separation though RT A Process can include both > sensors and processes. > > Yes!!!!! RT @jgraybeal No, I think the confusion may be about Process, or > maybe Component. > > > Your def. is IT process disjoint vs. measuring-system or measuring-chain RT > @manfred I'm using one of the general meanings of the word 'process', which > applies not just to what's happening in side the computer or component, but > what happens as all the software and components interact with each other. > > @laurent Another can of worms - not sure page 154 in the Frisco report > really helps RT @manfred There are local processes and there are external > processes. > > +1 RT @jgraybeal My assumption/preference was the group that used physical > devices to transform measurable phenomena into digital data (because that's > the easiest to model and the most immediately useful). > > We now know that sensor has two separate meaning: "measuring system" > (higher level ~ what a sensor network does) and "sensor" (the atomic > operation-only ones) RT @jgraybeal If you make a sensor too general, though, > it can have components. > > See VIM proposal above (and separate the measuring defs and the IT defs) RT > @jgrayvbeal What do we call those components > > We need to be very clear on the use of the terms which can be interpreted > differently, especially sensor, process and device RT @jgraybeal So now, > what is different ... > > Should we use instrument rather than device @jgraybeal since my Sensor was > hardware and my Device had a sensor, I was already on board with Device > being hardware > > In SensorML I would handle measuring systems as processes and declare them > as PhysicalProcess or as 'CompositeProcess' when it is possible to apply the > State-transition structure model offered by SensorML @Krzysztof From a > SensorML perspective I would still add that systems are processes, namely > subtypes of 'PhysicalProcess' and 'CompositeProcess' > > My 2 cts: the subsumption order you are all arguing about is a > "presentation trick" (to facilitate discovery) and not a core ontology > pattern. You can build an additional branch in the ontology if you want one > - My problem is to build the rest! @ Krzysztof whether we can agree on the > subsumption order > > Yes, the success criteria is the ability to transform what's in SensorMl > into something which can be queried in all the different ways we have listed > in the use cases RT @luis I think we will not have any issue if we go from > SensorML to our sensor ontology. > > my conceptions/preconceptions/misconceptions are as follows. > > Sensor = measuring system here RT @michael A sensor need not be a physical > device. Kevin's definition of "An entity capable of observing a phenomenon > and returning an observed value." seems ok to me. > > > Sensor = measuring system here RT @michael A Sensor need not be a single > entity - it can be composed of any number of sub sensors, each perhaps of > their own identity, each perhaps measuring different things that get > combined into the whole. > > - The following things 'are' sensors > > = (atomic) sensor (sub-class of device) RT @michael a temperature sensor > (i.e. a physical device) at location l > > = measuring chain RT @michael a program on a computer (far away from > location l) that can read in the temperature at location l and a wind speed > estimate for location l and calculate the windchill at l > > = measuring chain + one temp sensor + one wind speed sensor + one software > component (modelled as 4 "processes" in the sensorml representation of the > chain) RT @michael something has acted as a sensor for a particular > phenomenon: the program in the second > > Yes if sensor means measuring system RT @michael if I wrote down the > temperature and wind speed measurements on a piece of paper and calculated > the wind chill myself, then I have acted as the sensor. > > See the VIM has-part hierarchy RT @michael The example of the wind chill > sensor means that sensors can have multiple components, and I guess the > components may themselves be interesting. > > This product description viewpoint should already have been handled by the > W3PM XG http://www.w3.org/2005/Incubator/w3pm/ RT @michael It's physical > decomposition into its components is different from its decomposition into > the roles it can play as a sensor. So the two sorts of decomposition may be > related, but not equivalent. > > Need to discuss the relationship between the measuring chain description > and the way it is modelled in sensorml as a particular sort of > State-transition structure RT @michael I'm also unsure about the word system > and in particular it's relationship to process. > > We are also using the term process in ytwo different ways RT we are using > the word sensor in two different contexts. > > At least two and maybe three if you want to address the > hardware/software/product configuration aspect RT @michael So is the biggest > problem here simply that we (copying from SWE) have decided that systems > have components and sensors are also made up of things, so it must be a > system - where as there are actually two hierarchies here and we should > represent them with different relationships? > > Yes but we want its description as a measuring chain with components not > necessary as a product (or we want both) RT @michael a System is a > device/computer system/software system that is made up of components > > No it can be represented as a "process model" RT @michael a Sensor is a > process (a description of inputs/outputs, some steps and data flows) which > may also be made up of sub sensors > > Ok if sensor = measuring system RT @michael a System may play the role of a > sensor for phenomenon X. > > Measuring systems equivalent to Sensor (if we opt to use Sensor for this > usage and not for the other usage of (atomic) Sensor RT @luis Some sensors > are systems > > Measuring system are System (sub-class) RT @luis Some sensors are systems > > +1 RT @michael_kerry A system contains components. > > +1 (this is an IT Process) RT @michael_kerry A process has an output and > possibly inputs and, for a composite process, describes the temporal and > dataflow dependencies and relationships amongst its parts. > > +1 RT @michael_kerry A device is a physical unit / a piece of hardware / a > system in a box. > > +1 but it's a different process RT @michael_kerry Sensing is a process > that results in the estimation of the value of a phenomenon. > > +1 but may not be required RT @michael_kerry An observer is a thing that > can do sensing. > > +1 And I would add the atomic notion brought by VIM RT @michael_kerry A > sensor is a device that can do sensing > > A measuring system = a sensing system (it is no necessarily a good idea to > have it as a disjoint class from device or (atomic) sensor RT @michael_kerry > A sensing system is a non-device system that can do sensing (so this is > intended to represent things like the regional observing system that Luis > mentioned) > > Not intuitive enough for me. Suggestions anyone? RT @michael_kerry An > AdHocObserver is all the other things that you might want to model that can > do sensing (for example, me calculating wind chill - not really a system, > but definitely doing sensing) > > Plus some bits in VIM not yet in O&M? RT @michael_kerry An observation is > the record of some sensing and contains time stamps, a result, a reference > to the sensing process ... i.e. all the bits in O&M > > > @laurent Remember that Device is used elsewhere in W3C as handheld device! > > @laurent I'd be happy to compromise for Sensing system rather than > Measuring system (and keep Sensor at a lower level) > > > ---------------------------------------------------------------------------- > > >> Open issues... > > >> There is really one big issue in the discussion: how do processes relate > >> to systems? We see 4 options > > >> (1) Process <= System > > >> (2) System <= Process > > >> (3) state nothing > > >> (4) Process disjoing System > > > ---------------------------------------------------------------------------- > > @laurent I prefer (4) Process = IT Process as modelled in SensorML > (Representation in Frisco) disjoint from Measuring system (Conception in > Frisco) > > @laurent: should we discuss the possibilities to regroup all these > separately defined concepts (in the core ontology) into a single hierarchy > (in presentation ontology) to answer to specific application requirements > (e.g. sensor-oriented discovery or data-oriented discovery) where there is a > demand to have a single hierarchy mixing everything together. > > -- Luis Bermudez Ph.D. Coastal Research Technical Manager Southeastern Universities Research Association (SURA) bermudez@sura.org - Office: (202) 408-8211 1201 New York Ave. NW Suite 430, Washington DC 20005
Received on Tuesday, 22 December 2009 18:51:44 UTC