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

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 <mailto: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 <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
Germany

fon: 0049 - 251 - 83 39764
fax: 0049 - 251 - 83 39763
janowicz@uni-muenster.de
http://ifgi.uni-muenster.de/~janowicz

'Die Wahrheit ist das Kind der Zeit, nicht der Autorität'
(Bertolt Brecht)

Received on Thursday, 17 December 2009 16:28:54 UTC