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