- From: Phil Archer <phila@w3.org>
- Date: Wed, 13 Jul 2016 16:10:36 +0100
- To: SDW WG Public List <public-sdw-wg@w3.org>
The minutes of this week's SSN meeting are at https://www.w3.org/2016/07/12-sdwssn-minutes with a snapshot below. [1]W3C [1] http://www.w3.org/ Spatial Data on the Web SSN Sub Group Teleconference 12 Jul 2016 See also: [2]IRC log [2] http://www.w3.org/2016/07/12-sdwssn-irc Attendees Present kerry, KJanowic, SimonCox, DanhLePhuoc, roba, RaulGarciaCastro, scottsimmons Regrets Chair kerry Scribe KJanowic Contents * [3]Topics 1. [4]patent call https://www.w3.org/2015/spatial/wiki/Patent_Call 2. [5]SSN Requirements from UCR 3. [6]ISSUE-20 Reference external vocabularies 4. [7]ISSUE-24 clarification of lightweight APIs requirement 5. [8]Suggested changes to ontology editing process/tooling 6. [9]SOSA/SANDA? * [10]Summary of Action Items * [11]Summary of Resolutions __________________________________________________________ I can scribe :-) <kerry> scribe: KJanowic <kerry> scribenick: KJanowic patent call [12]https://www.w3.org/2015/spatial/wiki/Patent_Call [12] https://www.w3.org/2015/spatial/wiki/Patent_Call kerry: Discussion of how much change we can/should do compared to OWL:Time ... Dont delete but deprecate Simon: we are fine as long as we use a new namespace kerry: Agreed, but this is also about respecting the current user base <ahaller2> s/dont/don't Try to avoid removing parts of the ontology (axioms) ahaller2: we use a new namespace so we should be fine. The core will be significantly different but one of the other layers would be very similar to the existing SSN. Kerry: fair enough. We have more flexibility than OWL:Time <ahaller2> +1 for not adding deprecated classes in the core +1 Sure, I know this kerry: Agreed but we need to take it back to the group and be respectful of existing users Simon: I am pretty sure that this only applies for a previously published namespace. ... protecting users is done via not making changes to the existing namespace. kerry: lets wait for Phil and move on in the agenda SSN Requirements from UCR kerry: This is purely a reminder to have a look at UCR and that we are all happy with the current content. ISSUE-20 Reference external vocabularies <kerry> issue-20? <trackbot> issue-20 -- Reference external vocabularies -- open <trackbot> [13]http://www.w3.org/2015/spatial/track/issues/20 [13] http://www.w3.org/2015/spatial/track/issues/20 <kerry> ? kjanowic: isn't this about nomenclature? If so, we should deal with it ... so this is also about typecasting between class and entity based classifications, right? Rob: We also need to look into units of measure [My daughter just woke up, can somebody please scribe for 2min?] <kerry> roba: no the issue does not need to stay as it will be picked up by broader best practice environment although it is relevant <kerry> ....whether uom should be part of ssn for example? <roba> i'll scribe <kerry> ACTION: frans to close issue-20 please [recorded in [14]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01] [14] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01] <trackbot> Created ACTION-184 - Close issue-20 please [on Frans Knibbe - due 2016-07-19]. <roba> ...pointed out that its a general BP - but a Use Case and consideration of UoM as a challenge is SSN space ISSUE-24 clarification of lightweight APIs requirement <roba> ...kerry - consensus is then the close issue <kerry> issue-24? <trackbot> issue-24 -- clarification of lightweight APIs requirement -- open <trackbot> [15]http://www.w3.org/2015/spatial/track/issues/24 [15] http://www.w3.org/2015/spatial/track/issues/24 <roba> raul - infrastructure requirement not onotology req. <roba> armin - agree its infrastructure but points out that lightweight core will support lightweigt APIs <roba> kerry - UCR closing - need concrete proposal [I am back, sorry] <ahaller2> ahaller- <roba> Danh - more general problem? <roba> Kerry - change to an example Danh: Rephrase this requirement to the lightweight profile of the ontology wrt IoT. <RaulGarciaCastro> +1 <roba> roba: req reads like it is intended to ensure SSN is relevant to the IoT space - but we would need the IoT req stated <DanhLePhuoc> +1 <roba> +1 <ahaller2> +1 <kerry> +1 Proposal: Ask Franz to rephrase +1 <kerry> ACTION: frans to rephrase issue-24 requirement to something like "develop lightweight profile of the ontology for IoT" [recorded in [16]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02] [16] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02] <trackbot> Created ACTION-185 - Rephrase issue-24 requirement to something like "develop lightweight profile of the ontology for iot" [on Frans Knibbe - due 2016-07-19]. Sounds good to me whether this is about profiles or not is another story that we can discuss at a later time Simom: Develop an example how the ontology can be used. The SOSA Core is not a profile. Kerry: Show how the ontology can be used for lightweight IOT needs. <ahaller2> maybe "require a lightweight way to exchange data according to the SSN ontology" see above <ahaller2> "in the IoT context" final version: Show how the SSN ontology can be applied in the context of lightweight IoT needs Okay> Okay? <ahaller2> APIs are always about exchange <ahaller2> +1 <roba> +1 <DanhLePhuoc> +1 <RaulGarciaCastro> +1 <kerry> ACTION: frans to fix issue-24 by replacing requirment to "Show how the SSN ontology can be applied in the context of lightweight IoT needs" [recorded in [17]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03] [17] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03] <trackbot> Created ACTION-186 - Fix issue-24 by replacing requirment to "show how the ssn ontology can be applied in the context of lightweight iot needs" [on Frans Knibbe - due 2016-07-19]. Suggested changes to ontology editing process/tooling Ahaller2: We moved the ontology away from Webprotege for may reasons, one of them being issues with the namespace. This makes it pretty unusable for our work. Proposal was to use github. ... Most people will edit the file directly. We can usue whatever we want as long as we are carful with our github pull requests and the way we handle the raw file SOSA/SANDA? <SimonCox> I find TopBraid generates a very consistent serialization. It just isn't the same as Protege ... See: [18]https://github.com/w3c/sdw/blob/kjanowicz-ssn/ssn/rdf/sosa. ttl [18] https://github.com/w3c/sdw/blob/kjanowicz-ssn/ssn/rdf/sosa.ttl <roba> KJanowic: - didnt get that sorry.. <roba> Kerry: asks for summary Ahaller2: What we did was taking kjanowic work, add the actuator class and then change the name and so forth. ahaller starting the discussion on process and procedure <SimonCox> Armin + Simon worked on SANDA - [19]http://webprotege.stanford.edu/#Edit:projectId=32a4ea9e-4d0 6-4f92-8188-07fcd96f81a7 [19] http://webprotege.stanford.edu/#Edit:projectId=32a4ea9e-4d06-4f92-8188-07fcd96f81a7 <SimonCox> Simon and Jano worked on [20]https://www.w3.org/2015/spatial/wiki/SOSA_Ontology [20] https://www.w3.org/2015/spatial/wiki/SOSA_Ontology <SimonCox> Re Procedure - should be " ... responsible for generating an observation result or another change in the world" <ahaller2> +1 on distinguishing the instruments and the procedure. This was definitely my intention in the first proposal of the core <RaulGarciaCastro> +1 ahaller2, great. But if you look at samplingprocedure and procedure now, only sampling procedure is about a procedure. simon: agreed, there is some confusion that we need to clean up <ahaller2> KJanowic: That was a problem of wrong documentation of the class. <ahaller2> KJanowic: Webprotege was playing up with us <ahaller2> KJanowic: reintroducing rdf:comments for whatever reason aheller2: Sure, I just wanted to point this out same for Results being only created by Sensors (I already changed this) Very important issue <ahaller2> +1 to KJanowic, the procedure is measuring the temperature of soil or air, depending on how you use the SensingDevice <roba> +1 to KJanowic <RaulGarciaCastro> +1 <SimonCox> ObservingProcedure is subclass of Procedure and superclass of Sensor? <ahaller2> SimonCox: we called it Sensing, didn't we <SimonCox> Procedure is also superclass of ActuatingProcedure and SamplingProcedure <SimonCox> ?? Simon: IMHO, the procedure is like to cookbook recipe. It is not a superclass of sensor. <SimonCox> Yes - Sensing/Actuating/Sampling better names <ahaller2> Then yes <SimonCox> Agree - is recipe, not device <SimonCox> Uses a device It is a bridge to workflows <SimonCox> Agree Kerry: sorry, yes I will yes, so if the procedure is a sequence of actions (like in a receipt) and not a device, than we should change the description Rob: There needs to be a method to identify a procedure as well as to describe it <ahaller2> +1 to change the description. I think we all are on the same page great. We are also talking about the subtle differences between sensing and a procedure Rob: Just needs to be clear to the usage <kerry> krz: there are instruments, that might be a specific sensor that <kerry> ...carries an observation, a sensing is always tking place.. <kerry> ...but an observation procedure is more of a'to take a measurement do these steps" <kerry> ...this is a procedure that makes sure [missed] <kerry> ...want to be as inclusive as we can e,g instruments and human sensors <ahaller2> SensingDevice is an Instrument <ahaller2> We need to be careful with the Sensor class, this is why we renamed it to Sensing, because Sensor sounds like a device <kerry> .... want to distinguish describing a procedure from [missed] <roba> works for me - needs to be front anb centre of description If this is okay with everybody, I can do the change in SOSA (this is all just about the comment, there is no axiom anyway :-)) <kerry> armin: need to be careful with sensor class which sounds like an instrument ahaller2: lets be careful with sensor class as it sounds like an instrument. sensing is the super class ... we should use sensing <kerry> ... but sensing is a superclass..., sensor could be confused with sensing device Danh: Completely different question: What about the way we are coding, i.e., RDF versus OWL. <ahaller2> Sensing would not be the Instrument <roba> agree <kerry> krz: sensing implies an action, we need to discuss how to call this on the email list -- the procedure and the thing that executes it is doffernt <ahaller2> SensingDevice is the Instrument <ahaller2> Human could be the Instrument In short: there is the procedure and the XYZ that carries out this procedure to generate a valid observation <ahaller2> yes The question is how we call XYZ so that it includes sensors, simulations, humans,... kerry closing the meeting <ahaller2> XYZ could be Sensor, but not sure about the name <SimonCox> ObservingProcedure? <SimonCox> EstimatingProcedure? Summary of Action Items [NEW] ACTION: frans to close issue-20 please [recorded in [21]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01] [NEW] ACTION: frans to fix issue-24 by replacing requirment to "Show how the SSN ontology can be applied in the context of lightweight IoT needs" [recorded in [22]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03] [NEW] ACTION: frans to rephrase issue-24 requirement to something like "develop lightweight profile of the ontology for IoT" [recorded in [23]http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02] [21] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action01 [22] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action03 [23] http://www.w3.org/2016/07/12-sdwssn-minutes.html#action02 Summary of Resolutions [End of minutes] __________________________________________________________
Received on Wednesday, 13 July 2016 15:09:26 UTC