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: Krzysztof Janowicz <janowicz@uni-muenster.de>
Date: Tue, 22 Dec 2009 21:27:20 +0100
Message-ID: <4B312BA8.5090502@uni-muenster.de>
To: Manfred Hauswirth <manfred.hauswirth@deri.org>
CC: bermudez@sura.org, Michael Compton <Michael.Compton@csiro.au>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>

> So we name the same thing "component" and "system".

leaving the process, system, and sensor discussion aside for a moment: 
according to SensorML (as far as I remember) System and Component are  
subtypes of PhysicalProcess. System is also a subtype of 
CompositeProcess (same as ProcessChain). In contrast Component is a 
subtype of AtomicProcess and so forth. They all are subtypes of 


On 12/22/2009 08:30 PM, Manfred Hauswirth wrote:
> 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

Krzysztof Janowicz
Institute for Geoinformatics
University of Muenster
Weselerstr. 253
48151 Muenster

fon: 0049 - 251 - 83 39764
fax: 0049 - 251 - 83 39763

'Die Wahrheit ist das Kind der Zeit, nicht der Autoritšt'
(Bertolt Brecht)
Received on Tuesday, 22 December 2009 20:27:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 December 2009 20:27:56 GMT