Spatial Data on the Web SSN Sub Group Teleconference

I can scribe

:-)

<kerry> scribe: KJanowic

<kerry> scribenick: KJanowic

patent call 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> 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 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> 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 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 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: 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 - http://webprotege.stanford.edu/#Edit:projectId=32a4ea9e-4d06-4f92-8188-07fcd96f81a7

<SimonCox> Simon and Jano worked on 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?