- From: Krzysztof Janowicz <janowicz@uni-muenster.de>
- Date: Tue, 22 Dec 2009 21:27:20 +0100
- To: Manfred Hauswirth <manfred.hauswirth@deri.org>
- CC: bermudez@sura.org, Michael Compton <Michael.Compton@csiro.au>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
Hi,
> So we name the same thing "component" and "system".
leaving the process, system, and sensor discussion aside for a moment:
according to SensorML (as far as I remember) System and Component are
subtypes of PhysicalProcess. System is also a subtype of
CompositeProcess (same as ProcessChain). In contrast Component is a
subtype of AtomicProcess and so forth. They all are subtypes of
AbstractProcess.
Cheers,
Krzysztof
On 12/22/2009 08:30 PM, Manfred Hauswirth wrote:
>
> Luis Bermudez wrote:
>
> [...]
>
>> So I think this still holds true:
>>
>> - Some devices are sensors - because they have an output
>> - Some devices are systems - because they have components
>>
>> But if you wnat to propose other statements which make the system
>> composition more explict, please do so.
>
> I think we run into "2 names meaning the same thing" problem here.
> Following your definition, let's say I have a device which is a system
> which again is a component of another system. So we name the same
> thing "component" and "system". The "problem" seems to be hierarchical
> composability. In my domain I would not call a data structure which
> is composed of data structures anything else but a data structure.
> Maybe I see this too narrow, but it confuses me.
>
> Cheers,
>
> Manfred
>
>
>> - I'm also unsure about the word system and in particular it's
>> relationship to process.
>>
>>
>> We are separating them..
>>
>>
>> - partly I see the problem as linguistic: i.e. we are using the word
>> sensor in two different contexts. We think of things in terms of
>> 'ah this thing is a sensor', but we also say 'a sensor is a
>> process'. Is what we are really saying that to sense something is
>> to follow a process that leads to a value as an estimate of a
>> phenomenon. In which case a sensor isn't a thing at all it's really
>> a 'to sense do...' or 'was sensed by doing...'. So if we take it
>> that to sense something is to follow a process that estimates a
>> value, then what is a system and why is a sensor one? To think of a
>> system as a collection of components in some technical sense and
>> then make sensor one of these is to take the 'ah this thing is a
>> sensor' approach, but then we also agree on 'a sensor is a process'
>> which now seems to make a sensor not a system. So is the biggest
>> problem here simply that we (copying from SWE) have decided that
>> systems have components and sensors are also made up of things, so
>> it must be a system - where as there are actually two hierarchies
>> here and we should represent them with different relationships?
>>
>>
>>
>> The only think we are saying about sensor is that it has an output !
>>
>>
>>
>> So how about....
>>
>> a System is a device/computer system/software system that is made up
>> of components
>>
>>
>> I think we do not need to be explict about device/computer
>> system/software. For example, a regional observing system can also
>> be a system.
>>
>>
>> a Sensor is a process (a description of inputs/outputs, some steps
>> and data flows) which may also be made up of sub sensors
>>
>>
>> yes.
>>
>>
>>
>> a System may play the role of a sensor for phenomenon X.
>>
>>
>> So is this OK ?
>>
>> *- Some systems are sensors*
>>
>>
>> but I suggested before that *Some sensors are systems*
>> ** I think both are ok.. what do you think ?
>>
>> -luis
>>
>>
>>
>>
>>
>> Michael
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 17/12/2009, at 19:11 , John Graybeal 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 Tuesday, 22 December 2009 20:27:55 UTC