[Minutes-SSN] 2016-05-03

The minutes of this week's SSN meeting are at 
https://www.w3.org/2016/05/03-sdwssn-minutes with a text snapshot below.

         Spatial Data on the Web WG SSN Sub Group Teleconference

03 May 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/05/03-sdwssn-irc


           Kerry, KJanowicz, Payam, JRamsay, ClausStadler,
           SefkiKolozali_UniS, ahaller2, DanhLePhuoc, phila,
           SimonCox, joshlieberman, RaulGarciaCastro





      * [3]Topics
          1. [4]"Sensor" related to DUL: followup
      * [5]Summary of Action Items
      * [6]Summary of Resolutions

    <SefkiKolozali_UniS> +present

    <RaulGarciaCastro> +present RaulGarciaCastro

    <KJanowicz> sure

    <Kerry> scribe: claus

    <Kerry> scribenick: claus


       [7] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20160503

    <Kerry> proposed: approve minutes

       [8] http://www.w3.org/2016/04/19-sdwssn-minutes

    <KJanowicz> +

    <KJanowicz> 1+

    <Payam> +1

    <ClausStadler> +1

    <JRamsay> +1

    <ahaller2> +1

    <KJanowicz> +1

    <KJanowicz> sorry

    <DanhLePhuoc> +1

    <SefkiKolozali_UniS> +1

    <phila> 0 wasn't there

    RESOLUTION: approve minutes

       [9] http://www.w3.org/2016/04/19-sdwssn-minutes

    <SimonCox> +present SimonCox

    <joshlieberman> Webex having a spat with Safari. On finally.

    <Kerry_> patent call:

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

    <SimonCox> Can't get onto webex :(

"Sensor" related to DUL: followup

    <ClausStadler> Follow up from last SSN meeting's discussion to
    move sensor from PhysicalObject to Object

    <joshlieberman> Webber <xxx> Safari. Try Chrome?

    <Kerry_> [11]https://www.w3.org/2015/spatial/wiki/SSN_Tasks

      [11] https://www.w3.org/2015/spatial/wiki/SSN_Tasks

    <Payam> +q

    <KJanowicz> +q

    <SimonCox> Can a sensor be a person?

    <KJanowicz> IMHO, yes (and it should)

    <joshlieberman> I should hope so.

    <SimonCox> Perhaps sensing is a role, not an essence?

    <joshlieberman> Or is a person a platform for multiple sensors?

    <KJanowicz> everyting that takes measures and produces and
    outcome should be allowed to be a sensor

    <SimonCox> @josh depends on how much you want to decompose it

    <KJanowicz> btw, this also means that there has to be a

    <ClausStadler> payam: pratically people won't look into these
    kind of terminological details - they have a device that can
    measure things and want to model their setting - so suggestion
    to focus on more into practical issues

    <joshlieberman> I might challenge a visual observation by a
    blind person, but that's just me.

    <SimonCox> +1 to @KJanowicz

    <KJanowicz> +q

    <SimonCox> THe other problem with DUL alignment is Observation
    =/= Event

    <ClausStadler> KJanowicz: as SSN-DUL alignment won't be part in
    the FPWD and people are unlikely to query for "give me all
    objects" its not a major issue

    <SimonCox> We can defer this discussion until we have revisited
    the rest of the ontology

    <ClausStadler> Kerry_: There will be a note published which
    intends to show how to use SSN with DUL, so the alignment is an
    issue, although not a major one

    <SimonCox> ... and maybe also look at alignment with other
    upper ontologies (e.g. BFO) at the same time as DUL

    <DanhLePhuoc> +q

    <ClausStadler> KJanowicz: We should focus on the core
    observation and sensor model which should become as useful as
    schema.org and only once that has been established see how DUL
    alignment can be performed

    <KJanowicz> IMHO, we need a core part of SSN,e.g., a pattern
    that is as trivial as schema.org and then add more complex
    modules on top of it for more complicated applications

    <KJanowicz> +q


      [12] http://semantic-web-journal.net/system/files/swj1237.pdf

    <ClausStadler> DanhLePhuoc: Agrees with KJanowicz - the first
    class citizens are observation, measurement and some metadata
    and they should be worked out first

    <ClausStadler> KJanowicz: If there was small robust model
    published it will likely have millions of users right away.
    From there the model(s) can be extended.

    <KJanowicz> ahaller2: yes but lets not forget that SSN-XG was
    the result of an incubator group that was tasked to test out
    the waters. we should be allowed to include lessons learned

    <SimonCox> Process issue: yes, it is good to resolve things,
    and to clearly record the resolution. But that does not mean
    things can't be re-opened if the group agrees.

    <Kerry_> proposed: sensor is an dul:object issue delayed until
    we reconsider core ssn first and it may become irrelevant

    <KJanowicz> +1

    <ahaller2> +1

    <ClausStadler> ahaller2: Agrees that devising a simple set of
    core modules with light weight semantics (RDFS) is a good idea.
    Also, we should start from what is already on the web protege
    and remove items rather than starting over from scratch.

    <DanhLePhuoc> +1

    <KJanowicz> using foundational ontologies is really not
    cathcing up on the SW. Most people moved on to patterns and
    other approaches and this is for good reasons

    <KJanowicz> I reason is that it is not maintained any longer

    <joshlieberman> 1oT actually needs a strong device model to
    deal with bewildering variety of sensors and platforms.

    <Payam> +q

    <Payam> I don't think we need a redesign

    <Payam> what we need it to make SSN more lightweight, more
    modular and add O&M

    <ClausStadler> SefkiKolozali_UniS: As ontology engineers, in
    our work, we have to comply to certain criseria when publishing
    datasets, such as include links to certain foundation
    ontologies. Therefore, changing alignments requires update of
    established processes in the publishing workflows. Hence, there
    need to be strong arguments to remove ontologies and potential
    replacements need to be clarified.

    <KJanowicz> +1

    <KJanowicz> Agree with Payam

    <Payam> Kerry_ can you repeat your porposal

    <DanhLePhuoc> +1

    <Kerry_> proposed: sensor is an dul:object issue delayed until
    we reconsider core ssn first and it may become irrelevant

    <Payam> +1

    <DanhLePhuoc> +1

    <ahaller2> agree with Payam, I think we all agree on what to
    do, it is more a question around process

    <ClausStadler> +1

    <KJanowicz> +1

    <ahaller2> +1

    <Kerry_> +1

    <KJanowicz> I would like to speak on that

    <SimonCox> +1

    RESOLUTION: sensor is an dul:object issue delayed until we
    reconsider core ssn first and it may become irrelevant

    <joshlieberman> +1

    <KJanowicz> the reference to DUL at
    [13]http://www.loa-cnr.it/ontologies/DUL.owl does not exist

      [13] http://www.loa-cnr.it/ontologies/DUL.owl

    <Payam> agree with your plan Kerry_

    <KJanowicz> This one still works:

      [14] http://www.ontologydesignpatterns.org/ont/dul/DUL.owl

    <Payam> +q

    <DanhLePhuoc> [15]http://w3c.github.io/sdw/ssn/

      [15] http://w3c.github.io/sdw/ssn/

    <SimonCox> @KJanowicz disconnect between ontologies and linked
    data ;-)

    <ClausStadler> kerry The work on FPWD should stay close to what
    it is now

    <ClausStadler> DanhLePhuoc and Kerry: Proposal for
    modularization already exists, we should not start over from

    <KJanowicz> I am afraid that if we only do minimal changes for
    now with the hope to change them leater, we will not change
    them at all

    <KJanowicz> sorry :-)

    <ClausStadler> Payam: The meeting is run too democratically:
    Issues should be more prioritized such that important things
    get tackled before having to wrap up everything in the last two
    weeks :)

    <KJanowicz> +q

    <Payam> kerry when do you plan to publish it?

    <SimonCox> When it is in a condition which shows a coherent
    picture of what we expect to see going forward.

    <phila> [16]FPWD?

      [16] http://w3c.github.io/sdw/ssn/

    <ClausStadler> KJanowicz: We are trying to standardize
    something for the next 10 years to come. Therefore we should be
    allowed to perform major changes and it should take the time
    needed, such as 2 months. (I hope I got that right)

    <Payam_> +q

    <Zakim> phila, you wanted to ask about

      [17] http://w3c.github.io/sdw/ssn/

    <SimonCox> There is another proposal on the table, mentioned by
    @KJanowicz above

    <KJanowicz> +q

    <ClausStadler> payam: What are the priorities for getting FPWD

    <KJanowicz> +q

    <ClausStadler> kerry: It has been discussed over - 1. dul
    alignment 2. modularization 3. get open issues and
    documentation + introduction into the draft

    <ClausStadler> KJanowicz: Emphasizes that payam's comments on
    slow progress due to too much talking are a bit harsh

    <SimonCox> It is incorrect to suggest there are no other things
    on the table.

    <KJanowicz> I understand your point kerry and I fully
    appreciate your work on pushing us towards a first draft.

    <ClausStadler> kerry: The document suggests how modularization
    gets implemented - its in the proposal already. What goes into
    SSN and what not will not be resolved within the next two
    months, therefore the issues need to be documented - in a
    nutshell, we can have mechanisms for modularizationsbut not

    <ClausStadler> DanhLePhuoc: What's the ETA on the FPWD?

    <phila> (awkward process thing - publications need to be agreed
    by whole WG, not just sub group).

    <ClausStadler> kerry: plans were: 3 month ago it was end of
    april, but now estimate not clear yet - proposals?

    <ClausStadler> kerry: within a month it could be feasible,
    unresolved proposals could go into the document as questions

    <SimonCox> Agree that there is no consensus on alternative
    proposals, but some *are* fully worked out.

    <SimonCox> [Time draft is incomplete, but can be viewed here
    [18]http://w3c.github.io/sdw/time/ ]

      [18] http://w3c.github.io/sdw/time/

    <ClausStadler> phila: in order to get extension approved by W3C
    for dec 2016, formal ground work needs to be done by june

    <Zakim> phila, you wanted to talk about time lines

    <SimonCox> Alternatives to be considered:

      [19] http://def.seegrid.csiro.au/ontology/om/om-lite
      [20] http://def.seegrid.csiro.au/ontology/om/sam-lite

    <Payam> +q

    <ahaller2> +1 to publish first draft with ontology documented
    as now and then work on agreement on further modules

    <ClausStadler> DanhLePhuoc: will it be feasible to add
    measurement and observation to the FPWD?

    <ClausStadler> kerry: I first need to understand the proposal
    better - please elaborate

    <KJanowicz> SimonCox: This is what I tried to push; see above.

    <Payam> SimonCox , I think this can be a good starting point

    <SefkiKolozali_UniS> +q

    <KJanowicz> +q

    <kerry> ++++1

    <ClausStadler> DanhLePhuoc: Explained current work on alignment
    of observations and measurements

    <SimonCox> Note that om-lite does *not* provide a model for
    sensors - just a stub class. This where the SSO pattern could
    be introduced?

    <KJanowicz> My proposal was to have a common core module for
    observations and sensors in a schema.org style and then add
    more complex modules for other parts and for more involved
    axioms on top of it. I also proposed to use om-lite for the
    observation part (it does not speak about sensors).

    <KJanowicz> I understand if this is not feasible and do not
    want to add to the pain.

    <KJanowicz> q

    <ClausStadler> SefkiKolozali_UniS: Also has input on the
    observation and measurement topic and offers to contribute

    <SimonCox> This also of interest:


    <joshlieberman> bye

    <KJanowicz> Thanks, bye bye

    <Payam> thanks, bye

    <RaulGarciaCastro> Bye

Summary of Action Items

Summary of Resolutions

     1. [22]approve minutes
     2. [23]sensor is an dul:object issue delayed until we
        reconsider core ssn first and it may become irrelevant

    [End of minutes]

Received on Tuesday, 3 May 2016 22:16:08 UTC