- From: Francois Daoust <fd@w3.org>
- Date: Wed, 29 Mar 2017 09:35:16 +0200
- To: "'SDW WG'" <public-sdw-wg@w3.org>
Hi all,
The minutes of yesterday's SSN call are available at:
http://www.w3.org/2017/03/28-sdwssn-minutes
... and copied as raw text below.
Thanks,
Francois.
-----
Spatial Data on the Web WG - SSN Sub Group Teleconference
28 March 2017
[2]Agenda [3]IRC log
[2] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170328
[3] http://www.w3.org/2017/03/28-sdwssn-irc
Attendees
Present
Armin (ahaller2), Danh (DanhLePhuoc), Francois
(tidoust), Jano (KJanowic), Maxime (mlefranc), Raul
(RaulGarciaCastro), Simon (SimonCox)
Regrets
Scott
Chair
Armin
Scribe
Francois, Maxime
Contents
* [4]Meeting Minutes
1. [5]Approving last meeting's minutes https://
www.w3.org/2017/03/14-sdwssn-minutes
2. [6]Patent Call https://www.w3.org/2015/spatial/wiki/
Patent_Call
3. [7]Progress on ACTION 282 for Forecasting
4. [8]Progress on ACTION-283 to propose properties to
replace dul:includesEvent property as of ISSUE-117
5. [9]Progress on ACTION-279 to add a change history to
SSN document
6. [10]SSN Measurement and Operating properties for
actuators https://www.w3.org/2015/spatial/wiki/
Measurement_and_Operating_properties_for_actuators
7. [11]Proposal for ssn:Device (Deprecate?) as of
ISSUE-153
8. [12]Discussion of RecTrack requirements, i.e. last
working draft, 17-04-17
9. [13]Progress on ACTION-286 for Sampling and decision
on OBOE alignment
10. [14]Close ISSUE-89 as of implementation of https://
github.com/w3c/sdw/pull/634
11. [15]Progress on ACTION-284, temporal properties in
both SOSA/SSN, i.e. ssn:startTime, ssn:endTime as of
ISSUE-145, stimulusTime for Observation as of
ISSUE-151 and sosa:resultTime,
ssn:observationResultTime and
ssn:observationSamplingTime.
* [16]Summary of Action Items
* [17]Summary of Resolutions
Meeting Minutes
Approving last meeting's minutes [18]https://www.w3.org/2017/03/
14-sdwssn-minutes
[18] https://www.w3.org/2017/03/14-sdwssn-minutes
<RaulGarciaCastro> +1
<ahaller2> +1
<KJanowic> +1
<tidoust> +1
<mlefranc> +1
<DanhLePhuoc> +1
Resolved: Approving last meeting's minutes [19]https://
www.w3.org/2017/03/14-sdwssn-minutes
[19] https://www.w3.org/2017/03/14-sdwssn-minutes
Patent Call [20]https://www.w3.org/2015/spatial/wiki/Patent_Call
[20] https://www.w3.org/2015/spatial/wiki/Patent_Call
Progress on ACTION 282 for Forecasting
<mlefranc> [21]https://lists.w3.org/Archives/Public/
public-sdw-wg/2017Mar/0254.html
[21] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0254.html
<ahaller2> [22]https://www.w3.org/2015/spatial/track/actions/
282
[22] 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> [23]https://github.com/w3c/sdw/compare/
action-282-forecasting
[23] 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.
Progress on ACTION-283 to propose properties to replace
dul:includesEvent property as of ISSUE-117
<ahaller2> [24]https://www.w3.org/2015/spatial/track/actions/
283
[24] https://www.w3.org/2015/spatial/track/actions/283
<RaulGarciaCastro> [25]https://www.w3.org/2015/spatial/track/
issues/117
[25] 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> [26]https://www.w3.org/2015/spatial/track/
issues/117
[26] 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 [27]https://www.w3.org/
2015/spatial/track/issues/117 with isStimulatedBy replaced by
wasOriginatedBy
[27] https://www.w3.org/2015/spatial/track/issues/117
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.
Progress on ACTION-279 to add a change history to SSN document
ahaller2: I think you issued a new PR while I was sleeping,
Danh.
<ahaller2> [28]https://github.com/w3c/sdw/pull/633
[28] https://github.com/w3c/sdw/pull/633
<KJanowic> [there is somebody speaking in the background]
<DanhLePhuoc> [29]https://github.com/w3c/sdw/pull/643
[29] https://github.com/w3c/sdw/pull/643
<ahaller2> [30]https://github.com/w3c/sdw/pull/643
[30] 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]
SSN Measurement and Operating properties for actuators [31]https://
www.w3.org/2015/spatial/wiki/
Measurement_and_Operating_properties_for_actuators
[31] https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators
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: [32]https://www.w3.org/2015/spatial/
wiki/Measurement_and_Operating_properties_for_actuators
[32] 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: [33]https://
www.w3.org/2015/spatial/wiki/
measurement_and_operating_properties_for_actuators [on Maxime
Lefrançois - due 2017-04-04].
[33] https://www.w3.org/2015/spatial/wiki/measurement_and_operating_properties_for_actuators
<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
Proposal for ssn:Device (Deprecate?) as of ISSUE-153
<ahaller2> [34]https://www.w3.org/2015/spatial/track/issues/153
[34] 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 [35]https://www.w3.org/2015/
spatial/track/issues/153 and propose a solution
[35] https://www.w3.org/2015/spatial/track/issues/153
<trackbot> Created ACTION-296 - Look into [36]https://
www.w3.org/2015/spatial/track/issues/153 and propose a solution
[on Krzysztof Janowicz - due 2017-04-04].
[36] https://www.w3.org/2015/spatial/track/issues/153
Discussion of RecTrack requirements, i.e. last working draft,
17-04-17
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: [37]https://lists.w3.org/Archives/Public/
public-sdw-wg/2017Mar/0231.html ]
[37] 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].
Progress on ACTION-286 for Sampling and decision on OBOE alignment
<ahaller2> [38]https://www.w3.org/2015/spatial/track/actions/
286
[38] https://www.w3.org/2015/spatial/track/actions/286
<SimonCox> [39]https://www.w3.org/2015/spatial/wiki/Sampling
[39] https://www.w3.org/2015/spatial/wiki/Sampling
<SimonCox> [40]https://www.w3.org/2015/spatial/wiki/
Alignment_to_OBOE
[40] 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> [41]http://host.geolink.org/ngdb/id/geosample/
AAM055A
[41] 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> [42]https://github.com/w3c/sdw/blob/gh-pages/ssn/
rdf/sampling.ttl
[42] https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sampling.ttl
<KJanowic> [43]https://www.w3.org/2015/spatial/wiki/
SSN_core_modules :-)
[43] 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 [44]ACTION-299 created after the call]
[44] https://www.w3.org/2015/spatial/track/actions/299
<KJanowic> maximew: not remove the relationships as they are
not in there as of now
<SimonCox> [45]https://www.w3.org/2015/spatial/wiki/
Alignment_to_OBOE
[45] 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 [46]https://
www.w3.org/2015/spatial/wiki/Alignment_to_OBOE in the WD as a
non-normative section similar to the DULCE alignment
[46] https://www.w3.org/2015/spatial/wiki/Alignment_to_OBOE
[See [47]ACTION-300 created after the call]
[47] https://www.w3.org/2015/spatial/track/actions/300
Close ISSUE-89 as of implementation of [48]https://github.com/w3c/
sdw/pull/634
[48] https://github.com/w3c/sdw/pull/634
<KJanowic> Will do
Progress on ACTION-284, temporal properties in both SOSA/SSN, i.e.
ssn:startTime, ssn:endTime as of ISSUE-145, stimulusTime for
Observation as of ISSUE-151 and sosa:resultTime,
ssn:observationResultTime and ssn:observationSamplingTime.
<KJanowic> [49]https://www.w3.org/2015/spatial/wiki/
Time_in_SOSA_and_SSN
[49] 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 [50]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 .
[50] https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl
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
Summary of Action Items
1. [51]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
2. [52]KJanowic to look into https://www.w3.org/2015/spatial/
track/issues/153 and propose a solution
3. [53]ahaller2 Implement changes that were made to SOSA in
the WD document
4. [54]maxime to send an email to the list to list
classes/properties in SSN from the "integrated" directory
that we have not discussed yet
5. [55]SimonCox to include Sample relation text in WD and
reference ontology that was proposed in Github
(non-normative)
6. [56]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
Summary of Resolutions
1. [57]Approving last meeting's minutes https://www.w3.org/
2017/03/14-sdwssn-minutes
2. [58]Implement comments in issue https://www.w3.org/2015/
spatial/track/issues/117 with isStimulatedBy replaced by
wasOriginatedBy
3. [59]Deprecate ssn:startTime and ssn:endTime
Received on Wednesday, 29 March 2017 07:35:29 UTC