Spatial Data on the Web Working Group, SSN Sub Group Teleconference

<KJanowicz> has the meeting started?

<JRamsay> sorry, whats the webex password again?

hi Kerry, where can I the meeting Id and password?

<robin> Meeting ID is 647 066 501

<robin> I find from this https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20160419

<RaulGarciaCastro> it is

<robin> But I don't know the password

<robin> Thank you

<KJanowicz> kerry, you are breaking awar, maybe turning your head away from the mic

<KJanowicz> i can do it

<kerry> scribe: DanhLePhuoc

<kerry> scribeNick: DanhLePhuoc

<kerry> patent call: https://www.w3.org/2015/spatial/wiki/Patent_Call

is it this one? https://www.w3.org/2016/04/13-sdw-minutes

<kerry> http://www.w3.org/2016/04/05-sdwssn-minutes

<kerry> aprove minutes: http://www.w3.org/2016/04/05-sdwssn-minutes

<kerry> +1

<RaulGarciaCastro> +1

+1

<robin> +1

minutes approved

Modularity: discuss Armin's proposal

First item for meeting is : Modularisation

http://w3c.github.io/sdw/ssn/#Modularisation

Armin: the current version proposes two ways of modularisation: Vertical Segmentation and Horizontal Segmantation

The main idea ofr Vertical segmentation is to use a subset of modules/concepts without having uses another part

In the other hand, it's a bit tricky in the Horizontal Segmentation

KJanowicz: is possible to get rid of DUL completely?

kerry: it is worth to use DOCLE as it has its own community and we might need similar one to fill in the missing concepts

KJanowicz: be aware of maintenance problem of DOCLE
... I was among the one that proposed to use DOCLE for SSN
... I'm fine with keep it but I would like to highlight the issues

<RaulGarciaCastro> +1 to having it out of the recommendation

+1 for leaving DOCLE out this recommendatin

<ahaller2> agnostic about it, but keeping it out of the standard may be a good solution

<KJanowicz> +1

RESOLUTION: that DUL alignment becomes a note or some other product outside the recommendation

<KJanowicz> +1

+1

KJanowicz: would it make sense to have different level of complexity?

<KJanowicz> so, simple observation model module, sensor module, observation module, deployment module, and a sampling module

ahaller2: I don't see any use case to have to many separated modules

KJanowicz: I have a project only have observations, but there are some other UCs can combine some subsets of deployment, sensor module....

ahaller2: the core sensor module would be enough concepts and properties to cover most of the need
... the core sensor module would have enough concepts and properties to cover most of the need
... I meant sensing device core

<KJanowicz> rename sensing deviced core into sensor and observation core

ahaller2: a minimal subset of sensing device at very abstract level but cover most of generic and simple cases

<KJanowicz> keep in mind that there are many orders of magnitude more observations than sensors

kerry: the ways of current SSN used vary a lot in terms of grouping the concepts/modules, like IoT-Lite

ahaller2: the core sensing device is proposed is similar to IoT-lite, but it's is in more light-weight

<Zakim> RaulGarciaCastro, you wanted to talk about vertical and horizontal segmentation

ahaller2: if we pulled out too many modules, it's really hard to know what it is a module

<KJanowicz> I would still propose to have something like a minimal sensor-observation model

RaulGarciaCastro: introducing more modules might be more confusing

<kerry> +q

<KJanowicz> I agree with ahaller2 heree

ahaller2: in the end: what is our core? defining sensor as the central concept or sensor-obversion is the core here

KJanowicz: SSN was the first effort that put sensor and observation together to make them usable in many cases over the year

<KJanowicz> +1 for the alignment based version

<KJanowicz> q_

kerry: the concepts and properties can be added gradually via alignments to make them more flexible

<KJanowicz> great idea!

<KJanowicz> yes, lets do this!

ahaller2: each of us will group the classes in modules to bring to the next meetings to discuss

<ahaller2> +1

+1

<RaulGarciaCastro> +1

<KJanowicz> +1

<ClausStadler> +1

<kerry> ach DanhLePhuoc

"Sensor" related to DUL: not a physical object, should be an Object?

kerry: we can discuss about we can discuss logic profiles.e.g, RDFS, OWL ... in later stages

in current "Sensor" is very general concept

<KJanowicz> this will cause problems

<ahaller2> +1 on moving sensor up in the hierarchy

kerry: I put the alignment by : Sensor is subclass of dul:Object

<KJanowicz> yes, I will

<KJanowicz> I also agree that sensors should include humans and simulations

KJanowicz: will need to look closely to this issue

<KJanowicz> I think computation in DUL will be in the 'abstract' part of DUL. I will check

Sensor" annotation: clarify relation to O&M Concept

<ahaller2> +1 reasonable

+1

<KJanowicz> +1

RESOLUTION: sensor annotation adjusted as discussed

<ahaller2> we don't have a resolution yet, though

kerry: we will bring up the issues to the big meeting

ahaller2: it might be a bit early to bring to the big meeting due to a lot of uncertainty a.t.m

<KJanowicz> thanks, bye bye

<RaulGarciaCastro> Bye!

bye!

<kerry> rrsagent: draft minites

<robin> Thanks, bye