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

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?

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

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

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

Best regards,

Manfred

> 
>  > Talk to you later (hopefully),
>  >
>  > Manfred
>  >
>  > Semantic Sensor Network Incubator Group Issue Tracker wrote:
>  >> 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 ]
>  >> http://www.w3.org/2005/Incubator/ssn/track/issues/2
>  >> Raised by: Luis Bermudez
>  >> On product: sensor ontology - 
> http://mmisw.org/orr/#http://www.w3.org/2009/SSN-XG/Ontologies/SensorBasis.owl
>  >>  - 09.12.15
>  >> In SensorML all systems are processes, but in our case we can say 
>  >> that all processes are systems. And all the other classes (types of 
>  >> systems and processes) should be subclass of both. Suggestion:
>  >> - Move Sensor to be subclass of Device
>  >> - Remove PhysicalSystem - not needed
>  >> - Move Device to be subclass of Process
>  >
>  > --
>  > Prof. Manfred Hauswirth
>  > Digital Enterprise Research Institute (DERI)
>  > National University of Ireland, Galway (NUIG)
>  > http://www.manfredhauswirth.org/
>  >
> 
> 
> --------------
> I have my new work email address: jgraybeal@ucsd.edu
> --------------
> 
> John Graybeal   <mailto:jgraybeal@ucsd.edu>
> phone: 858-534-2162
> System Development Manager
> Ocean Observatories Initiative Cyberinfrastructure Project: 
> http://ci.oceanobservatories.org
> Marine Metadata Interoperability Project: http://marinemetadata.org
> 

-- 
Prof. Manfred Hauswirth
Digital Enterprise Research Institute (DERI)
National University of Ireland, Galway (NUIG)
http://www.manfredhauswirth.org/

Received on Wednesday, 16 December 2009 20:01:16 UTC