19:53:48 <RRSAgent> RRSAgent has joined #sdwssn
19:53:48 <RRSAgent> logging to http://www.w3.org/2017/03/28-sdwssn-irc
19:53:50 <trackbot> RRSAgent, make logs world
19:53:50 <Zakim> Zakim has joined #sdwssn
19:53:52 <trackbot> Zakim, this will be SDW
19:53:52 <Zakim> ok, trackbot
19:53:53 <trackbot> Meeting: Spatial Data on the Web Working Group Teleconference
19:53:53 <trackbot> Date: 28 March 2017
19:56:04 <tidoust> tidoust has joined #sdwssn
19:59:54 <ahaller2> @tidoust, do you have the host key?
20:03:02 <DanhLePhuoc> DanhLePhuoc has joined #sdwssn
20:03:24 <mlefranc> mlefranc has joined #sdwssn
20:03:47 <tidoust> RRSAgent, draft minutes v2
20:03:47 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/28-sdwssn-minutes.html tidoust
20:03:52 <mlefranc> present+ mlefranc
20:03:57 <KJanowic> KJanowic has joined #sdwssn
20:04:01 <KJanowic> present+
20:04:10 <ahaller2> present+ ahaller2
20:04:32 <DanhLePhuoc> present+ DanhLePhuoc
20:04:52 <RaulGarciaCastro> RaulGarciaCastro has joined #sdwssn
20:05:06 <RaulGarciaCastro> present+ RaulGarciaCastro
20:05:20 <tidoust> Agenda: https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170328
20:05:25 <tidoust> Chair: Armin
20:05:35 <KJanowic> I can scribe
20:05:46 <tidoust> scribe: Francois
20:05:49 <tidoust> scribenick: tidoust
20:06:00 <KJanowic> :-)
20:06:21 <ahaller2> topic: Approving last meeting's minutes https://www.w3.org/2017/03/14-sdwssn-minutes
20:06:27 <RaulGarciaCastro> +1
20:06:30 <ahaller2> +1
20:06:30 <KJanowic> +1
20:06:33 <tidoust> +1
20:06:37 <mlefranc> +1
20:06:47 <DanhLePhuoc> +1
20:07:00 <ahaller2> RESOLVED: Approving last meeting's minutes https://www.w3.org/2017/03/14-sdwssn-minutes
20:07:04 <ahaller2> topic: Patent Call https://www.w3.org/2015/spatial/wiki/Patent_Call
20:07:38 <ahaller2> topic: Progress on ACTION 282 for Forecasting
20:07:45 <mlefranc> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0254.html
20:07:52 <ahaller2> https://www.w3.org/2015/spatial/track/actions/282
20:08:33 <tidoust> ahaller2: Maxime, you posted an email about that action.
20:08:51 <tidoust> ... What we discussed is that we do not include forecasting as a first level property
20:09:07 <tidoust> ... but include a comment in the document to explain how you could do forecasting using existing properties
20:09:17 <ahaller2> https://github.com/w3c/sdw/compare/action-282-forecasting
20:09:31 <tidoust> ... Maxime prepared a commit on this.
20:09:46 <ahaller2> q?
20:10:04 <tidoust> mlefranc: It's a new section because I don't know where to put it, but otherwise it just has 2 notes.
20:10:24 <ahaller2> q?
20:10:28 <KJanowic> q+
20:10:40 <tidoust> ahaller2: Are there any comment on the text?
20:10:43 <ahaller2> ack KJanowic
20:10:59 <tidoust> KJanowic: Some wordsmithing needed, I think. Should we do it now?
20:11:28 <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/>
20:11:28 <tidoust> ahaller2: We could do that on the mailing-list or within the Pull Request if we agree on the general direction.
20:11:44 <tidoust> KJanowic: Basically tiny changes to the grammar and the terms.
20:11:56 <tidoust> ... The bigger change that I would propose is not to use the second paragraph.
20:12:01 <mlefranc> q+
20:12:40 <tidoust> ... Removing the part the note that "There are other means to represent forecasts..."
20:12:51 <ahaller2> ack mlefranc
20:13:11 <tidoust> mlefranc: No problem with changes on the grammar.
20:13:13 <SimonCox> SimonCox has joined #sdwssn
20:13:23 <ahaller2> q+
20:13:24 <tidoust> ... On the second part, I don't know, I believe it would be a different vote.
20:13:49 <KJanowic> q+
20:13:55 <SimonCox> present+
20:13:57 <ahaller2> ack ahaller
20:14:06 <tidoust> ... You did not comment on the part that talks about the fact that the spec does not mandate ways to talk about the future.
20:14:28 <tidoust> ahaller2: I think the sentence is useful as it tells users what can be done.
20:14:29 <ahaller2> ack KJanowic
20:14:39 <mlefranc> q+
20:14:55 <tidoust> KJanowic: I'm not saying it's not useful, just that it does not belong to a normative part of the document.
20:15:10 <ahaller2> q?
20:15:12 <tidoust> ... My understanding that we would e.g. reference SEAS here.
20:15:16 <ahaller2> ack mlefranc
20:15:21 <ClausStadler> ClausStadler has joined #sdwssn
20:15:48 <tidoust> 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.
20:16:00 <ahaller2> q?
20:16:29 <tidoust> 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.
20:16:59 <ahaller2> q?
20:17:00 <mlefranc> q+
20:17:05 <ahaller2> ack mlefranc
20:17:05 <tidoust> ... Put it together with the notion of observation and have the reference there to the SEAS ontology, and then remove the second part.
20:17:26 <KJanowic> q+
20:17:31 <KJanowic> and therefore I would remove it
20:18:06 <tidoust> 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.
20:18:11 <ahaller2> ack KJanowic
20:18:56 <tidoust> SimonCox: It seems relevant to have a reference to SEAS but it should be offset in some way with respect to the main document.
20:19:04 <ahaller2> q?
20:19:22 <tidoust> KJanowic: It would be odd not to reference an ontology worked upon by some participants in the group.
20:19:30 <ahaller2> q?
20:19:34 <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
20:19:44 <KJanowic> ontology --> SEAS ontology
20:20:00 <tidoust> mlefranc: I can provide a new commit based on this discussion. I believe I understand where people are heading here.
20:20:07 <ahaller2> topic: Progress on ACTION-283 to propose properties to replace dul:includesEvent property as of ISSUE-117
20:20:20 <ahaller2> https://www.w3.org/2015/spatial/track/actions/283
20:20:29 <RaulGarciaCastro> https://www.w3.org/2015/spatial/track/issues/117
20:20:38 <ahaller2> q?
20:20:58 <tidoust> RaulGarciaCastro: I sent an email to the mailing-list. In the link I just posted, you can see the proposed resolution.
20:21:38 <tidoust> ... The dul:includesEvent property disappeared. The proposal is to add a restriction as it was before for the new property.
20:21:59 <mlefranc> +1 for that proposal. What would be the definition ?
20:22:01 <ahaller2> q?
20:22:24 <KJanowic> Sorry, where do I find the exact proposal?
20:22:43 <ahaller2> @KJanowic in the comments of the action
20:22:51 <ahaller2> @KJanowic in the comments of the issue
20:23:11 <tidoust> ... Relation between a property and a stimulus. For me, the constraint is restrictive.
20:23:13 <mlefranc> q+
20:23:22 <RaulGarciaCastro> https://www.w3.org/2015/spatial/track/issues/117
20:23:57 <ahaller2> ack mlefranc
20:24:24 <ahaller2> +1 from me btw
20:24:37 <KJanowic> looks good to me!
20:24:52 <tidoust> ... Proposal: New property in SSN "isStimulatedBy" and a restriction that is the same as the one that existed before for the "includesEvent" property.
20:25:20 <tidoust> mlefranc: No problem with the proposal. Maybe in the definition, the term "link" is more used than "relation".
20:25:41 <ahaller2> q+
20:25:46 <ahaller2> ack ahaller
20:26:14 <RaulGarciaCastro> q+
20:26:27 <tidoust> 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.
20:26:41 <tidoust> ... We need to have someone go through all the comments in the end.
20:26:43 <KJanowic> Yes, but this is a task for editors
20:26:53 <tidoust> ... Whatever we use should be consistent with the rest of the comments.
20:26:56 <ahaller2> q?
20:26:57 <RaulGarciaCastro> q-
20:27:18 <KJanowic> yes on relation instead of link
20:27:26 <tidoust> ... Any comment? What about the restriction?
20:28:14 <KJanowic> q+
20:28:19 <ahaller2> ack KJanowic
20:29:30 <RaulGarciaCastro> OK
20:29:31 <tidoust> KJanowic: My only concern is wordsmithing. The current name "isStimulatedBy". What is stimulated by a stimulus is the sensor, not the observation.
20:29:46 <ahaller2> q?
20:29:50 <KJanowic> the stimulus stimulates the sensor and this triggers the observation
20:29:51 <RaulGarciaCastro> q+
20:29:51 <tidoust> RaulGarciaCastro: Can we change it to "isTriggeredBy"?
20:30:01 <mlefranc> ok
20:30:04 <KJanowic> so the observation is caused by or triggered by the stimulus
20:30:36 <KJanowic> q+
20:30:41 <RaulGarciaCastro> q-
20:30:45 <DanhLePhuoc> +q
20:30:45 <ahaller2> ack KJanowic
20:30:49 <tidoust> ahaller2: The only concern I would have is that this seems to mandate a "trigger" somewhere.
20:31:03 <tidoust> KJanowic: Nothing prevents us from using includesEvent in theory.
20:31:10 <ahaller2> q?
20:31:11 <KJanowic> ssn:includesEvent
20:31:13 <ahaller2> ack DanhLePhuoc
20:31:40 <tidoust> DanhLePhuoc: isTriggeredBy could be linked to actuation. That could confuse people.
20:31:42 <KJanowic> trigger was just a proposal, I am fine with other names as well
20:31:54 <tidoust> ahaller2: Right, my opinion as well. Trigger feels more active.
20:32:01 <ahaller2> q?
20:32:09 <ahaller2> q+
20:32:13 <ahaller2> ack ahaller
20:32:13 <DanhLePhuoc> +1 ssn:includesEvent
20:32:16 <KJanowic> so what about ssn:includesEvent
20:32:23 <KJanowic> we likes the name before
20:32:30 <RaulGarciaCastro> +1 ssn:isStimulatedBy
20:32:36 <RaulGarciaCastro> q+
20:32:36 <tidoust> ahaller2: I personally think isStimulatedBy is better than includesEvent but I'm ok with both.
20:32:38 <KJanowic> and ssn:includesEvent will be a subpropertyof dul:includesEvent
20:32:45 <mlefranc> q+
20:32:52 <KJanowic> +1 for ssn:includesEvent
20:32:53 <ahaller2> ack RaulGarciaCastro
20:33:08 <ahaller2> ack mlefranc
20:33:12 <KJanowic> q+
20:33:15 <tidoust> RaulGarciaCastro: The problem I see with includesEvent is that without the context of dul, it does not make much sense.
20:33:52 <RaulGarciaCastro> What about isOriginatedBy?
20:33:56 <tidoust> 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.
20:34:08 <tidoust> ... So "wasStimulatedBy", perhaps?
20:34:19 <ahaller2> q?
20:34:24 <ahaller2> ack KJanowic
20:34:24 <KJanowic> the stimulus (as an activity) has to stimulate an entity, namely the sensor (not another activity). see the rest of SSO and SSN
20:34:55 <RaulGarciaCastro> So it can be said that the stimulus originates the observation?
20:35:13 <tidoust> KJanowic: We need to get rid of this stimulus. I like the originate idea.
20:35:15 <KJanowic> +1 to raul's
20:35:24 <ahaller2> wasOriginatedBy
20:35:27 <KJanowic> +1
20:35:30 <tidoust> ahaller2: Then "wasOriginatedBy"?
20:35:44 <mlefranc> +1 wasOriginatedBy
20:35:47 <SimonCox> +1
20:35:51 <RaulGarciaCastro> +1 (but see no problem in isOriginatedBy
20:35:55 <DanhLePhuoc> +1
20:36:17 <KJanowic> I would be in favor of isOriginatedBy for sake of conistency but fine with 'was' as well
20:36:35 <RaulGarciaCastro> I also prefer “is” for consistency
20:36:41 <ahaller2> RESOLVED: Implement comments in issue https://www.w3.org/2015/spatial/track/issues/117 with isStimulatedBy replaced by wasOriginatedBy
20:36:46 <RaulGarciaCastro> If not, we should review all property names
20:37:07 <ahaller2> q?
20:37:15 <tidoust> ahaller2: Raul, can you work on a PR for this?
20:37:16 <tidoust> RaulGarciaCastro: Yes.
20:37:37 <tidoust> ... Another question about the dul alignment. [scribe missed question]
20:37:59 <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
20:38:00 <tidoust> ahaller2: There are two files (.ttl, and .owl)
20:38:03 <mlefranc> q+
20:38:09 <ahaller2> ack mlefranc
20:38:19 <tidoust> ... I think there are the same, but it would be useful to check
20:38:51 <tidoust> mlefranc: We should serve the right file based on what the client asks.
20:39:11 <ahaller2> q?
20:39:12 <tidoust> ahaller2: Fine but I'm not sure changes made to the Turtle file were reflected in the OWL file.
20:40:23 <KJanowic> Yes, only one file!
20:40:30 <KJanowic> and yes, let us use the ttl file
20:40:35 <tidoust> ... My problem is that changes need to be made to 2 files. I think it would be better to have only one file.
20:40:49 <RaulGarciaCastro> q+
20:40:50 <mlefranc> +1 agree with keeping in the ttl
20:40:52 <tidoust> ... I'm proposing that we only skip the Turtle file for the time being.
20:41:13 <tidoust> ... Can you do that, Raul, when you implement your changes?
20:41:28 <tidoust> RaulGarciaCastro: Yes, but should I also change the dul alignment OWL file?
20:41:40 <tidoust> ahaller2: Yes, but please make that a Turtle file as well.
20:42:02 <ahaller2> q?
20:42:03 <tidoust> RaulGarciaCastro: OK.
20:42:06 <ahaller2> ack RaulGarciaCastro
20:42:18 <ahaller2> topic: Progress on ACTION-279 to add a change history to SSN document
20:42:48 <tidoust> ahaller2: I think you issued a new PR while I was sleeping, Danh.
20:42:49 <ahaller2> https://github.com/w3c/sdw/pull/633
20:43:02 <ahaller2> q?
20:43:23 <KJanowic> [there is somebody speaking in the background]
20:44:21 <DanhLePhuoc> https://github.com/w3c/sdw/pull/643
20:44:23 <ahaller2> https://github.com/w3c/sdw/pull/643
20:44:30 <tidoust> DanhLePhuoc: Two PR. I made a revised one based on comments today.
20:45:06 <tidoust> ... I checked the PR we did since January and now there should be everything.
20:45:14 <tidoust> ahaller2: Any quick comment?
20:45:15 <ahaller2> q?
20:45:40 <tidoust> [none heard]
20:45:49 <ahaller2> topic: SSN Measurement and Operating properties for actuators https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators
20:46:28 <tidoust> mlefranc: I sent a couple of emails too.
20:46:47 <tidoust> ... The most important mail is about measurement properties.
20:46:57 <ahaller2> q?
20:47:37 <tidoust> ... Currently there is one way to link a sensor to its measurement property, using hasMeasurementCapability and then from MeasurementCapability through the measurement property.
20:48:09 <KJanowic> q+
20:48:26 <tidoust> ... 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.
20:49:07 <tidoust> ... One option would be to duplicate things for actuators "hasActuationProperty" perhaps. But I don't know how to change the name MeasurementProperty.
20:49:25 <ahaller2> Q?
20:49:29 <ahaller2> ack KJanowic
20:49:32 <tidoust> ... Option 3 is to deprecate all of this, and make sure SSN does not talk about measurement properties.
20:49:51 <tidoust> KJanowic: Thanks for spotting this. I'm more optimistic. Option 2 is not too much work.
20:49:58 <tidoust> ... We have done bigger changes.
20:49:58 <ahaller2> q+
20:50:42 <mlefranc> q+
20:50:51 <RaulGarciaCastro> q+
20:50:52 <ahaller2> ack ahaller
20:51:03 <tidoust> ... 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.
20:51:43 <ahaller2> q?
20:51:43 <tidoust> 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.
20:51:46 <ahaller2> ack mlefranc
20:52:07 <KJanowic> I can help maxime to find names etc for next week
20:52:13 <KJanowic> q+
20:52:24 <tidoust> mlefranc: I volunteer in being part of the team that proposes something. Maybe we could use systems properties.
20:52:51 <ahaller2> q?
20:52:57 <ahaller2> ack RaulGarciaCastro
20:53:25 <DanhLePhuoc_> DanhLePhuoc_ has joined #sdwssn
20:53:32 <KJanowic> if we decide on this now, it will freak certain people out. Let us have a proposal on the table and vote next week.
20:53:35 <tidoust> RaulGarciaCastro: I was about to propose the same thing. Capabilities are related to the device in the end, or to the system.
20:53:44 <ahaller2> q?
20:53:47 <ahaller2> ack KJanowic
20:54:31 <tidoust> 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.
20:55:03 <ahaller2> ACTION: maxime and KJanowic to propose implementation options for Option 2 on the wiki: https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators
20:55:05 <trackbot> Created ACTION-295 - And kjanowic to propose implementation options for option 2 on the wiki: https://www.w3.org/2015/spatial/wiki/measurement_and_operating_properties_for_actuators [on Maxime Lefrançois - due 2017-04-04].
20:55:34 <KJanowic> Maxime can draft and I can review
20:55:36 <tidoust> ahaller2: If you both can work on a Wiki page, that would be great!
20:55:36 <ahaller2> q?
20:55:46 <ahaller2> topic: Proposal for ssn:Device (Deprecate?) as of ISSUE-153
20:55:47 <mlefranc> ok jano
20:56:09 <ahaller2> https://www.w3.org/2015/spatial/track/issues/153
20:57:06 <tidoust> ahaller2: We have a device class in SSN which is pretty much unused at the moment. Do we actually need this class?
20:57:15 <ahaller2> q?
20:57:17 <RaulGarciaCastro> q+
20:57:19 <KJanowic> delete
20:57:21 <ahaller2> ack RaulGarciaCastro
20:57:49 <tidoust> RaulGarciaCastro: The device class is frequently used. Now, devices and systems are sufficiently different for us to consider them differently.
20:57:56 <ahaller2> q?
20:57:56 <DanhLePhuoc> +q
20:57:58 <KJanowic> q+
20:58:06 <ahaller2> ack DanhLePhuoc
20:58:44 <RaulGarciaCastro> q+ to say that if we think about alignment with other initiatives (WoT, oneM2M, etc.) the link usually is through Device
20:58:48 <mlefranc> q+
20:58:51 <tidoust> DanhLePhuoc: I know several EU projects that have been using or extending SSN, with subclasses of device.
20:59:04 <tidoust> ... I think we should not remove it.
20:59:08 <ahaller2> ack KJanowic
20:59:39 <tidoust> KJanowic: We could just deprecate the term, and discourage its usage.
21:00:04 <mlefranc> q+
21:00:13 <KJanowic> just 'discourage' the usage of device as a weaker version of 'deprecating'
21:00:18 <ahaller2> ack RaulGarciaCastro
21:00:18 <Zakim> RaulGarciaCastro, you wanted to say that if we think about alignment with other initiatives (WoT, oneM2M, etc.) the link usually is through Device
21:00:21 <mlefranc> q-, just ok with jano and danh about using owl:DeprecatedClass
21:00:22 <tidoust> ahaller2: Is there some ontology that has a term for that? skos, perhaps?
21:00:41 <mlefranc> ok with jano and danh about using owl:DeprecatedClass
21:00:42 <KJanowic> q+
21:01:08 <tidoust> 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.
21:01:30 <tidoust> ahaller2: Sensor and Actuators can be attached to Platform, which makes them Devices in the dul sense.
21:02:00 <ahaller2> q?
21:02:02 <ahaller2> ack mlefranc
21:02:04 <KJanowic> we can pick an axiomatic solution by subclassing
21:02:40 <tidoust> mlefranc: I would be ok to deprecate Device. Just make sure that the old usage of ssn:Device remains compatible with ssn:System.
21:02:42 <ahaller2> ack KJanowic
21:03:04 <mlefranc> ok
21:03:21 <tidoust> KJanowic: My favorite solution would be to deprecate the class. If people ignore what we propose, then it's still ok.
21:03:33 <ahaller2> q?
21:03:45 <KJanowic> device subclassof new:platform and then phase out the usage of device.
21:03:47 <tidoust> ahaller2: Any volunteer to look into it until our next meeting?
21:03:54 <KJanowic> I can lookm into this
21:04:02 <KJanowic> s/lookm/look
21:04:35 <ahaller2> ACTION: KJanowic to look into https://www.w3.org/2015/spatial/track/issues/153 and propose a solution
21:04:35 <trackbot> Created ACTION-296 - Look into https://www.w3.org/2015/spatial/track/issues/153 and propose a solution [on Krzysztof Janowicz - due 2017-04-04].
21:04:56 <ahaller2> q?
21:05:05 <ahaller2> topic: Discussion of RecTrack requirements, i.e. last working draft, 17-04-17
21:05:25 <mlefranc> I can start
21:05:35 <tidoust> ahaller2: I had an exchange with Phil about timeline.
21:06:00 <tidoust> ... We need a last call working draft by 17 April.
21:06:14 <KJanowic> q+
21:06:23 <tidoust> ... No more substantive changes to make on the document.
21:06:25 <tidoust> ... Then 4 weeks time for people to make comments
21:06:43 <mlefranc> q+
21:06:48 <tidoust> ... Then we can go to the Director to ask for transition as Candidate Recommendation.
21:07:14 <tidoust> ... Timeline is pretty tight.
21:07:21 <tidoust> ... Many issues are still open.
21:07:40 <ahaller2> q?
21:07:51 <tidoust> ... We made changes to ontologies but still need to make changes to the document.
21:07:52 <ahaller2> ack KJanowic
21:08:00 <tidoust> ... What would the availability of people be in the next 3 weeks?
21:08:34 <tidoust> 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!
21:08:49 <tidoust> ... I can help on the implementation evidence.
21:09:05 <tidoust> ... If we do crazy things such as renaming sosa and so on, I'm more worried.
21:09:11 <tidoust> ... But otherwise, I'm happy to support.
21:09:34 <tidoust> [Note description of the timeline in email I posted on the mailing-list: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0231.html ]
21:09:41 <ahaller2> q?
21:09:44 <ahaller2> ack mlefranc
21:10:23 <tidoust> mlefranc: I would like to be as optimistic as KJanowic. Just in case, what happens if we just end up with a note?
21:10:25 <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.
21:10:52 <tidoust> ... Also question on implementations.
21:10:56 <KJanowic> q+
21:11:13 <tidoust> ... [missed, audio was chopped]
21:11:19 <DanhLePhuoc> +q
21:11:24 <tidoust> ahaller2: If we end up with a Note, we have more time.
21:11:45 <tidoust> ... In terms of implementation, it is really up to the Director to interpret that.
21:11:52 <tidoust> ... It would be nice to have data.
21:11:53 <ahaller2> q?
21:11:56 <ahaller2> ack KJanowic
21:12:02 <tidoust> q+
21:12:21 <RaulGarciaCastro> agree
21:12:24 <ahaller2> ack DanhLePhuoc
21:12:25 <tidoust> KJanowic: I understand the Note would be a fallback solution. Let's aim for a Rec!
21:12:43 <KJanowic> no backup plans, let us be optimistic! we have a strong team, we can pull this off
21:13:15 <KJanowic> Great!
21:13:24 <tidoust> DanhLePhuoc: What we need for the Rec track is implementation. KJanowic already has one. I can offer another one.
21:13:28 <mlefranc> can I take over scribing ? tidous ask so 15min ago
21:13:43 <tidoust> scribe: mlefranc
21:14:18 <KJanowic> we have until 05/30 for the implementations
21:14:29 <mlefranc> ahaller2: implementation is after closing all the issues and be ok with the document
21:14:30 <KJanowic> we can close all issues by having a qucik vote on all of them
21:14:31 <KJanowic> q+
21:14:36 <ahaller2> ack tidoust
21:14:38 <mlefranc> ... ok to help to implement things also
21:14:56 <mlefranc> tidoust: implementation: the Director will decide
21:15:19 <mlefranc> ... what we require is the rec to be explicit about conformance criteria for the implementations
21:15:36 <mlefranc> ... before the candidate recommendation phase
21:15:53 <KJanowic> q+
21:16:35 <mlefranc> ... I don't know if ontologies that extend ssn, datasets that use terms, or tools that use terms are considered as implementations,
21:16:48 <mlefranc> ... but we need each and every term to be used somewhere
21:17:35 <mlefranc> ... the mail I sent describes all that the document needs to explicit before each transition to the next step
21:17:43 <ahaller2> q?
21:17:47 <ahaller2> ack KJanowic
21:18:22 <mlefranc> 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.
21:18:23 <RaulGarciaCastro> That’s it: “won’t fix” is also an alternative
21:18:51 <mlefranc> ... if no one complains with issues, one may just close them
21:19:14 <mlefranc> ahaller2: some of these issues can be closed because they are not "in scope"
21:19:31 <mlefranc> ... we need a longer meeting where we go though the issues
21:19:43 <mlefranc> ... I'll propose this in the following weeks
21:19:57 <ahaller2> q?
21:20:10 <mlefranc> ... if we don't have implementation evidence for a class or property, then we can just push that in a note
21:20:39 <mlefranc> tidoust: you can identify features that are "at risk" before candidate recommendations. these are the ones that you may "drop"
21:20:54 <ahaller2> q?
21:21:13 <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
21:22:19 <ahaller2> ACTION: ahaller2 Implement changes that were made to SOSA in the WD document
21:22:19 <trackbot> Created ACTION-297 - Implement changes that were made to sosa in the wd document [on Armin Haller - due 2017-04-04].
21:22:21 <mlefranc> 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
21:22:57 <mlefranc> ahaller2: changes in ssn need to be postponned to next week
21:24:50 <mlefranc> maxime there is the "integrated" directory, please send a mail about what remains to be discussed before candidate rec
21:25:51 <ahaller2> 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
21:25:52 <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 2017-04-04].
21:25:55 <ahaller2> q?
21:26:07 <ahaller2> topic: Progress on ACTION-286 for Sampling and decision on OBOE alignment
21:26:20 <ahaller2> https://www.w3.org/2015/spatial/track/actions/286
21:27:01 <SimonCox> https://www.w3.org/2015/spatial/wiki/Sampling
21:27:12 <SimonCox> https://www.w3.org/2015/spatial/wiki/Alignment_to_OBOE
21:27:14 <mlefranc> SimonCox: everything I proposed is already in position to be discussed here
21:27:31 <mlefranc> ... the sampling part and the alignment to oboe
21:27:51 <mlefranc> ... for samping, the upper part of the wiki page has been added to sosa,
21:28:49 <mlefranc> ... <sorry, speak too fast>
21:29:43 <ahaller2> q?
21:30:02 <mlefranc> ok to accept simon's proposal
21:30:09 <KJanowic> same here
21:30:12 <mlefranc> ahaller2: the pull request has been made
21:30:20 <mlefranc> ... need implementation evidence now,
21:30:28 <KJanowic> q+
21:30:30 <mlefranc> ... and maybe accept the lower part of the wiki page
21:30:54 <mlefranc> SimonCox: or just fallback to saying that there are "horizontal modules"
21:30:58 <ahaller2> ack KJanowic
21:31:04 <mlefranc> ahaller2: they could be in non normative parts
21:31:37 <mlefranc> KJanowic: sampling/sampler/sample we agreed
21:31:51 <mlefranc> ... for the properties, let's put them in the non normative parts
21:32:00 <mlefranc> ... for the classes, I have evidence of implementations
21:32:01 <KJanowic>  http://host.geolink.org/ngdb/id/geosample/AAM055A
21:32:58 <ahaller2> q?
21:32:59 <mlefranc> ... I would have loved to have horizontal modules
21:33:31 <KJanowic> q+
21:33:38 <mlefranc> ahaller2: if we put it in non-normative parts of ssn, what would the document look like ?
21:34:08 <mlefranc> ... the document will look like having non-normative sections that talk about "horizontal" modules
21:34:36 <ahaller2> q?
21:34:39 <ahaller2> ack KJanowic
21:34:43 <mlefranc> ... there will be classes and properties that we have not deprecated yet, but that will potentially not be implemented
21:35:02 <SimonCox> q+
21:35:06 <ahaller2> ack SimonCox
21:35:07 <mlefranc> KJanowic: so horizontal can be what we offer on the side
21:35:32 <mlefranc> SimonCox: the question is whether we have one non-normative part, or a set of those
21:36:05 <SimonCox> https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sampling.ttl
21:36:10 <mlefranc> ... let's sort those into quite separated sets, and put them in different section
21:36:15 <mlefranc> q+
21:36:20 <ahaller2> ack mlefranc
21:36:59 <KJanowic> https://www.w3.org/2015/spatial/wiki/SSN_core_modules :-)
21:37:32 <KJanowic> let us not revisit the prefix / namespace idea again
21:37:38 <KJanowic> we decided on option 5
21:37:48 <mlefranc> mlefranc: do we nee multiple ontologies if there are multiple non-normative sections in the document ?
21:37:51 <SimonCox> (I started these modularization experiments back in July 2016, in response to Jano's horizontal/vertical proposal.)
21:37:57 <RaulGarciaCastro> q+
21:38:19 <ahaller2> ack RaulGarciaCastro
21:38:26 <KJanowic> @simoncox: yes, somehow something stopped the progress on this...
21:38:32 <mlefranc> ahaller2: we are not in a position where we need to have at least one separate ontology that contains terms that are "non-normative"
21:39:23 <mlefranc> 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
21:39:28 <mlefranc> q+
21:39:45 <ahaller2> ack mlefranc
21:39:47 <mlefranc> ahaller2: that would means that we need that optional terms are deprecated ?
21:41:18 <KJanowic> imho decoupling the document from the ontology is not a good idea
21:41:30 <RaulGarciaCastro> agree with KJanowic
21:41:35 <mlefranc> ahaller2: the deprecated terms should not be in the new ssn file
21:41:53 <mlefranc> ... they can be in "horizontal modules", which are in non-normative parts of the document
21:42:17 <mlefranc> KJanowic and RaulGarciaCastro areagainst decoupling the ontology and the document
21:42:26 <mlefranc> q+
21:42:31 <ahaller2> ack mlefranc
21:42:52 <KJanowic> q+
21:43:05 <RaulGarciaCastro> Yes
21:43:14 <RaulGarciaCastro> q+
21:43:26 <RaulGarciaCastro> q-
21:43:44 <mlefranc> ahaller2: terms that have normative differences should be in two different documents
21:44:25 <mlefranc> tidoust: the only normative things are the normative parts of the document
21:44:42 <SimonCox> q+
21:44:43 <mlefranc> ... the ontology files are not normative according to the w3c standards
21:44:53 <mlefranc> ... ontologies files are "examples" in a way
21:45:35 <mlefranc> ... but obviously here you are writing an ontology spec, so the ontology file should follow the spec itself
21:45:38 <ahaller2> ack KJanowic
21:45:43 <mlefranc> ... but that's only my guttfeeling
21:45:49 <mlefranc> (very good response francois)
21:46:50 <KJanowic> do it exactly the same way as for the forecasting
21:46:53 <ahaller2> q?
21:46:56 <mlefranc> 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
21:46:57 <ahaller2> Ack SimonCox
21:47:24 <KJanowic> q+
21:47:48 <mlefranc> SimonCox: the OGC policy is: the content of the code repository trumps what is in the document
21:48:06 <mlefranc> ... the machine readable artifact are deemed to be the correct ones
21:48:21 <mlefranc> ... so OGC's policy is different than W3C's
21:49:06 <ahaller2> q?
21:49:09 <ahaller2> ack KJanowic
21:49:31 <mlefranc> ahaller2: a discussion held at TPAC about this with the directors, W3C doesn't accept typo corrections in rec (for now)
21:49:34 <KJanowic> q+
21:49:45 <ahaller2> ack KJanowic
21:49:51 <mlefranc> SimonCox: contrast in ISO: the pdf is normative and nothing els
21:50:12 <mlefranc> KJanowic and all make joke about word "trump", and I agree
21:52:33 <mlefranc> KJanowic, we could remove the relationships in the sosa.ttl, but reference to the Sampling Ontologythat simon developed
21:52:53 <ahaller2> ACTION: SimonCox to include Sample relation text in WD and reference ontology that was proposed in Github (non-normative)
21:52:53 <trackbot> Error finding 'SimonCox'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
21:52:59 <KJanowic> maximew: not remove the relationships as they are not in there as of now
21:53:04 <ahaller2> q?
21:53:14 <SimonCox> https://www.w3.org/2015/spatial/wiki/Alignment_to_OBOE
21:53:45 <KJanowic> Can we make sure that there are 2min left for ACTION-284 today. There is one important issue where I need your help
21:54:00 <mlefranc> SimonCox: in this part (more formal) the structure of the document is parallel to what is implemented in the ontology
21:54:34 <mlefranc> ... agree that OBOE is important and well used in this domain
21:54:42 <mlefranc> ... so we should keep it mentioned
21:54:44 <KJanowic> if we use oboe we may republish their data using sosa and thus have implementation evidence
21:55:28 <KJanowic> q+
21:55:34 <mlefranc> ... there is a property chain axiom required here to link hasFeatureofInterest to oboe-core:ofEntity
21:56:05 <mlefranc> ahaller2: so this part is part of the non-normativ part of the document, and implemented in a alignment document
21:56:06 <mlefranc> ?
21:56:06 <KJanowic> non-normative alignment like dul.
21:56:40 <mlefranc> SimonCox: the alignments are there to not constrain people to use them, so ok to put them in a different document
21:56:44 <ahaller2> ack KJanowic
21:57:17 <mlefranc> KJanowic: data that uses OBOE may be used to populate SOSA, so become a implementation evidence ?
21:57:33 <ahaller2> q?
21:58:12 <KJanowic> @ahaller2: can we have 2 min for action-284 before we close?
21:58:26 <ahaller2> ACTION: 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
21:58:26 <trackbot> Error finding 'SimonCox'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
21:58:40 <ahaller2> topic: Close ISSUE-89 as of implementation of https://github.com/w3c/sdw/pull/634
21:59:04 <KJanowic> Will do
21:59:14 <ahaller2> topic: 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.
21:59:16 <KJanowic> q+
21:59:21 <KJanowic> https://www.w3.org/2015/spatial/wiki/Time_in_SOSA_and_SSN
21:59:21 <ahaller2> ack KJanowic
22:00:50 <mlefranc> ok to merge pull request 634, but the quotes are not standard quoes, and please check there are no more mention of process
22:00:51 <mlefranc> q+
22:01:44 <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
22:01:50 <mlefranc> KJanowic: some "time" properties are object properties and other are datatype properties, so that's not really consistend
22:02:18 <ahaller2> q?
22:02:23 <ahaller2> ack mlefranc
22:02:41 <ahaller2> zakim, close queue
22:02:41 <Zakim> ok, ahaller2, the speaker queue is closed
22:03:00 <SimonCox> In 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 .
22:03:43 <mlefranc> mlefranc: if you use rdf:Property, then they become annotation  properties, and they are not covered by OWL semantics.
22:03:45 <ahaller2> PROPOSED: Deprecate ssn:startTime and ssn:endTime
22:03:47 <KJanowic> +1
22:03:48 <RaulGarciaCastro> +1
22:03:50 <ahaller2> +1
22:03:56 <mlefranc> ... so it's a good idea after all
22:03:56 <KJanowic> can we also vote on the alignment?
22:03:58 <mlefranc> +1
22:04:06 <DanhLePhuoc> +1
22:04:07 <SimonCox> +1
22:04:26 <mlefranc> ... but the ontology is not anymore OWL DL
22:04:33 <ahaller2> PROPOSED:  ssn:observationResultTime rdfs:subPropertyOf sosa:resultTime.
22:04:37 <KJanowic> +1
22:04:43 <RaulGarciaCastro> -1
22:04:44 <mlefranc> +1
22:04:50 <RaulGarciaCastro> q+
22:04:52 <ahaller2> RESOLVED: Deprecate ssn:startTime and ssn:endTime
22:04:54 <DanhLePhuoc> +1
22:05:05 <ahaller2> PROPOSED: ssn:observationSamplingTime owl:equivalentProperty sosa:phenomenonTime
22:05:08 <KJanowic> +1
22:05:14 <ahaller2> +1
22:05:18 <mlefranc> +1
22:05:22 <RaulGarciaCastro> -1 (don’t see the need to create two properties)
22:05:46 <RaulGarciaCastro> Can’t we reuse the same property?
22:05:47 <KJanowic> Will do
22:05:52 <KJanowic> Raul, we can
22:05:57 <RaulGarciaCastro> Good!
22:06:22 <RaulGarciaCastro> bye
22:06:23 <ahaller2> bye
22:06:27 <mlefranc> bye
22:06:32 <KJanowic> we would just need to deprecate the ssn versions first
22:06:34 <tidoust> RRSAGent, draft minutes v2
22:06:34 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/28-sdwssn-minutes.html tidoust
22:06:39 <KJanowic> bye bye
22:07:00 <ahaller2> bye