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

[Minutes SSN] 2017-03-07

From: Francois Daoust <fd@w3.org>
Date: Wed, 8 Mar 2017 09:16:12 +0100
To: <public-sdw-wg@w3.org>
Message-ID: <020f01d297e4$401bff40$c053fdc0$@w3.org>

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

... and copied as raw text below.


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


          DanhLePhuoc, Francois, KJanowic, SefkiKolozali,
          SimonCox, ahaller2, kerry, mlefranc, roba





     * [4]Meeting Minutes
         1. [5]Approving last meeting's minutes https://
         2. [6]patent call https://www.w3.org/2015/spatial/wiki/
         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/
         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/
     * [10]Summary of Action Items
     * [11]Summary of Resolutions

Meeting Minutes

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

     [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/

     [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

   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
   … Do we just write changes twice? I feel uncomfortable about

   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

   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/

     [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/

     [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

   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

   Maxime: We agreed to discuss afterwards the existence of
   … 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

   <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

   <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

   <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

   <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

   <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

   <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,

   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

   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,

   KJanowic: Trying to collect options, what's your preferred

   <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

   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,

   Armin: Everyone, please post your preferred option

   <ahaller2> hasObservationResult

   <KJanowic> hasSimpleObservationResult or hasObservationValue or

   <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

   <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

   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/

     [21] https://www.w3.org/2015/spatial/wiki/Actuation_in_SOSA


     [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

   <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

   <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/

     [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
Received on Wednesday, 8 March 2017 08:16:26 UTC

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