- From: Michael Compton <Michael.Compton@csiro.au>
- Date: Wed, 23 Dec 2009 14:28:29 +1100
- To: "Compton, Michael (ICT Centre, Acton)" <Michael.Compton@csiro.au>
- CC: Semantic Sensor Network Incubator Group WG <public-xg-ssn@w3.org>
This email is an attempt to collate all the things that I think we
agree on (which I believe to largely be the concepts and their
relationships) and to try and put sensible things in for the bits we
don't agree on (which I think is mostly the names) - some of this
borrowed from emails from Manfred, Luis and others.
I've tried to set out some statements that I think were largely agreed
and also some OWL that I think matches up to those statements - the
names of concepts may be incorrect or worth more debate/thought.
(1) A system is a unit of abstraction for pieces of infrastructure
(and we largely care that they are) for sensing. A system has
components, which are other systems.
(2) A device is a physical piece of technology - a system in a box.
Devices may of course be built of smaller devices and software
components (i.e. systems have components)
(3) A process has an output and possibly inputs and, for a composite
process, describes the temporal and dataflow dependencies and
relationships amongst its parts.
(4) Sensing is a process that results in the estimation, or
calculation, of the value of a phenomenon.
(5) An observation is the record of some sensing and contains time
stamps, a result, a reference to the sensing process ... i.e. all the
bits in O&M
(6) There are some things that can do sensing and thus make
observations.
(7) Some devices can do sensing.
Now in something approximating (manchester?) OWL (again using <= for
subclass and == for equivalence)
System == hasComponent some System
#statement (1)
Device <= System
#statement (2)
#statement (3) omitted - given other definitions I would expect the
definitions of a process and its inputs and outputs and structure to
be largely uncontroversial (see SensorML or the CSIRO ontology
originally posted for ideas of how to go about this)
Sensing <= Proccess
#statement (4)
#statement (5) omitted - if we accept what was agreed at f2f then we
can take observations as O&M with their 'procedure' relation linking
to sensing.
Sensor == implements some Sensing
# statement (6)
SensingDevice <= Sensor
SensingDevice <= Device
#statement (7)
Now we all seem to agree that there are other things that can do
sensing - regional observing systems, me calculating values, etc - but
I haven't named them here. If we agree this far we can come up with
names for the other sensing things.
(8) For the moment we will state nothing about any is-a relationship
between processes and systems
I still think that: " systems ... component relation describes
structural make up, and processes ... component relation describes
temporal ordering and data flow." is an important distinction between
processes and systems. As Manfred made clear the process describes
essentially the algorithm which may be implemented by some system.
But I don't think that we are forced at this point to make any final
statement about (8) in the ontology.
Michael
On 22/12/2009, at 22:49 , Compton, Michael (ICT Centre, Acton) wrote:
> Hi all,
>
> Kerry and I had a long discussion about this issue this afternoon
> and tried to assimilate all the various points. The three sections
> below contain our conclusions in text, one way of rendering it in
> DL, and open issues.
>
> ------------------
>
> Text describing what we though...
>
> A system contains components.
>
> A process has an output and possibly inputs and, for a composite
> process, describes the temporal and dataflow dependencies and
> relationships amongst its parts.
>
> A device is a physical unit / a piece of hardware / a system in a box.
>
> Sensing is a process that results in the estimation of the value of
> a phenomenon.
>
> An observer is a thing that can do sensing.
>
> A sensor is a device that can do sensing
>
> A sensing system is a non-device system that can do sensing (so this
> is intended to represent things like the regional observing system
> that Luis mentioned)
>
> An AdHocObserver is all the other things that you might want to
> model that can do sensing (for example, me calculating wind chill -
> not really a system, but definitely doing sensing)
>
> An observation is the record of some sensing and contains time
> stamps, a result, a reference to the sensing process ... i.e. all
> the bits in O&M
>
> Notes:
>
> There seemed to be some difference in what the word sensor mean
> (some people though devices, others thought of it as anything that
> can do sensing) so we decided to take sensor as devices and then
> categorise all the other things that can sense as some other type of
> observer.
>
> Also, we agreed that coming to estimations of the value of
> phenomenon is a process, but both had difficulty with the idea that
> a device is a process. It seems more like a device can do these
> processes, but not really that a device is a process.
>
> These definitions make a split between systems whose component
> relation describes structural make up, and processes whose component
> relation describes temporal ordering and data flow. SensorML seems
> to make a similar distinction by classing some processes as abstract
> things and systems as physical things (though it of course has a
> superclass of abstract processes that encompasses both).
>
> ------------------
>
> An OWL representation of the key points...
>
> I'll use <= for the OWL sub class relation and == for the
> equivalence relation
>
> System <= hasComponent . System
> Device <= System
>
> Sensing <= Process
>
> Observer == cando . Sensing
> Observer == (Sensor or SensingSystem or AdHocObserver)
>
> Sensor <= Device
> Senser <= Observer
>
> SensingSystem <= System and not Device
> SensingSystem <= Observer
>
> AdHocObserver <= Observer and not System
>
>
> ------------------
>
> Open issues...
>
> There is really one big issue in the discussion: how do processes
> relate to systems? We see 4 options
>
> (1) Process <= System
>
> (2) System <= Process
>
> (3) state nothing
>
> (4) Process disjoing System
>
>
> Option (1) is essentially stating that the component relation for
> processes is a sub relation of hasComponent, which seems fair
> enough, but I'm not sure if it's essential or what it adds.
>
> Option (2) is the SensorML modelling, but seems difficult for most
> people to come to terms with.
>
> Option (3) allows either option (1) or (2), so is flexible, but it's
> not then clear how one could reconcile two ontologies where one uses
> option (1) and the other option (2).
>
> Option (4) forces processes to be abstract descriptions of steps and
> temporal relations and systems to be structural relationships and
> the two to be different.
>
>
> Michael
>
>
>
> ________________________________________
> From: public-xg-ssn-request@w3.org [public-xg-ssn-request@w3.org] On
> Behalf Of Michael Compton [Michael.Compton@csiro.au]
> Sent: Monday, 21 December 2009 2:32 PM
> To: Semantic Sensor Network Incubator Group WG
> Subject: [ExternalEmail] Re: ISSUE-2 (All processes are systems):
> All processes are systems [sensor ontology - http://mmisw.org/orr/#http
> ://www.w3.org/2009/SSN-XG/Ontologies/SensorBasis.owl - 09.12.15 ]
>
> Maybe I should just address the dot points.
>
>
> - A process has inputs and outputs
>
> ok
>
> - A system has components
>
> ok
>
> (1)
> - A sensor is a process
> (2)
> - Some devices are sensors
> - Some devices are sensors - because they have an output
>
> are we saying that a sensor is a process or that sensing is a
> process. For example, lets say:
>
> * I have a device that measures wind chill (i.e. it measures
> temperature and wind speed and does a calculation), by (2) above
> it's a device that is-a sensor, and by (1) it must be a process (I'm
> uncomfortable with this already because we have now said that a
> device is-a process, which seems wrong to me. I'd think a device
> might follow some process, but this is-a relationship seems strange).
>
> * Now what if I write down the wind speed and temperature
> measurements myself and do the calculation myself. What's the
> sensor here? It can't really be me, can it - it would seem strange
> to say that I am a process and a sensor. Seems more like I followed
> a process and thus calculated wind chill. So maybe the sensor is the
> process I followed? Or is it the act of me following the process?
> In either case we have a problem because above we said a device is-a
> sensor and then here we are saying something entirely different (a
> process or the act of following it) is-a sensor.
>
> I would say that a device cannot be a sensor (well not in the
> process sense that we have been talking about) otherwise we are
> conflating an abstract (a process) and a concrete thing (a device).
>
> Seems from all the discussions that we have had that sensing is-a
> process - or that some processes result in sensing something, and
> that a device or a person, or a regional observing system might act
> out such a process and thus sense something.
>
> So I would be more comfortable with
>
> - Sensing is a process
> - Some devices can act as sensors
>
> And then that a device that senses something could be a 'sensing
> device', which thus acts out some sensing process.
>
> but I don't agree with (2) above
>
>
> - Some devices are systems
>
> Why aren't all devices systems? Even if they only have one
> component or we don't want to write down all their components?
>
>
> - Some systems are sensors
>
> It depends, is our definition "A system has components" or "All
> things with components are systems"? The question itself is silly,
> but my point is why are we trying to use the same component
> relationship to describe devices and processes?
>
> I'm having trouble seeing the example above with me calculating wind
> chill as a system.
>
>
> Michael
>
>
>
>
>
>
>
>
>
> On 20/12/2009, at 2:19 , Luis Bermudez wrote:
>
> Hi Michael,
>
> The only thing we have said about systems is that it contains
> components...
>
>
>
> On Fri, Dec 18, 2009 at 12:42 AM, Michael Compton <Michael.Compton@csiro.au
> <mailto:Michael.Compton@csiro.au>> wrote:
> my conceptions/preconceptions/misconceptions are as follows.
>
> - A sensor need not be a physical device. Kevin's definition of "An
> entity capable of observing a phenomenon and returning an observed
> value." seems ok to me.
>
> agree !
>
>
> - A Sensor need not be a single entity - it can be composed of any
> number of sub sensors, each perhaps of their own identity, each
> perhaps measuring different things that get combined into the whole.
>
> This is why it can be a system . Maybe we need to add also:
>
> Some sensors are systems
>
>
>
> - The following things 'are' sensors
> *a temperature sensor (i.e. a physical device) at location l
> *a program on a computer (far away from location l) that can read in
> the temperature at location l and a wind speed estimate for location
> l and calculate the windchill at l
>
>
> Yes.. Commonality is that a sensor has an output and therefore are
> processes.
>
>
> More correctly, in both cases something has acted as a sensor for a
> particular phenomenon: a device in the first instance, and the
> program in the second - if I wrote down the temperature and wind
> speed measurements on a piece of paper and calculated the wind chill
> myself, then I have acted as the sensor.
>
> - The example of the wind chill sensor means that sensors can have
> multiple components, and I guess the components may themselves be
> interesting.
>
> - A device (a physical piece of hardware) can also be broken down
> into components (presumably other devices, but perhaps also systems
> - software systems etc) but I don't see that as having anything to
> do with sensors or their decomposition into parts. For example,
> imagine a device that can measure wind speed and temperature, that
> has a small inbuilt chip that can calculate wind chill, round
> measurements, compute averages and a radio to communicate its
> readings. It's physical decomposition into its components is
> different from its decomposition into the roles it can play as a
> sensor. So the two sorts of decomposition may be related, but not
> equivalent.
>
>
> 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'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
>
Received on Wednesday, 23 December 2009 03:29:08 UTC