- 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