Re: [Minutes] 2016-02-03

Hi Phil, all,

Apologies in retrospect that I didn’t make it to the meeting, but thanks for referencing our MELODIES work! The credit for this work should go to my colleague Maik Riechert, who has been working very hard on this. It’ll be good to open the discussion more widely through CEO-LD.

Cheers,
Jon

> On 3 Feb 2016, at 21:05, Phil Archer <phila@w3.org> wrote:
> 
> As ever, the minutes of today's meeting are at
> https://www.w3.org/2016/02/03-sdw-minutes

> 
> The black and white version is provided below.
> 
>          Spatial Data on the Web Working Group Teleconference
> 
> 03 Feb 2016
> 
>   [2]Agenda
> 
>      [2] https://www.w3.org/2015/spatial/wiki/Meetings:Telecon20160203

> 
>   See also: [3]IRC log
> 
>      [3] http://www.w3.org/2016/02/03-sdw-irc

> 
> Attendees
> 
>   Present
>          eparsons, Linda, ScottSimmons, RaulGarciaCastro,
>          BartvanLeeuwen, frans, Lewis_John_McGibbney,
>          ChrisLittle, ClausStadler, Payam, DanhLePhuoc, ahaller2,
>          robin, MattPerry, phila
> 
>   Regrets
>          Kerry, Simon, Jeremy, Lars, Clemens, Bill, Andrea,
>          Andreas, Josh
> 
>   Chair
>          eparsons
> 
>   Scribe
>          linda
> 
> Contents
> 
>     * [4]Topics
>         1. [5]F2F homework for next week
>     __________________________________________________________
> 
>   <Lewis_John_McGibbney> Afternoon Folks,
> 
>   <Lewis_John_McGibbney> Can someone PM me the Webex login?
> 
>   <Lewis_John_McGibbney> Than kyou
> 
>   <eparsons> Hello Lewis_John_McGibbney
> 
>   <eparsons> It's the topic..
> 
>   <Lewis_John_McGibbney> Grand
> 
>   <eparsons> scribe: linda
> 
>   <ChrisLittle> +1 to Linda
> 
>   <frans> thank you Linda
> 
>   eparsons: may not be a full length call
> 
>   <eparsons> Topic : Approve last week's minutes
> 
>   <eparsons> Proposed : Approve last week's minutes
> 
>   <eparsons> [6]http://www.w3.org/2016/01/27-sdw-minutes

> 
>  http://www.w3.org/2016/01/27-sdw-minutes

> 
>   +1
> 
>   <Lewis_John_McGibbney> +1
> 
>   <RaulGarciaCastro> +1
> 
>   <ScottSimmons> +1
> 
>   <frans> +1
> 
>   <ClausStadler> +1
> 
>   <DanhLePhuoc> +1
> 
>   <ahaller2> +1
> 
>   <BartvanLeeuwen> +1
> 
>   <eparsons> Resolved : Approve last week's minutes
> 
>   <ChrisLittle> 0 not oresent
> 
>   <eparsons> Topic : Patent Call
> 
>   <robin_> +1
> 
>   <eparsons> [7]https://www.w3.org/2015/spatial/wiki/Patent_Call

> 
>      [7] https://www.w3.org/2015/spatial/wiki/Patent_Call

> 
>   <eparsons> Topic : FYI Joint call with DWBP 17th February
> 
>   eparsons: the next call after the f2f will be a joint call with
>   the data on the web best practice group
>   ... to deal with items in coordination with this group
>   ... particularly the editors
>   ... may prepare this in the f2f next week
> 
>   <eparsons> Topic : Review of SSN wiki pages
> 
>   <frans> good idea to link up!
> 
>   eparsons: Kerry has asked us to do this
> 
>   <eparsons>
>   [8]https://www.w3.org/2015/spatial/wiki/SSN_Wish_List

> 
>      [8] https://www.w3.org/2015/spatial/wiki/SSN_Wish_List

> 
>   <frans> I am interested in SSN, to learn some more about the
>   subject
> 
>   eparsons: this is a link to a brain dump by Kerry about the
>   thing she expects to be part of the ssn deliverable
>   ... lets work through this list and see if anything's missing
> 
>   <Payam> +1
> 
>   eparsons: anyone closer to the topic who wants to walk us
>   through these?
> 
>   <Payam> +q
> 
>   <frans> Has anyone ever used SSN?
> 
>   Payam: i was involved in ssn work
> 
>   <KJanowicz> I was involved as well
> 
>   Payam: one of the key issues was the modularity of the
>   ontology.
>   ... we started creating modules, Simon knows a lot about this
>   ... became a complex model
>   ... we omitted multilanguage support
> 
>   <frans> Will the idea of SSN being an upper ontology remain
>   intact?
> 
>   Payam: another thing we didn't do was create tools or libraries
>   to transform CSV to SSN
> 
>   eparsons: KJanowicz has a comment
> 
>   KJanowicz: may jump in if I have comments
> 
>   Payam: ssn became popular but tools are lacking
> 
>   KJanowicz: originally semantic sensor network ontology, but
>   also went into observation part.
>   ... but missing is unit and type of measurement values
> 
>   Payam: correct
>   ... the next item: probably actuation is meant. This is not
>   supported by ssn but is requested. A group may have tried to do
>   this.
>   ... network structure: not clear what kerry means here
>   ... ssn structure is device oriented, we never looked at human
>   sensory data
> 
>   KJanowicz: ssn supports human sensors, but explicitly excludes
>   this in the definition
> 
>   <Payam> correct
> 
>   eparsons: can you clarify?
> 
>   KJanowicz: for example, if I say it is raining, this is an
>   observation
> 
>   <frans> So this is about humans using their own senses? Not
>   humans carrying devices?
> 
>   eparsons: seems like a broader scope then. Any data/observation
>   collected by any actor.
> 
>   ChrisLittle: I think it's good to have activation and
>   actuation.
> 
>   <frans> Current definition of sensor seems not to exclude human
>   senses:
>   [9]https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensor

> 
>      [9] https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensor

> 
>   ChrisLittle: and about human observations: there are frameworks
>   in which this can be very reliable information
>   ... so am in favor of them being in scope
>   ... and ogc standards support this, this could plug the gap in
>   ssn
> 
>   KJanowicz: output of computer models can also be called
>   observations
> 
>   [missed a bit]
> 
>   ahaller2: important to tackle this
>   ... about the values: important to work together with the csv
>   on the web WG.
> 
>   <KJanowicz> +1
> 
>   ahaller2: they also have a JSON encoding
> 
>   <Payam> ahaller2: it is important to work on actuation- WoT
>   group also finds this important
> 
>   eparsons: good point. There is much more interest in this from
>   a broader community now.
> 
>   ChrisLittle: csv for transmitting observations leads me to
>   think about the difference between precision and accuracy which
>   is sometimes ignored. Don't know how ssn addresses that.
> 
>   eparsons: broader than just ssn, would be good to have
>   pointers.
> 
>   <frans> Precision and accuracy should be addressed in the data
>   on the web context, I think
> 
>   Payam: systems platforms and deployment: details of this are
>   not included in ssn
>   ... e.g. what are the details of systems that should be
>   specified?
>   ... in ssn this is not specified, only some examples.
>   ... validation: we have a validation tool but this could be
>   made more formal.
>   ... like HTML validators etc.
>   ... ssn doesn't have a descriptive model for how to describe
>   location.
>   ... if sensing resources are mobile, it is unclear how to
>   specifiy this
>   ... ssn has some examples, but they are fragmented and not
>   detailed.
>   ... uncertainty: there is nothing in ssn to deal with trust,
>   quality etc.
>   ... IoT light might become a note; the idea is to have a simple
>   version, ssn light, a compact version that would be useful to
>   web of things WG.
>   ... stories: linking to best practices, examples of where ssn
>   is adopted.
>   ... Ontology classes are described etc, but there is no How to
>   get started with SSN tutorial. This would be helpful.
>   ... Also nothing about reasoning with ssn. Examples would be
>   useful.
>   ... At the moment ssn is specified in RDF, it would be good to
>   see if it can be specified in JSON(LD?)
>   ... Also, looking at provenance.
> 
>   KJanowicz: ssn emerged on the linked data side. Viewed as
>   records, while OGC views the values as events.
>   ... If we take Dolce away my proposal would be not to talk
>   about events at all.
> 
>   Payam: sampling features
> 
>   KJanowicz: in ssn there is not much about sampling strategies.
> 
>   Payam: that's it
> 
>   eparsons: any comments anyone?
>   ... or a question: how realistic is delivering 70% of those
>   wishes?
> 
>   <Payam> +q
> 
>   eparsons: seems to me like we need to prioritize them. And do
>   some scoping.
> 
>   KJanowicz: unrealistic, we should focus on ssn light
> 
>   <Payam> agree- focusing on SSN-lite is a good idea
> 
>   eparsons: do you have a particular community in mind that would
>   need ssn light?
> 
>   <Payam> +q
> 
>   <ahaller2> +1 for SSN-Lite
> 
>   <DanhLePhuoc> +q
> 
>   KJanowicz: e.g. big repositories of earth obeservation data,
>   domain models
> 
>   BartvanLeeuwen: last time i wondered why this is on our
>   charter. It's really a lot.
>   ... we could say something about how you would encode location,
>   this is close to our SDW BP work
> 
>   <eparsons> evening phil
> 
>   frans: we have a task force for ssn, what about bringing in
>   outside people to help work on this?
>   ... we are open to collaboration, right?
> 
>   eparsons: even with collaborators it's a lot of work. We should
>   focus on the spatial aspects. But collaboration would
>   absolutely be a good idea.
> 
>   <KJanowicz> we have a lot of expertise about SSN in this group
> 
>   ChrisLittle: guidance of what should be in ssn or not would be
>   good - in relation to o&m.
>   ... where's the overlap and what does ssn do that o&m doesn't?
> 
>   <KJanowicz> E.g., o&m is not about sensor networks
> 
>   eparsons: good point, could you add this to the wiki?
> 
>   <Payam> O&M is be also complex at times to describe the data;
>   isn't also described in XML?
> 
>   there's a proposed json encoding just out, Payam
> 
>   <KJanowicz> o&m as such can also not directly used for
>   semantically enabled Linked Data but there is a version from
>   SCox that does.
> 
>   Payam: ssn is popular, if we could create a working model for
>   data in ssn, this would increase the impact.
> 
>   <Lewis_John_McGibbney> I need to drop off early today folks.
>   Thanks for the insight into SSN. I am still lacking context but
>   this has helped a lot. I look forward to seeing more of this
>   topic on list.
> 
>   Payam: e.g. location specification and measurement data and
>   make it modular and extensible
> 
>   <eparsons> action ChrisLittle to add to wiki SSN vs. O&M
>   illustration
> 
>   <trackbot> Created ACTION-134 - Add to wiki ssn vs. o&m
>   illustration [on Chris Little - due 2016-02-10].
> 
>   DanhLePhuoc: I'm currently in Web of THings WG. We have a lot
>   of industry parties that have sensor devices.
>   ... they want interoperability and ssn is a candidate.
>   ... problem is ssn is to big, ssn-lite is needed
>   ... good modular version would be adopted 6 months ago
>   ... internet of things needs spatial data
> 
>   <Payam> +q
> 
>   eparsons: for ssn-lite we would need to identify clearly what
>   the target community is.
> 
>   KJanowicz: ssn is broader than o&m. The latter is not about
>   sensor network etc.
>   ... secondly, a lot of data does not require a lot of detail,
>   often not entire ssn is needed, only a metadata record about
>   the instrument, eg in oceanography.
>   ... ssn lite would rule here too
> 
>   Payam: ssn can now not be used for annotating data
> 
>   <KJanowicz> I could not hear Payam
> 
>   ChrisLittle: I may be misunderstanding but there are a lot of
>   standards on top of o&m that allow you to describe networks etc
>   ... thats why scoping ssn is important
> 
>   <KJanowicz> There is a lot of voice
> 
>   <KJanowicz> noise
> 
>   ChrisLittle: in metereology and oceanography etc there are a
>   lot of ontologies existing. A lot of work done.
> 
>   <eparsons> KJanowicz can you 1:1 with Payam
> 
>   <Payam> I said that SSN specifies abstract concepts and their
>   relations; SSN-Lite should help to create SSN instances to
>   describe sensors/data
> 
>   thanks payam
> 
>   <frans> Thanks, the SSN information was educational.
> 
>   eparsons: thanks for this useful discussion and ideas.
> 
>   <KJanowicz> ChrisLittle: yes, see
>   [10]http://schema.geolink.org/

> 
>     [10] http://schema.geolink.org/

> 
> F2F homework for next week
> 
>   eparsons: one of the requirements is to continue work on the
>   BP. For that we need examples!
>   ... Bring examples to the f2f that can fit into the BP. There
>   are slots for them already in the BP.
>   ... Examples should be on the web; with a description why it is
>   a best practice.
>   ... Really helpful if we can get plenty of these.
> 
>   <Payam> +q
> 
>   phila: Can you prioritise? Try to match best practices with
>   specific persons?
> 
>   frans: can we bring examples of not so good practices?
> 
>   <KJanowicz> +1 for the anti-patterns
> 
>   <ScottSimmons> must leave early, bye
> 
>   eparsons: absolutely
> 
>   <ChrisLittle> +1 to bad practice
> 
>   Payam: We editors discussed this. If someone has a model
>   example, we can discuss this and gain concensus on how to
>   specify the examples.
>   ... during the meeting we can then assign tasks to specific
>   persons.
> 
>   eparsons: what mechanism?
> 
>   Payam: email list
>   ... we need to have 1 or 2 to start with, so we can decide what
>   the form should be.
> 
>   eparsons: anyone who can contribute one before next week?
> 
>   BartvanLeeuwen: as narrative or as something I can show?
> 
>   <Payam> +q
> 
>   eparsons: not a huge narrative, something you can point at and
>   a sentence describing it would be good
> 
>   BartvanLeeuwen: will see what I can do
> 
>   <eparsons> Topic : CEO-LD Report
> 
>   <phila> [11]CEO-LD Project
> 
>     [11] https://www.w3.org/2015/ceo-ld

> 
>   <eparsons> action BartvanLeeuwen Email Public List with example
>   of BP as an initial example for F2F
> 
>   <trackbot> Error finding 'BartvanLeeuwen'. You can review and
>   register nicknames at
>   <[12]http://www.w3.org/2015/spatial/track/users>.
> 
>     [12] http://www.w3.org/2015/spatial/track/users

> 
>   phila: project funded by british embassy in Beijing. It's a
>   specifically UK thing.
>   ... idea is that they will contribute to Coverage work of this
>   WG
>   ... everyone involved in CEO-LD group is involved in this group
>   as well.
>   ... next meeting Sunday 28th february. Nothing has been done
>   since September.
>   ... Jon Blower has done cool work regarding this
> 
>   <phila> [13]Coverage Data REST API Core Specification
> 
>     [13] https://github.com/Reading-eScience-Centre/coverage-restapi/blob/master/spec.md

> 
>   phila: covers things we will be concerned about in this group
>   when we work on this
>   ... eg subsetting, how webby is it, etc
>   ... if you're interested in coverages, look at this work
>   ... see the Melodies project for this
> 
>   <eparsons> 2 minute warning !!!
> 
>   phila: chunks of this work could be useful also for our BP
>   ... talks about JSON, content negotiation, and other stuff we
>   could find useful. Thanks to Jeremy for pointing this out.
> 
>   <phila> [14]Mailing list
> 
>     [14] https://lists.w3.org/Archives/Public/public-ceo-ld/2016Feb
> 
>   phila: project is open to anyone to join the mailing list
> 
>   <BartvanLeeuwen> see you next week !
> 
>   <phila> Linda++
> 
>   KJanowicz: [missed that last bit]
> 
>   <KJanowicz> +1 for Linda
> 
>   <ChrisLittle> bye and thanks to Linda
> 
>   <KJanowicz> bye bye
> 
>   <Payam> thanks and bye
> 
>   eparsons: thanks everyone!
> 
>   <eparsons> bye !!
> 
>   bye!
> 
>   <frans> bye!
> 
>   [End of minutes]
>     __________________________________________________________
>

Received on Thursday, 4 February 2016 10:33:41 UTC