- From: Luis Bermudez <bermudez@sura.org>
- Date: Thu, 17 Dec 2009 10:53:22 -0500
- To: John Graybeal <jbgraybeal@mindspring.com>
- Cc: Manfred Hauswirth <manfred.hauswirth@deri.org>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
- Message-ID: <56b27e7e0912170753l23171263y119b7dc0f01ecb2f@mail.gmail.com>
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 Thursday, 17 December 2009 16:00:29 UTC