- From: Luis Bermudez <bermudez@sura.org>
- Date: Thu, 17 Dec 2009 12:01:40 -0500
- To: Krzysztof Janowicz <janowicz@uni-muenster.de>
- 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: <56b27e7e0912170901p57bc7e52t45a54f544e54dad9@mail.gmail.com>
Hi Krzysztof, On Thu, Dec 17, 2009 at 11:27 AM, Krzysztof Janowicz < janowicz@uni-muenster.de> wrote: > 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. > I think we will not have any issue if we go from SensorML to our sensor ontology. The instances we create will have properties from a process and from a system.. and we will still be fine. We are not saying that a "thing" cannot be a process and a system at the same time, which would then be a problem. -luis > > 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>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 > > > > -- > Krzysztof Janowicz > Institute for Geoinformatics > University of Muenster > Weselerstr. 253 > 48151 Muenster > Germany > > fon: 0049 - 251 - 83 39764 > fax: 0049 - 251 - 83 39763janowicz@uni-muenster.dehttp://ifgi.uni-muenster.de/~janowicz <http://ifgi.uni-muenster.de/%7Ejanowicz> > > 'Die Wahrheit ist das Kind der Zeit, nicht der Autorität' > (Bertolt Brecht) > > -- 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 17:02:17 UTC