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: Michael Compton <Michael.Compton@csiro.au>
Date: Fri, 18 Dec 2009 16:42:47 +1100
Message-ID: <D994A3FC-780B-40B4-9FF6-485676709D2D@csiro.au>
To: Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
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.

- 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
*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

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.

- I'm also unsure about the word system and in particular it's  
relationship to process.

- 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?

So how about....

a System is a device/computer system/software system that is made up  
of components

a Sensor is a process (a description of inputs/outputs, some steps and  
data flows) which may also be made up of sub sensors

a System may play the role of a sensor for phenomenon X.



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
>>
>
>
Received on Friday, 18 December 2009 05:44:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 December 2009 05:44:28 GMT