See also: IRC log
<billroberts> https://www.w3.org/2015/spatial/wiki/Meetings:Coverage-Telecon20160504
<Kerry__> scribenick: kerry
<billroberts> https://www.w3.org/2016/04/20-sdwcov-minutes
<Kerry__> proposed: approve minutes https://www.w3.org/2016/04/20-sdwcov-minutes
<billroberts> +1
<Maik> +1
<ScottSimmons> +1
<sam> +1
RESOLUTION: accept minutes https://www.w3.org/2016/04/20-sdwcov-minutes
<billroberts> https://www.w3.org/2015/spatial/wiki/Patent_Call
<Kerry__> patent call
<billroberts> https://www.w3.org/2015/spatial/wiki/Coverage_Solution_Criteria
<Kerry__> bill: billroberts discussed criteria and also updates wiki page
<Kerry__> billroberts: also had presentation from ANU team
<Kerry__> ... suggest w have update from ANU and Maik at Reading today, then plan wehat to do next
<Kerry__> ... invite sam or Duo to speak
<Kerry__> Duo: not much to say -- getting protoype working but not quite ready to show off
<Kerry__> ...we have some data in a live application but not quite uasable or interactive yet -- will take another week or 2
<Kerry__> billroberts: anything stood out as challenging or othereise of interest to us?
<Kerry__> Duo: just getting things to run and work together
<Kerry__> .... how to create sparql queries that are efficient enough for coverage data -- we have identified this as significant
<Kerry__> billroberts: spaql on large data or with complicated joins is more than an art than a science and can be implementation dependent
<Kerry__> ...some trial and error for how to best write the query
<Kerry__> which sparql?
<Kerry__> billroberts: duo: jena and fuseki
<Kerry__> billroberts: jena list is very helpful
<Kerry__> ... please let me know when you have something to show and we will schedule it
<Kerry__> billroberts: how is coveragejson going?
<Kerry__> maik:spoke at egu, got good feedback
<Kerry__> .. completely different to what exists now -- at first confused but then positive
<Kerry__> maik: been looking at what exactly json-ld means for coveragejson
<Kerry__> ... this is a coveragejson doc with json-ld context
<Kerry__> ...some perople were asking about this
<Kerry__> s/perope/people/
<Kerry__> ...also how to express quesantity types, fractions, etc, pls see our issues page and cookbook we are writing
<Maik> https://github.com/Reading-eScience-Centre/coveragejson/issues/63
<Kerry__> billroberts: rdf datacube has dealt with these questions too and might help here
<Kerry__> Maik: here is what we are looking at for rgb bands.
<Maik> https://github.com/neothemachine/xndarray
<Kerry__> ...am writing a javascript library for arrays called (missed it)
<Kerry__> ... more lightweight than others for mutidimensional data, expecially for coveragejson multidimensional range objects
<billroberts> (library called xndarray)
<Kerry__> ...will have coordinates some time
<Kerry__> ...that's it...
<Kerry__> billroberts: collaboration with beijing re CEO-ld -- have you heard anything?
<Kerry__> Maik: they have implemented coveragejson from scratch with geotiff and landsat
<Kerry__> ... see how to efficiently have an api for big amounts of statellite images
<Kerry__> billroberts: uses a geotiff to ccoveragejson converter
<Kerry__> billroberts: how do we take our scoping work and use it?
<Kerry__> .... we should aim towards producing a spec
<Kerry__> ...as well we also need a primer to esxplain what we are trying to achieve
<Kerry__> s...can use these solution criteria
<Kerry__> ...but need to go further on exploringdetails on what that would be
<Kerry__> ...thinking to continue both tracks as at present and at some point we compare these solutions to criteria and make a proposed solution
<Kerry__> ... also need to test alongside existing technology such as wcs
<Kerry__> ... to demonstrate we have something to offer
<Zakim> phila, you wanted to answer Duo's question
<Kerry__> phila: an implementation for a spec needs 2 independent implementations of every feature of the sepc, so it's a high bar!
<Kerry__> ... needs to be as good as html or css...
<Kerry__> ...if ANU does na REading does and they both implement everything, but we really would like a third too
<Kerry__> .... and a common test suite is needed too, and exmaples
<Kerry__> ... if we are going for something as solid as that then we need all this
<Kerry__> billroberts: then we also need to be canvassing for people outside this meeting for implementations too
<Kerry__> phila: If we say 'who wnats to do cool map overlays" etc we can get a huge amount of interest if we do this right
<Kerry__> billroberts: amybe SWIRRL too
<Kerry__> phila: SWIRRL as a commercial player is a plus -- working with the universities here
<Kerry__> billroberts: we could do this if it works for our use cases
<Kerry__> ....evidence of commercial application is extra power it seems
<Kerry__> phila: yes. shows it has value
<Kerry__> billroberts: is a spec that works towards a rec plus a primer as a technical note ok?
<Kerry__> phila: that is one way, but not the only way.
<Kerry__> phila: matbe unlike ssn, the test suite may be important itself as supplmentary material
<Kerry__> ... also whatever OGC needs
<Kerry__> billroberts: so... how do we get to that point/
<Kerry__> billroberts: will cjheck over which BPs need we need to take into account
<Kerry__> ..we may need to move requiremnt to formal testable form
<phila> Activity Streams
<Kerry__> kerry: suggest looking at WCS too for an idea
<Kerry__> Duo: testing framework -- who would develop this suite?
<phila> Build the suite as you go, then rationalise into a doc
<Kerry__> ... we'd like to strt building ad testing against this asap
<Kerry__> billroberts: agrees... we will need volunteers
<Kerry__> ScottSimmons: we can use ogc teamengine for test development as it will need one for spec anyway
<Kerry__> ...ogc does note require multiple implementations but the test suite is very important
<Kerry__> ...this staurday there might be a decision that will affect the standard tier wrt reference implementations
<Kerry__> billroberts: "abstract test suite"
<Kerry__> ScottSimmons: set out in words that exaplins what a physical test suite would look like
<Kerry__> [scott looks for an abstract test suite to share]
<ScottSimmons> look at Annex A in http://docs.opengeospatial.org/is/14-100r2/14-100r2.html
<Kerry__> billroberts: so we need our requirements formalised, a test suite, and in the meantime example implementations to carry on. then we can evaluate implementations against the requirements
<Kerry__> ... implementations will also help us to understand appropriateness for requirements
<Kerry__> phila: requirements are always important becuase they help you develop the test suite -- as an anchor-- but alsway leave out or cover up stuff
<Kerry__> ...suc has huge assumptions
<Kerry__> ...we have a good UCR
<Kerry__> ..does not say "the Web has to exist' as it is assumed
<Kerry__> ...but just doing what the requirements says can be silly
<Kerry__> we have one verty advanced and one rapidly developing group, plus commercial interst, plus chinese group so we have time to work on this
<Kerry__> ..if we can develop some of that test data too and get in place by (northern) summer break we'd be cooking with gas
<Kerry__> ...i would be happy to say then that we are making progress, but if we get to september still messing around, im not so sure..
<Kerry__> billroberts: all good.
<Kerry__> billroberts: will take first attempt at requirements
<phila> Kerry__: Don't forget that the WG's UCR already exists :-) https://www.w3.org/TR/sdw-ucr/
<Kerry__> billroberts: any other questions?
<phila> s/sdw-ucr/TR\/sdw-ucr/
<Kerry__> Maik: how concrete or abstract would they be?
<Kerry__> ... itsounds like they have to be abstract
<Kerry__> billroberts: needs to be concrete while expressing what, not how
<Kerry__> ...requirements doc, not design doc
<Kerry__> ...not excessively prejudging the soluti0ons
<Kerry__> ...will try writing something
<Kerry__> billroberts: close meeting
<billroberts> thanks kerry!
<billroberts> thanks everyone