[Minutes SSN] 2016-11-01

The minutes of this week's SSN editors' call are at 
https://www.w3.org/2016/11/01-sdwssn-minutes with a text snapshot below.

The SSN sub group is now meeting every week, with those held in the same 
week as plenary meetings aimed particularly at editors - everyone is, of 
course welcome.


           Spatial Data on the Web SSN Sub Group Teleconference

01 Nov 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/11/01-sdwssn-irc

Attendees

    Present
           ahaller2, Kjanowic, DanhLePhuoc, SimonCox, kerry,
           ClausStadler

    Regrets
    Chair
           Armin

    Scribe
           ahaller2

Contents

      * [3]Topics
      * [4]Summary of Action Items
      * [5]Summary of Resolutions
      __________________________________________________________

    <scribe> agenda: patent call

    <scribe> agenda: Import/Non-import of modules in the onion
    layers of the SSN ontology

    [6]http://w3c.github.io/sdw/ssn/#modularisation

       [6] http://w3c.github.io/sdw/ssn/#modularisation

    <SimonCox> If modules that import (SOSA-)core demonstrate
    implementation, wouldn't that suit?

    <SimonCox> ahaller2: notes difficulty with having reliance on
    SOSA-core because of lack of evidence of implementation (can't
    be normative)

    KJanowic: still believe that SOSA should be in the core and in
    the normative part
    ... I think the alignment would break the axioms

    <SimonCox> KJanowic: difficulty with simultaneously aligning to
    old SSN and DOLCE and O&M - will break axioms in DOLCE

    <SimonCox> ahaller2: new SSN would not import alignment graph

    <KJanowic> but we will still switch back and forth on the
    meaning of those classes, right?

    kerry: this gymnastics is all about getting implementations

    <SimonCox> kerry: alignment is all about re-using the old
    implementations as evidence

    <KJanowic> +1 on getting new implementations

    kerry: convince ourselves that we get new implementation
    ... we can get implementations for the SOSA core

    <KJanowic> I can provide implementation on sosa-core. I am just
    totally scared of having the same class, e.g., observation,
    with 3 different meanings no matter whether the alignment is
    optional.

    kerry: proposed the alignment about 6 months ago already
    ... implement at least a fraction of what we are trying to do

    <SimonCox> kerry: keep DOLCE alignment out of normative
    rec-track

    kerry: alignment to DOLCE in a seperate document

    <KJanowic> +1

    <KJanowic> +1 to sosa-core being normative and essential

    <SimonCox> kerry: SOSA-core is absolutely essential, needs to
    be normative

    <SimonCox> +1

    <KJanowic> +1 on that!

    <SimonCox> ahaller2: would prefer to keep alignments out of
    normative docs

    <SimonCox> ahaller2: alignment with old SSN is desirable to
    document changes

    <SimonCox> ... but in non-normative part for now?

    KJanowic: lot of work gone into the SOSA core. Let's start
    talking about implementations now.

    <SimonCox> Needed in SOSA-core: decision on whether
    sub-classing is included ...

    <scribe> ... new observation concept can not link to the old
    one

    UNKNOWN_SPEAKER: if the axiom is there it will make some
    unwanted asssertions

    <Zakim> kerry, you wanted to ask if we are seriously going to
    look for implmentations of the non-core parts of new ssn and to
    disagree that sosa-core is ready to go

    <SimonCox> KJanowic: if there is any axiom anywhere that aligns
    new sosa:Observation with old ssn:Observation then
    sosa:Observation cannot be an Event, because of OWL
    inconsistency with DOLCE ...

    <KJanowic> but for me there is no difference between ssn and
    sosa-core. These are just names. We can call sosa-core ssn-core
    if this fixes the issue.

    <KJanowic> @kerry: but we can work on that

    <SimonCox> kerry: SOSA-core definitely not ready to go - would
    vote -1 right now, suspect many other would too

    <KJanowic> but will there be a relation between
    newssn:observation and oldssn:observation?

    <KJanowic> Agreed

    <SimonCox> ahaller2: SOSA-core has not been discussed in wider
    SDWWG-SSN group

    <KJanowic> +1 on what ahaller2 just said, namely having
    sosa-core (ssn-core) in the normative part, as core of ssn,
    aligned with the new SSN and not having the DUL alignment in
    the normative part

    <SimonCox> KJanowic: asked - "will there be a relation between
    newssn:observation and oldssn:observation?" - ahaller2 says
    "non-normative"

    <SimonCox> is that good enough KJanowic ?

    kerry: agree with, Raul has offered to look into doing a survey
    of old implementations. By the end of the year.

    <KJanowic> @simonCox: it is not clear of what non-normative
    means for the formal semantics of OWL

    <KJanowic> axioms don't care about whether they are normative
    or not, they either imply something or they don't

    ahaller2: in terms of relation between newssn:observation and
    oldssn:observation, there is none! therefore no alignment there

    <KJanowic> +1 to no relation

    <scribe> agenda: Current SOSA core, scope of terms

    [7]https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl

       [7] https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl

    <SimonCox> kerry: alignment axioms (equivalence) will constrain
    SOSA-core

    <SimonCox> Suggest avoiding 'Process' because in BFO Process is
    an occurrent

    <KJanowic> this is about magnitude not information vs.
    non-information resource

    <SimonCox> (though Process used in this way would be aligned
    with SensorML)

    <Zakim> kerry, you wanted to ask krystof about how much he can
    live with inconsistent normative or not alignments

    <KJanowic> kerry: not because I want to be mean but because
    there may be disjointness axioms hidden there

    <SimonCox> KJanowic: normative vs non-normative OK for humans,
    but will trip up m2m usage

    KJanowic: if the file sits somewhere our ontology becomes
    inconsistent

    <SimonCox> ahaller2: propose no alignment for concepts where
    there is a conflict - only have alignment axioms where there is
    real equivalence

    KJanowic: Procedure vs Process. There is one thing that is the
    cooking recipe how to make the sensor work and then each
    observation done using the same procedure is comparable.

    <SimonCox> Does "procedure" include either the sensor type, or
    even sensor instance KJanowic ?

    KJanowic: every time you follow the procedure, instantiation.
    It is a workflow.

    <Zakim> SimonCox, you wanted to discuss use of word "Process"
    vs "Procedure"

    SimonCox: naming is less important than to agree what it is

    <SimonCox> ... Procedure is a re-usable thing

    [8]http://www.aiai.ed.ac.uk/project/wfmc/ARCHIVE/DOCS/glossary/
    gloss2.gif

       [8] 
http://www.aiai.ed.ac.uk/project/wfmc/ARCHIVE/DOCS/glossary/gloss2.gif

    <KJanowic> This is what we had as text "A workflow, protocol,
    plan, algorithm, or computational method specifying how to set
    up an Observation, take a Sample, or make a change to the state
    of the world (via an Actuator). A Procedure is re-usable, and
    might be involved in many observations, samplings, or
    actuations. It explains the steps to be carried out to arrive
    at reproducible results. Put differently, millions of
    observations may be created via the same Proced[CUT]

    <KJanowic> My problem with 'process' is its meaning wrt event,
    action, and so forth. Process is a perdurant.

    <KJanowic> Do we agree that an observation is the carrying out
    of the procedure/process?

    +1

    <KJanowic> great

    <DanhLePhuoc> +q

    <Zakim> kerry, you wanted to note something important
    procedurally

    <SimonCox> ... or 'an observation is an event that utilises or
    executes the procedure/process'

    <SimonCox> (that was in response to KJanowic)

    DanhLePhuoc: I asked before, are we using RDF(S) or are we
    using some OWL in here, inverse, meta

    <KJanowic> super difficult discussion, would be better to open
    this up to the group

    <KJanowic> I would leave it as it is

    <KJanowic> e.g., sosa-core:Observation rdf:type owl:Class ;

    DanhLePhuoc: make the formal semantics clear

    <kerry> +1 to open it up

    <kerry> +1 make sure the agenda is clear for each meeting

    <DanhLePhuoc> +1

    <KJanowic> fine with me

    <DanhLePhuoc> +Q

    <SimonCox> Weekly meetings from now on ok from me +1

    <DanhLePhuoc>
    [9]http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/01.
    01.01_60/ts_103264v010101p.pdf

       [9] 
http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/01.01.01_60/ts_103264v010101p.pdf

    <DanhLePhuoc>
    [10]https://sites.google.com/site/smartappliancesproject/ontolo
    gies/reference-ontology

      [10] 
https://sites.google.com/site/smartappliancesproject/ontologies/reference-ontology

    DanhLePhuoc: reached out to them already

    kerry: happy to get involved with her
    ... contact monica and have a chat about the status of the ETSI
    smart appliances ontology

    DanhLePhuoc: also potentially an evidence of implementation

    <SimonCox> THanks folks - useful meeting

    <KJanowic> Thanks a lot for the productive meeting today. Bye,
    Bye

Summary of Action Items

Summary of Resolutions

    [End of minutes]
      __________________________________________________________

Received on Thursday, 3 November 2016 08:37:27 UTC