- From: Krzysztof Janowicz <janowicz@uni-muenster.de>
- Date: Thu, 17 Dec 2009 17:27:51 +0100
- To: Luis Bermudez <bermudez@sura.org>
- CC: John Graybeal <jbgraybeal@mindspring.com>, Manfred Hauswirth <manfred.hauswirth@deri.org>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
- Message-ID: <4B2A5C07.3040406@uni-muenster.de>
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