See also: IRC log
<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
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
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
<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