- From: Manfred Hauswirth <manfred.hauswirth@deri.org>
- Date: Tue, 22 Dec 2009 19:37:04 +0000
- To: Michael Compton <Michael.Compton@csiro.au>
- CC: Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
The notion of "implementation" would also allow you to separate the "interface" (how do I use the output" from the implementation of the actual measurement process (what physical phenomenon did I measure and how) - borrowed from computer languages :-) Cheers, Manfred Hauswirth, Manfred wrote: > I agree with Michael. > > What about "A sensor implements a process"? The process may be > implemented in hardware (=> device) or in software or a mix. Sensors can > be components of more complex sensor. > > Cheers, > > Manfred > > Michael Compton wrote: > > > > Maybe I should just address the dot points. > > > > > >> - A process has inputs and outputs > > > > ok > > > >> - A system has components > > > > ok > > > > (1) > >> - A sensor is a process > > (2) > >> - *Some* devices are sensors > >> - Some devices are sensors - because they have an output > > > > are we saying that a sensor is a process or that sensing is a process. > > For example, lets say: > > > > * I have a device that measures wind chill (i.e. it measures temperature > > and wind speed and does a calculation), by (2) above it's a device that > > is-a sensor, and by (1) it must be a process (I'm uncomfortable with > > this already because we have now said that a device is-a process, which > > seems wrong to me. I'd think a device might follow some process, but > > this is-a relationship seems strange). > > > > * Now what if I write down the wind speed and temperature measurements > > myself and do the calculation myself. What's the sensor here? It can't > > really be me, can it - it would seem strange to say that I am a process > > and a sensor. Seems more like I followed a process and thus calculated > > wind chill. So maybe the sensor is the process I followed? Or is it the > > act of me following the process? In either case we have a problem > > because above we said a device is-a sensor and then here we are saying > > something entirely different (a process or the act of following it) is-a > > sensor. > > > > I would say that a device cannot be a sensor (well not in the process > > sense that we have been talking about) otherwise we are conflating an > > abstract (a process) and a concrete thing (a device). > > > > Seems from all the discussions that we have had that sensing is-a > > process - or that some processes result in sensing something, and that a > > device or a person, or a regional observing system might act out such a > > process and thus sense something. > > > > So I would be more comfortable with > > > > - Sensing is a process > > - Some devices can act as sensors > > > > And then that a device that senses something could be a 'sensing > > device', which thus acts out some sensing process. > > > > but I don't agree with (2) above > > > > > >> - *Some* devices are systems > > > > Why aren't all devices systems? Even if they only have one component or > > we don't want to write down all their components? > > > > > >> *- Some systems are sensors* > > > > It depends, is our definition "A system has components" or "All things > > with components are systems"? The question itself is silly, but my > > point is why are we trying to use the same component relationship to > > describe devices and processes? > > > > I'm having trouble seeing the example above with me calculating wind > > chill as a system. > > > > > > Michael > > > > > > > > > > > > > > > > > > > > On 20/12/2009, at 2:19 , Luis Bermudez wrote: > > > >> Hi Michael, > >> > >> The only thing we have said about systems is that it contains > >> components... > >> > >> > >> > >> On Fri, Dec 18, 2009 at 12:42 AM, Michael Compton > >> <Michael.Compton@csiro.au <mailto:Michael.Compton@csiro.au>> wrote: > >> > >> my conceptions/preconceptions/misconceptions are as follows. > >> > >> - 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. > >> > >> > >> agree ! > >> > >> > >> > >> - 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. > >> > >> > >> This is why it can be a system . Maybe we need to add also: > >> > >> *Some sensors are systems* > >> ** > >> > >> > >> > >> - The following things 'are' sensors > >> *a temperature sensor (i.e. a physical device) at location l > >> *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 > >> > >> > >> > >> Yes.. Commonality is that a sensor has an output and therefore are > >> processes. > >> > >> > >> > >> More correctly, in both cases something has acted as a sensor for > >> a particular phenomenon: a device in the first instance, and the > >> program in the second - 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. > >> > >> - The example of the wind chill sensor means that sensors can have > >> multiple components, and I guess the components may themselves be > >> interesting. > >> > >> - A device (a physical piece of hardware) can also be broken down > >> into components (presumably other devices, but perhaps also > >> systems - software systems etc) but I don't see that as having > >> anything to do with sensors or their decomposition into parts. > >> For example, imagine a device that can measure wind speed and > >> temperature, that has a small inbuilt chip that can calculate wind > >> chill, round measurements, compute averages and a radio to > >> communicate its readings. 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. > >> > >> > >> > >> So I think this still holds true: > >> > >> - Some devices are sensors - because they have an output > >> - Some devices are systems - because they have components > >> > >> But if you wnat to propose other statements which make the system > >> composition more explict, please do so. > >> > >> > >> > >> > >> > >> - I'm also unsure about the word system and in particular it's > >> relationship to process. > >> > >> > >> We are separating them.. > >> > >> > >> - partly I see the problem as linguistic: i.e. we are using the > >> word sensor in two different contexts. We think of things in > >> terms of 'ah this thing is a sensor', but we also say 'a sensor is > >> a process'. Is what we are really saying that to sense something > >> is to follow a process that leads to a value as an estimate of a > >> phenomenon. In which case a sensor isn't a thing at all it's > >> really a 'to sense do...' or 'was sensed by doing...'. So if we > >> take it that to sense something is to follow a process that > >> estimates a value, then what is a system and why is a sensor one? > >> To think of a system as a collection of components in some > >> technical sense and then make sensor one of these is to take the > >> 'ah this thing is a sensor' approach, but then we also agree on 'a > >> sensor is a process' which now seems to make a sensor not a > >> system. 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? > >> > >> > >> > >> The only think we are saying about sensor is that it has an output ! > >> > >> > >> > >> So how about.... > >> > >> a System is a device/computer system/software system that is made > >> up of components > >> > >> > >> I think we do not need to be explict about device/computer > >> system/software. For example, a regional observing system can also be > >> a system. > >> > >> > >> a Sensor is a process (a description of inputs/outputs, some steps > >> and data flows) which may also be made up of sub sensors > >> > >> > >> yes. > >> > >> > >> > >> a System may play the role of a sensor for phenomenon X. > >> > >> > >> So is this OK ? > >> > >> *- Some systems are sensors* > >> > >> > >> but I suggested before that *Some sensors are systems* > >> ** > >> I think both are ok.. what do you think ? > >> > >> -luis > >> > >> > >> > >> > >> > >> Michael > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On 17/12/2009, at 19:11 , John Graybeal wrote: > >> > >> > >> On Dec 16, 2009, at 12:00, Manfred Hauswirth wrote: > >> > >> Hi John, > >> > >> thanks for your insightful comments. Some more comments > >> from my side. > >> > >> John Graybeal wrote: > >> > >> Regarding "all systems are processes": Honestly, I > >> would not > > >> > >> understand this (I stated this at the F2F). For me, > >> you have > >> systems > which include one ore more processes. If > >> systems are > >> processes, why > have systems at all. My notion of > >> systems would > >> informally consist > of processes, scenarios, > >> deployments, etc. > >> The question "why have systems at all?" is the crux > >> here. Can we > >> state clearly when a process is not a system? Or in > >> other words, > >> how is a system more narrow than a process? > >> Incidentally, my notion of processes would informally > >> consist of > >> the same list. I am also having trouble drawing the > >> distinction. > >> > >> > >> Interesting! I think this may be due to our different > >> background (I > >> assume your are not a computer scientist like myself - > without > >> evidence I may add). > >> > >> > >> Computer Science and Statistics. 30 years software and systems > >> support. (No worries!) > >> > >> In my area (computer science, information systems) systems > >> would be > >> defined as I do and a system would consist of software and > >> hardware > >> and 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), > >> whereas you seem to define this more from the viewpoint > of an > >> experiment which is being observed (?) where processes > >> come into > >> play as part of the observation process (please correct me > >> - I am > >> guessing here). > >> > >> > >> 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. There are local processes and > there are > >> external processes. > >> > >> It isn't driven by experiment orientation but by broader CS > >> orientation -- dealing with engineering systems of systems, and > >> including the human component in those systems, and modeling > >> all the > >> above as processes (which may, or may not, then be > >> computerized in the > >> new version of the system). Anyway, just a different viewpoint, > >> neither right nor wrong. > >> > >> The problem here seems to lie in different > >> conceptualizations in > >> different communities - all of which done according to the > >> specific > >> needs of a community. Now, while this may complicate > >> things, I think > >> it is also a useful and actually mandatory exercise. While > >> I may > >> claim, that I need to understand the conceptualization > >> because as an > >> CS/IS person I will have to build (software/hardware) > systems > >> (sorry! no other term comes to mind) which need to manage > >> information coming out of observations, you may claim > >> exactly the > >> same from you point of view (and rightfully so). The > >> question now > >> for me is: Who are our users and how to serve them best? > >> Where's the > >> sweet spot? > >> > >> > >> Concur. I presumed from the start that the group was > interested in > >> modeling hardware elements, but I have found it useful to > consider > >> those hardware components as processes in a larger system of > >> systems. > >> They take data in and transform it to other data that is > spit out. > >> This is one useful definition of a process, as Luis notes. > >> > >> Oops, got off track there! But our agreed point is to agree on > >> which > >> type of devices (= which group of users) we want to make the > >> ontology > >> for. 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). > >> But I > >> can go with whatever on this, as long as we all understand. > >> > >> PhysicalSystem: I don't remember the exact reason > >> for this. Did > >> > >> we > mean deployment? > >> I assume this is to distinguish it from a software > system. > >> > >> Sensor as subclass of Device: I think this is too > >> narrow. I can > >> think of sensors which are not devices at all, > >> e.g., human > >> > >> "sensors" > in the context of social sensing (which > >> is an accepted > >> concept in > many domains including CS by now). > >> Making sensors a > >> subclass of > device limits us to purely technical > >> systems in > >> hardware, IMHO. Is > an RSS feed a device? I can > >> clearly use it as > >> a sensor. I think that > Device should be a subclass > >> of Sensor. > >> Even in existing middelware > systems like our GSN we > >> followed > >> that path (without having an > ontology in mind at > all). > >> This gets to purpose of the ontology. As I understood > >> it, the > >> group was originally constructed to model hardware > >> sensors. (May > >> have just been a wrong assumption on my part. More > >> precisely, what > >> we clearly were not doing is modeling samplers, that > >> is, devices > >> that return a physical sample.) > >> > >> > >> Agreed. But "sensors" do not necessarily manifest > >> themselves as > >> hardware. 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. It > >> is very hard to draw the line here. My question: Do I have > >> to have > >> this distinction at all? 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. > >> > >> > >> Sure, that works for me too. If you make a sensor too general, > >> though, it can have components. What do we call those > >> components -- > >> are not at least some of them sensors? So now, what is > >> different from > >> the sensor that can have sensors, and a device, which has > the same > >> recursion into smaller devices; and a system, which can have > >> systems > >> (and a process, that can have processes)? > >> > >> I'm being a little silly of course. All I mean to do is call > >> attention to the need to define the terms according to what > >> makes them > >> different from each other, not just whether they are higher or > >> lower > >> in a hierarchy. I think we haven't done that well enough yet. > >> > >> So using one definition of sensor ("anything that > >> senses") makes > >> Sensor very broad, and other things would subclass to > >> it. (Since > >> some devices (a hammer) don't sense things, we'll have > >> to define > >> Device narrowly to make it a subclass Sensor.) Using > >> another > >> definition of sensor ("a component that detects > >> (measures) a > >> physical phenomenon, converting it into a digital > >> representation > >> that can be output to other components"), a Sensor is > >> clearly a > >> specific type of Device, and is also a component of > >> any sensing > >> device. > >> > >> > >> If you see software as a Device, I would agree to it, but > >> then again > >> Device has the connotation of hardware. > >> > >> > >> Ah, I said a Sensor was hardware in my original world, so I > didn't > >> have any problem here -- since my Sensor was hardware and my > >> Device > >> had a sensor, I was already on board with Device being hardware. > >> > >> Do we have a set of definitions by any chance, so we > >> can all use > >> these (or some) terms the same way? > >> > >> > >> I don't think we have. > >> > >> Why is a Device a subclass of a Process? A Process > >> can use > >> > >> Sensors > which are manifested as Devices to > >> do/measure something, > >> IMHO. Again > this is a quite narrow notion of the > >> concepts. > >> I'm not following your argument here. 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. > >> > >> > >> Sorry, but I don't understand how a Device can be a Process. > >> > >> > >> The "Process: something that receives an input and produces an > >> output" > >> is not a sufficient explanation or model of that? > >> > >> John > >> > >> > >> Best regards, > >> > >> Manfred > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Luis Bermudez Ph.D. > >> Coastal Research Technical Manager > >> Southeastern Universities Research Association (SURA) > >> bermudez@sura.org <mailto:bermudez@sura.org> - Office: (202) 408-8211 > >> 1201 New York Ave. NW Suite 430, Washington DC 20005 > > > > -- > Prof. Manfred Hauswirth > Digital Enterprise Research Institute (DERI) > National University of Ireland, Galway (NUIG) > http://www.manfredhauswirth.org/ > -- Prof. Manfred Hauswirth Digital Enterprise Research Institute (DERI) National University of Ireland, Galway (NUIG) http://www.manfredhauswirth.org/
Received on Tuesday, 22 December 2009 19:37:45 UTC