- From: Francois Daoust <fd@w3.org>
- Date: Wed, 8 Mar 2017 09:16:12 +0100
- To: <public-sdw-wg@w3.org>
Hi,
The minutes of yesterday's SSN call are available at:
http://www.w3.org/2017/03/07-sdwssn-minutes.html
... and copied as raw text below.
Thanks,
Francois.
-----
Spatial Data on the Web SSN Sub Group Teleconference
07 March 2017
[2]Agenda [3]IRC log
[2] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170307
[3] http://www.w3.org/2017/03/07-sdwssn-irc
Attendees
Present
DanhLePhuoc, Francois, KJanowic, SefkiKolozali,
SimonCox, ahaller2, kerry, mlefranc, roba
Regrets
Chair
Armin
Scribe
Francois
Contents
* [4]Meeting Minutes
1. [5]Approving last meeting's minutes https://
www.w3.org/2017/02/21-sdwssn-minutes
2. [6]patent call https://www.w3.org/2015/spatial/wiki/
Patent_Call
3. [7]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
4. [8]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_O
bservation_and_Value:_remove_hasValue.2C_keep_class_Re
sult
5. [9]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
* [10]Summary of Action Items
* [11]Summary of Resolutions
Meeting Minutes
Approving last meeting's minutes [12]https://www.w3.org/2017/02/
21-sdwssn-minutes
[12] https://www.w3.org/2017/02/21-sdwssn-minutes
<kerry> +1
<mlefranc> +1
<tidoust> +1
<KJanowic> +1
<DanhLePhuoc> +1
<SimonCox> +1
<roba> +1
patent call [13]https://www.w3.org/2015/spatial/wiki/Patent_Call
[13] https://www.w3.org/2015/spatial/wiki/Patent_Call
Armin goes through the OGC patent call
Implementation of Platform resolution [14]https://www.w3.org/2015/
spatial/track/actions/275 and close of issue [15]https://www.w3.org/
2015/spatial/track/issues/88
[14] https://www.w3.org/2015/spatial/track/actions/275
[15] https://www.w3.org/2015/spatial/track/issues/88
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.
Progress on Implementing Option 3: SOSA pattern for Observation and
Value: remove hasValue, keep class Result [16]https://www.w3.org/
2015/spatial/wiki/
Storing_Observation_Value#Option_3:_SOSA_pattern_for_Observation_and_
Value:_remove_hasValue.2C_keep_class_Result
[16] https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value#Option_3:_SOSA_pattern_for_Observation_and_Value:_remove_hasValue.2C_keep_class_Result
<ahaller2> [17]https://www.w3.org/2015/spatial/wiki/
Storing_Observation_Value
[17] 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> [18]https://www.w3.org/2015/spatial/track/issues/138
[18] https://www.w3.org/2015/spatial/track/issues/138
<ahaller2> [19]https://www.w3.org/2015/spatial/track/issues/122
[19] https://www.w3.org/2015/spatial/track/issues/122
<ahaller2> [20]https://www.w3.org/2015/spatial/track/issues/140
[20] 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].
Resolving of the following questions in the Actuation proposal for
SOSA/SSN as of discussion on wiki: [21]https://www.w3.org/2015/
spatial/wiki/Actuation_in_SOSA
[21] https://www.w3.org/2015/spatial/wiki/Actuation_in_SOSA
[22]https://www.w3.org/2015/spatial/wiki/
Link_between_Observation_and_ObservableProperty
[22] 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 OM lite.
… 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> [23]https://www.w3.org/2015/spatial/wiki/
Link_between_Observation_and_ObservableProperty
[23] 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
Simon: 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.
<ahaller2> bye
<kerry> bye!
Armin: Right, I'll check tomorrow, and propose to discuss here
instead if other people are not interested.
<roba> bye
Summary of Action Items
1. [24]KJanowic to make updates to SOSA in WD according to our
resolutions in the last couple of weeks
2. [25]Danh to make updates to SSN in WD according to our
resolutions in the last couple of weeks
3. [26]KJanowic to implement hasSimpleResult in SOSA
Summary of Resolutions
1. [27]Use a datatype property for modelling values in SOSA
and SSN that attaches to Observation and name this property
hasSimpleResult
Received on Wednesday, 8 March 2017 08:16:26 UTC