See also: IRC log
<scribe> scribe: phila
<SimonCox> Is webex running? I see 'meeting not started'.
<ahaller2> webex is started, yes
Last week's minutes https://www.w3.org/2017/01/17-sdwssn-minutes
-> https://www.w3.org/2015/spatial/wiki/Patent_Call Patent Call
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 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> 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> 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> 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.
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> 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: 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: 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 http://www.w3.org/2017/01/24-sdwssn-minutes.html#action01]
<trackbot> Error finding 'SimonCox'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<scribe> ACTION: Simon to send e-mail with options for O&M alignment [recorded in 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> 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.
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
-> https://www.w3.org/TR/vocab-ssn/images/modular_ontology.png the diagram
<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 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> 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 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: 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!
![https://www.w3.org/TR/vocab-ssn/images/modular_ontology.png]](https://www.w3.org/TR/vocab-ssn/images/modular_ontology.png]){kind=link}