Re: [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 ]

Hi Laurent, et al

Thanks for the summary. I think will be useful for the meeting to have all
the statements in etherpad or something similar, so we can make progress
while at the meeting. I created this if we think is a good idea to use it at
the meeting
http://etherpad.com/zyMhasUHgf

And,  added the summary statements from Kerry and Michael..

Please all feel free to add or edit if I missed something,



cheers,

-luis




On Tue, Dec 22, 2009 at 8:32 AM, <Laurent.Lefort@csiro.au> wrote:

> Hi,
>
> Let me try to complete Michael's attempt to wrap it up.
> I have tried to capture everything which has been said and I use a twitter
> style to keep it short.
>
> Read it as:
> - My inputs RT (re-tweet) @someone something copied and paste from the
> previous email written by someone)
> - @someone look at this, you may be interested
>
> I hope this helps
> Laurent
>
>
> ----------------------------------------------------------------------------
>
> @luis: SensorML defs are sometomes tricky, especially Process (see
> http://www.w3.org/2005/Incubator/ssn/wiki/SWE_terms)
>
> +1 RT: @Manfred: wants a "natural way" (for lack of a better
> term) of modeling a domain
>
> @Manfred: human "sensors" are tricky - I can see many "sensor" properties
> that they don't have (e.g. it is hard to "calibrate them") and I would not
> necessarily use an OGC-originated framework to model them.
>
> @Simon: one way to handle social sensing in O&M is to place the human in
> the role of the SamplingFeature (the sensor is the device thru which the
> observations are transmitted) :-)
>
> My answer is because it is natural to put a name at multiple levels of a
> part-whole hierarchy of sensing components (easier to define simple things
> than complex things) RT @jgraybeal: why have systems at all?
>
> Yep! Process is the tricky one to define!  RT @jgraybeal: Incidentally, my
> notion of processes would informally consist of the same list.  I am also
> having trouble drawing the distinction.
>
> No! We also want to characterise services! RT @jgraybeal: As I understood
> it, the group was originally constructed to model hardware sensors.
>
> In this case, the IT process is doing the sensing job RT @Manfred: 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.
>
> My 2cts: okay as long as we are targeting the process of experimentally
> obtaining one or more quantity values that can reasonably be attributed to a
> quantity (VIM) RT @Manfred: 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.
>
> Yes VIM! see http://www.w3.org/2005/Incubator/ssn/wiki/SWE_terms RT
> @jgraybeal Do we have a set of definitions by any chance, so we can all use
> these (or some) terms the same way?
>
>
> ----------------------------------------------------------------------------
>
> measuring system
> -- measuring chain
> ---- measuring instrument
> ------ sensor
> -------- detector (device or substance)
> ---------- measuring transducer
>
> (read measuring system --has-part-- measuring chain
>  and not measuring chain --are-- measuring system)
>
> Note: device is a generic term roughly a subclass of Thing and a superclass
> of all the others.
>
>
> ----------------------------------------------------------------------------
>
> This Process = a measuring system RT @jgraybeal 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.
>
> Yes and users are sometimes included in it as well RT @Manfred systems
> would be defined as I do and a system would consist of software and hardware
>
> This process = a IT process RT @Manfred 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)
>
> @Manfred for an Information Systems ontology check the FRISCO report
> http://www.mathematik.uni-marburg.de/~hesse/papers/fri-full.pdf<http://www.mathematik.uni-marburg.de/%7Ehesse/papers/fri-full.pdf>
>
> @Manfred: Does your definition of process correspond to Definition E8:
> State-transition structure?
>
> @laurent Note Frisco Definition E26: A model is a purposely abstracted,
> clear, precise and unambiguous conception.
>
> @laurent Frisco Definition E26 (2) A model denotation is a precise and
> unambiguous representation of a model, in some appropriate formal or
> semi-formal language (see Fig. 3.6-1)
>
> Device = subclass of thing (hardware union software) RT @Manfred If you see
> software as a Device, I would agree to it, but then again Device has the
> connotation of hardware.
>
> Device not to be put in the same inheritance hierarchy as Process or as
> measuring Instruments RT @Manfred Sorry, but I don't understand how a Device
> can be a Process.
>
> RT @luis +1 RT: @Manfred: wants a "natural way" (for lack of a better
> term) of modeling a domain
>
> Can be modelled does not mean should be sub-classes of RT @luis Sensors and
> sensor system can be model as process (they can get some input and can
> produce some output). We are mainly interested in the output, this is why
> "process" is important
>
> Think you're talking of IT process here @luis Sensors and sensor system can
> be model as process (they can get some input and can produce some output).
> We are mainly interested in the output, this is why "process" is important
>
> Why should we use any sub-class relationships for this? I prefer nested
> has-part relationships (see above) RT @luis System and Process are two
> independent concepts. Maybe we should leave them that way and say sensor is
> subclass of both.
>
> @laurent: FRISCO Definition E30: System, System denotation, System
> component, System environment, System viewer, System representer
>
> A system is a special model, whereby all the things contained in that model
> (all the system components) are transitively coherent, i.e. all of them are
> directly or indirectly related to each other form a coherent whole. A system
> is conceived as having assigned to it, as a whole, a specific
> characterisation (the so-called "systemic properties").
>
> @laurent; in Frisco: System is composed of sub-systems, component (and some
> of them have processors)
>
> These defs may not belong/be mappable to the same categories of abstract IT
> concepts (difference between State-transition structures and other
> approaches) RT @manfred Hmm, in my domain, process is an active component,
> whereas what you describe, I would describe as a data stream (processing)
> system.
>
> Why should we use any sub-class relationships for this? I prefer nested
> has-part relationships (see above) RT @luis System and Process are two
> independent concepts. Maybe we should leave them that way and say sensor is
> subclass of both.
>
> See the definition above - stop defining the world just by using sub-class
> relationships ! RT @manfred Am I misunderstanding "system"? RT @luis A
> system on the other hand can consist of sensors and processes.
>
> +1 RT @jgraybeal Well, it can certainly be modeled as a system, and it
> certainly has components. (See, I bet you thought 'component' meant
> hardware. But I didn't.)
>
> s//device//instrument// RT @jgraybeal I found the only way it made sense to
> have a word 'sensor' that was different from a word 'device' was if the
> sensor was performing an atomic operation.
>
> @jgraybeal VIM defines sensor as a "element of a measuring system that is
> directly affected by a phenomenon, body, or substance carrying a quantity to
> be measured" This is what you say with "atomic operation"
>
> 1st reading: sensor embeds an IT process RT @jgraybeal I think this is
> still implementing a process, though.
>
> 2nd reading: sensor is-part-of a measuring-system (or measuring-chain) RT
> @jgraybeal I think this is still implementing a process, though.
>
> A measuring-chain can include both sensors and IT processes - okay, but
> need some unambiguous separation though RT A Process can include both
> sensors and processes.
>
> Yes!!!!! RT @jgraybeal No, I think the confusion may be about Process, or
> maybe Component.
>
>
> Your def. is IT process disjoint vs. measuring-system or measuring-chain RT
> @manfred 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.
>
> @laurent Another can of worms - not sure page 154 in the Frisco report
> really helps RT @manfred There are local processes and there are external
> processes.
>
> +1 RT @jgraybeal 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).
>
> We now know that sensor has two separate meaning: "measuring system"
> (higher level ~ what a sensor network does) and "sensor" (the atomic
> operation-only ones) RT @jgraybeal If you make a sensor too general, though,
> it can have components.
>
> See VIM proposal above (and separate the measuring defs and the IT defs) RT
> @jgrayvbeal What do we call those components
>
> We need to be very clear on the use of the terms which can be interpreted
> differently, especially sensor, process and device RT @jgraybeal So now,
> what is different ...
>
> Should we use instrument rather than device @jgraybeal since my Sensor was
> hardware and my Device had a sensor, I was already on board with Device
> being hardware
>
> In SensorML I would handle measuring systems as processes and declare them
> as PhysicalProcess or as 'CompositeProcess' when it is possible to apply the
> State-transition structure model offered by SensorML @Krzysztof From a
> SensorML perspective I would still add that systems are processes, namely
> subtypes of 'PhysicalProcess' and 'CompositeProcess'
>
> My 2 cts: the subsumption order you are all arguing about is a
> "presentation trick" (to facilitate discovery) and not a core ontology
> pattern. You can build an additional branch in the ontology if you want one
> - My problem is to build the rest! @ Krzysztof whether we can agree on the
> subsumption order
>
> Yes, the success criteria is the ability to transform what's in SensorMl
> into something which can be queried in all the different ways we have listed
> in the use cases RT @luis I think we will not have any issue if we go from
> SensorML to our sensor ontology.
>
> my conceptions/preconceptions/misconceptions are as follows.
>
> Sensor = measuring system here RT @michael 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.
>
>
> Sensor = measuring system here RT @michael 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.
>
> - The following things 'are' sensors
>
> = (atomic) sensor (sub-class of device) RT @michael a temperature sensor
> (i.e. a physical device) at location l
>
> = measuring chain RT @michael 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
>
> = measuring chain  + one temp sensor + one wind speed sensor + one software
> component (modelled as 4 "processes" in the sensorml representation of the
> chain) RT @michael something has acted as a sensor for a particular
> phenomenon: the program in the second
>
> Yes if sensor means measuring system RT @michael 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.
>
> See the VIM has-part hierarchy RT @michael The example of the wind chill
> sensor means that sensors can have multiple components, and I guess the
> components may themselves be interesting.
>
> This product description viewpoint should already have been handled by the
> W3PM XG http://www.w3.org/2005/Incubator/w3pm/ RT @michael 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.
>
> Need to discuss the relationship between the measuring chain description
> and the way it is modelled in sensorml as a particular sort of
> State-transition structure RT @michael I'm also unsure about the word system
> and in particular it's relationship to process.
>
> We are also using the term process in ytwo different ways RT we are using
> the word sensor in two different contexts.
>
> At least two and maybe three if you want to address the
> hardware/software/product configuration aspect RT @michael 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?
>
> Yes but we want its description as a measuring chain with components not
> necessary as a product (or we want both) RT @michael a System is a
> device/computer system/software system that is made up of components
>
> No it can be represented as a "process model" RT @michael a Sensor is a
> process (a description of inputs/outputs, some steps and data flows) which
> may also be made up of sub sensors
>
> Ok if sensor = measuring system RT @michael a System may play the role of a
> sensor for phenomenon X.
>
> Measuring systems equivalent to Sensor (if we opt to use Sensor for this
> usage and not for the other usage of (atomic) Sensor RT @luis Some sensors
> are systems
>
> Measuring system are System (sub-class) RT @luis Some sensors are systems
>
> +1 RT @michael_kerry  A system contains components.
>
> +1 (this is an IT Process) RT @michael_kerry  A process has an output and
> possibly inputs and, for a composite process, describes the temporal and
> dataflow dependencies and relationships amongst its parts.
>
> +1 RT @michael_kerry A device is a physical unit / a piece of hardware / a
> system in a box.
>
> +1 but it's a different process RT @michael_kerry  Sensing is a process
> that results in the estimation of the value of a phenomenon.
>
> +1 but may not be required RT @michael_kerry An observer is a thing that
> can do sensing.
>
> +1 And I would add the atomic notion brought by VIM RT @michael_kerry A
> sensor is a device that can do sensing
>
> A measuring system = a sensing system (it is no necessarily a good idea to
> have it as a disjoint class from device or (atomic) sensor RT @michael_kerry
> 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)
>
> Not intuitive enough for me. Suggestions anyone? RT @michael_kerry 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)
>
> Plus some bits in VIM not yet in O&M? RT @michael_kerry 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
>
>
> @laurent Remember that Device is used elsewhere in W3C as handheld device!
>
> @laurent I'd be happy to compromise for Sensing system rather than
> Measuring system (and keep Sensor at a lower level)
>
>
> ----------------------------------------------------------------------------
>
> >> 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
>
>
> ----------------------------------------------------------------------------
>
> @laurent I prefer (4) Process = IT Process as modelled in SensorML
> (Representation in Frisco) disjoint from Measuring system (Conception in
> Frisco)
>
> @laurent: should we discuss the possibilities to regroup all these
> separately defined concepts (in the core ontology) into a single hierarchy
> (in presentation ontology) to answer to specific application requirements
> (e.g. sensor-oriented discovery or data-oriented discovery) where there is a
> demand to have a single hierarchy mixing everything together.
>
>


-- 
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