Re: Coverage subgroup update

Hi Jon,

thank you for the pointer; not sure though I could be of help, my earlier
attempts to chime in have been remarkably ignored. I will be curious to go over
the SDW work once all is final & frozen, but I am more than engaged already with
OGC + ISO + INSPIRE work.

thanks for your understanding,
Peter


On 07/25/2016 12:16 PM, Jon Blower wrote:
>
> Hi Peter,
>
>  
>
> Ø  I'll be curious of course to study your work, kindly let me know about its
> final release.
>
>  
>
> Well, the work is not absolutely “final” yet, but now is a very good time to
> hear your comments. The work is pretty well developed and we are unlikely to
> make any major changes before the final release. It is better for you to
> comment now rather than when it is too late! ;-)
>
>  
>
> The overall website is http://covjson.org and the easiest place to start is
> with the Cookbook, which also contains examples. The gory details are in the spec.
>
>  
>
> Best wishes,
> Jon
>
>  
>
>  
>
> *From: *Peter Baumann <p.baumann@jacobs-university.de>
> *Organization: *Jacobs University Bremen
> *Date: *Thursday, 21 July 2016 13:36
> *To: *Jon Blower <sgs02jdb@reading.ac.uk>, Bill Roberts <bill@swirrl.com>,
> "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
> *Cc: *Maik Riechert <m.riechert@reading.ac.uk>
> *Subject: *Re: Coverage subgroup update
>
>  
>
> Hi Jon,
>
> On 07/20/2016 08:30 AM, Jon Blower wrote:
>
>     Hi Peter,
>
>      
>
>     Ø  redefining "coverage" is detrimental.
>
>      
>
>     To my knowledge we are not redefining “coverage”. The term is defined in
>     ISO19123 (which gives the overall abstract concepts as you know) and I
>     consider CovJSON to be fully conceptually compatible with that. As has
>     been discussed many times, there are many ways to concretely serialise a
>     coverage, all of which may be compatible with the abstract concepts of
>     ISO19123.
>
>
> Exactly, and implementations of 19123 in general are well known to be
> incompatible. One reason why ISO will revamp 19123 into 19123-1 and have the
> OGC Coverage Implementation Schema as its concretized, interoperable 19123-2.
>
>
>      
>
>     If you can point to a specific instance where you believe we are not
>     compatible with the abstract model, please do point it out and we will
>     look at it seriously.
>
>
> I'll be curious of course to study your work, kindly let me know about its
> final release.
>
>
>      
>
>     Ø  your model might become an additional encoding, based on a
>     compatibility exercise.
>
>      
>
>     Yes, exactly. I imagine there would be some kind of a mapping exercise, a
>     bit like the mapping to the existing CF-NetCDF standard.
>
>
> seems we have a nice coherence in this point!
>
> cheers,
> Peter
>
>
>      
>
>     Cheers,
>     Jon
>
>      
>
>     *From: *Peter Baumann <p.baumann@jacobs-university.de>
>     <mailto:p.baumann@jacobs-university.de>
>     *Organization: *Jacobs University Bremen
>     *Date: *Wednesday, 20 July 2016 07:04
>     *To: *Jon Blower <sgs02jdb@reading.ac.uk> <mailto:sgs02jdb@reading.ac.uk>,
>     Bill Roberts <bill@swirrl.com> <mailto:bill@swirrl.com>,
>     "public-sdw-wg@w3.org" <mailto:public-sdw-wg@w3.org>
>     <public-sdw-wg@w3.org> <mailto:public-sdw-wg@w3.org>
>     *Cc: *Maik Riechert <m.riechert@reading.ac.uk>
>     <mailto:m.riechert@reading.ac.uk>
>     *Subject: *Re: Coverage subgroup update
>
>      
>
>     Hi Jon,
>
>     of course I am in no way impeding scientific work on establishing and
>     evaluating alternative concepts, and I am by no means questioning the
>     merits of your approach.
>
>     From a standards point of view, however, it is essential that one term has
>     one definition, so redefining "coverage" is detrimental. But you open a
>     door by suggesting your model might become an additional encoding, based
>     on a compatibility exercise.
>
>     PS: Just to mention this, the OGC coverage model never enforced GML (just
>     aligned to its conceptual structure and offered GML as one option), and
>     neither did WCS (cf Core). Starting CIS 1.1, JSON and RDF are supported as
>     well, so an implementation may well reside in RDF world, or NetCDF world,
>     or any other encoding/service style world exclusively.
>
>     cheers,
>     Peter
>
>
>     On 07/20/2016 01:45 AM, Jon Blower wrote:
>
>         Hi Peter,
>
>          
>
>         It depends exactly what you mean by “aligned”. Certainly CovJSON uses
>         the same high-level concepts of a domain, range and range descriptor.
>         And it’s possible to encode a wide variety of coverages in CovJSON –
>         continuous and categorical, regular and irregular, gridded and
>         non-gridded, with some embedded semantic information. The
>         specification, playground and cookbook illustrate this, although they
>         are all currently unfinished (see https://covjson.org)
>         <https://covjson.org%29>. If there appears to be a gap (i.e. important
>         information that we can’t encode) then please do report this – all the
>         development is being done fully out in the open on GitHub and we
>         welcome all comments.
>
>          
>
>         However, CovJSON deliberately does not attempt to use GML structures
>         as its basis, mainly for reasons of simplicity and minimalism. It aims
>         at an audience that is unfamiliar with GML. It tries to be a simple
>         and clear format that can encode the relevant information accurately
>         using idiomatic JSON, using a minimal set of consistent rules. It
>         happens to share quite a lot in common with how NetCDF works, but is
>         certainly not a literal translation of NetCDF into JSON either.
>
>          
>
>         (One important point is that we don’t currently support the
>         “interleaved domain and range” structure for coverages. We can maybe
>         try to address this if there is enough user demand.)
>
>          
>
>         Personally I don’t see any reason why CovJSON could not one day become
>         an OGC standard, alongside the other possible coverage encoding
>         formats. I’m not pushing hard for this myself at the moment because I
>         would like to test its efficacy seriously in the community first – if
>         it turns out to be successful and there is community support then that
>         would be a good time to move for full standardisation. At the moment,
>         I don’t think we are talking about a full OGC spec, although I’m not
>         quite sure what the official OGC status of the document resulting from
>         this working group would be (Bill, can you help?)
>
>          
>
>         Cheers,
>         Jon
>
>          
>
>          
>
>          
>
>          
>
>         *From: *Peter Baumann <p.baumann@jacobs-university.de>
>         <mailto:p.baumann@jacobs-university.de>
>         *Organization: *Jacobs University Bremen
>         *Date: *Tuesday, 19 July 2016 21:52
>         *To: *Bill Roberts <bill@swirrl.com> <mailto:bill@swirrl.com>,
>         "public-sdw-wg@w3.org" <mailto:public-sdw-wg@w3.org>
>         <public-sdw-wg@w3.org> <mailto:public-sdw-wg@w3.org>
>         *Cc: *Maik Riechert <m.riechert@reading.ac.uk>
>         <mailto:m.riechert@reading.ac.uk>, Jon Blower <sgs02jdb@reading.ac.uk>
>         <mailto:sgs02jdb@reading.ac.uk>
>         *Subject: *Re: Coverage subgroup update
>
>          
>
>         hm, is this aligned with the OGC coverage model? If not, why do you
>         think that OGC could support something not compatible?
>         puzzled,
>         Peter
>
>
>
>         On 07/19/2016 10:42 PM, Bill Roberts wrote:
>
>             Hi all
>
>              
>
>             Sorry for being a bit quiet on this over the last month or so - it
>             was as a result of a combination of holiday and other commitments.
>
>              
>
>             However, some work on the topic has been continuing.  Here is an
>             update for discussion in the SDW plenary call tomorrow.
>
>              
>
>             In particular I had a meeting in Reading on 5 July with Jon Blower
>             and fellow-editor Maik Riechert.
>
>              
>
>             During that we came up with a proposed approach that I would like
>             to put to the group.  The essence of this is that we take the
>             CoverageJSON specification of Maik and Jon and put it forward as a
>             potential W3C/OGC recommendation.  See
>             https://github.com/covjson/specification/blob/master/spec.md for
>             the current status of the CoverageJSON specification.
>
>              
>
>             That spec is still work in progress and we identified a couple of
>             areas where we know we'll want to add to it, notably around a URI
>             convention for identifying an extract of a gridded coverage,
>             including the ability to identify a single point within a
>             coverage. (Some initial discussion of this issue at
>             https://github.com/covjson/specification/issues/66).
>
>              
>
>             Maik and Jon understandably feel that it is for others to judge
>             whether their work is an appropriate solution to the requirements
>             of the SDW group.  My opinion from our discussions and initial
>             review of our requirements is that it is indeed a good solution
>             and I hope I can be reasonably objective about that.  
>
>              
>
>             My intention is to work through the requirements from the UCR
>             again and systematically test and cross-reference them to parts of
>             the CovJSON spec. I've set up a wiki page for that:
>             https://www.w3.org/2015/spatial/wiki/Cross_reference_of_UCR_to_CovJSON_spec
>              That should give us a focus for identifying and discussing issues
>             around the details of the spec and provide evidence of the
>             suitability of the approach (or not, as the case may be). 
>
>              
>
>             There has also been substantial interest and work within the
>             coverage sub-group on how to apply the RDF Data Cube vocabulary to
>             coverage data, and some experiments on possible adaptations to
>             it.  The main potential drawback of the RDF Data Cube approach in
>             this context is its verbosity for large coverages.  My feeling is
>             that the standard RDF Data Cube approach could be a good option in
>             the subset of applications where the total data volume is not
>             excessive - creating a qb:Observation and associated triples for
>             each data point in a coverage.  I'd like to see us prepare a note
>             of some sort to explain how that would work.  I also think it
>             would be possible and desirable to document a transformation
>             algorithm or process for converting CoverageJSON (with its
>             'abbreviated' approach to defining the domain of a coverage) to an
>             RDF Data Cube representation.
>
>              
>
>             So the proposed outputs of the group would then be:
>
>              
>
>             1) the specification of the CoverageJSON format, to become a W3
>             Recommendation (and OGC equivalent)
>
>             2) a Primer document to help people understand how to get started
>             with it.  (Noting that Maik has already prepared some learning
>             material at https://covjson.gitbooks.io/cookbook/content/)
>
>             3) contributions to the SDW BP relating to coverage data, to
>             explain how CovJSON would be applied in relevant applications
>
>             4) a note on how RDF Data Cube can be used for coverages and a
>             process for converting CovJSON to RDF Data Cube
>
>              
>
>             Naturally I expect to discuss this proposal in plenary and
>             coverage sub-group calls!
>
>              
>
>             Best regards
>
>              
>
>             Bill
>
>              
>
>              
>
>              
>
>              
>
>              
>
>              
>
>
>
>
>
>         -- 
>
>         Dr. Peter Baumann
>
>          - Professor of Computer Science, Jacobs University Bremen
>
>            www.faculty.jacobs-university.de/pbaumann
>         <http://www.faculty.jacobs-university.de/pbaumann>
>
>            mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>
>            tel: +49-421-200-3178, fax: +49-421-200-493178
>
>          - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>
>            www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>
>            tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>
>         "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>
>          
>
>          
>
>
>
>
>     -- 
>
>     Dr. Peter Baumann
>
>      - Professor of Computer Science, Jacobs University Bremen
>
>        www.faculty.jacobs-university.de/pbaumann
>     <http://www.faculty.jacobs-university.de/pbaumann>
>
>        mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>
>        tel: +49-421-200-3178, fax: +49-421-200-493178
>
>      - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>
>        www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>
>        tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
>
>     "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>
>      
>
>      
>
>
>
> -- 
> Dr. Peter Baumann
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
> <http://www.faculty.jacobs-university.de/pbaumann>
>    mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>    www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>  
>  

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)