W3C home > Mailing lists > Public > public-xg-ssn@w3.org > December 2009

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 ]

From: Luis Bermudez <bermudez@sura.org>
Date: Wed, 16 Dec 2009 15:02:29 -0500
Message-ID: <56b27e7e0912161202i743c82e9md886fbcd5a768025@mail.gmail.com>
To: John Graybeal <jbgraybeal@mindspring.com>
Cc: Manfred Hauswirth <manfred.hauswirth@deri.org>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>

On Wed, Dec 16, 2009 at 2:34 PM, John Graybeal <jbgraybeal@mindspring.com>wrote:

> I found these observations to be helpfully concrete, so I'd like to add my
> own (inline).
> On Dec 16, 2009, at 09:50, Manfred Hauswirth wrote:
>  Hi,
>> as I may not be able to join today's call (50/50 chance - one of my kids
>> got sick), I am starting the discussion via mail.
>> Let me start with a disclaimer: I generally think it is a good idea to
>> stay in sync with existing standards. But I think it may be better to
>> deviate if something is problematic. This is especially relevant when it
>> comes to modeling an ontology, which not only should provide a concise
>> classification system but also be a "natural way" (for lack of a better
>> term) of modeling a domain. I the modeling is not "natural", people will not
>> understand it and thus not use it.
> +1

-  I agree.

>  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.
>  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.)
> 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.
> Do we have a set of definitions by any chance, so we can all use these (or
> some) terms the same way?
>  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.

Senors and sensor system can be model as process ( they can get some input
and can produce some output). We are mainly interested in the output, this
is why "process" is important

Sensors and platform  have components, these is why they can be model as

System and Process are two independent concepts. Maybe we should leave them
that way and say sensor is subclass of both.


>  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

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
Received on Wednesday, 16 December 2009 20:03:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:15 UTC