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.



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:15 UTC