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:30:50 +0000
Message-ID: <4B311E6A.9030902@deri.org>
To: bermudez@sura.org
CC: Michael Compton <Michael.Compton@csiro.au>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>

Luis Bermudez wrote:

[...]

> 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 think we run into "2 names meaning the same thing" problem here. 
Following your definition, let's say I have a device which is a system 
which again is a component of another system. So we name the same thing 
"component" and "system". The "problem" seems to be hierarchical 
composability. In my domain I would not call a data structure  which is 
composed of data structures anything else but a data structure. Maybe I 
see this too narrow, but it confuses me.

Cheers,

Manfred


>     - 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/
Received on Tuesday, 22 December 2009 19:31:32 GMT

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