- From: <Laurent.Lefort@csiro.au>
- Date: Wed, 23 Dec 2009 00:32:17 +1100
- To: <Michael.Compton@csiro.au>, <public-xg-ssn@w3.org>
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 @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.
Received on Tuesday, 22 December 2009 13:32:54 UTC