Re: [Minutes-SSN] 2016-04-19

My apologies for not being able to attend the meeting - I was running a workshop in Canberra. 

Jano makes an important point here: 

>  <KJanowicz> keep in mind that there are many orders of magnitude more observations than sensors

but not quite sure what the implications of that for modularization are. 

The O&M Observations model was conceived as a consumer-oriented viewpoint, to complement the SensorML producer-oriented viewpoint. (Hence SOS 2.0, which is for getting observation data, uses the O&M model and terminology in its query.) 
This played out as follows: 
(i) O&M promoted the properties that we thought were required for data discovery to the top (i.e. observed-property, feature-of-interest, procedure used (i.e. sensor)). But no model was provided for any of these, so matching was 'by identifier' (e.g. 'show me observations about propertyA of featureB') or using structures that were delegated to a user-community; 
(ii) SensorML provides a highly flexible XML format. Easy on providers. Very hard on consumers who have to be prepared to handle a huge variety of incoming data structures that are all conformant to SensorML. 

My hunch is that detailed discovery scenarios require detailed descriptions of observable properties, which support reasoning. These might be provided as a side-effect of detailed sensor descriptions, but possibly worth thinking about them in their own right. And also spatial queries, which might involved reasoning if words rather than numbers are used ;-) 

Simon J D Cox
Research Scientist
Land and Water
CSIRO
E simon.cox@csiro.au T +61 3 9545 2365 M +61 403 302 672
   Physical: Reception Central, Bayview Avenue, Clayton, Vic 3168
   Deliveries: Gate 3, Normanby Road, Clayton, Vic 3168
   Postal: Private Bag 10, Clayton South, Vic 3169
people.csiro.au/C/S/Simon-Cox
orcid.org/0000-0002-3884-3420
researchgate.net/profile/Simon_Cox3

________________________________________
From: Phil Archer <phila@w3.org>
Sent: Thursday, 21 April 2016 1:14 AM
To: SDW WG Public List
Subject: [Minutes-SSN] 2016-04-19

The minutes of this week's SSN call are at
https://www.w3.org/2016/04/19-sdwssn-minutes and in text form below.


   Spatial Data on the Web Working Group, SSN Sub Group Teleconference

19 Apr 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/04/19--irc

Attendees

    Present
           RaulGarciaCastro, DanhLePhuoc, kerry, kJanowicz, robin,
           Claus, Stadler, ClausStadler, ahaller2, JRamsay

    Regrets
           phila

    Chair
           kerry

    Scribe
           DanhLePhuoc

Contents

      * [3]Topics
          1. [4]Modularity: discuss Armin's proposal
          2. [5]"Sensor" related to DUL: not a physical object,
             should be an Object?
          3. [6]Sensor" annotation: clarify relation to O&M Concept
      * [7]Summary of Action Items
      * [8]Summary of Resolutions
      __________________________________________________________

    <KJanowicz> has the meeting started?

    <JRamsay> sorry, whats the webex password again?

    hi Kerry, where can I the meeting Id and password?

    <robin> Meeting ID is 647 066 501

    <robin> I find from this
    [9]https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon201
    60419

       [9] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20160419

    <RaulGarciaCastro> it is

    <robin> But I don't know the password

    <robin> Thank you

    <KJanowicz> kerry, you are breaking awar, maybe turning your
    head away from the mic

    <KJanowicz> i can do it

    <kerry> scribe: DanhLePhuoc

    <kerry> scribeNick: DanhLePhuoc

    <kerry> patent call:
    [10]https://www.w3.org/2015/spatial/wiki/Patent_Call

      [10] https://www.w3.org/2015/spatial/wiki/Patent_Call

    is it this one? [11]https://www.w3.org/2016/04/13-sdw-minutes

      [11] https://www.w3.org/2016/04/13-sdw-minutes

    <kerry> [12]http://www.w3.org/2016/04/05-sdwssn-minutes

      [12] http://www.w3.org/2016/04/05-sdwssn-minutes

    <kerry> aprove minutes:
    [13]http://www.w3.org/2016/04/05-sdwssn-minutes

      [13] http://www.w3.org/2016/04/05-sdwssn-minutes

    <kerry> +1

    <RaulGarciaCastro> +1

    +1

    <robin> +1

    minutes approved

Modularity: discuss Armin's proposal

    First item for meeting is : Modularisation

    [14]http://w3c.github.io/sdw/ssn/#Modularisation

      [14] http://w3c.github.io/sdw/ssn/#Modularisation

    Armin: the current version proposes two ways of modularisation:
    Vertical Segmentation and Horizontal Segmantation

    The main idea ofr Vertical segmentation is to use a subset of
    modules/concepts without having uses another part

    In the other hand, it's a bit tricky in the Horizontal
    Segmentation

    KJanowicz: is possible to get rid of DUL completely?

    kerry: it is worth to use DOCLE as it has its own community and
    we might need similar one to fill in the missing concepts

    KJanowicz: be aware of maintenance problem of DOCLE
    ... I was among the one that proposed to use DOCLE for SSN
    ... I'm fine with keep it but I would like to highlight the
    issues

    <RaulGarciaCastro> +1 to having it out of the recommendation

    +1 for leaving DOCLE out this recommendatin

    <ahaller2> agnostic about it, but keeping it out of the
    standard may be a good solution

    <KJanowicz> +1

    RESOLUTION: that DUL alignment becomes a note or some other
    product outside the recommendation

    <KJanowicz> +1

    +1

    KJanowicz: would it make sense to have different level of
    complexity?

    <KJanowicz> so, simple observation model module, sensor module,
    observation module, deployment module, and a sampling module

    ahaller2: I don't see any use case to have to many separated
    modules

    KJanowicz: I have a project only have observations, but there
    are some other UCs can combine some subsets of deployment,
    sensor module....

    ahaller2: the core sensor module would be enough concepts and
    properties to cover most of the need
    ... the core sensor module would have enough concepts and
    properties to cover most of the need
    ... I meant sensing device core

    <KJanowicz> rename sensing deviced core into sensor and
    observation core

    ahaller2: a minimal subset of sensing device at very abstract
    level but cover most of generic and simple cases

    <KJanowicz> keep in mind that there are many orders of
    magnitude more observations than sensors

    kerry: the ways of current SSN used vary a lot in terms of
    grouping the concepts/modules, like IoT-Lite

    ahaller2: the core sensing device is proposed is similar to
    IoT-lite, but it's is in more light-weight

    <Zakim> RaulGarciaCastro, you wanted to talk about vertical and
    horizontal segmentation

    ahaller2: if we pulled out too many modules, it's really hard
    to know what it is a module

    <KJanowicz> I would still propose to have something like a
    minimal sensor-observation model

    RaulGarciaCastro: introducing more modules might be more
    confusing

    <kerry> +q

    <KJanowicz> I agree with ahaller2 heree

    ahaller2: in the end: what is our core? defining sensor as the
    central concept or sensor-obversion is the core here

    KJanowicz: SSN was the first effort that put sensor and
    observation together to make them usable in many cases over the
    year

    <KJanowicz> +1 for the alignment based version

    <KJanowicz> q_

    kerry: the concepts and properties can be added gradually via
    alignments to make them more flexible

    <KJanowicz> great idea!

    <KJanowicz> yes, lets do this!

    ahaller2: each of us will group the classes in modules to bring
    to the next meetings to discuss

    <ahaller2> +1

    +1

    <RaulGarciaCastro> +1

    <KJanowicz> +1

    <ClausStadler> +1

    <kerry> ach DanhLePhuoc

"Sensor" related to DUL: not a physical object, should be an Object?

    kerry: we can discuss about we can discuss logic profiles.e.g,
    RDFS, OWL ... in later stages

    in current "Sensor" is very general concept

    <KJanowicz> this will cause problems

    <ahaller2> +1 on moving sensor up in the hierarchy

    kerry: I put the alignment by : Sensor is subclass of
    dul:Object

    <KJanowicz> yes, I will

    <KJanowicz> I also agree that sensors should include humans and
    simulations

    KJanowicz: will need to look closely to this issue

    <KJanowicz> I think computation in DUL will be in the
    'abstract' part of DUL. I will check

Sensor" annotation: clarify relation to O&M Concept

    <ahaller2> +1 reasonable

    +1

    <KJanowicz> +1

    RESOLUTION: sensor annotation adjusted as discussed

    <ahaller2> we don't have a resolution yet, though

    kerry: we will bring up the issues to the big meeting

    ahaller2: it might be a bit early to bring to the big meeting
    due to a lot of uncertainty a.t.m

    <KJanowicz> thanks, bye bye

    <RaulGarciaCastro> Bye!

    bye!

    <kerry> rrsagent: draft minites

    <robin> Thanks, bye

Summary of Action Items

Summary of Resolutions

     1. [15]that DUL alignment becomes a note or some other product
        outside the recommendation
     2. [16]sensor annotation adjusted as discussed

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [17]scribe.perl version
     1.144 ([18]CVS log)
     $Date: 2016/04/20 14:39:19 $
      __________________________________________________________

      [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [18] http://dev.w3.org/cvsweb/2002/scribe/

Received on Monday, 25 April 2016 00:19:22 UTC