W3C home > Mailing lists > Public > public-sdw-wg@w3.org > January 2017

[Minutes-SSN] 2017-01-24

From: Phil Archer <phila@w3.org>
Date: Tue, 24 Jan 2017 22:19:52 +0000
To: SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <e59b01e5-2380-504e-08df-9b89a06d2d03@w3.org>
The minutes of today's, at times heated, SSN sub group meeting, are at 
https://www.w3.org/2017/01/24-sdwssn-minutes with a text snapshot below.


           Spatial Data on the Web SSN Sub Group Teleconference

24 Jan 2017

    [2]Agenda

       [2] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170124

    See also: [3]IRC log

       [3] http://www.w3.org/2017/01/24-sdwssn-irc

Attendees

    Present
           Kerry, phila, KJanowic, DanhLePhuoc, laurent_oz,
           ahaller2, ClausStadler, SimonCox

    Regrets
           Scott

    Chair
           Armin

    Scribe
           phila

Contents

      * [4]Topics
          1. [5]Preliminaries
          2. [6]patent call
          3. [7]Commit Workflow for Editor’s draft
          4. [8]O&M alignment “normative” or “non-normative”
          5. [9]Proposal to align sosa:Platform and ssn:Platform
             from Krzysztof, taking into account virtual sensors
             (https://www.w3.org/TR/sdw-ucr/#VirtualObservations)
             as of ISSUE 88 (carried from
             https://www.w3.org/2016/12/06-sdwssn-minutes#item05)
             and ACTION-251
      * [10]Summary of Action Items
      * [11]Summary of Resolutions
      __________________________________________________________

    <scribe> scribe: phila

    <SimonCox> Is webex running? I see 'meeting not started'.

    <ahaller2> webex is started, yes

Preliminaries

    Last week's minutes
    [12]https://www.w3.org/2017/01/17-sdwssn-minutes

      [12] https://www.w3.org/2017/01/17-sdwssn-minutes

    -> [13]https://www.w3.org/2015/spatial/wiki/Patent_Call Patent
    Call

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

patent call

Commit Workflow for Editor’s draft

    ahaller2: When making edits to our editors' draft, we had the
    idea that Danh was the only one to merge PRs. That's not
    practical
    ... So we agreed that evertone should stick to their own branch

    <ahaller2> . All commits to the Editor's Draft + the ontologies
    the Editor’s draft depends upon regardless if you are editor or
    not need to be committed to your own branch

    <ahaller2> 2. Pull requests need to be issued assigning all
    editors but yourself, but multiple commits can be made in each
    PULL request. Each commit should be atomic enough to make it
    easy for the approver to recognise the diff.

    <ahaller2> 3. The Pull request needs to be approved by ONE
    editor other than the one who made the change.

    <ahaller2> 4. This means that once you have committed your
    changes and a PULL request, until your PULL request is
    accepted, you need to again create a new Branch from the main
    branch in your local repository. Preferably, though, the PULL
    request should be accepted quickly and prior to you needing to
    make a new branch.

    ahaller2: Might be useful to just assign one editor so they can
    make the merge, but alert all the editors
    ... If you make a change in the meantime, you need to make a
    new local branch of your own and then push that, so you might
    have multiple branches. That shouldn't happen often.

    <Zakim> kerry, you wanted to speak on workflow

    kerry: I'm OK with that. SLight clarification - doesn't matter
    who we assign in GH, any editor can make the merge.
    ... If an editor makes a change, assign another editor
    ... I don't think assigning the person trells them

    ahaller2: I think it does sometimes. Send an e-mail to all
    editors that you made a change.
    ... Assigning an editor, it could be anyone

    kerry: Should I take on a merge even if it's assigned to
    another editor?

    ahaller2: I think only the assigned person can do it.
    ... I guess you could assign them all, and then if someone has
    a prob they can be removed.

    kerry: 2nd comment - I find multiple branches as painful as
    everyone, you can't build on top of your new work.
    ... I suggest... once you've done a PR, you can keep putting
    more commits into that same PR, that works
    ... Even if it hasn't been merged, you can continue to work on
    it.
    ... But you follow Jeremy's original workflow, you can continue
    to operate on your branch and get everyone else's changes. That
    works if there are no conflicts.
    ... GH is clever enough to handle this.

    <laurent_oz> Is it this page
    [14]https://www.w3.org/2015/spatial/wiki/How_to_work_with_GitHu
    b_for_ssn

      [14] 
https://www.w3.org/2015/spatial/wiki/How_to_work_with_GitHub_for_ssn

    <KJanowic> May I jump in here to add something to the
    discussion?

    <kerry>
    [15]https://www.w3.org/2015/spatial/wiki/How_to_work_with_GitHu
    b_for_ssn

      [15] 
https://www.w3.org/2015/spatial/wiki/How_to_work_with_GitHub_for_ssn

    kerry: Talks through the page she's linked to

    [More discussion between Kerry and Armin]

    ahaller2: Main message is that PRs should be approved or
    disapproved quickly by the editors.

    KJanowic: For the sake of simplicity. 2 things - I think GH is
    good at sneding off the e-mails but it depends what you're
    subscribed to.
    ... I only get them if I subscribe to the whole repository
    ... The 2nd thing, I suggest if we just make a small change,
    then flag it as such

    <laurent_oz>
    [16]https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/
    0109.html

      [16] 
https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0109.html

    KJanowic: Work on small pieces, better not to edit multiple
    files at once

    laurent_oz: I saw a mail on the list... There are PRs that
    correspond to the editors work, and some about the discussion.

    <laurent_oz> [17]https://waffle.io/w3c/svgwg

      [17] https://waffle.io/w3c/svgwg

    laurent_oz: I think it's better to tell people who are looking
    at PRs what PR is about.
    ... The SVG WG uses labels etc. and makes it easier

    <KJanowic> @laurent_oz: yes, this is why I am proposing small
    changes that are well documented in the pull message. keep your
    changes as atomic as possible. E.g., if you fix typos do not
    change axioms at the same time.

    ahaller2: We use the W3C issue tracker for issues

    <KJanowic> and the issue tracker works very well for that

    ahaller2: We did already agree that PRs specific to SSN or
    Time, a label in front of the PR would be useful

    <KJanowic> (both the w3c and the github trackers)

    <KJanowic> @phila: that would be fantastic!

    laurent_oz: I don't know whether something on GH has been
    discussed or approved etc. This multiple view is difficult,
    that's why I'm asking for more connection between the two

    ahaller2: If you issue a PR, you can always remove the PR and
    work on your branch.

    <Zakim> kerry, you wanted to answer laurent

    kerry: That's a disaster as well because you have to do it
    again

    <KJanowic> make requests on individual files and you will avoid
    90% of the problems

    ahaller2: No, removing yourtPR doesn't undo anything you've
    done

    kerry: When I'm doing work, I tell you what the issue or action
    no was.

    ahaller2: I'll update my workflow and send it round again.

O&M alignment “normative” or “non-normative”

    ahaller2: There was a request by Simon late last year why this
    one is non-normative
    ... The linking to O&M is important, people use it all the
    time.
    ... Simon, you obviously want to pull in the OGC links

    SimonCox: The comment I can make - I see no difficulty in
    making statements that are normative
    ... It's difficult if we're tryinbg to match up OWL and UML
    ... How do we express the UML elements that we're claiming to
    include
    ... and there's a difference in modelling

    <KJanowic> It is even more problematic as, formally speaking,
    we have an monotonical environment

    kerry: Dunno if this affects normative/informative - can we do
    it through the mapping tables?
    ... How it relates to the UML model

    <SimonCox>
    [18]https://www.w3.org/2015/spatial/wiki/Mapping_Table

      [18] https://www.w3.org/2015/spatial/wiki/Mapping_Table

    kerry: That part of the mapping table you've already done makes
    sense to me.

    <Zakim> phila, you wanted to talk about UML/OWL

    <KJanowic> (was somehow dropped from the queue)

    <laurent_oz> Phil : issue of converting UML to OWL comes up in
    many contexts. There are official ways of doing which create an
    "awful" result.

    <SimonCox> ISO 19150-2 provides a recipe, but it is ugly

    <SimonCox> THat's why I did om-lite instead

    <laurent_oz> Approach which works is to work directly in OWL.

    <SimonCox> and sam-lite

    SimonCox: That's what I did essentially
    ... There is an ISO standard for this
    ... which produces an OWL view of a UML model
    ... We tried to make it less ugly but it's still ugly
    ... So I did a hand conversion

    phila: Sounds like the right approach to me, SimonCox

    SimonCox: The work has been done in the mapping table
    ... It was originally done so that we can examine the textual
    definitions. Without that the table becomes lean.

    laurent_oz: For me, it's the same... I've been trying to work
    on the alignmenet with his work. The issue is that these
    ontologies are not as official as other ones.
    ... I wouldn't go for normative. Good to have an example of
    mapping
    ... but at this stage we haven't committed to publishing an
    official version.
    ... It's fine for me, it's the same kind of situation

    KJanowic: What exactly do we mean by alignment?
    ... DO we mean sub class or equiv class statements?
    ... We can't take aeway inferences after the fact.
    ... DULCE Ultra-lite works for every day discussions
    ... If we want to pick an alignment then I would pick O&M as
    it's the most used.
    ... The current version of SOSA is in line with O&M. That's not
    true for DOLCE
    ... If they're both normative we'd be inconsistent

    ahaller2: To summarise, you're suggesting making O&M normative,
    dulce non-normative

    KJanowic: Yes, that would be fantastic

    kerry: We're going round in circles again here. Most of us see
    no problem with multiple alignments that are inconsistent

    <KJanowic> no, it wasn't given up at all

    kerry: It's asking that every use of every term is consistent
    with every other use.
    ... In consistent
    ... The reason for alignment in some space is that people can
    bring it in and work with it.

    <KJanowic> we cannot have inconisten alignment as this would
    not result in a valid ontology

    kerry: And B - I suggest that the alignment to O&M be done wrt
    the O&M standard.

    <ahaller2> s/inconsten/inconsistent

    kerry: That's a UML doc. Sam-lite has no status
    ... Simon may be able to help with that by promising that it's
    stable, that will help, but it hasn't been reviewed, not used
    AFAIK?
    ... OGC has published O&M

    <SimonCox> FWIW - sam-lite is used in IGSN implementations in
    CSIRO and GA (not my work)

    kerry: Doing the alignment formally in this spec won't make the
    sam-lite formal

    <SimonCox> +1 that primary alignment should be to ISO 19156 O&M

    KJanowic: To be clear here - in the ontology we need to be
    precise, if we say x is a sub class of y, then we can't have
    alignment to different ontologies that contradict each other
    ... The second thing. When we put the alignment as part of the
    normative doc, there's no easy way to say optional. Not saying
    we shouldn't have the description, but

    <SimonCox> Example of use of sam-lite in the wild:
    [19]http://54.66.133.7/igsn-ld-api/sample/AU1000011?_view=igsn&
    _format=text/turtle

      [19] 
http://54.66.133.7/igsn-ld-api/sample/AU1000011?_view=igsn&_format=text/turtle

    ahaller2: We also need to consider... would be use a different
    namespace
    ... The standard may be inconsistent in itself but only if you
    use multiple namespaces

    <Zakim> phila, you wanted to ask about dul

    <laurent_oz> Laurent: I have put all the alignments in a single
    ontology (doing what KJanowic claim is not possible) here:
    [20]https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/
    0117.html

      [20] 
https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0117.html

    <KJanowic> +1 to phila!

    ahaller2: What is Simon is coming up with options?
    ... WE don't want to introduce a full mapping from UML to OWL

    <SimonCox> OK - I accept the challenge!

    <scribe> ACTION: SimonCox to send e-mail with options for O&M
    alignment [recorded in
    [21]http://www.w3.org/2017/01/24-sdwssn-minutes.html#action01]

      [21] http://www.w3.org/2017/01/24-sdwssn-minutes.html#action01]

    <trackbot> Error finding 'SimonCox'. You can review and
    register nicknames at
    <[22]http://www.w3.org/2015/spatial/track/users>.

      [22] http://www.w3.org/2015/spatial/track/users

    <scribe> ACTION: Simon to send e-mail with options for O&M
    alignment [recorded in
    [23]http://www.w3.org/2017/01/24-sdwssn-minutes.html#action02]

      [23] http://www.w3.org/2017/01/24-sdwssn-minutes.html#action02]

    <trackbot> Created ACTION-255 - Send e-mail with options for
    o&m alignment [on Simon Cox - due 2017-01-31].

    <KJanowic> @laurent_oz: just to be sure we talk about the same.
    If you have alignments in form of subclasses than ssn:x
    subclass dul:y implies that every x is also an y. If we do so
    for O&M as well we will have that x is an y and a z and we need
    to be careful that the y and z’s are not disjoint classes.

    <KJanowic> yes

    KJanowic: I just want to answer Phil's question on whether
    dulce matgters in this context. We used it in our incubator.
    Its top level version sn'[t used, it's not maintainedf
    ... We said we're getting rid of it in SOSA so I'd be happy to
    see it go.
    ... And I was responsible for introducing it

    kerry: I put a lot of work into this a year ago and I'll be
    upset if it's dropped I have not said it should be normative.

    <KJanowic> I have to disagree here Kerry.

    kerry: It's part of SSN. All our SSN user base uses the dulce
    alignment, whether they use it or not. We've removed it so we
    can move on

    <KJanowic> I have not said it is not used

    kerry: Dulce is used, it is maintained, it is stable
    ... No need for an either or

    ahaller2: I don't think it's worth arguing about more here

    <KJanowic> But we can observe that the DUL link in SSN was
    broken for more than a year

    KJanowic: There are 2 versions of dulce, one of the links
    doesn't work. We still get mails in the XG
    ... asking about the 404 I can send the link

    <KJanowic> [24]http://www.loa-cnr.it/ontologies/DUL.owl

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

    kerry: The current WD of SSN refers in the index and the
    published version of the doc, a stable, consustent version of
    dulce

    <KJanowic> yes

    ahaller2: Let's discuss this in the next meeting. It's not
    about removing the alignment, it's about normative/informative.

Proposal to align sosa:Platform and ssn:Platform from Krzysztof,
taking into account virtual sensors
([25]https://www.w3.org/TR/sdw-ucr/#VirtualObservations) as of ISSUE
88 (carried from
[26]https://www.w3.org/2016/12/06-sdwssn-minutes#item05) and
ACTION-251

      [25] https://www.w3.org/TR/sdw-ucr/#VirtualObservations)
      [26] https://www.w3.org/2016/12/06-sdwssn-minutes#item05)

    ahaller2: There was a long discussion on the mailing list.
    There seems to be agreement that ssn and sosa Platform are
    equivalent
    ... It's the rdfs:comment that are not aligned
    ... The current comments don't mention virtual sensors, but we
    have a Use Case for these.
    ... So the suggestion is to change the comment in the
    ssn:Platform
    ... If necessary, use the old one
    ... What is the opinion on the current proposal.

    kerry: On the comment - yes, fine.
    ... But it's too specific for the bigger problem which is that
    SOSA and SSN don't align
    ... We don't have a use case for virtual platforms
    ... Personally, I don't care [breaking up]
    ... They're mostly the same, there are strong similarities
    ... Third comment - there are issues around Platform being
    different

    <kerry> no we have not agreed that ssn should subclass from sos

    ahaller2: We haven't agreed that SSN imports SOSA

    <kerry> ssn cannot subclass from sosa

    <kerry> this idea of definitions isdoes not hold

    ahaller2: SOSA terms need to be super classes and super
    properties of SSN
    ... There's a use case around virtual observations which
    enatils a virtual sensor

    <kerry> virtul observation does not require vitrual platform

    KJanowic: These issues are strongly aligned
    ... SOSA and SSN are aligned. Wherever possible, we use the
    same comments
    ... Paret if SSN allows for virtual sensors, other parts tend
    towards only allowing physical ones.

    <kerry> subclass axioms do not work

    KJanowic: We can have subclass axioms, which I think is the
    most reasonable way. All that would not work would be having
    SSN classes in SOSA.

    ahaller2: Both are in separate namespace

    <Zakim> phila, you wanted to talk about SOSA/SSN relationship

    ->
    [27]https://www.w3.org/TR/vocab-ssn/images/modular_ontology.png
    the diagram

      [27] https://www.w3.org/TR/vocab-ssn/images/modular_ontology.png

    <kerry> I agree the huge proble m is that SOSA *is* different
    from ssn!!!!

    <KJanowic> yes, we would have a very serious problem but
    luckily we do not have this problem

    <KJanowic> +1 to phila

    <ahaller2> +1 phila

    <Zakim> kerry, you wanted to say that a formal ontological
    alignment to ssn does not exist and to commnet that ssn allows
    virual sensors as does sosa --- thius is sue is about virtual

    phila: If we can't align SOSA with SSN that's a problem and I
    will raise a formal objection to further publications

    <KJanowic> You are an editor of the same draft kerry!

    kerry: We have the two being developed separately (paraphrase)

    <KJanowic> Simon did lign them up

    kerry: The problem is that we have two independent tracks

    <SimonCox> 'No-one has attempted to line them up" is incorrect

    <KJanowic> that if formally impossible, sorry to say that

    kerry: to say that SSN should be a subclass isn't right, they
    should be identical

    <KJanowic> there is an alignment by simon

    ahaller2: There has been work on an alignment. There's a
    mapping table
    ... We have not been able to discuss it in detail

    <KJanowic> +1 to ahaller2

    ahaller2: Not every class can be the same. In SOSA we have
    property paths that are different.
    ... We don't have a system class in SOSA

    <KJanowic> SOSA is broader that is the entire point. SSN is
    more specific

    kerry: But there's no reason why SSN can't adopt those same
    things, it would be a mess

    ahaller2: We're working through the issues, has Value,
    hasResult etc. We need a way to attach values in SSN
    ... potentially the same way in SOSA

    <SimonCox> But SOSA was not done indpendently - it was done by
    some of the same people who worked on SSN

    <KJanowic> and this was due to the DUL issue, this has nothing
    to do wil SOSA

    ahaller2: It doesn't help to say that the whole thing doesn't
    work, we should work through the issues one by one and we'll
    get there
    ... So I would propose that we may need 2 hour SSN meetings in
    future
    ... You already identified the issue of Platform

    <DanhLePhuoc> +1 Armin: go over alignment issues, one by one

    phila: No way can you have sosa:Platform and ssn:Platform
    meaning different things. One can subclass the other however.

    <KJanowic> yes, phila and sosa:platofrm is simply a super class
    of ssn:platform

    ahaller2: I don't think aligning SOSA and SSN is too difficult.
    We have a proposal.

    <ClausStadler> If there is issues with short cut properties,
    prior w3c specifications kinda just threw them in, such as
    [28]https://www.w3.org/TR/r2rml/#dfn-constant-shortcut-property

      [28] https://www.w3.org/TR/r2rml/#dfn-constant-shortcut-property

    ahaller2: We work through the issues...

    kerry: I can see that alignments do exit but I've obviously
    missed it, despite being here every week.

    ahaller2: We haven't worked through the issues in the tracker
    yet
    ... When we go through that issues, we'll end up with an
    alignment

    <KJanowic> kerry, let me jump in here

    <SimonCox> [29]https://github.com/w3c/sdw/pull/512

      [29] https://github.com/w3c/sdw/pull/512

    <KJanowic> I am on the queue

    <KJanowic> come on kerry, you have not even seen the results
    you are objecting!

    <SimonCox> and of course
    [30]https://www.w3.org/2015/spatial/wiki/Mapping_Table

      [30] https://www.w3.org/2015/spatial/wiki/Mapping_Table

    kerry: So when we can say that all SSN classes are sub classes
    SOSA, I will not be happy

    <KJanowic> they have to!

    <KJanowic> this is imposssible!

    kerry: SSN classes should be SOSA classes, we don't want
    another alignment.

    KJanowic: Let's try to be constructive
    ... we have multiple alignments. If we say that classes are
    equivalent... identical won't work.

    <kerry> qI express strong disagrement -- please lee the
    discussion oin the email list

    KJanowic: [more comments missed, sorry]

    ahaller2: To finalise today...
    ... We'll work on this alignment file and decide whether SSN
    imports SOSA etc.

    <KJanowic> [Poining again to our own draft:
    [31]https://www.w3.org/TR/vocab-ssn/images/modular_ontology.png
    ]

      [31] https://www.w3.org/TR/vocab-ssn/images/modular_ontology.png]

    ahaller2: We can discuss the current alignment but it doesn't
    make sense without going throug the issues

    phila: I do not like work going on behind closed doors. We work
    in public.

    <Zakim> kerry, you wanted to say that we have not agreed that
    an alignment is even needed -- that is a messy and uneccessary
    solution

    <KJanowic> nothing is going behind close doors

    kerry: I dob't like the idea of being presented with an
    alignment

    <KJanowic> See github, see the mapping table

    ahaller2: We had an alignment file from the start but there are
    issues so we didn't present it
    ... I think we go through the issue tracker for the properties
    and classes

    kerry: The issues on the tracker are not about rdfs:comment -
    they're more than that.

    ahaller2: of course

    <laurent_oz> Just a reminder that we did not know if the
    relationships were subclass or equivalentclass until very
    recently - the figures I have mande shows both options.

    ahaller2: I think you raised all the issues in the tracker,
    we're working on them.

    [Meeting adjourned]

    <SimonCox> bye

    <ahaller2> bye

    <KJanowic> bye

    <kerry> bye!

Summary of Action Items

    [NEW] ACTION: Simon to send e-mail with options for O&M
    alignment [recorded in
    [32]http://www.w3.org/2017/01/24-sdwssn-minutes.html#action02]
    [NEW] ACTION: SimonCox to send e-mail with options for O&M
    alignment [recorded in
    [33]http://www.w3.org/2017/01/24-sdwssn-minutes.html#action01]

      [32] http://www.w3.org/2017/01/24-sdwssn-minutes.html#action02
      [33] http://www.w3.org/2017/01/24-sdwssn-minutes.html#action01

Summary of Resolutions

    [End of minutes]
      __________________________________________________________
Received on Tuesday, 24 January 2017 22:19:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 January 2017 22:19:46 UTC