Spatial Data on the Web SSN Sub Group Teleconference
07 March 2017
<kerry> +1
<mlefranc> +1
<tidoust> +1
<KJanowic> +1
<DanhLePhuoc> +1
<SimonCox> +1
<roba> +1
Armin goes through the OGC patent call
Armin: Our implementation of our resolutions around Platform we took during last meeting.
… Maxime, any problem?
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.
… Next step is to discuss Device and SensorDevice to understand what they should become now.
… There was no change at all for SOSA.
Armin: We did change the description for the Platform class for alignment.
Kerry: There are a few things that I think need to be catered for before we close the issue.
… Some comments need to be integrated.
Kerry: Also, Maxime raised the problem of Device and SensorDevice, that's intrisically related.
… For all of these things, the documentation of the spec needs to be updated.
… 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.
… What's the best practice to reflect them?
… It's about the end of the document, sections where we report changes.
… Do we just write changes twice? I feel uncomfortable about that.
Armin: Currently, we haven't made changes to the document, only the ontology files.
Kerry: Well, I would argue that we are making substantive changes and that should be reflected.
Armin: Yes, I agree.
<KJanowic> I can do so for the SOSA part
Kerry: We have two changes to report, a) changes since the previous SSN, b) changes since we started this work and published an update.
<KJanowic> Agreed
Action: KJanowic to make updates to SOSA in WD according to our resolutions in the last couple of weeks
<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].
<KJanowic> Yes to closing issue-88
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.
<kerry> -1 to closing the issue
<KJanowic> +1 to closing issue-88
Kerry: OK, I'll take that as advice to put the changes in the list of changes done to the document since 2005.
<KJanowic> I disagree
Kerry: I'm happy to move on and discuss on the mailing-list, just not happy with closing the issue right now.
<mlefranc> that can be a new issue what kerry just said
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.
Armin: I would like to give an action to someone to update the SSN document. Perhaps Danh?
Action: Danh to make updates to SSN in WD according to our resolutions in the last couple of weeks
<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].
<KJanowic> There is already an action for sosa, lets make one more foor ssn and move on
<KJanowic> yes! we are running out of time, lets move on.
Armin: There's clearly a mismatch between the document and the ontology that needs to be fixed.
<KJanowic> issue 8 is "ISSUE-88: Why is a sosa-core platofrm completely different to an ssn:platform?"
Kerry: I would like us to address all of these actions before closing any issue. But let's take that offline.
<ahaller2> https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value
Maxime: Implementation of Option 3 we voted in favor of. Not much to add on top of that.
Armin: Everything is implemented according to option 3. What is missing is that we could still have a "hasValue" attached to a sosa:Result.
Maxime: I think it is clear that we voted for option 3, and "hasValue" is in option 5.
<KJanowic> we voted for option 3 and agreed to rediscuss hasValue
Maxime: We agreed to discuss afterwards the existence of sosa:hasValue.
… In the old SSN, sosa:hasValue is a object property. It's a datatype property in sosa.
<ahaller2> https://www.w3.org/2015/spatial/track/issues/138
<ahaller2> https://www.w3.org/2015/spatial/track/issues/122
<ahaller2> https://www.w3.org/2015/spatial/track/issues/140
Maxime: This could introduce some confusion.
… If we introduce something like that, I think we should rename it differently.
KJanowic: What we agreed on is option 3 with the possibility to revisit that specific part.
… Specifically for sosa, it's a huge deal that people can assign simple result data.
… We cannot want to keep it simple and require users to dive into further ontologies.
… Let's just say it is specific to observations and make "sosa:hasObservation".
<mlefranc> I would prefer sosa:hasLiteralValue to make it clear
KJanowic: That gives us option 3 and a clear way forward
<KJanowic> sosa:hasObservationValue
<Zakim> directly, you wanted to this issue
Kerry: I agree entirely. I was going to add another counter argument against hasValue, which is that it is an rdf type value (?).
… I agree with the rename.
<KJanowic> or 'hasScalarValue'
Kerry: Just not clear about the exact name.
… hasObservationValue may already be in SSN.
<mlefranc> currently proposed properties: sosa:hasLiteralValue , sosa:hasScalarValue ?
<KJanowic> I do not see hasObservationValue in SSN, what am I missing?
<ahaller2> other proposa: hasObservationValue
Danh: hasObservationValue or hasScalarValue sounds good.
<KJanowic> I do not see hasObservationValue in SSN but would like to suggest it for SOSA
Maxime: Two proposals currently. Could some implementations require to link a result to an instance, making two ways to link things?
<SimonCox> hasObservationValue sub-property-of hasValue ?
Maxime: hasLiteralValue and hasTypeValue, perhaps?
<DanhLePhuoc> +q
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.
<KJanowic> KISS: keep it simple, stupid
Danh: Two hops from observation to the value. That makes things more complicated for developers and affects robustness.
<roba> agree with Danh...
<KJanowic> Interesting proposal
<kerry> i agree with danh too
Danh: I would rather keep a direct one hop connexion from observation to value.
<ahaller2> PROPOSED: Use a simple property for modelling values in SOSA and SSN and name this property hasObservationValue
<KJanowic> +1
<mlefranc> -1
<ahaller2> +1
Armin: Thanks, let me try to draft a proposal.
<kerry> +1
<roba> i think we should decide where it attaches first..
Maxime: I understand the point of Danh. It's a very good point. Maybe we could have hasLiteralResult or hasScalarResult.
<DanhLePhuoc> +1
Maxime: I do not understand why KJanowic sees a difference between literal and scalar?
KJanowic: Multiple reasons. Literal means strings in many domains.
<ahaller2> roba: attached to sosa:Result, i will change this in the proposal
KJanowic: Also want to make sure that this is used for the observation part and not for the result part.
<kerry> +1 to hasLiteralResult attached to observation
<roba> so we cant just use rdfs:Property instead of owl:objectProperty and just allow hasResult to be scalar?
KJanowic: If the proposal is to attach it directly to Observation, that's even better.
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.
<KJanowic> What I would suggest is a datatype property called hasObservationValue that goes from the Observation to the value.
<KJanowic> +1 to simon on the difference of literal and scalar
Simon: 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.
<KJanowic> Simon is making a very good point here but how can we implement this in SOSA without making it too complicated?
<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 ..
Simon: 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...
<ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to sosa:Observation and name this property hasObservationValue
<KJanowic> +1
Armin: OK, let me try again to summarize where we are.
<mlefranc> -1
<kerry> -1 to the name
<mlefranc> also to the name
<ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to sosa:Observation and name this property hasLiteralResult
<KJanowic> Kerry you voted +1 on the same name 5min ago?
<KJanowic> -1
<mlefranc> +1
<kerry> +1
<DanhLePhuoc> -1
<SimonCox> The word 'result' is important, and should appear in the label
<SimonCox> or name
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.
<KJanowic> I can we can solve this,can I reply to this?
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, this is democraty!
<KJanowic> collecting names: hasObservationValue, hasObservationResult, hasLiteralResult, hasScalarValue, hasScalarResult,...
Maxime: I'm happy with hasLiteralResult. It's good to keep sosa extensible, so I would avoid putting "Observation" in the name.
<KJanowic> I think literal would be very confusing, it mixes modeling with technical details
Maxime: 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.
<ahaller2> +1 with KJanowic and objections against literal
<SimonCox> +1 KJanowic
<KJanowic> literal is mixing technical details with domain modelling
Armin: The problem with literal is that you can use different types, including integer.
<ahaller2> roba has just proposed hasSimpleValue
<mlefranc> ok for hasSimpleValue
Roba: The reason for encapsulating values is that you can have metadata associated with the value, and extend as needed.
<kerry> hasdatatypeResult?
Roba: I'm agnostic about the name, I care about the pattern.
… The encapsulation pattern seems a good one to me.
<KJanowic> IMHO, a name needs to clearly state that this is about observations, namely the result, and that it is a value
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?
<KJanowic> we are again going off in different directions; lets address the issue at hand first
Sefki: [gives an example]
<KJanowic> we agreed on option 3 already
Sefki: 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.
Armin: We do have sosa:Result, we're discussing the property to attach values to observation.
… You can attach multiple properties, not restricted to one.
<mlefranc> +1
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.
… What we argue about is the name of the property.
<SimonCox> hasSimpleObservationResult
<SimonCox> seems to be the inevitable end point of Jano's case
<roba> hasSimpleRTesult
KJanowic: "hasSimpleObservationResult", as Simon just suggested, is good. Let's vote on names.
<mlefranc> +1 for hasSimpleResult
<roba> hasSimpleResult
<SimonCox> (Observation is there to distinguish from SamplingEvent and Actuation results)
Kerry: I think it should look like hasResult. I do not mind if it has Observation or not.
… We want to mix results.
<KJanowic> options so far: hasSimpleObservationResult, hasObservationValue, hasObservationResult, hasLiteralResult, hasScalarValue, hasScalarResult, hasSimpleResult, hasDataTypeResult
KJanowic: Trying to collect options, what's your preferred option?
<KJanowic> me too
Kerry: Possibly hasDataTypeResult...
<mlefranc> and hasDatatypeResult :-)
<KJanowic> this is a conceptual modelling no-go
<KJanowic> yes, same for hasDatatypeResult
<KJanowic> Armin, see options above
<ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to hasSimpleObservationResult and name this property hasSimpleObservationResult
Armin: It needs to be different from hasResult since we already have that property.
<mlefranc> -1
<KJanowic> +1
<ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to Observation and name this property hasSimpleObservationResult
<SimonCox> +1
<KJanowic> +1
<DanhLePhuoc> 0
KJanowic: Whatever the name, some people will love it, others will hate it. Let's use majority.
<roba> hasSimpleResult
<DanhLePhuoc> hasSimpleResult
<kerry> hassimpleResult
<mlefranc> ok with hasSimpleResult, hasScalarResult, hasDatatypeResult
Armin: Everyone, please post your preferred option
<ahaller2> hasObservationResult
<KJanowic> hasSimpleObservationResult or hasObservationValue or hasObservationResult
<SimonCox> hasSimpleResult or hasSimpleObservationResult
<ahaller2> PROPOSED: Use a datatype property for modelling values in SOSA and SSN that attaches to Observation and name this property hasSimpleResult
<mlefranc> +1
<ahaller2> 0
<roba> +1
<DanhLePhuoc> +1
<KJanowic> 0
Armin: OK, hasSimpleResult seems to be the one gaining traction.
<kerry> +1
<SimonCox> +1
<SefkiKolozali> hasObservationValue
Resolved: Use a datatype property for modelling values in SOSA and SSN that attaches to Observation and name this property hasSimpleResult
KJanowic: It's not my favorite choice, but I can live with it. Can we move on? It's just names!
<KJanowic> Armin, I will implement this in SOSA
Action: KJanowic to implement hasSimpleResult in SOSA
<trackbot> Created ACTION-280 - Implement hassimpleresult in sosa [on Krzysztof Janowicz - due 2017-03-14].
https://www.w3.org/2015/spatial/wiki/Link_between_Observation_and_ObservableProperty
Armin: Discussion we had on Actuation. Many remaining issues. I'd like to cover at least one.
… Link between Observation and ObservableProperty.
<mlefranc> sosa:actsOn/sosa:isActedOnBy
Maxime: We voted for the link between Actuation and ActuatableProperty. sosa:actsOn/sosa:isActedBy.
… Now, same thing for Observation and ObservableProperty.
<SimonCox> q
Maxime: I would vote for sosa:observes/sosa:isObservedBy
<ahaller2> SimonCox: proposes sosa:observedProperty/sosa:isObservedPropertyOf
<KJanowic> +1
Simon: observes in natural language could refer to the observation thing and the feature being observed. That was deemed important in O&M.
… I would go for sosa:observedProperty/isObservedPropertyOf
<SimonCox> q
Maxime: OK, but then for consistency, this should be reflected on Actuation as well.
<KJanowic> lets not mix issue again
<ahaller2> sosa:actsOn/sosa:isActedOnBy
Maxime: I would like the naming to be consistent between Observation and Actuation.
<ahaller2> sosa:observedProperty/wasObservedPropertyOf
<KJanowic> the link between sensor and property is more complicated and we do not even know whether we will have one
Maxime: [observes, observed, observable, scribe missed point]. I'd like to see consistency in the naming between Observation and Actuation.
Kerry: observes/isObservedBy is already used in SSN and in there for a long time, right?
Maxime: True.
Kerry: That goes in favor of that option.
… I agree it matches the pattern we already established for Actuation.
<KJanowic> and we need to be open to suggestions from others
Simon: We all love our labels. I appreciate Maxime's points, also on used of present and past tenses.
<mlefranc> so you would be ok with sosa:observedProperty/sosa:wasObservedPropertyOf ? I would, too
<KJanowic> I agree with everything Simon just said
Simon: 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.
… That was a strong requirement by the community, and we cannot lose that.
<SimonCox> afraid I have to leave so I don't miss a flight.
<ahaller2> PROPOSED: Use of sosa:observes/sosa:isObservedBy as a link between Observation and ObservableProperty
<KJanowic> -1
<ahaller2> 0
<mlefranc> -1
<kerry> -1
<ahaller2> PROPOSED: Use of sosa:observedProperty/sosa:wasObservedPropertyOf as a link between Observation and ObservableProperty
<kerry> -1
<mlefranc> +1
<DanhLePhuoc> -1
<roba> 0
<KJanowic> 0 (we lost simon)
<ahaller2> https://www.w3.org/2015/spatial/wiki/Link_between_Observation_and_ObservableProperty
Armin: OK, let's update the Wiki page and revisit next time.
<KJanowic> bye bye
Armin: We'll probably need another longer call in the future.
<kerry> maxime -- please also cover how ssn:observes needs to change or not in its other use in ssn (around capability)
<mlefranc> +1
[someone]: Can I remind people that the integration issue will be discussed tomorrow during the plenary?
<roba> +1
KJanowic: I think we should discuss this within this group first. The larger group will be confused.
Armin: Right, I'll check tomorrow, and propose to discuss here instead if other people are not interested.
<ahaller2> bye
<kerry> bye!
<roba> bye