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

[minutes SSN] 2017-03-28

From: Francois Daoust <fd@w3.org>
Date: Wed, 29 Mar 2017 09:35:16 +0200
To: "'SDW WG'" <public-sdw-wg@w3.org>
Message-ID: <032d01d2a85f$02927d80$07b77880$@w3.org>
Hi all,

The minutes of yesterday's SSN call are available at:

... and copied as raw text below.


Spatial Data on the Web WG - SSN Sub Group Teleconference
28 March 2017

   [2]Agenda [3]IRC log

      [2] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170328
      [3] http://www.w3.org/2017/03/28-sdwssn-irc


          Armin (ahaller2), Danh (DanhLePhuoc), Francois
          (tidoust), Jano (KJanowic), Maxime (mlefranc), Raul
          (RaulGarciaCastro), Simon (SimonCox)



          Francois, Maxime


     * [4]Meeting Minutes
         1. [5]Approving last meeting's minutes https://
         2. [6]Patent Call https://www.w3.org/2015/spatial/wiki/
         3. [7]Progress on ACTION 282 for Forecasting
         4. [8]Progress on ACTION-283 to propose properties to
            replace dul:includesEvent property as of ISSUE-117
         5. [9]Progress on ACTION-279 to add a change history to
            SSN document
         6. [10]SSN Measurement and Operating properties for
            actuators https://www.w3.org/2015/spatial/wiki/
         7. [11]Proposal for ssn:Device (Deprecate?) as of
         8. [12]Discussion of RecTrack requirements, i.e. last
            working draft, 17-04-17
         9. [13]Progress on ACTION-286 for Sampling and decision
            on OBOE alignment
        10. [14]Close ISSUE-89 as of implementation of https://
        11. [15]Progress on ACTION-284, temporal properties in
            both SOSA/SSN, i.e. ssn:startTime, ssn:endTime as of
            ISSUE-145, stimulusTime for Observation as of
            ISSUE-151 and sosa:resultTime,
            ssn:observationResultTime and
     * [16]Summary of Action Items
     * [17]Summary of Resolutions

Meeting Minutes

Approving last meeting's minutes [18]https://www.w3.org/2017/03/

     [18] https://www.w3.org/2017/03/14-sdwssn-minutes

   <RaulGarciaCastro> +1

   <ahaller2> +1

   <KJanowic> +1

   <tidoust> +1

   <mlefranc> +1

   <DanhLePhuoc> +1

   Resolved: Approving last meeting's minutes [19]https://

     [19] https://www.w3.org/2017/03/14-sdwssn-minutes

Patent Call [20]https://www.w3.org/2015/spatial/wiki/Patent_Call

     [20] https://www.w3.org/2015/spatial/wiki/Patent_Call

Progress on ACTION 282 for Forecasting

   <mlefranc> [21]https://lists.w3.org/Archives/Public/

     [21] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0254.html

   <ahaller2> [22]https://www.w3.org/2015/spatial/track/actions/

     [22] https://www.w3.org/2015/spatial/track/actions/282

   ahaller2: Maxime, you posted an email about that action.
   … What we discussed is that we do not include forecasting as a
   first level property
   … but include a comment in the document to explain how you
   could do forecasting using existing properties

   <ahaller2> [23]https://github.com/w3c/sdw/compare/

     [23] https://github.com/w3c/sdw/compare/action-282-forecasting

   ahaller2: Maxime prepared a commit on this.

   mlefranc: It's a new section because I don't know where to put
   it, but otherwise it just has 2 notes.

   ahaller2: Are there any comment on the text?

   KJanowic: Some wordsmithing needed, I think. Should we do it

   ahaller2: We could do that on the mailing-list or within the
   Pull Request if we agree on the general direction.

   <KJanowic> One may represent forecasts as observations by
   setting the value of <code>sosa:phenomenonTime</code> to a
   later time than the <code>sosa:resultTime</code>. Given the
   definition of these properties, this means that <em>the time
   when the observation activity was completed is before the time
   that the result of the observation applies to the feature of
   interest.</em> <br/>

   KJanowic: Basically tiny changes to the grammar and the terms.
   … The bigger change that I would propose is not to use the
   second paragraph.
   … Removing the part the note that "There are other means to
   represent forecasts..."

   mlefranc: No problem with changes on the grammar.
   … On the second part, I don't know, I believe it would be a
   different vote.
   … You did not comment on the part that talks about the fact
   that the spec does not mandate ways to talk about the future.

   ahaller2: I think the sentence is useful as it tells users what
   can be done.

   KJanowic: I'm not saying it's not useful, just that it does not
   belong to a normative part of the document.
   … My understanding that we would e.g. reference SEAS here.

   mlefranc: So you think the first part of the note would belong
   to a normative section of the spec. That's not the intend. It's
   intended to be an informative note.

   KJanowic: I would move the first part of the sentence to the
   normative part of SOSA/SSN, and then at the end of it, I would
   add a not that references SEAS.
   … Put it together with the notion of observation and have the
   reference there to the SEAS ontology, and then remove the
   second part.

   <KJanowic> and therefore I would remove it

   mlefranc: I think I would agree with what you propose. The
   second part of the paragraph does not call for a reference to
   the SEAS ontology because that is not how things are done
   there. If we do reference SEAS, then we should explain how
   things are done there.

   SimonCox: It seems relevant to have a reference to SEAS but it
   should be offset in some way with respect to the main document.

   KJanowic: It would be odd not to reference an ontology worked
   upon by some participants in the group.

   <KJanowic> my proposal would be to say "One may represent
   forecasts as observations by setting the value of
   <code>sosa:phenomenonTime</code> to a later time than the
   <code>sosa:resultTime</code>. Given the definition of these
   properties, this means that <em>the time when the observation
   activity was completed is before the time that the result of
   the observation applies to the feature of interest.</em> <br/>"
   and then add a reference to the ontology

   <KJanowic> ontology --> SEAS ontology

   mlefranc: I can provide a new commit based on this discussion.
   I believe I understand where people are heading here.

Progress on ACTION-283 to propose properties to replace
dul:includesEvent property as of ISSUE-117

   <ahaller2> [24]https://www.w3.org/2015/spatial/track/actions/

     [24] https://www.w3.org/2015/spatial/track/actions/283

   <RaulGarciaCastro> [25]https://www.w3.org/2015/spatial/track/

     [25] https://www.w3.org/2015/spatial/track/issues/117

   RaulGarciaCastro: I sent an email to the mailing-list. In the
   link I just posted, you can see the proposed resolution.
   … The dul:includesEvent property disappeared. The proposal is
   to add a restriction as it was before for the new property.

   RaulGarciaCastro: Relation between a property and a stimulus.
   For me, the constraint is restrictive.

   <mlefranc> +1 for that proposal. What would be the definition ?

   <KJanowic> Sorry, where do I find the exact proposal?

   <ahaller2> @KJanowic in the comments of the issue

   <RaulGarciaCastro> [26]https://www.w3.org/2015/spatial/track/

     [26] https://www.w3.org/2015/spatial/track/issues/117

   <ahaller2> +1 from me btw

   <KJanowic> looks good to me!

   RaulGarciaCastro: Proposal: New property in SSN
   "isStimulatedBy" and a restriction that is the same as the one
   that existed before for the "includesEvent" property.

   mlefranc: No problem with the proposal. Maybe in the
   definition, the term "link" is more used than "relation".

   ahaller2: In terms of the comment, I do think that we use
   "relation" in most of our comments. Before we go to rec, we'll
   need to revisit all comments to make sure we're consistent.
   … We need to have someone go through all the comments in the

   <KJanowic> Yes, but this is a task for editors

   ahaller2: Whatever we use should be consistent with the rest of
   the comments.

   <KJanowic> yes on relation instead of link

   ahaller2: Any comment? What about the restriction?

   KJanowic: My only concern is wordsmithing. The current name
   "isStimulatedBy". What is stimulated by a stimulus is the
   sensor, not the observation.

   <KJanowic> the stimulus stimulates the sensor and this triggers
   the observation

   RaulGarciaCastro: Can we change it to "isTriggeredBy"?

   <mlefranc> ok

   <KJanowic> so the observation is caused by or triggered by the

   ahaller2: The only concern I would have is that this seems to
   mandate a "trigger" somewhere.

   KJanowic: Nothing prevents us from using includesEvent in

   <KJanowic> ssn:includesEvent

   DanhLePhuoc: isTriggeredBy could be linked to actuation. That
   could confuse people.

   <KJanowic> trigger was just a proposal, I am fine with other
   names as well

   ahaller2: Right, my opinion as well. Trigger feels more active.

   <DanhLePhuoc> +1 ssn:includesEvent

   <KJanowic> so what about ssn:includesEvent

   <KJanowic> we likes the name before

   <RaulGarciaCastro> +1 ssn:isStimulatedBy

   ahaller2: I personally think isStimulatedBy is better than
   includesEvent but I'm ok with both.

   <KJanowic> and ssn:includesEvent will be a subpropertyof

   <KJanowic> +1 for ssn:includesEvent

   RaulGarciaCastro: The problem I see with includesEvent is that
   without the context of dul, it does not make much sense.

   <RaulGarciaCastro> What about isOriginatedBy?

   mlefranc: Maybe we can reuse the past/present scheme and say
   that anything present could apply to the sensor/actuator, while
   past could be applied to observation/actuation.
   … So "wasStimulatedBy", perhaps?

   <KJanowic> the stimulus (as an activity) has to stimulate an
   entity, namely the sensor (not another activity). see the rest
   of SSO and SSN

   <RaulGarciaCastro> So it can be said that the stimulus
   originates the observation?

   KJanowic: We need to get rid of this stimulus. I like the
   originate idea.

   <KJanowic> +1 to raul's

   <ahaller2> wasOriginatedBy

   <KJanowic> +1

   ahaller2: Then "wasOriginatedBy"?

   <mlefranc> +1 wasOriginatedBy

   <SimonCox> +1

   <RaulGarciaCastro> +1 (but see no problem in isOriginatedBy

   <DanhLePhuoc> +1

   <KJanowic> I would be in favor of isOriginatedBy for sake of
   conistency but fine with 'was' as well

   <RaulGarciaCastro> I also prefer “is” for consistency

   <RaulGarciaCastro> If not, we should review all property names

   Resolved: Implement comments in issue [27]https://www.w3.org/
   2015/spatial/track/issues/117 with isStimulatedBy replaced by

     [27] https://www.w3.org/2015/spatial/track/issues/117

   ahaller2: Raul, can you work on a PR for this?

   RaulGarciaCastro: Yes.
   … Another question about the dul alignment. [scribe missed

   <mlefranc> we should serve any of them depending on what the
   client ask... so if the turtle file we write looks better than
   then one that is automatically generated, let's serve this one

   ahaller2: There are two files (.ttl, and .owl)
   … I think there are the same, but it would be useful to check

   mlefranc: We should serve the right file based on what the
   client asks.

   ahaller2: Fine but I'm not sure changes made to the Turtle file
   were reflected in the OWL file.

   <KJanowic> Yes, only one file!

   <KJanowic> and yes, let us use the ttl file

   ahaller2: My problem is that changes need to be made to 2
   files. I think it would be better to have only one file.

   <mlefranc> +1 agree with keeping in the ttl

   ahaller2: I'm proposing that we only skip the Turtle file for
   the time being.
   … Can you do that, Raul, when you implement your changes?

   RaulGarciaCastro: Yes, but should I also change the dul
   alignment OWL file?

   ahaller2: Yes, but please make that a Turtle file as well.

   RaulGarciaCastro: OK.

Progress on ACTION-279 to add a change history to SSN document

   ahaller2: I think you issued a new PR while I was sleeping,

   <ahaller2> [28]https://github.com/w3c/sdw/pull/633

     [28] https://github.com/w3c/sdw/pull/633

   <KJanowic> [there is somebody speaking in the background]

   <DanhLePhuoc> [29]https://github.com/w3c/sdw/pull/643

     [29] https://github.com/w3c/sdw/pull/643

   <ahaller2> [30]https://github.com/w3c/sdw/pull/643

     [30] https://github.com/w3c/sdw/pull/643

   DanhLePhuoc: Two PR. I made a revised one based on comments
   … I checked the PR we did since January and now there should be

   ahaller2: Any quick comment?

   [none heard]

SSN Measurement and Operating properties for actuators [31]https://

     [31] https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators

   mlefranc: I sent a couple of emails too.
   … The most important mail is about measurement properties.
   … Currently there is one way to link a sensor to its
   measurement property, using hasMeasurementCapability and then
   from MeasurementCapability through the measurement property.
   … I think it would be odd if the user of the SSN ontology would
   not be able to use any object in the hierarchy of measurement
   properties as actuators.
   … One option would be to duplicate things for actuators
   "hasActuationProperty" perhaps. But I don't know how to change
   the name MeasurementProperty.
   … Option 3 is to deprecate all of this, and make sure SSN does
   not talk about measurement properties.

   KJanowic: Thanks for spotting this. I'm more optimistic. Option
   2 is not too much work.
   … We have done bigger changes.
   … If we simply rename the super class, we do not have to find
   new implementations, but if we introduce actuation limit, we'll
   need new implementations and we're running out of time.

   ahaller2: I agree with option 2 as well. I agree that we should
   not introduce new properties anymore. None of us has a product
   where we implement actuation, so implementation evidence would
   be hard to get.

   <KJanowic> I can help maxime to find names etc for next week

   mlefranc: I volunteer in being part of the team that proposes
   something. Maybe we could use systems properties.

   <KJanowic> if we decide on this now, it will freak certain
   people out. Let us have a proposal on the table and vote next

   RaulGarciaCastro: I was about to propose the same thing.
   Capabilities are related to the device in the end, or to the

   KJanowic: We shouldn't take a big decision like this right now.
   Let's have someone craft a concrete proposal and see what comes
   out of it before we resolve that.

   Action: maxime and KJanowic to propose implementation options
   for Option 2 on the wiki: [32]https://www.w3.org/2015/spatial/

     [32] https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators

   <trackbot> Created ACTION-295 - And kjanowic to propose
   implementation options for option 2 on the wiki: [33]https://
   measurement_and_operating_properties_for_actuators [on Maxime
   Lefrançois - due 2017-04-04].

     [33] https://www.w3.org/2015/spatial/wiki/measurement_and_operating_properties_for_actuators

   <KJanowic> Maxime can draft and I can review

   ahaller2: If you both can work on a Wiki page, that would be

   <mlefranc> ok jano

Proposal for ssn:Device (Deprecate?) as of ISSUE-153

   <ahaller2> [34]https://www.w3.org/2015/spatial/track/issues/153

     [34] https://www.w3.org/2015/spatial/track/issues/153

   ahaller2: We have a device class in SSN which is pretty much
   unused at the moment. Do we actually need this class?

   <KJanowic> delete

   RaulGarciaCastro: The device class is frequently used. Now,
   devices and systems are sufficiently different for us to
   consider them differently.

   DanhLePhuoc: I know several EU projects that have been using or
   extending SSN, with subclasses of device.
   … I think we should not remove it.

   KJanowic: We could just deprecate the term, and discourage its

   <KJanowic> just 'discourage' the usage of device as a weaker
   version of 'deprecating'

   <Zakim> RaulGarciaCastro, you wanted to say that if we think
   about alignment with other initiatives (WoT, oneM2M, etc.) the
   link usually is through Device

   ahaller2: Is there some ontology that has a term for that?
   skos, perhaps?

   <mlefranc> ok with jano and danh about using

   RaulGarciaCastro: If we take into account alignment with other
   initiatives, usually the alignment is through the Device class.
   If we remove it, people will have more difficulties to
   integrate their data with other ontologies.

   ahaller2: Sensor and Actuators can be attached to Platform,
   which makes them Devices in the dul sense.

   <KJanowic> we can pick an axiomatic solution by subclassing

   mlefranc: I would be ok to deprecate Device. Just make sure
   that the old usage of ssn:Device remains compatible with

   <mlefranc> ok

   KJanowic: My favorite solution would be to deprecate the class.
   If people ignore what we propose, then it's still ok.

   <KJanowic> device subclassof new:platform and then phase out
   the usage of device.

   ahaller2: Any volunteer to look into it until our next meeting?

   <KJanowic> I can look into this

   Action: KJanowic to look into [35]https://www.w3.org/2015/
   spatial/track/issues/153 and propose a solution

     [35] https://www.w3.org/2015/spatial/track/issues/153

   <trackbot> Created ACTION-296 - Look into [36]https://
   www.w3.org/2015/spatial/track/issues/153 and propose a solution
   [on Krzysztof Janowicz - due 2017-04-04].

     [36] https://www.w3.org/2015/spatial/track/issues/153

Discussion of RecTrack requirements, i.e. last working draft,

   ahaller2: I had an exchange with Phil about timeline.
   … We need a last call working draft by 17 April.
   … No more substantive changes to make on the document.
   … Then 4 weeks time for people to make comments
   … Then we can go to the Director to ask for transition as
   Candidate Recommendation.
   … Timeline is pretty tight.
   … Many issues are still open.
   … We made changes to ontologies but still need to make changes
   to the document.
   … What would the availability of people be in the next 3 weeks?

   KJanowic: The current group as we are now, we're doing a good
   job, are ready to make compromises, and so on. We can do it!
   … I can help on the implementation evidence.
   … If we do crazy things such as renaming sosa and so on, I'm
   more worried.
   … But otherwise, I'm happy to support.

   [Note description of the timeline in email I posted on the
   mailing-list: [37]https://lists.w3.org/Archives/Public/
   public-sdw-wg/2017Mar/0231.html ]

     [37] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0231.html

   mlefranc: I would like to be as optimistic as KJanowic. Just in
   case, what happens if we just end up with a note?

   <SimonCox> Unfortunately I have to focus on OWL-Time in the
   next two weeks. Can try to keep on top of the correspondence re
   SSN/SOSA but won't be able to do detailed editorial work.

   mlefranc: Also question on implementations.
   … [missed, audio was chopped]

   ahaller2: If we end up with a Note, we have more time.
   … In terms of implementation, it is really up to the Director
   to interpret that.
   … It would be nice to have data.

   <RaulGarciaCastro> agree

   KJanowic: I understand the Note would be a fallback solution.
   Let's aim for a Rec!

   <KJanowic> no backup plans, let us be optimistic! we have a
   strong team, we can pull this off

   <KJanowic> Great!

   DanhLePhuoc: What we need for the Rec track is implementation.
   KJanowic already has one. I can offer another one.

   <KJanowic> we have until 05/30 for the implementations

   ahaller2: implementation is after closing all the issues and be
   ok with the document
   … ok to help to implement things also

   <KJanowic> we can close all issues by having a qucik vote on
   all of them

   tidoust: implementation: the Director will decide
   … what we require is the rec to be explicit about conformance
   criteria for the implementations
   … before the candidate recommendation phase
   … I don't know if ontologies that extend ssn, datasets that use
   terms, or tools that use terms are considered as
   … but we need each and every term to be used somewhere
   … the mail I sent describes all that the document needs to
   explicit before each transition to the next step

   KJanowic: want to be optimistic, we are the ones that decide on
   the status of the issues. We can run into those and close them
   one by one.
   … if no one complains with issues, one may just close them

   <RaulGarciaCastro> That’s it: “won’t fix” is also an

   ahaller2: some of these issues can be closed because they are
   not "in scope"
   … we need a longer meeting where we go though the issues
   … I'll propose this in the following weeks
   … if we don't have implementation evidence for a class or
   property, then we can just push that in a note

   tidoust: you can identify features that are "at risk" before
   candidate recommendations. these are the ones that you may

   <mlefranc> if you miss a class/property that is not at risk but
   you cant provide evidence that it is implemented, then that's
   an issues and you will go backwards in the process

   Action: ahaller2 Implement changes that were made to SOSA in
   the WD document

   <trackbot> Created ACTION-297 - Implement changes that were
   made to sosa in the wd document [on Armin Haller - due

   ahaller2: sosa ontology is quite stable now, so we can start
   writing the doc by hand in the spec and not rely anymore on
   specgen, that has some issues

   ahaller2: changes in ssn need to be postponned to next week

   <mlefranc> maxime there is the "integrated" directory, please
   send a mail about what remains to be discussed before candidate

   Action: maxime to send an email to the list to list
   classes/properties in SSN from the "integrated" directory that
   we have not discussed yet

   <trackbot> Created ACTION-298 - Send an email to the list to
   list classes/properties in ssn from the "integrated" directory
   that we have not discussed yet [on Maxime Lefrançois - due

Progress on ACTION-286 for Sampling and decision on OBOE alignment

   <ahaller2> [38]https://www.w3.org/2015/spatial/track/actions/

     [38] https://www.w3.org/2015/spatial/track/actions/286

   <SimonCox> [39]https://www.w3.org/2015/spatial/wiki/Sampling

     [39] https://www.w3.org/2015/spatial/wiki/Sampling

   <SimonCox> [40]https://www.w3.org/2015/spatial/wiki/

     [40] https://www.w3.org/2015/spatial/wiki/Alignment_to_OBOE

   SimonCox: everything I proposed is already in position to be
   discussed here
   … the sampling part and the alignment to oboe
   … for samping, the upper part of the wiki page has been added
   to sosa,
   … <sorry, speak too fast>

   <mlefranc> ok to accept simon's proposal

   <KJanowic> same here

   ahaller2: the pull request has been made
   … need implementation evidence now,
   … and maybe accept the lower part of the wiki page

   SimonCox: or just fallback to saying that there are "horizontal

   ahaller2: they could be in non normative parts

   KJanowic: sampling/sampler/sample we agreed
   … for the properties, let's put them in the non normative parts
   … for the classes, I have evidence of implementations
   … I would have loved to have horizontal modules

   <KJanowic> [41]http://host.geolink.org/ngdb/id/geosample/

     [41] http://host.geolink.org/ngdb/id/geosample/AAM055A

   ahaller2: if we put it in non-normative parts of ssn, what
   would the document look like ?
   … the document will look like having non-normative sections
   that talk about "horizontal" modules
   … there will be classes and properties that we have not
   deprecated yet, but that will potentially not be implemented

   KJanowic: so horizontal can be what we offer on the side

   SimonCox: the question is whether we have one non-normative
   part, or a set of those
   … let's sort those into quite separated sets, and put them in
   different section

   <SimonCox> [42]https://github.com/w3c/sdw/blob/gh-pages/ssn/

     [42] https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sampling.ttl

   <KJanowic> [43]https://www.w3.org/2015/spatial/wiki/
   SSN_core_modules :-)

     [43] https://www.w3.org/2015/spatial/wiki/SSN_core_modules

   <KJanowic> let us not revisit the prefix / namespace idea again

   <KJanowic> we decided on option 5

   mlefranc: do we nee multiple ontologies if there are multiple
   non-normative sections in the document ?

   <SimonCox> (I started these modularization experiments back in
   July 2016, in response to Jano's horizontal/vertical proposal.)

   <KJanowic> @simoncox: yes, somehow something stopped the
   progress on this...

   ahaller2: we are not in a position where we need to have at
   least one separate ontology that contains terms that are

   RaulGarciaCastro: I'd like a separate note that says what the
   scope is the document is, and a paragraph that says what are
   the additions to the scope is

   ahaller2: that would means that we need that optional terms are
   deprecated ?

   <KJanowic> imho decoupling the document from the ontology is
   not a good idea

   <RaulGarciaCastro> agree with KJanowic

   ahaller2: the deprecated terms should not be in the new ssn
   … they can be in "horizontal modules", which are in
   non-normative parts of the document

   <mlefranc> KJanowic and RaulGarciaCastro areagainst decoupling
   the ontology and the document

   <RaulGarciaCastro> Yes

   ahaller2: terms that have normative differences should be in
   two different documents

   tidoust: the only normative things are the normative parts of
   the document
   … the ontology files are not normative according to the w3c
   … ontologies files are "examples" in a way
   … but obviously here you are writing an ontology spec, so the
   ontology file should follow the spec itself
   … but that's only my guttfeeling

   <mlefranc> (very good response francois)

   <KJanowic> do it exactly the same way as for the forecasting

   KJanowic: for all the non-normative parts, we could write just
   a note, and point to existing work that implement it, such as
   seas for the forecasting and the sampling that is done by simon

   SimonCox: the OGC policy is: the content of the code repository
   trumps what is in the document
   … the machine readable artifact are deemed to be the correct
   … so OGC's policy is different than W3C's

   ahaller2: a discussion held at TPAC about this with the
   directors, W3C doesn't accept typo corrections in rec (for now)

   SimonCox: contrast in ISO: the pdf is normative and nothing els

   <mlefranc> KJanowic and all make joke about word "trump", and I

   <mlefranc> KJanowic, we could remove the relationships in the
   sosa.ttl, but reference to the Sampling Ontologythat simon

   Action: SimonCox to include Sample relation text in WD and
   reference ontology that was proposed in Github (non-normative)

   [See [44]ACTION-299 created after the call]

     [44] https://www.w3.org/2015/spatial/track/actions/299

   <KJanowic> maximew: not remove the relationships as they are
   not in there as of now

   <SimonCox> [45]https://www.w3.org/2015/spatial/wiki/

     [45] https://www.w3.org/2015/spatial/wiki/Alignment_to_OBOE

   <KJanowic> Can we make sure that there are 2min left for
   ACTION-284 today. There is one important issue where I need
   your help

   SimonCox: in this part (more formal) the structure of the
   document is parallel to what is implemented in the ontology
   … agree that OBOE is important and well used in this domain
   … so we should keep it mentioned
   … there is a property chain axiom required here to link
   hasFeatureofInterest to oboe-core:ofEntity

   <KJanowic> if we use oboe we may republish their data using
   sosa and thus have implementation evidence

   ahaller2: so this part is part of the non-normativ part of the
   document, and implemented in a alignment document

   <mlefranc> ?

   <KJanowic> non-normative alignment like dul.

   SimonCox: the alignments are there to not constrain people to
   use them, so ok to put them in a different document

   KJanowic: data that uses OBOE may be used to populate SOSA, so
   become a implementation evidence ?

   <KJanowic> @ahaller2: can we have 2 min for action-284 before
   we close?

   Action: SimonCox to include OBOE alignment as of [46]https://
   www.w3.org/2015/spatial/wiki/Alignment_to_OBOE in the WD as a
   non-normative section similar to the DULCE alignment

     [46] https://www.w3.org/2015/spatial/wiki/Alignment_to_OBOE

   [See [47]ACTION-300 created after the call]

     [47] https://www.w3.org/2015/spatial/track/actions/300

Close ISSUE-89 as of implementation of [48]https://github.com/w3c/

     [48] https://github.com/w3c/sdw/pull/634

   <KJanowic> Will do

Progress on ACTION-284, temporal properties in both SOSA/SSN, i.e.
ssn:startTime, ssn:endTime as of ISSUE-145, stimulusTime for
Observation as of ISSUE-151 and sosa:resultTime,
ssn:observationResultTime and ssn:observationSamplingTime.

   <KJanowic> [49]https://www.w3.org/2015/spatial/wiki/

     [49] https://www.w3.org/2015/spatial/wiki/Time_in_SOSA_and_SSN

   <mlefranc> ok to merge pull request 634, but the quotes are not
   standard quoes, and please check there are no more mention of

   <KJanowic> In short everything is easy to do (see the wikipage)
   but the issue with owl2 dl and datatype versus objecttype
   properties needs some thinking

   KJanowic: some "time" properties are object properties and
   other are datatype properties, so that's not really consistend

   <SimonCox> In [50]https://github.com/w3c/sdw/blob/gh-pages/ssn/
   rdf/sosa.ttl we have sosa:resultTime rdf:type
   owl:DatatypeProperty . sosa:phenomenonTime rdf:type
   owl:ObjectProperty .

     [50] https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl

   mlefranc: if you use rdf:Property, then they become annotation
   properties, and they are not covered by OWL semantics.
   … so it's a good idea after all
   … but the ontology is not anymore OWL DL

   <ahaller2> PROPOSED: Deprecate ssn:startTime and ssn:endTime

   <KJanowic> +1

   <RaulGarciaCastro> +1

   <ahaller2> +1

   <KJanowic> can we also vote on the alignment?

   <mlefranc> +1

   <DanhLePhuoc> +1

   <SimonCox> +1

   <ahaller2> PROPOSED: ssn:observationResultTime
   rdfs:subPropertyOf sosa:resultTime.

   <KJanowic> +1

   <RaulGarciaCastro> -1

   <mlefranc> +1

   Resolved: Deprecate ssn:startTime and ssn:endTime

   <DanhLePhuoc> +1

   <ahaller2> PROPOSED: ssn:observationSamplingTime
   owl:equivalentProperty sosa:phenomenonTime

   <KJanowic> +1

   <ahaller2> +1

   <mlefranc> +1

   <RaulGarciaCastro> -1 (don’t see the need to create two

   <RaulGarciaCastro> Can’t we reuse the same property?

   <KJanowic> Will do

   <KJanowic> Raul, we can

   <RaulGarciaCastro> Good!

   <RaulGarciaCastro> bye

   <ahaller2> bye

   <mlefranc> bye

   <KJanowic> we would just need to deprecate the ssn versions

Summary of Action Items

    1. [51]maxime and KJanowic to propose implementation options
       for Option 2 on the wiki: https://www.w3.org/2015/spatial/
    2. [52]KJanowic to look into https://www.w3.org/2015/spatial/
       track/issues/153 and propose a solution
    3. [53]ahaller2 Implement changes that were made to SOSA in
       the WD document
    4. [54]maxime to send an email to the list to list
       classes/properties in SSN from the "integrated" directory
       that we have not discussed yet
    5. [55]SimonCox to include Sample relation text in WD and
       reference ontology that was proposed in Github
    6. [56]SimonCox to include OBOE alignment as of https://
       www.w3.org/2015/spatial/wiki/Alignment_to_OBOE in the WD as
       a non-normative section similar to the DULCE alignment

Summary of Resolutions

    1. [57]Approving last meeting's minutes https://www.w3.org/
    2. [58]Implement comments in issue https://www.w3.org/2015/
       spatial/track/issues/117 with isStimulatedBy replaced by
    3. [59]Deprecate ssn:startTime and ssn:endTime
Received on Wednesday, 29 March 2017 07:35:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:05 UTC