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