20:48:47 <RRSAgent> RRSAgent has joined #sdwssn
20:48:47 <RRSAgent> logging to http://www.w3.org/2017/03/07-sdwssn-irc
20:48:49 <trackbot> RRSAgent, make logs world
20:48:49 <Zakim> Zakim has joined #sdwssn
20:48:51 <trackbot> Zakim, this will be SDW
20:48:51 <Zakim> ok, trackbot
20:48:52 <trackbot> Meeting: Spatial Data on the Web Working Group Teleconference
20:48:52 <trackbot> Date: 07 March 2017
20:50:02 <ahaller2> present+ ahaller2
20:51:04 <roba> roba has joined #sdwssn
20:56:29 <tidoust> tidoust has joined #sdwssn
20:57:45 <ahaller2> tidoust: I don't have the host key, do you?
20:59:13 <roba> present+
20:59:21 <SimonCox> SimonCox has joined #sdwssn
21:00:19 <mlefranc> mlefranc has joined #sdwssn
21:00:36 <KJanowic> KJanowic has joined #sdwssn
21:00:52 <tidoust> RRSAgent, draft minutes v2
21:00:52 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/07-sdwssn-minutes.html tidoust
21:00:57 <mlefranc> present+ mlefranc
21:01:20 <tidoust> present+ Francois
21:01:47 <tidoust> Chair: Armin
21:02:12 <kerry> kerry has joined #sdwssn
21:02:12 <tidoust> Scribe: Francois
21:02:14 <ahaller2> scribe tidoust
21:02:15 <tidoust> scribenick: tidoust
21:02:21 <KJanowic> present+
21:02:29 <tidoust> Agenda: https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170307
21:02:37 <kerry> present+
21:04:07 <DanhLePhuoc> DanhLePhuoc has joined #sdwssn
21:04:21 <ahaller2> topic: Approving last meeting's minutes https://www.w3.org/2017/02/21-sdwssn-minutes
21:04:28 <kerry> +1
21:04:30 <mlefranc> +1
21:04:32 <tidoust> +1
21:04:34 <KJanowic> +1
21:04:41 <DanhLePhuoc> +1
21:04:48 <SimonCox> present+ SimonCox
21:04:49 <SimonCox> +1
21:04:50 <roba> +1
21:04:56 <ahaller2> topic: patent call https://www.w3.org/2015/spatial/wiki/Patent_Call
21:04:57 <DanhLePhuoc> present+ DanhLePhuoc
21:05:18 <tidoust> Armin goes through the OGC patent call
21:05:27 <ahaller2> topic: Implementation of Platform resolution https://www.w3.org/2015/spatial/track/actions/275 and close of issue https://www.w3.org/2015/spatial/track/issues/88
21:05:52 <tidoust> Armin: Our implementation of our resolutions around Platform we took during last meeting.
21:05:57 <tidoust> ... Maxime, any problem?
21:06:20 <tidoust> Maxime: I think there is no problem to discuss here. I did the job for Platform, discussed with Kerry, and merged it a few hours ago.
21:06:34 <tidoust> ... Next step is to discuss Device and SensorDevice to understand what they should become now.
21:06:44 <tidoust> ... There was no change at all for SOSA.
21:06:50 <kerry> q+
21:06:57 <ahaller2> q?
21:06:58 <tidoust> Armin: We did change the description for the Platform class for alignment.
21:06:59 <SefkiKolozali> SefkiKolozali has joined #sdwssn
21:07:00 <ahaller2> ack kerry
21:07:17 <tidoust> Kerry: There are a few things that I think need to be catered for before we close the issue.
21:07:18 <SefkiKolozali> present+
21:07:26 <tidoust> ... Some comments need to be integrated.
21:07:38 <mlefranc> mlefranc+
21:07:43 <mlefranc> q+
21:07:47 <tidoust> ... Also, Maxime raised the problem of Device and SensorDevice, that's intrisically related.
21:08:04 <tidoust> ... For all of these things, the documentation of the spec needs to be updated.
21:08:55 <mlefranc> q-
21:08:57 <tidoust> ... One general question: in our document of changes, we have "changes since first version of SSN", also "changes since the course of our work". Obviously some of the changes such the one we just made are changes to both.
21:09:12 <tidoust> ... What's the best practice to reflect them?
21:09:54 <tidoust> ... It's about the end of the document, sections where we report changes.
21:10:15 <tidoust> ... Do we just write changes twice? I feel uncomfortable about that.
21:10:33 <tidoust> Armin: Currently, we haven't made changes to the document, only the ontology files.
21:10:53 <tidoust> Kerry: Well, I would argue that we are making substantive changes and that should be reflected.
21:11:07 <tidoust> Armin: Yes, I agree.
21:11:13 <KJanowic> I can do so for the SOSA part
21:11:47 <KJanowic> q+
21:12:13 <tidoust> Kerry: We have two changes to report, a) changes since the previous SSN, b) changes since we started this work and published an update.
21:12:39 <KJanowic> q?
21:13:05 <KJanowic> Agreed
21:13:21 <ahaller2> ACTION: KJanowic to make updates to SOSA in WD according to our resolutions in the last couple of weeks
21:13:22 <trackbot> Created ACTION-278 - Make updates to sosa in wd according to our resolutions in the last couple of weeks [on Krzysztof Janowicz - due 2017-03-14].
21:13:55 <KJanowic> q+
21:14:49 <KJanowic> Yes to closing issue-88
21:14:49 <ahaller2> ack KJanowic
21:15:09 <tidoust> Francois: Just put changes where you feel it makes the more sense. The process does not "require" anything too concrete here. Don't let it block you.
21:15:30 <kerry> -1 to closing the issue
21:15:32 <KJanowic> +1 to closing issue-88
21:15:33 <tidoust> Kerry: OK, I'll take that as advice to put the changes in the list of changes done to the document since 2005.
21:15:46 <KJanowic> q+
21:16:09 <KJanowic> I disagree
21:16:16 <ahaller2> ack KJanowic
21:16:20 <tidoust> ... I'm happy to move on and discuss on the mailing-list, just not happy with closing the issue right now.
21:17:24 <mlefranc> that can be a new issue what kerry just said
21:17:27 <tidoust> KJanowic: Just to be clear, issue-88 started as a way to align Platform. We discussed that at length and implemented changes. Let's close issue-88 now, and create new issues as needed. People like me do not see what else needs to be done for that issue.
21:17:56 <tidoust> Armin: I would like to give an action to someone to update the SSN document. Perhaps Danh?
21:18:04 <kerry> q+
21:18:07 <ahaller2> ACTION: Danh to make updates to SSN in WD according to our resolutions in the last couple of weeks
21:18:07 <trackbot> Created ACTION-279 - Make updates to ssn in wd according to our resolutions in the last couple of weeks [on Danh Le Phuoc - due 2017-03-14].
21:18:12 <KJanowic> There is already an action for sosa, lets make one more foor ssn and move on
21:18:26 <KJanowic> yes! we are running out of time, lets move on.
21:19:00 <tidoust> ... There's clearly a mismatch between the document and the ontology that needs to be fixed.
21:19:05 <ahaller2> topic: Progress on Implementing Option 3: SOSA pattern for Observation and Value: remove hasValue, keep class Result https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value#Option_3:_SOSA_pattern_for_Observation_and_Value:_remove_hasValue.2C_keep_class_Result
21:19:11 <KJanowic> issue 8 is "ISSUE-88: Why is a sosa-core platofrm completely different to an ssn:platform?"
21:19:19 <KJanowic> q+
21:19:26 <tidoust> Kerry: I would like us to address all of these actions before closing any issue. But let's take that offline.
21:20:03 <ahaller2> https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value
21:20:05 <tidoust> Maxime: Implementation of Option 3 we voted in favor of. Not much to add on top of that.
21:20:15 <KJanowic> q+
21:20:36 <ahaller2> ack kerry
21:20:38 <tidoust> Armin: Everything is implemented according to option 3. What is missing is that we could still have a "hasValue" attached to a sosa:Result.
21:20:45 <kerry> q+
21:21:04 <tidoust> Maxime: I think it is clear that we voted for option 3, and "hasValue" is in option 5.
21:21:07 <KJanowic> we voted foroption 3 and agreed to rediscuss hasValue
21:21:25 <tidoust> ... We agreed to discuss afterwards the existence of sosa:hasValue.
21:21:27 <ahaller2> s/foroption/for option
21:21:43 <tidoust> ... In the old SSN, sosa:hasValue is a name property. It's a datatype property in sosa.
21:21:48 <ahaller2> https://www.w3.org/2015/spatial/track/issues/138
21:21:49 <ahaller2> https://www.w3.org/2015/spatial/track/issues/122
21:21:49 <ahaller2> https://www.w3.org/2015/spatial/track/issues/140
21:21:57 <tidoust> s/name property/object property
21:22:04 <tidoust> ... This could introduce some confusion.
21:22:13 <ahaller2> q?
21:22:15 <KJanowic> q+ directly to this issue
21:22:18 <ahaller2> ack KJanowic
21:22:19 <tidoust> ... If we introduce something like that, I think we should rename it differently.
21:22:30 <kerry> q?
21:22:48 <tidoust> KJanowic: What we agreed on is option 3 with the possibility to revisit that specific part.
21:23:11 <tidoust> ... Specifically for sosa, it's a huge deal that people can assign simple result data.
21:23:12 <DanhLePhuoc> q+
21:23:31 <tidoust> ... We cannot want to keep it simple and require users to dive into further ontologies.
21:23:54 <tidoust> ... Let's just say it is specific to observations and make "sosa:hasObservation".
21:23:57 <mlefranc> I would prefer sosa:hasLiteralValue to make it clear
21:24:06 <mlefranc> q+
21:24:08 <ahaller2> ack kerry
21:24:11 <tidoust> ... That gives us option 3 and a clear way forward
21:24:35 <KJanowic> sosa:hasObservationValue
21:24:38 <ahaller2> ack directly
21:24:38 <Zakim> directly, you wanted to this issue
21:24:46 <tidoust> Kerry: I agree entirely. I was going to add another counter argument against hasValue, which is that it is an rdf type value (?).
21:24:50 <tidoust> ... I agree with the rename.
21:24:57 <KJanowic> or 'hasScalarValue'
21:25:06 <tidoust> ... Just not clear about the exact name.
21:25:22 <ahaller2> ack DanhLePhuoc
21:25:28 <tidoust> ... hasObservationValue may already be in SSN.
21:25:51 <mlefranc> currently proposed properties: sosa:hasLiteralValue , sosa:hasScalarValue ?
21:26:06 <KJanowic> I do not see hasObservationValue in SSN, what am I missing?
21:26:07 <KJanowic> q+
21:26:08 <ahaller2> other proposa: hasObservationValue
21:26:12 <ahaller2> ack mlefranc
21:26:12 <tidoust> Danh: hasObservationValue or hasScalarValue sounds good.
21:26:36 <KJanowic> I do not see hasObservationValue in SSN but would like to suggest it for SOSA
21:26:59 <tidoust> Maxime: Two proposals currently. Could some implementations require to link a result to an instance, making two ways to link things?
21:27:00 <KJanowic> q+
21:27:07 <ahaller2> Ack KJanowic
21:27:18 <SimonCox> hasObservationValue sub-property-of hasValue ?
21:27:25 <tidoust> ... hasLiteralValue and hasTypeValue, perhaps?
21:27:34 <DanhLePhuoc> +q
21:27:44 <mlefranc> q+
21:28:22 <ahaller2> ack DanhLePhuoc
21:28:29 <tidoust> KJanowic: I agree, but I think this is more for the SSN user. What I'm trying to do here is to address 80% of users who want to do something simple. "hasObservationValue" seems enough there. For SSN users, we can go deeper as needed.
21:28:33 <KJanowic> KISS: keep it simple, stupid
21:29:16 <tidoust> Danh: Two hops from observation to the value. That makes things more complicated for developers and affects robustness.
21:29:19 <roba> agree with Danh...
21:29:25 <KJanowic> Interesting proposal
21:29:27 <KJanowic> q+
21:29:31 <kerry> i agree with danh too
21:29:33 <tidoust> ... I would rather keep a direct one hop connexion from observation to value.
21:29:40 <ahaller2> PROPOSED: Use a simple property for modelling values in SOSA and SSN and name this property hasObservationValue
21:29:45 <KJanowic> +1
21:29:47 <mlefranc> -1
21:29:49 <ahaller2> +1
21:29:59 <tidoust> Armin: Thanks, let me try to draft a proposal.
21:29:59 <ahaller2> ack mlefranc
21:30:00 <kerry> +1
21:30:05 <roba> i think we should decide where it attaches first..
21:30:34 <tidoust> Maxime: I understand the point of Danh. It's a very good point. Maybe we could have hasLiteralResult or hasScalarResult.
21:30:36 <DanhLePhuoc> +1
21:30:42 <SimonCox> q+
21:30:57 <ahaller2> ack KJanowic
21:30:58 <tidoust> ... I do not understand why KJanowic sees a difference between literal and scalar?
21:31:11 <tidoust> KJanowic: Multiple reasons. Literal means strings in many domains.
21:31:22 <ahaller2> roba: attached to sosa:Result, i will change this in the proposal
21:31:29 <tidoust> ... Also want to make sure that this is used for the observation part and not for the result part.
21:31:56 <kerry> +1 to hasLiteralResult attached to observation
21:31:59 <mlefranc> q+
21:32:01 <roba> so we cant just use rdfs:Property instead of owl:objectProperty and just allow hasResult to be scalar?
21:32:09 <ahaller2> ack SimonCox
21:32:13 <tidoust> ... If the proposal is to attach it directly to Observation, that's even better.
21:33:11 <tidoust> Simon: When I was developing OM lite, I struggled with the same problem of the number of hops. It always made me uncomfortable to have to encapsulate scalar values.
21:33:20 <KJanowic> What I would suggest is a datatype property called hasObservationValue that goes from the Observation to the value.
21:33:52 <KJanowic> +1 to simon on the difference of literal and scalar
21:34:09 <tidoust> ... Scalar vs. Literal. The other issue with scalar, is that scale and unit of measures may need to be given. Not a literal value in all cases.
21:34:58 <KJanowic> Simon is making a very good point here but how can we implement this in SOSA without making it too complicated?
21:35:01 <roba> so - if its an object property, then we can always use entailment to attach metadata - e.g. the uom can be entailed for every scalar value without changing the structure ..
21:35:04 <roba> q+
21:35:22 <tidoust> ... For all 3 of Observation, Actuation and ObservableEvent, in English, it would make sense to say hasResult. Whether we need an abstract near the top and derive sub-properties or not...
21:35:36 <ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to sosa:Observation and name this property hasObservationValue
21:35:44 <KJanowic> +1
21:35:46 <tidoust> Armin: OK, let me try again to summarize where we are.
21:35:46 <mlefranc> -1
21:35:53 <kerry> -1 to the name
21:35:59 <mlefranc> also to the name
21:36:06 <KJanowic> q+
21:36:16 <ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to sosa:Observation and name this property hasLiteralResult
21:36:19 <KJanowic> Kerry ou voted +1 on the same name 5min ago?
21:36:23 <KJanowic> -1
21:36:24 <mlefranc> +1
21:36:32 <kerry> +1
21:36:32 <DanhLePhuoc> -1
21:36:34 <KJanowic> s/ou/you
21:36:38 <SimonCox> The word 'result' is important, and should appear in the label
21:36:43 <SefkiKolozali> q+
21:36:50 <SimonCox> or name
21:37:04 <KJanowic> q+
21:37:13 <tidoust> Armin: Can we perhaps have options on the Wiki page to resolve the naming issue? It does not seem possible to solve it right now.
21:37:20 <KJanowic> I can we can solve this,can I reply to this?
21:37:31 <ahaller2> ack KJanowic
21:38:19 <ahaller2> ack mlefranc
21:38:24 <tidoust> KJanowic: Let's try for 5-10mn to resolve that now. If we defer things, we'll be running out of time and we're close to that. Let's make 3 proposals. Majority wins, viva democraty!
21:38:25 <tidoust> s/viva/this is/
21:38:50 <KJanowic> collecting names: hasObservationValue, hasObservationResult, hasLiteralResult, hasScalarValue, hasScalarResult,...
21:38:51 <KJanowic> q+
21:38:52 <tidoust> Maxime: I'm happy with hasLiteralResult. It's good to keep sosa extensible, so I would avoid putting "Observation" in the name.
21:39:13 <KJanowic> I think literal would be very confusiing, it mixes modeling with technical details
21:39:24 <tidoust> ... I also understand Simon's point, but as long as you want to link something to a scalar and a literal, then you need both things. That's how OWL works.
21:39:28 <KJanowic> s/confuiing/confusing
21:39:36 <ahaller2> +1 with KJanowic and objections against literal
21:39:43 <KJanowic> q+
21:39:49 <SimonCox> +1 KJanowic
21:40:12 <kerry> q+
21:40:30 <ahaller2> ack roba
21:40:33 <KJanowic> literal is mixing technical details with domain modelling
21:40:42 <tidoust> Armin: The problem with literal is that you can use different types, including integer.
21:41:01 <ahaller2> roba has just proposed hasSimpleValue
21:41:12 <mlefranc> ok for hasSimpleValue
21:41:17 <tidoust> Roba: The reason for encapsulating values is that you can have metadata associated with the value, and extend as needed.
21:41:22 <kerry> hasdatatypeResult?
21:41:45 <tidoust> ... I'm agnostic about the name, I care about the pattern.
21:41:47 <ahaller2> q?
21:41:51 <ahaller2> ack SefkiKolozali
21:42:02 <tidoust> ... The encapsulation pattern seems a good one to me.
21:42:15 <KJanowic> IMHO, a name needs to clearly state that this is about observations, namely the result, and that it is a value
21:42:53 <tidoust> Sefki: I'm a bit confused by this diagram. This literal is one one value or is it a chunk of data. If it's only one observation, does this mean we will actuate the actuator on this only one number?
21:42:55 <ahaller2> q?
21:43:24 <KJanowic> we are again going off in different directions; lets address the issue at hand first
21:43:35 <tidoust> ... [gives an example]
21:44:30 <KJanowic> we agreed on option 3 already
21:44:33 <tidoust> ... Another point is that ssn:Result is a concept. Will it be a concept at the end of the day? How will result be evaluated? It's so generic. If it's sensor specific, maybe it could be better.
21:44:42 <ahaller2> ack KJanowic
21:45:07 <tidoust> Armin: We do have sosa:Result, we're discussing the property to attach values to observation.
21:45:21 <tidoust> ... You can attach multiple properties, not restricted to one.
21:45:40 <mlefranc> +1
21:45:55 <tidoust> KJanowic: We have agreement on option 3. We have agreement on the need to have a simple and direct mechanism to attach values to observations.
21:46:14 <tidoust> ... What we argue about is the name of the property.
21:46:17 <SimonCox> hasSimpleObservationResult
21:46:36 <ahaller2> q?
21:46:40 <SimonCox> seems to be the inevitable end point of Jano's case
21:46:43 <ahaller2> ack KJanowic
21:46:44 <roba> hasSimpleRTesult
21:46:46 <ahaller2> ack kerry
21:46:53 <tidoust> ... "hasSimpleObservationResult", as Simon just suggested, is good. Let's vote on names.
21:47:29 <mlefranc> +1 for hasSimpleResult
21:47:32 <roba> hasSimpleResult
21:47:42 <SimonCox> (Observation is there to distinguish from SamplingEvent and Actuation results)
21:47:44 <tidoust> Kerry: I think it should look like hasResult. I do not mind if it has Observation or not.
21:47:44 <ahaller2> q+
21:47:53 <tidoust> ... We want to mix results.
21:48:21 <KJanowic> options so far: hasSimpleObservationResult, hasObservationValue, hasObservationResult, hasLiteralResult, hasScalarValue, hasScalarResult, hasSimpleResult, hasDataTypeResult
21:48:24 <tidoust> KJanowic: Trying to collect options, what's your preferred option?
21:48:31 <ahaller2> ack ahaller
21:48:34 <KJanowic> me too
21:48:36 <tidoust> Kerry: Possibly hasDataTypeResult...
21:48:41 <mlefranc> and  hasDatatypeResult :-)
21:48:41 <KJanowic> this is a conceptual modelling no-go
21:48:53 <KJanowic> yes, same for hasDatatypeResult
21:48:57 <KJanowic> Armin, see options above
21:49:15 <ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to hasSimpleObservationResult and name this property hasSimpleObservationResult
21:49:18 <tidoust> Armin: It needs to be different from hasResult since we already have that property.
21:49:20 <mlefranc> -1
21:49:21 <KJanowic> +1
21:49:32 <ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to Observation and name this property hasSimpleObservationResult
21:49:35 <roba> q+
21:49:39 <ahaller2> ack KJanowic
21:49:44 <SimonCox> +1
21:49:57 <KJanowic> +1
21:50:02 <DanhLePhuoc> 0
21:50:05 <tidoust> KJanowic: Whatever the name, some people will love it, others will hate it. Let's use majority.
21:50:26 <roba> hasSimpleResult
21:50:31 <DanhLePhuoc> hasSimpleResult
21:50:33 <kerry> hassimpleResult
21:50:36 <mlefranc> ok with hasSimpleResult, hasScalarResult, hasDatatypeResult
21:50:37 <tidoust> Armin: Everyone, please post your preferred option
21:50:39 <ahaller2> hasObservationResult
21:50:46 <KJanowic> hasSimpleObservationResult or  hasObservationValue or hasObservationResult
21:50:53 <SimonCox> hasSimpleResult or hasSimpleObservationResult
21:51:03 <ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to Observation and name this property hasSimpleResult
21:51:06 <mlefranc> +1
21:51:08 <ahaller2> 0
21:51:12 <roba> +1
21:51:13 <DanhLePhuoc> +1
21:51:14 <KJanowic> 0
21:51:15 <tidoust> Armin: OK, hasSimpleResult seems to be the one gaining traction.
21:51:15 <kerry> +1
21:51:21 <SimonCox> +1
21:51:30 <KJanowic> q+
21:51:39 <roba> q-
21:51:39 <SefkiKolozali> hasObservationValue
21:51:48 <ahaller2> ack KJanowic
21:52:35 <ahaller2> RESOLVED: Use a datatype property for modelling values in SOSA and SSN that attaches to Observation and name this property hasSimpleResult
21:52:42 <tidoust> KJanowic: It's not my favorite choice, but I can live with it. Can we move on? It's just names!
21:52:47 <KJanowic> Armin, I will implement this in SOSA
21:53:13 <ahaller2> ACTIOn: KJanowic to implement hasSimpleResult in SOSA
21:53:15 <trackbot> Created ACTION-280 - Implement hassimpleresult in sosa [on Krzysztof Janowicz - due 2017-03-14].
21:53:18 <ahaller2> topic: Resolving of the following questions in the Actuation proposal for SOSA/SSN as of discussion on wiki: https://www.w3.org/2015/spatial/wiki/Actuation_in_SOSA
21:53:37 <ahaller2> topic: https://www.w3.org/2015/spatial/wiki/Link_between_Observation_and_ObservableProperty
21:53:42 <tidoust> Armin: Discussion we had on Actuation. Many remaining issues. I'd like to cover at least one.
21:54:00 <tidoust> ... Link between Observation and ObservableProperty.
21:54:14 <mlefranc> sosa:actsOn/sosa:isActedOnBy
21:54:21 <tidoust> Maxime: We voted for the link between Actuation and ActuatableProperty. sosa:actsOn/sosa:isActedBy.
21:54:40 <tidoust> ... Now, same thing for Observation and ObservableProperty.
21:54:42 <ahaller2> q?
21:54:46 <SimonCox> q
21:55:07 <tidoust> ... I would vote for sosa:observes/sosa:isObservedBy
21:55:09 <mlefranc> q+
21:55:32 <kerry> q+
21:55:45 <ahaller2> SimonCox: proposes sosa:observedProperty/sosa:isObservedPropertyOf
21:55:47 <ahaller2> ack mlefranc
21:55:47 <KJanowic> +1
21:55:52 <tidoust> Simon: observes in natural language could refer to the observation thing and the feature being observed. That was deemed important in OM lite.
21:56:13 <tidoust> ... I would go for sosa:observedProperty/isObservedPropertyOf
21:56:27 <SimonCox> q
21:56:28 <tidoust> Maxime: OK, but then for consistency, this should be reflected on Actuation as well.
21:56:28 <SimonCox> q+
21:56:31 <KJanowic> lets not mix issue again
21:56:49 <ahaller2> sosa:actsOn/sosa:isActedOnBy
21:56:53 <tidoust> ... I would like the naming to be consistent between Observation and Actuation.
21:57:29 <ahaller2> sosa:observedProperty/wasObservedPropertyOf
21:57:39 <KJanowic> the link between sensor and property is more complicated and we do not even know whether we will have one
21:57:44 <KJanowic> q+
21:58:01 <ahaller2> ack KJanowic
21:58:04 <ahaller2> ack kerry
21:58:11 <KJanowic> q+
21:58:11 <tidoust> Maxime: [observes, observed, observable, scribe missed point]. I'd like to see consistency in the naming between Observation and Actuation.
21:58:35 <tidoust> Kerry: observes/isObservedBy is already used in SSN and in there for a long time, right?
21:58:38 <tidoust> Maxime: True.
21:58:46 <tidoust> Kerry: That goes in favor of that option.
21:59:03 <ahaller2> q?
21:59:05 <tidoust> ... I agree it matches the pattern we already established for Actuation.
21:59:06 <ahaller2> ack SimonCox
21:59:28 <KJanowic> and we need to be open to suggestions from others
21:59:55 <tidoust> Simon: We all love our labels. I appreciate Maxime's points, also on used of present and past tenses.
21:59:59 <ahaller2> q?
22:00:06 <ahaller2> zakim, close queue
22:00:06 <Zakim> ok, ahaller2, the speaker queue is closed
22:00:26 <mlefranc> so you would be ok with sosa:observedProperty/sosa:wasObservedPropertyOf ? I would, too
22:00:31 <KJanowic> I agree with everything Simon just said
22:00:34 <tidoust> ... But there comes a point where we may have to give up on some of the alignment. Not clear whether it's the feature or the property that you expect at the end of the line.
22:00:46 <ahaller2> q?
22:00:48 <tidoust> ... That was a strong requirement by the community, and we cannot lose that.
22:00:49 <ahaller2> ack KJanowic
22:01:13 <SimonCox> afraid I have to leave so I don't miss a flight.
22:01:17 <ahaller2> PROPOSED: Use of sosa:observes/sosa:isObservedBy as a link between Observation and ObservableProperty
22:01:25 <KJanowic> -1
22:01:29 <ahaller2> 0
22:01:29 <mlefranc> -1
22:01:34 <kerry> -1
22:01:38 <ahaller2> PROPOSED: Use of sosa:observedProperty/sosa:wasObservedPropertyOf as a link between Observation and ObservableProperty
22:01:44 <kerry> -1
22:01:45 <mlefranc> +1
22:01:51 <DanhLePhuoc> -1
22:01:55 <roba> 0
22:02:05 <KJanowic> 0 (we lost simon)
22:02:15 <ahaller2> https://www.w3.org/2015/spatial/wiki/Link_between_Observation_and_ObservableProperty
22:02:25 <kerry> q+
22:02:40 <tidoust> Armin: OK, let's update the Wiki page and revisit next time.
22:02:40 <KJanowic> bye bye
22:02:50 <tidoust> ... We'll probably need another longer call in the future.
22:02:54 <kerry> maxime -- please also cover how ssn:observes needs to change or not in its other use in ssn (around capability)
22:02:55 <mlefranc> +1
22:03:17 <tidoust> Simon: Can I remind people that the integration issue will be discussed tomorrow during the plenary?
22:03:26 <roba> +1
22:03:39 <tidoust> KJanowic: I think we should discuss this within this group first. The larger group will be confused.
22:03:53 <ahaller2> bye
22:03:55 <kerry> bye!
22:03:57 <tidoust> Armin: Right, I'll check tomorrow, and propose to discuss here instead if other people are not interested.
22:03:59 <roba> bye
22:04:02 <tidoust> RRSAgent, draft minutes v2
22:04:02 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/07-sdwssn-minutes.html tidoust
22:42:16 <eparsons> eparsons has joined #sdwssn
23:29:09 <ahaller2> ahaller2 has joined #sdwssn