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: Luis Bermudez <bermudez@sura.org>
Date: Thu, 17 Dec 2009 12:01:40 -0500
Message-ID: <56b27e7e0912170901p57bc7e52t45a54f544e54dad9@mail.gmail.com>
To: Krzysztof Janowicz <janowicz@uni-muenster.de>
Cc: John Graybeal <jbgraybeal@mindspring.com>, Manfred Hauswirth <manfred.hauswirth@deri.org>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
Hi Krzysztof,

On Thu, Dec 17, 2009 at 11:27 AM, Krzysztof Janowicz <
janowicz@uni-muenster.de> wrote:

>  Hi Luis,
> I can agree with all of them. From a SensorML perspective I would still add
> that systems are processes, namely subtypes of 'PhysicalProcess' and
> 'CompositeProcess' - but this of course would lead back to the discussion
> how much of SensorML and O&M we need, whether they are 'intuitive enough'
> (with respect to Manfred's arguments), and whether we can agree on the
> subsumption order.

I think we will not have any issue if we go from SensorML to our sensor
ontology. The instances we create will have properties from a process and
from a system.. and we will still be fine. We are not saying that a "thing"
cannot be a process and a system at the same time, which would then be a


> Krzysztof
> On 12/17/2009 04:53 PM, Luis Bermudez wrote:
> Can we make some conclusions, in particular those of you discussing this
> thread ?
> I agree with all of these:
> - A process has inputs and outputs
> - A system has components
> - A sensor is a process
> - *Some* devices are sensors
> - *Some* devices are systems
> -luis
> On Thu, Dec 17, 2009 at 3:11 AM, John Graybeal <jbgraybeal@mindspring.com>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 - 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
> Germany
> fon: 0049 - 251 - 83 39764
> fax: 0049 - 251 - 83 39763janowicz@uni-muenster.dehttp://ifgi.uni-muenster.de/~janowicz <http://ifgi.uni-muenster.de/%7Ejanowicz>
> 'Die Wahrheit ist das Kind der Zeit, nicht der Autoritšt'
> (Bertolt Brecht)

Luis Bermudez Ph.D.
Coastal Research Technical Manager
Southeastern Universities Research Association (SURA)
bermudez@sura.org - Office: (202) 408-8211
1201 New York Ave. NW Suite 430, Washington DC 20005
Received on Thursday, 17 December 2009 17:02:17 UTC

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