– DRAFT –
Spatial Data on the Web Working Group Teleconference
09 May 2017
<mlefranc> +1
<KJanowic> +1
<SimonCox> +1
<DanhLePhuoc> +1
<RaulGarciaCastro> +1
<KJanowic> Patent Call https://www.w3.org/2015/spatial/wiki/Patent_Call
KJanowic: Nothing more to report on this particular case compared to last time. I would propose to deal with more pressing issues first
<KJanowic> 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: 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: 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].
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 <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 <http://www.w3.org/2015/spatial/track/users>.
<KJanowic> next item on agenda: Decision on Pull request https://github.com/w3c/sdw/pull/792 for moving ssn:hasProperty and ssn:isPropertyOf to SOSA
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.
ACTION-346?
<trackbot> ACTION-346 -- Armin Haller to Mark classes/properties as at risk in the ed -- due 2017-05-09 -- OPEN
<trackbot> http://www.w3.org/2015/spatial/track/actions/346
<KJanowic> 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: 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 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
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: 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_> 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