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

[minutes SSN] 2017-05-09 call

From: Francois Daoust <fd@w3.org>
Date: Wed, 10 May 2017 14:15:27 +0200
To: <public-sdw-wg@w3.org>
Message-ID: <006101d2c987$1c28a780$5479f680$@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

This archive was generated by hypermail 2.3.1 : Wednesday, 10 May 2017 12:15:42 UTC