Re: Coverage subgroup update

Thanks Jon,

i guess this boils down to whether its possible to use RDf-QB model and
terms inside covJson to define dimensions (using JSON-LD patterns), and
allow discretion as to whether a well-known literal, URI or descriptive
model is embedded at this point for CRS and UoM (and this actually applies
to other fun things like sensor identification :-) ).

If so I think this is a bit of a win-win: we get a re-usable expression
that can be used in data, metadata and API descriptions, and common terms
and semantics across JSON, RDF - and at least via metadata (not embedded
links) this can be used across existing WCS and GML solutions.

I will try to channel the wider BP discussion into the coverage-specific
domain and put up a straw-man for how this might look in RDF and JSON - and
if it works can deploy some reusable descriptions.

Rob

On Wed, 20 Jul 2016 at 10:07 Jon Blower <j.d.blower@reading.ac.uk> wrote:

> Hi Rob,
>
>
>
> Ø  Can therefore Jon and Maik please review Jeremy's summary and revert
> back to the sub-group with their perspective and a proposal?
>
>
>
> This is clearly a complex area and I don’t think either Maik or I want to
> own the problem of solving it for everyone! ;-) I’m also not exactly clear
> what kind of information we need for a BP. This is a problem that is wider
> than this working group and there are a lot of things that could be done
> which we might not have time to bottom out.
>
>
>
> I’ve already given my thoughts on what I consider a “high-level” best
> practice, which is basically to make sure the unit is machine readable if
> possible, using a named grammar, to enable automated unit conversion. I
> don’t really mind too much how this is achieved as long as it’s relatively
> straightforward for clients to find out which unit grammar they are
> supposed to use. I think that realistically, knowledge of how the grammar
> works has to be out of band – I don’t think a client will want to try to
> discover how the grammar works at runtime through any kind of fancy
> ontology, but will fall back to an existing library that operates on UCUM,
> UDUNITS or whatever. Maybe RDF can be used to express some simple
> equivalencies, “alternative units” or something like that, but the full
> grammar is going to be quite complex.
>
>
>
> The actual encoding of this in RDF (or whatever) is not a problem I’m
> particularly keen on tackling, so I’m happy to leave it to others to debate
> this. I certainly agree that you don’t want to have to re-encode the unit
> for every data point - I don’t think Maik was intending to imply this in
> his example and CovJSON certainly does not do this.
>
>
>
> Ø  the question is whether there is a lightweight encoding for the single
> dimension and/or single result case - but why would we be using coverages
> for such cases anyway
>
>
>
> Single-dimension coverages are perfectly valid in my opinion (e.g.
> timeseries, vertical profiles, trajectories). Single results
> (zero-dimension coverages) are another thing, you could argue that a full
> coverage model is overkill but I think it’s still useful to reuse the
> overarching coverage concepts for consistency, to avoid clients having to
> know too many models. Alternative representations may be equally valid.
>
>
>
> Cheers,
> Jon
>
>
>
> *From: *Rob Atkinson <rob@metalinkage.com.au>
> *Date: *Wednesday, 20 July 2016 00:05
> *To: *Rob Atkinson <rob@metalinkage.com.au>, Peter Baumann <
> p.baumann@jacobs-university.de>, Bill Roberts <bill@swirrl.com>, "
> public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
>
>
> *Cc: *Maik Riechert <m.riechert@reading.ac.uk>, Jon Blower <
> sgs02jdb@reading.ac.uk>
>
> *Subject: *Re: Coverage subgroup update
>
>
>
> Note: Please refer to Jeremy Tandy's latest email summarising the UoM
> problem (and the CRS one for that matter).
>
>
>
> This applies to all cases being discussed, including JSON-LD encoding.  We
> need to have a consistent BP that we apply to both JSON-LD and RDf-Datacube
> (and any other places where coverage dimensions are being described). IMHO
> having a collection of ad-hoc approaches embedded in different BP would be
> bad.
>
>
>
> Can therefore Jon and Maik please review Jeremy's summary and revert back
> to the sub-group with their perspective and a proposal?  Personally I think
> JSON-LD is likely to be the easiest place, as its a pattern for decorating
> data
>
>
>
> Looking at Maiks original proposal:
>
> {
>   "@context": {
>     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> <http://www.w3.org/1999/02/22-rdf-syntax-ns>,
>     "qudt": "http://qudt.org/schema/qudt#" <http://qudt.org/schema/qudt>,
>     "skos": "http://www.w3.org/2004/02/skos/core#"
> <http://www.w3.org/2004/02/skos/core>
>   },
>   "rdf:value": 27.5, // for example purposes only
>   "qudt:unit": {
>     "@id": "qudt:DegreeCelsius",
>     "skos:prefLabel": { "en": "Degree Celsius" },
>     "qudt:symbol": {
>       "@type": "http://www.opengis.net/def/uom/UCUM/"
> <http://www.opengis.net/def/uom/UCUM/>,
>       "@value": "Cel"
>     }
>
>
>
> I think this following my predilection that skos is used for labelling,
> and declaring equivalences and model-independent hierarchies.
>
>
>
> note that SKOS can also be used for notations (i think UCUM would be a
> notation something like this, if ucum model was (virtually) available as an
> ontology :-))
>
> skos:notation "m/s"^^ucum:Unit
>
>
>
> note also there is magic: the client needs to know about qudt and
> understand in advance that a qudt element will contain relevant metadata.
>
>
>
> The final thing that I beleive needs unpacking here is that we dont want
> to specify the unit for every single result : and IMHO this collapses back
> to the RDF-QB dimension model;
>
>
>
> {
>   "@context": {
>     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> <http://www.w3.org/1999/02/22-rdf-syntax-ns>,
>     "qudt": "http://qudt.org/schema/qudt#" <http://qudt.org/schema/qudt>,
>     "skos": " <http://www.w3.org/2004/02/skos/core>
> http://www.w3.org/2004/02/skos/core# <http://www.w3.org/2004/02/skos/core>
> " <http://www.w3.org/2004/02/skos/core>
>
>     "qb": "http://purl.org/linked-data/cube#
> <http://purl.org/linked-data/cube>"
>
>   },
>
>  {
>
>    ..describe UoM here ...
>
>
>
>
>
>    "qudt:unit": {
>     "@id": "qudt:DegreeCelsius",
>     "skos:prefLabel": { "en": "Degree Celsius" },
>     "qudt:symbol": {
>       "@type": "http://www.opengis.net/def/uom/UCUM/"
> <http://www.opengis.net/def/uom/UCUM/>,
>       "@value": "Cel"
>     }
>
>  {
>
>     ... describe a qb:MeasureProperty here ..  using the UoM description
> above
>
>    .. note this can describe multipe dimensions - do we need a full
> qb:component if we only have one dimension?
>
> },
>
> {
>
>   " dimensionalThing": [ 27.5, 33.3, 56.2 ]
>   }
> }
>
>
>
> I'm pretty sure this will give us a solution based on available standards
> - the question is whether there is a lightweight encoding for the single
> dimension and/or single result case - but why would we be using coverages
> for such cases anyway rather than metadata-rich feature models?
>
>
>
> Rob
>
>
>
>
>
> On Wed, 20 Jul 2016 at 07:53 Rob Atkinson <rob@metalinkage.com.au> wrote:
>
> I still think it is more important to be able to describe a coverage and
> operations to subset it, and how subsets are related than to encode the
> data itself. Im trying to get a sensible answer about UoM referencing so
> dimensions can be expressed properly.
>
> Rob
>
>
>
> On Wed, 20 Jul 2016 6:52 am Peter Baumann <p.baumann@jacobs-university.de>
> wrote:
>
> 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
>
>    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)
>
>
>
>
>
>