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 ]

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