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 ]

Hi Michael,

The only thing we have said about systems is that it contains components...



On Fri, Dec 18, 2009 at 12:42 AM, Michael Compton
<Michael.Compton@csiro.au>wrote:

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

agree !


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

This is why it can be a system . Maybe we need to add also:

*Some sensors are systems*
**


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


Yes.. Commonality is that a sensor has an output and therefore are
processes.


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


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'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 - Office: (202) 408-8211
1201 New York Ave. NW Suite 430, Washington DC 20005