- From: Manfred Hauswirth <manfred.hauswirth@deri.org>
- Date: Tue, 22 Dec 2009 19:30:50 +0000
- To: bermudez@sura.org
- CC: Michael Compton <Michael.Compton@csiro.au>, Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
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
--
Prof. Manfred Hauswirth
Digital Enterprise Research Institute (DERI)
National University of Ireland, Galway (NUIG)
http://www.manfredhauswirth.org/
Received on Tuesday, 22 December 2009 19:31:32 UTC