Re: ISSUE-2 (All processes are systems): All processes are systems [sensor ontology - - 09.12.15 ]

Looks fine to me. The only item I am really having trouble with is "a 
sensor is a process". Since I wanted to test, if I am the only person 
who could not understand this, I tested it around here: 100% had the 
proverbial question marks written on their faces (mostly CS people, some 
with a science back ground - physics).

Just wanted to flag this. Seems a pretty strong indicator to me though. 
However, If this is the consensus of the group it to go with it, I am OK 
  with it (still feels strange for me though).



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 
> < <>> 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)
> <> - 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:11:22 UTC