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
<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
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> (if by note you mean sentence)
yes, note = sentences
<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?
@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
DanhLePhuoc_: Raul raised another issue with the DUL alignment
@RaulGarciaCastro do you want to comment on this?
<DanhLePhuoc_> ask RaulGarciaCastro
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
<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
<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
Resolved: RaulGarciaCastro to propose a solution(adding some properties) resolve ISSUE-117
<SimonCox> This is just a vote for Raul to do some more work?
<SimonCox> More like an ACTION
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.
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_: 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
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.
<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?
<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
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
<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.
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
<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.
<ahaller2> DanhLePhuoc_: still working on 279, only done locally
KJanowic: when my pull request is accepted, it will update the document
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
<RaulGarciaCastro> Which of the 4 options in the wiki?
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
<KJanowic> +1 (as long as we revisit/change the actual code used on the wiki)
<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].
<trackbot> issue-92 -- Why do we need Sampling in the simple core? -- raised
<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
<mlefranc> at first sight, sampling seems too similar to sensing or actuating
<KJanowic> iot.schema.org -- > does not work for me
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
Armin: in terms of subclass, we have ruled out the using subclasses
<ahaller2> Ahaller: culture heritage domain is using sampling quite extensively
<ahaller2> PROPOSED: Include Sampling in SOSA core
KJanowic: we should defer the discussion on how to it another, we should focus to voting whether to include Sampling in SOSA core
<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
<ahaller2> PROPOSED: Include Sampling in SSN
DanhLePhuoc_: I can live with it
<KJanowic> +1 (if is is also in SOSA :-))
<KJanowic> I see roba's argument we had a positive vote on having it in SOSA
<SimonCox> +1 (by import from SOSA)
<ahaller2> PROPOSED: Include Sampling in SOSA
<KJanowic> Agree with roba
<KJanowic> again, agree with roba
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!
<KJanowic> bye bye
<ahaller2> type RRSAgent, draft minutes