- From: Francois Daoust <fd@w3.org>
- Date: Wed, 10 May 2017 14:15:27 +0200
- To: <public-sdw-wg@w3.org>
Hi all,
The draft minutes of yesterday's SSN call are available at:
http://www.w3.org/2017/05/09-sdwssn-minutes.html
... and copied as raw text below.
Thanks,
Francois.
--
[1]W3C
[1] https://www.w3.org/
– DRAFT –
Spatial Data on the Web Working Group Teleconference
09 May 2017
[2]Agenda [3]IRC log
[2] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170509
[3] http://www.w3.org/2017/05/09-sdwssn-irc
Attendees
Present
DanhLePhuoc, Francois, KJanowic, mlefranc,
RaulGarciaCastro, SimonCox
Regrets
ArminHaller, ScottSimmons
Chair
KJanowic
Scribe
Francois
Contents
* [4]Meeting Minutes
1. [5]Approving last minutes
2. [6]Patent Call
3. [7]Implementation of proposal for alignment as of
https://www.w3.org/2015/spatial/wiki/
Events_and_Situations for ssn:Observation
4. [8]Progress on Action 350 to incorporate examples in
ED for each modular section of the SSN ontology
5. [9]Progress on related Action 348 to inquire the need
for implementation evidence for, e.g. ssn:Stimulus
6. [10]Progress on Action 346 to mark features at risk
7. [11]Strategies to make the WD more readable and how to
coordinate the collection of implementation evidence
* [12]Summary of Action Items
* [13]Summary of Resolutions
Meeting Minutes
Approving last minutes
[14]Last SSN minutes
[14] http://www.w3.org/2017/05/02-sdwssn-minutes
<mlefranc> +1
<KJanowic> +1
<SimonCox> +1
<DanhLePhuoc> +1
<RaulGarciaCastro> +1
Patent Call
<KJanowic> Patent Call [15]https://www.w3.org/2015/spatial/
wiki/Patent_Call
[15] https://www.w3.org/2015/spatial/wiki/Patent_Call
Implementation of proposal for alignment as of [16]https://
www.w3.org/2015/spatial/wiki/Events_and_Situations for
ssn:Observation
[16] https://www.w3.org/2015/spatial/wiki/Events_and_Situations
KJanowic: Nothing more to report on this particular case
compared to last time. I would propose to deal with more
pressing issues first
Progress on Action 350 to incorporate examples in ED for each modular
section of the SSN ontology
<KJanowic> [17]https://www.w3.org/2015/spatial/track/actions/
350
[17] https://www.w3.org/2015/spatial/track/actions/350
Maxime: First Pull Request that I created and then closed after
last week's meeting.
Maxime: [goes through proposal]. The suggestion that we had
last week was to merge the examples at the beginning of each
section
… I started to do that but I don't think it's the right place
for some of the examples, e.g. for stimulus
… I don't think having an example about stimulus is appropriate
when we haven't introduced observation yet.
… Also, the examples that I write consider that an instance of
a property is deeply attached to a feature of interest.
… I understand that some people disagree. I'd like to discuss
that issue beforehand.
KJanowic: I think we should still continue to work on examples.
If we wait until everyone agrees, then we'll likely run out of
time.
<mlefranc> first pull request with examples: [18]https://
github.com/w3c/sdw/pull/730
[18] https://github.com/w3c/sdw/pull/730
KJanowic: We can adjust examples afterwards.
… There are also preliminary examples for older versions of
SSN. Of course we changed the names, but adjusting them should
be easy.
… How atomic should these examples be? Clearly you need to
combine concepts. There will be no perfect solution.
… You can't talk about sampling without talking about feature
of interest. We may re-shuffle section 4 so that things make
more sense.
DanhLePhuoc: If we put examples on each property, it feels kind
of redundant. Even in simple use cases you don't describe one
simple thing.
… I think it's rather grouping that makes sense
<KJanowic> Examples as of now: [19]https://github.com/w3c/sdw/
blob/gh-pages/ssn/rdf/documentation_examples/
sosa-core_examples.ttl
[19] https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/documentation_examples/sosa-core_examples.ttl
SimonCox: I haven't been looking in details into examples, I
wonder if it's possible to use a URI without giving a full
explanation of what that URI denotes.
… And then expand the example further down.
KJanowic: Raul, any thought on this?
RaulGarciaCastro: From my perspective, all approaches are good.
Devil is in the details.
KJanowic: Just to summarize, it looks like doing step by step
is rather confusing. One way would be to move examples towards
the end.
… In complement to that, we may use URIs that we expand later
on.
mlefranc: I think the problems and the solutions might become
more obvious when I will have delivered the first version of
the total set of examples.
… Maybe we'll have a last phase of re-shuffling the examples.
… Same for the URI, usually I use example.org/data/something,
but sometimes I talk about actual examples.
… In that case, when the URI is dereferenceable, I used it.
DanhLePhuoc: I didn't have time to go over the version that
includes the examples. The current approach is to put examples
on every class and property?
mlefranc: Yes, the current pull request puts examples whereever
we introduce a new concept
<KJanowic> Can you post the link to the request?
mlefranc: I'm trying to merge examples near the top of section.
DanhLePhuoc: I propose to group examples so that it looks like
a small piece that fits together in a consistent way.
… People look at certain subsets of class and want to see
something relevant to them.
KJanowic: How are we going to handle the fact that some of
these examples will be SOSA only and some examples will be SSN
only.
… We should avoid examples that mix them, and we should avoid
duplicate examples.
… SOSA is made for a different target audience, and we need to
make sure that these examples stand out.
… Do we need separate SOSA and SSN examples?
… If SOSA examples contain SSN parts, would that do a favor to
SOSA readers?
mlefranc: I'm looking for a way for ReSpec to handle multiple
examples at once. We may hide examples that we don't want to
show.
… We could hide the SOSA example when we want the SSN example
to appear for instance.
… Not sure how example numbering would work in that case.
… It could be very interesting to have the examples both in
Turtle format and as a graph that is similar to the one that
describes the concepts
DanhLePhuoc: That's a good idea.
RaulGarciaCastro: I also thing that a figure is worth a
thousand words and I volunteer.
… I agree that we need examples focused on the SOSA audience
and complete them with examples focused on the SSN audience.
<KJanowic> Both, sosa and ssn examples
RaulGarciaCastro: We need to make them fit together to show
SOSA readers how they could extend them with SSN terms.
SimonCox: I share your concern KJanowic that the document would
become cluttered.
… Doing it in the specification part, we can get away with
that.
… Interleaving more material, it worries me certainly.
<KJanowic> ...and link to e xamples
<Zakim> RaulGarciaCastro, you wanted to say why not to put the
examples at the end of the document?
SimonCox: I wonder whether we could rather examples in a
completely different section rather than having them in line.
RaulGarciaCastro: I agree with this. When I read the
specification, I don't know anything. I want to see examples.
When I know the specification, I want to see things in details.
… These have two separate use cases.
KJanowic: Once you are a more frequent user of SSN, you'll only
go there for definition, and you won't want to be bothered by
examples.
… So I favour putting examples in a separate section.
… Now I do not think that we should go back to a document that
separates SOSA and SSN.
… now that we have them presented in combination.
… We should just try something and see whether that works.
<KJanowic> Btw, the button still jumps around for me
mlefranc: If you have a button that allows you to hide anything
that is related to SSN, then it's OK.
<RaulGarciaCastro> If we separate SOSA and SSN in the
specification it will be more confusing
<KJanowic> q
<KJanowic> +
mlefranc: There is the question of the timeline. If we accept
that examples fall at the beginning of each section with a
hide/show button, then everything falls in place for me.
KJanowic: I may a little old school here. If someone wants to
print out the document, can it print only the SSN part? That
would be difficult.
<RaulGarciaCastro> You share the screen, no problem :)
KJanowic: Also, if people have different settings, it makes
referencing sections online more difficult
… These are specification. Readability and ease of navigation
are the most crucial parts.
mlefranc: Try to also think in terms of SSN users sometimes. If
we move all the SOSA terms in a separate section, then imagine
how a user interested in both SOSA/SSN will understand the
spec.
KJanowic: That's a good point. But you can duplicate parts in
that case.
… When I want to learn, I look at the OWL file in any case.
RaulGarciaCastro: If we separate SOSA with a nice SOSA part,
the SSN part would indeed be quite a mess.
… It will be very difficult to understand what goes where and
how things relate. I'm not in favor of that.
… I'm even thinking about a primer.
… This is something we can do with examples.
… What we have now is a good compromise
KJanowic: Would it make sense to have a figure over figure 3
that explains what SOSA only is?
RaulGarciaCastro: Yes, but that's something we can do. We can
add a new figure. I'm happy to do that.
Action: RaulGarciaCastro: Sosa only figure
<trackbot> Created ACTION-354 - Sosa only figure [on Raúl
García Castro - due 2017-05-16].
Simon: I support the view that there's a significant set of
users that will jump straight to examples, but then it can be
the purpose of a Primer document.
KJanowic: I'm not super eager to vote in the absence of Armin.
mlefranc: I agree with the need to have SOSA only examples and
I will duplicate examples where it makes sense.
… To have SSN examples that extend SOSA examples.
Action: mlefranc: make SOSA and SSN examaples
<trackbot> Created ACTION-355 - Make sosa and ssn examples [on
Maxime Lefrançois - due 2017-05-16].
Progress on related Action 348 to inquire the need for implementation
evidence for, e.g. ssn:Stimulus
KJanowic: [question for Francois about classes that won't be
populated]
<KJanowic> tidoust: should be fine
KJanowic: The rationale to included some classes is from an
ontology modelling perspective
DanhLePhuoc: There are classes that people do not instantiate
but that will be used in the entailment regime
<KJanowic> I agree, we discussed this before and it is okay
DanhLePhuoc: In the SPARQL query, this will be used.
… I wonder if the implementation evidence needs to only address
abstract classes
KJanowic: The implementation evidence is for terms in HTTP
where not using them does not make any sense
<KJanowic> for the note above: implementation evidence natural
for something like tags in html, not necessarily axioms
Francois: Danh's explanation makes sense to me. Entailment
regime is a very good rationale to define abstract classes.
… No need to find implementation evidence in terms of
instantiation if it does not make sense.
KJanowic: There should be an action for somebody who list
classes and properties for which we don't expect instantiation.
mlefranc: Plus there are classes and properties that are
entangled.
… Whenever you have an observation, then you have a stimulus.
If you have implementation evidence for observation, then you
can that you implementation evidence for stimulus.
… Only a few terms that are not related such as accuracy and
precision.
<mlefranc> * true :-)
KJanowic: The presence of domain and range specifications would
immediately mean that you do not need implementation evidence
for the parent class.
… I would like to follow these rules.
… For now, I would just record an action that we create a list
of classes and properties where we don't expect instantiations.
… Any volunteer?
SimonCox: I'm interested in this but I feel I have less
experience in the SSN side. There's a bit of homework required,
here.
KJanowic: Absolutely, you'd have to understand what the axioms
trigger.
DanhLePhuoc: I can try and you can comment on that
Action: DanhLePhuoc: Create a lit of axioms that do not need
implementation evidence
<trackbot> Error finding 'DanhLePhuoc'. You can review and
register nicknames at <[20]http://www.w3.org/2015/spatial/
track/users>.
[20] http://www.w3.org/2015/spatial/track/users>.
Action: Danh to Create a lit of axioms that do not need
implementation evidence
<trackbot> Created ACTION-356 - Create a lit of axioms that do
not need implementation evidence [on Danh Le Phuoc - due
2017-05-16].
Action: DanhLePhuoc: Create a lit of axioms that do not need
implementation evidence
<trackbot> Error finding 'DanhLePhuoc'. You can review and
register nicknames at <[21]http://www.w3.org/2015/spatial/
track/users>.
[21] http://www.w3.org/2015/spatial/track/users>.
<KJanowic> next item on agenda: Decision on Pull request
[22]https://github.com/w3c/sdw/pull/792 for moving
ssn:hasProperty and ssn:isPropertyOf to SOSA
[22] https://github.com/w3c/sdw/pull/792
KJanowic: I wonder whether we should rather discuss features at
risk
<KJanowic> next would be: Progress on Action 346 to mark
features at risk
KJanowic: I just fear that if we discuss this now, we'll take
most of the remaining hour and Armin would still need to be in
the conversation.
… I suggest to talk about features at risk first.
Progress on Action 346 to mark features at risk
ACTION-346?
<trackbot> ACTION-346 -- Armin Haller to Mark
classes/properties as at risk in the ed -- due 2017-05-09 --
OPEN
<trackbot> [23]http://www.w3.org/2015/spatial/track/actions/346
[23] http://www.w3.org/2015/spatial/track/actions/346
<KJanowic> [24]https://github.com/w3c/sdw/pull/850
[24] https://github.com/w3c/sdw/pull/850
KJanowic: Please look at this discussion
… Simon, you brought up this idea of moving this in the
horizontal module part
<KJanowic> I strongly agree
Simon: Yes, I think the whole approach to modularization is
motivated by a few things. You can say that importing an
ontology does not mean that you have to use all the terms it
defines.
… All the classes that seemed to be discussed as at risk were
related to detailed descriptions of sensors
… I suggest to package them separately
<KJanowic> nbasically do what we did with Sample Relations
Module
<sdwssn> thats exactly what i was proposing in the Option 8
modularity.... for those reasons
Simon: in a different graph. SOSA at the core. Then a basic SSN
with axiomization but similar scope.
… Then a separate graph for horizontal extensions as was
proposed by KJanowic a year ago.
<KJanowic> Yes, and that is a very important point (the
readability)
Simon: In terms of document, it means we could move concepts to
a different part, normative initially and that we could flip to
informative prose if we cannot find implementation evidence.
<sdwssn> hmm - sleepy eyes - manged to miss my nick roba - can
i fix this
<RaulGarciaCastro> Some of those terms had implementation
evidence in the old SSN: [25]http://w3c.github.io/sdw/
ssn-usage/
[25] http://w3c.github.io/sdw/ssn-usage/
KJanowic: The risk is not being able to move forward because of
lack of evidence.
mlefranc: I also back you on moving some of the properties and
classes that we feel are at risk in a separate module.
<KJanowic> I agree
mlefranc: I just saw the pull request, had missed that one. I
think other classes could be moved to a separate section.
<KJanowic> No, then this would no longer be needed, that is the
benefit
<KJanowic> yes!
mlefranc: My understanding of feature at risk is that we would
need to remove them altogether.
… Switching them to informative would be a clever way to keep
them around.
… We already have two namespaces, now there would be 3, I'm not
fan.
<KJanowic> "The namespace for Sample relationships terms is
[26]http://www.w3.org/ns/sosa/sampling/"
[26] http://www.w3.org/ns/sosa/sampling/"
mlefranc: If we put these features in a non-normative section
already, then we don't need to have them as features at risk.
KJanowic: This is a really big issue. This is not only about
restructuring. Putting features informative would avoid having
to mark them at risk altogether.
RaulGarciaCastro: For me, this is a significant change right
now.
KJanowic: It's only about moving parts of the document. It
won't change axioms.
Francois: Wondering about normative vs. informative meaning
here
KJanowic: It's more thinking in terms of a family of terms that
we carry over from the old SSN.
DanhLePhuoc: I share Raul's concern about that being a major
change.
Francois: Moving these classes to a horizontal module is fine.
However, I note marking that module as informative means you
basically drop that module from the ontology.
roba: My concern is that this relationship between factories
and namespaces still seems confusing. I would like to see
options for extensions that make it easy to do so. Provide a
useful pattern.
Francois: Why don't you drop these terms altogether right away?
They seem to come from the past without too much rationale.
<KJanowic> I agree with Maxime
mlefranc: If we find evidence, then these terms would be great
to have.
… There are other people on top of us.
Simon: I think it's the wrong container. There should be one
REC, and a series of NOTE maybe.
… We can focus on SOSA core and publish a note for the rest of
the stuff.
<KJanowic> PROPOSAL: Drop conditions, capabilities, and ranges
entirely from new SSN.
<RaulGarciaCastro> -1
<KJanowic> -1
<mlefranc> -1
<DanhLePhuoc_> -1
<SimonCox> -1
KJanowic: I'm going to propose that we vote on different
options, starting with the most provocative one.
<roba> -1
<KJanowic> PROPOSAL: Move conditions, capabilities, and ranges
to a horizontal module and make them non-normative.
<roba> ("the new SSN" is still amorphous - reading it as SOSA +
SSN)
KJanowic: I'll take this as a "no".
<mlefranc> +1
<KJanowic> 0
<RaulGarciaCastro> 0
<roba> 0
<SimonCox> +1
<DanhLePhuoc_> 0
<KJanowic> PROPOSAL: Move conditions, capabilities, and ranges
to a horizontal module and make them normative.
<KJanowic> 0
<SimonCox> -1
<mlefranc> +1 "and at risk"
<RaulGarciaCastro> 0
<DanhLePhuoc_> 0
<roba> +1 (but revert to previous if no implementation)
<KJanowic> PROPOSAL: Do not change anything and mark as at risk
<SimonCox> -1
<KJanowic> -1
<mlefranc> 0
<roba> 0
<RaulGarciaCastro> 0
<DanhLePhuoc_> 0
<SimonCox> Could we ask the simple question 'Move conditions,
capabilities, and ranges to a horizontal module' first?
<mlefranc> +1
<KJanowic> PROPOSAL: Move conditions, capabilities, and ranges
to a horizontal module and make them as normative (and at
risk). If no implementation evidence found, mark section as
non-normative.
<mlefranc> +1
<SimonCox> +1
<KJanowic> +1
<roba> +1
<DanhLePhuoc_> +1
<RaulGarciaCastro> +1
<SimonCox> Good ooutcome
Resolved: Move conditions, capabilities, and ranges to a
horizontal module and make them as normative (and at risk). If
no implementation evidence found, mark section as
non-normative.
KJanowic: Excellent. This needs an action. Any volunteer?
mlefranc: I can do that. Not before next Monday though
Action: mlefranc : implement resolution "Move conditions,
capabilities, and ranges to a horizontal module and make them
as normative. If no implementation evidence found, mark section
as non-normative."
<trackbot> Created ACTION-357 - : implement resolution "move
conditions, capabilities, and ranges to a horizontal module and
make them as normative. if no implementation evidence found,
mark section as non-normative." [on Maxime Lefrançois - due
2017-05-16].
<KJanowic> Next on the agenda: Strategies to make the WD more
readable and how to coordinate the collection of implementation
evidence
Strategies to make the WD more readable and how to coordinate the
collection of implementation evidence
KJanowic: We haven't got a lot of comments so far.
… Right now, we don't have a lot of feedback. We sent it to a
lot of people.
… It may turn into a thing that we need to address.
… Any idea of a better way to solicit feedback.
<KJanowic> Very good idea!
<KJanowic> Directly target authors of previous SSN workshops
mlefranc: I was just wondering. There have been a few
conferences about SSN. Some emails to paper authors could be a
good idea
KJanowic: But then we risk getting statu quo feedback.
<KJanowic> tidoust: check back again with WoT group
<RaulGarciaCastro> tidoust: I wrote this comparison in the
wiki: [27]https://www.w3.org/2015/spatial/wiki/
Comparison_between_SSN_and_WoT_TD
[27] https://www.w3.org/2015/spatial/wiki/Comparison_between_SSN_and_WoT_TD
DanhLePhuoc: Involved in the Wot WG on Thing Description
discussions. They haven't looked very closely at SSN and how it
could be integrated but are aware of it.
Francois: OK, what I wanted to know was that there are people
who look at both. That's good.
<KJanowic> Agreed!
mlefranc: Having examples should help us to get reviews.
… It will enhance readability of the document.
… As soon as we have accepted the examples, then we're good.
KJanowic: I agree. Let's continue with the example despite the
fact that we could have to change what property means.
<mlefranc> * as we have accepted what a ssn:Property is
KJanowic: I can collect implementation evidence for social
sensing. And I can ask people from Siemens to help.
<SimonCox> I can provide implementation evidence for sampling
(and also sampling relations!)
KJanowic: Anyone else who can contribute implementation
evidence?
… For the actuation part?
<SimonCox> ... from Geoscience Australia (2M samples)
mlefranc: If it is some data about my building and a few
actuators done by my students, that's probably not enough in
terms of dataset size.
<roba> i dont htink its size as stability - needs to be a
production sysrtem
KJanowic: I think it will have to be a bit more substantial
than that.
… OK, we need to be proactive about gathering evidence.
DanhLePhuoc: I will check with Web of Things plugfest demos, as
they have some things for actuation.
roba: My impression is that it has nothing to do about the
size, but rather stability. It needs to be in a production
system.
… I think we should give it some thoughts before we spend too
much time on demos.
KJanowic: I hope that academic usage will be ok.
DanhLePhuoc: Even the industry, most of the work is in research
labs, so it's not easy to find things in production.
… We have to check.
… It's really hard to find evidence within 3 month time.
KJanowic: In a EU research project, I think that would be
enough.
… It would be a chicken and egg problem.
<roba> just saying we should check...
<DanhLePhuoc_> [28]https://www.w3.org/2011/gld/wiki/
DCAT_Implementations
[28] https://www.w3.org/2011/gld/wiki/DCAT_Implementations
<DanhLePhuoc_> some of them are academic demontrations
Francois: [clarifying the needs are somewhere in between, CR
phase is to ask for implementations and deployments or plans
for deployments in actual production environments]
KJanowic: OK, it seems we have people looking at implementation
evidence, this is good.
… Any other topic to address in the last 10 minutes?
… [recap of call discussions]
<RaulGarciaCastro> bye
Summary of Action Items
1. [29]RaulGarciaCastro: Sosa only figure
2. [30]mlefranc: make SOSA and SSN examaples
3. [31]DanhLePhuoc: Create a lit of axioms that do not need
implementation evidence
4. [32]Danh to Create a lit of axioms that do not need
implementation evidence
5. [33]DanhLePhuoc: Create a lit of axioms that do not need
implementation evidence
6. [34]mlefranc : implement resolution "Move conditions,
capabilities, and ranges to a horizontal module and make
them as normative. If no implementation evidence found,
mark section as non-normative."
Summary of Resolutions
1. [35]Move conditions, capabilities, and ranges to a
horizontal module and make them as normative (and at risk).
If no implementation evidence found, mark section as
non-normative.
Received on Wednesday, 10 May 2017 12:15:41 UTC