W3C home > Mailing lists > Public > public-xg-ssn@w3.org > December 2009

Re: ISSUE-2 (All processes are systems): All processes are systems [sensor ontology - http://mmisw.org/orr/#http://www.w3.org/2009/SSN-XG/Ontologies/SensorBasis.owl - 09.12.15 ]

From: Manfred Hauswirth <manfred.hauswirth@deri.org>
Date: Tue, 22 Dec 2009 19:37:04 +0000
Message-ID: <4B311FE0.7030603@deri.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 December 2009 19:37:45 GMT