W3C

Spatial Data on the Web SSN Sub Group Teleconference

14 March 2017

Meeting Minutes

Approving last meeting's minutes https://‌www.w3.org/‌2017/‌03/‌07-sdwssn-minutes

+1

<RaulGarciaCastro> +1

<KJanowic> +1

<roba> +1

<tidoust> +1

<mlefranc> +1

minutes approved

Patent Call https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Patent_Call

1st hour - SSN, SSN+DULCE, SSN+SSNX

Forecasts and observations https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌82

DanhLePhuoc: Forecast is a long running issue already on the mailing list

DanhLePhuoc: Question: Should we cover Forecasting in SSN and if yes, how?

DanhLePhuoc: Domain Meteorology for example require forecasting, Chris, Simon are advocates for Forecasting

DanhLePhuoc_: But we have time pressure for two implementations

<DanhLePhuoc_> ask KJanowic

KJanowic: Good in theory, but it will require several new classes

<DanhLePhuoc_> ask DanhLePhuoc

KJanowic: For Forecasting to the best of my knowledge there are no reference implementation out there and that makes me concerned

<KJanowic> note that these are not just changes no property and class names, we do not know who will use the forcasting classes and whether we can get the implementations for this

DanhLePhuoc_: It is not only Weather forecasting, but predicting other measurements, e.g. in traffic management, which means it will be difficult in terms of timing

<DanhLePhuoc_> ask DanhLePhuoc_

<DanhLePhuoc_> ask ahaller2

<KJanowic> ahaller2: I am concerned about timing as well, maybe put it into a note?

<mlefranc> talking about https://‌w3id.org/‌seas/‌ForecastingOntology

<DanhLePhuoc_> ask mlefranc

maxime: Talks about the SEAS ontology and mentions that there are many new classes and properties. In the context of this group, we could just follow SimonCox's proposal on the list that if the phneomenonTime is after the ResultTime, it is a Forecast

KJanowic: Forecasting changes the balance. The weakest part of SSN is the sensor network part, which it is named after. Keep in mind how long we take to discuss sometimes one concept.

<KJanowic> Let us go back to the group and say it should go into a follow up of this group

yes, proposal

ahaller2+

<KJanowic> Danh, I would not even propose anything now, just say we cannot handle it for the current ssn

mlefranc: in favour of a vote on putting it into a note and add a frequently asked question in the main body

KJanowic: concerned about the status of a note. If we are unsure we deliver quality, are we delivering a note?

<roba> why not just an informative section in the document - lots of vocabs have guidance notes

<roba> as maxime just said

<KJanowic> Keep in mind how the XG (!) work restricts our SSN work now. A note on forcasting will do more harm than we may anticipate if the model is not well worked out.

ahaller2: thinks that non-normative is a stronger commitment than a note

<KJanowic> One more idea.

tidoust: there is no difference between the two

mlefranc: it could be a little note after the observation concept

mlefranc: a few lines in the document could suffice

tidoust: notes can be updated more easily, they are informative

<mlefranc> +1

KJanowic: in the introduction we can talk about about forecasts, and point the user to existing attempts in doing forecasts such as mlefranc's work

+1 for KJanowic

<DanhLePhuoc_> ask ahaller2

<KJanowic> not a note, a senstence in the intro

<KJanowic> agree roba, but this is why we would jointly work out a sentence based on maxime drafting 1-2 sentences

roba: sloppy terminology. SSN does support forecasting, it does not name it forecasting. So we need to be clear what support means.

mlefranc: we can mention how to do the simple way of forecasting

PROPOSED: Forecasting will not be an explicit class and associated properties in the SSN document, but we include a note how forecasting can be modelled with existing properties

<KJanowic> lets not make ssn an ontology that covers everything. lets point to maxime's work thereby acknowledging the need for forecasting and at the same time point to an example that does so using the ssn

<KJanowic> +1

<DanhLePhuoc_> +1

<SimonCox> +1

<RaulGarciaCastro> +1

<mlefranc> +1

+1

<KJanowic> (if by note you mean sentence)

yes, note = sentences

<roba> +1

<SimonCox> There is a class="note" style in the W3C CSS which puts it in a nice box

<KJanowic> Can you assign an action to maxime (assuming maxime is okay with that)?

Resolved: Forecasting will not be an explicit class and associated properties in the SSN document, but we include a note how forecasting can be modelled with existing properties

Action: mlefranc will draft a note on Forecasting to address ISSUE-82

<trackbot> Created ACTION-282 - Will draft a note on forecasting to address issue-82 [on Maxime Lefrançois - due 2017-03-21].

<KJanowic> When will we close 82?

The dul:includesEvent property has disappeared https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌117

@KJanowic we can close the issue once mlefranc has implemented the action

DanhLePhuoc_: issue raised by Raul, that by removing DUL we have no dul:includesEvent property anymore

KJanowic: was questioning if DUL is a non-normative part

ahaller2: yes, we had a resolution on DUL being a non-normative part

<KJanowic> Great!

DanhLePhuoc_: Raul raised another issue with the DUL alignment

@RaulGarciaCastro do you want to comment on this?

<DanhLePhuoc_> ask RaulGarciaCastro

<KJanowic> +1

RaulGarciaCastro: If we don't have DUL as non-normative, we need a term to link events

KJanowic: if this removes the relation between Stimulus and Observation we need to introduce a relation and align it with the dul:includesEvent property

+1 KJanowic

<RaulGarciaCastro> This is the proposal I wrote in the issue tracker: “* To create in SSN the ssn:isStimulatedBy property between ssn:Observation and ssn:Stimulus.

<RaulGarciaCastro> * To state in the SSN-DUL alignment that ssn:isStimulatedBy is a subproperty of dul:includesEvent.”

@RaulGarciaCastro action item for you?

<KJanowic> Yes, I can look into the Stimulus part. I agree with Raul that we need ssn-local relations

we vote after the solution is presented

<KJanowic> first the proposal then the vote :-)

<DanhLePhuoc_> PROPOSAL: RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117

<mlefranc> +1

+1

<RaulGarciaCastro> +1

<DanhLePhuoc_> +1

<SimonCox> We also briefly discussed on the list the idea of a :stimulusTime property (which also helps tease out some of the details needed for forecasts, where the stimulus is some current and past observations)

PROPOSAL: RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117

07: 39 mlefranc

PROPOSED: RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117

<roba> +1

<SimonCox> +1

<mlefranc> +1

<DanhLePhuoc_> +1

<RaulGarciaCastro> +1

Resolved: RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117

<KJanowic> +1

<SimonCox> This is just a vote for Raul to do some more work?

<SimonCox> More like an ACTION

<mlefranc> yes

Action: RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117

<trackbot> Created ACTION-283 - Propose a solution(adding some properties) resolve issue-117 [on Raúl García Castro - due 2017-03-21].

mlefranc: Simon had a proposal for a stimulusTime, can you outline that

SimonCox: stimulustime will be before the present time, so it is a forecast.

<KJanowic> hmmm

SimonCox: stimulustime will be the beginning of the observation, the resulttime at the end, the phenomenontime in between

KJanowic: not sure about that, because the stimulustime may start the sensor in an implementation

<KJanowic> I like the idea but I would need to think more about it. The stimulus is the thing that you cannot yet talk about (in contrast to the observation)

SimonCox: sometimes you don't know when the stimulus occurred, OWA. it makes activities sensing more like an event in the sense of an activity, with a start time and end time

KJanowic: OWA is not an excuse for delaying the effort of modelling. Simply because it is not there, it is not wrong, but we should not give the OWA as an excuse for a lack of precision in the model

<DanhLePhuoc_> KJanowic:

DanhLePhuoc_: Antoine made a comment on the mailing list. Modelling is one thing, the implementer will make decisions on how it goes into the database.

KJanowic: you will never model humans have three hands, but be ok with it, because only two go in the database

ssn:startTime and ssn:endTime https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌145

<RaulGarciaCastro> https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌123

RaulGarciaCastro: more important than this issue is the related issue 123

RaulGarciaCastro: instead of a coherent set of properties for time, we currently have 6 different ways of attaching time

KJanowic: SSN imports SOSA, so we should have a proposal to align all six

mlefranc: going through the emails, also kerry agrees in deprecating the old terms and avoid introducing new terms in SSN new

mlefranc: what are we do with the four remaining properties that are related to time

mlefranc: delete start time and delete end time

<KJanowic> I can look into this

just raise action

<KJanowic> create action, no vote needed

<KJanowic> the vote will be on whatever the action results in

Action: KJanowic will address the ISSUES relevant for temporal properties in both SOSA/SSN

<trackbot> Created ACTION-284 - Will address the issues relevant for temporal properties in both sosa/ssn [on Krzysztof Janowicz - due 2017-03-21].

<SimonCox> See https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌151 "Do we need :stimulusTime property for observation?"

<SimonCox> (new issue I just created)

<DanhLePhuoc_> Specgen doesn’t generate ssn:hasProperty and ssn:produces https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌105

<roba> Kjanowic: note QB4ST has a need to specify envelopes for dimensions, which may be temporal - would appreciate a review of that in light of your proposed solution.

Specgen doesn’t generate ssn:hasProperty and ssn:produces https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌105

<mlefranc> delay ?

<KJanowic> Thanks a lot roba, I will come back to you and simon wrt this.

<KJanowic> So how well does specgen really work for us?

CLOSE ISSUE-105

<trackbot> Closed ISSUE-105.

<mlefranc> we could use the generic tool https://‌ns.inria.fr/‌sparql-template/

<DanhLePhuoc_> Align ssn with prov-o https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌53

Align ssn with prov-o https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌53

ahaller2: proposed to not use specGen in the next iteration of the WD, but issue-105 was addressed

<KJanowic> Do we need an alignment to prov?

DanhLePhuoc_: will PROV-O be in the normative part or non-normative part

<KJanowic> same here!

RaulGarciaCastro: question is if we need these alignments?

KJanowic: we were picky about the sensor part, not do OBOE, but then PROV-O. That would be strange.

<KJanowic> then lets vote on this like we voted on OBOE

<KJanowic> Agree with ahaller2

ahaller2: agree with what was said before, and postpone the topic to next week

mlefranc: alignments in non-normative parts of the document because they are W3C standards.

<DanhLePhuoc_> Align ssn with rdf datacube https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌55

ahaller2: proposal to postpone the rdf datacube one until kerry is here

Align ssn with the ontology developed for the coverage deliverable https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌57

<SimonCox> https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌150 https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Alignment_to_OBOE

<mlefranc> agree with jano

KJanowic: understand mlefranc's argument that these are W3C rec's, but the argument earlier was made in regards to OBOE, that we just don't have time.

KJanowic: don't do things too hasty

roba: not sure how much overlap there is between coverage and SSN WD

<SimonCox> Its not actually so hard.

roba: QB4ST is just an early proposal

<KJanowic> I would like that

maxime: will there be a follow up group?

<DanhLePhuoc_> Align ssn to implement best practices as defined in our BP deliverable. https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌42

ahaller2: there may be a follow up group, but even if not, we can still have a CG

<mlefranc> i don't think we voted against an oboe alignment

<KJanowic> which vote?

<KJanowic> we did not vote against the oboe alignment, correct?

SimonCox: we have not voted on OBOE

ahaller2: There was no vote yet on OBOE not being part of the document

<KJanowic> IMHO, this is a misunderstanding. Can I address this briefly?

KJanowic: OBOE alignment is important. Last time we had very picky discussions around OBOE. The argument that was brought up that we don't have time.

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

ahaller2: There is a proposal in wiki and today, we try to vote and close the issue

<mlefranc> +1 to close and raise new

<KJanowic> +1 to close 88

ahaller2: Kerry has some concerns, but Armin suggested Kerry to raises such concerns as issues

<ahaller2> KJanowic: the original claim was that SOSA platform and SSN platform are different, and we solved this specific issue very carefully

<ahaller2> KJanowic: if we don't clean up, and other issues that radiate out of it, we can't move on

Krzysztof Janowicz & Danh Le Phuoc reporting on progress on ACTION 278, ACTION 279, ACTION 280

<ahaller2> https://‌www.w3.org/‌2015/‌spatial/‌track/‌actions/‌278

<mlefranc> (can we close the action that was assigned to me ?)

<ahaller2> @mlefranc which one?

<mlefranc> @armin ow ok it was assigned to kerry. still action 270 should be closed

<ahaller2> close action-270

<trackbot> Closed action-270.

<KJanowic> https://‌github.com/‌w3c/‌sdw/‌pull/‌618

<ahaller2> https://‌www.w3.org/‌2015/‌spatial/‌track/‌actions/‌279

<ahaller2> DanhLePhuoc_: still working on 279, only done locally

<ahaller2> https://‌www.w3.org/‌2015/‌spatial/‌track/‌actions/‌280

KJanowic: when my pull request is accepted, it will update the document

Discussion of options for the modelling of Processes/Procedures in SOSA and SSN as on the wiki at: https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Procedure_Process

<ahaller2> https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌89

ahaller2: this item was raised a long time ago

<KJanowic> and because process means something else in sensorML (e.g., a sensor)

<ahaller2> KJanowic: some of those things have been resolved. Procedure is the like the cooking recipe, i.e. it is the workflow plan

<ahaller2> @DanhLePhuoc_ please don't forget to scribe

KJanowic: the Procedure in SOSA already address some features of the Process-related properties

<KJanowic> observation, sampling, actuation are events (processes). they all follow procedures, e.g., how to measure air temperature (not one specific but measuring air temperate in general)

<ahaller2> PROPOSED: Rename Process in SSN to Procedure

<mlefranc> +1

<RaulGarciaCastro> Which of the 4 options in the wiki?

<KJanowic> +1

<ahaller2> +1

<RaulGarciaCastro> 0

<SimonCox> +1

<roba> +1

+1

Resolved: Rename Process in SSN to Procedure

<KJanowic> 3 has the subclassing 1 does not, right?

KJanowic: Option 3 is more conservative but Option 1 is also ok

<KJanowic> but option 1 generates different entailment

mlefranc: Option 1 is simpler to understand

<KJanowic> ok, fine with me. I agree with maxime and ahaller

ahaller2: Note that we have owl:equivalentClass/Property in other classes as well

<ahaller2> PROPOSED: Option 1: Rename Process to Procedure as of https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Procedure_Process

<mlefranc> +1

<ahaller2> +1

<KJanowic> +1 (as long as we revisit/change the actual code used on the wiki)

<RaulGarciaCastro> +1

+1

<roba> +1

<SimonCox> +1

<ahaller2> ahaller2: yes, code has changed since then and needs to be revisited

Resolved: Option 1: Rename Process to Procedure as of https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Procedure_Process

Action: ahaller2 to implement Option 1: Rename Process to Procedure as of https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Procedure_Process

<trackbot> Created ACTION-285 - Implement option 1: rename process to procedure as of https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌procedure_process [on Armin Haller - due 2017-03-21].

Discussion of Sampling https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Sampling ISSUE-92 https://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌92

<KJanowic> yay!

<phila> issue-92?

<trackbot> issue-92 -- Why do we need Sampling in the simple core? -- raised

<trackbot> http://‌www.w3.org/‌2015/‌spatial/‌track/‌issues/‌92

<KJanowic> Note that this will also trigger: https://‌github.com/‌w3c/‌sdw/‌commit/‌22d923b884d013cd72864f4bfabf350e71c770a0

SimonCox: Sample is involved in major cases on observations, especially in scientific publications

<KJanowic> my proposal: move fig 1 to sosa, fig2 to ssn. rename samplingactivity to sampling and samplingdevice to sampler (?)

<KJanowic> imho, waterbodies are a great example why we should have more about samples in sosa

<KJanowic> we have this raul

<KJanowic> we did this already

<ahaller2> RaulGarciaCastro: is Sample not a subclass of FeatureOfInterest

<ahaller2> SimonCox: yes, could be

<KJanowic> Simon, we have this already

<KJanowic> we addressed this in december

<ahaller2> DanhLePhuoc_: Why is Sampling in the SOSA core?

<ahaller2> DanhLePhuoc_: in Schema.org they already have an IoT core

<ahaller2> DanhLePhuoc_: maybe makes SOSA more complicated

iot.schema.org

<mlefranc> at first sight, sampling seems too similar to sensing or actuating

<KJanowic> iot.schema.org -- > does not work for me

<mlefranc> http://‌iot.webschemas.org/

mlefranc: Sampling might confuse the developer with measurement

<ahaller2> KJanowic: subclass relation should be part of SSN

KJanowic: Note that,we don't subclass in SOSA

KJanowic: I agree with the argument to keep SOSA simple, but, I suggest to add 1-2 classes to address scientific data

<KJanowic> +1 to roba, makes sense to me

<RaulGarciaCastro> That’s it!

<KJanowic> we have the sosa:hasFeatureOfInterest for sosa and can add the subclass for ssn

<KJanowic> also keep in mind that in science you very, very often work with samples of samples. more specifically every time you use data from somebody else

<RaulGarciaCastro> KJanowic, That’s the good thing of having the subclass and the isSampleOf property from and to the FoI

<KJanowic> yes!

Armin: in terms of subclass, we have ruled out the using subclasses

<mlefranc> +1

<ahaller2> Ahaller: culture heritage domain is using sampling quite extensively

<roba> +1

<ahaller2> PROPOSED: Include Sampling in SOSA core

<mlefranc> +1

<KJanowic> +1

<RaulGarciaCastro> -1

<SimonCox> +1

KJanowic: we should defer the discussion on how to it another, we should focus to voting whether to include Sampling in SOSA core

<ahaller2> +1

<roba> +1

0

<KJanowic> I would disagree here

<KJanowic> we use sampling in IoT

<roba> Raul - with the right pattern, sampling looks the same - you can look at the data and work out its smapling..

RaulGarciaCastro: I prefer to see it in SSN

<KJanowic> but you would be okay, right? so we have a majority for inclusion.

<SimonCox> SOSA also provides 'tags' for schema.org applications, not just WoT

KJanowic: we do a lot of uses case here in the WoT, we use the Sampling the heavily

<ahaller2> zakim close queue

<RaulGarciaCastro> My -1 was just to force the discussion, I can live with the 0

<KJanowic> thanks!

<ahaller2> PROPOSED: Include Sampling in SSN

<mlefranc> +1

<RaulGarciaCastro> +1

<ahaller2> +1

DanhLePhuoc_: I can live with it

<roba> -1

<KJanowic> +1 (if is is also in SOSA :-))

<KJanowic> I see roba's argument we had a positive vote on having it in SOSA

<KJanowic> +1

<SimonCox> +1 (by import from SOSA)

<KJanowic> +1

<ahaller2> PROPOSED: Include Sampling in SOSA

<KJanowic> Agree with roba

<KJanowic> +1

<ahaller2> +1

<RaulGarciaCastro> 0

<KJanowic> again, agree with roba

0

<roba> +1

<mlefranc> +1

<SimonCox> +1

Resolved: Include Sampling in SOSA

Action: simon to implement proposal on wiki in SOSA

<trackbot> Created ACTION-286 - Implement proposal on wiki in sosa [on Simon Cox - due 2017-03-21].

<KJanowic> Thanks everybody for the very constructive 2 hours!

<RaulGarciaCastro> Bye!

<KJanowic> bye bye

<roba> Bye

<ahaller2> bye

<ahaller2> type RRSAgent, draft minutes

Summary of Action Items

  1. mlefranc will draft a note on Forecasting to address ISSUE-82
  2. RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117
  3. KJanowic will address the ISSUES relevant for temporal properties in both SOSA/SSN
  4. ahaller2 to implement Option 1: Rename Process to Procedure as of https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Procedure_Process
  5. simon to implement proposal on wiki in SOSA

Summary of Resolutions

  1. Forecasting will not be an explicit class and associated properties in the SSN document, but we include a note how forecasting can be modelled with existing properties
  2. RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117
  3. Rename Process in SSN to Procedure
  4. Option 1: Rename Process to Procedure as of https://‌www.w3.org/‌2015/‌spatial/‌wiki/‌Procedure_Process
  5. Include Sampling in SOSA