- From: Michael Compton <Michael.Compton@csiro.au>
- Date: Fri, 18 Dec 2009 16:42:54 +1100
- To: Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
- Message-ID: <10117FF5-F685-46A3-A778-53A670FCD595@csiro.au>
They all seem fine except the last one. (see my other email)
Michael
On 18/12/2009, at 2:53 , 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
> > 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 - Office: (202) 408-8211
> 1201 New York Ave. NW Suite 430, Washington DC 20005
Received on Friday, 18 December 2009 05:44:57 UTC