W3C home > Mailing lists > Public > public-sdw-wg@w3.org > July 2016

Re: Coverage subgroup update

From: Sam Toyer <u5568237@anu.edu.au>
Date: Thu, 21 Jul 2016 09:18:46 +1000
To: Jon Blower <j.d.blower@reading.ac.uk>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "bill@swirrl.com" <bill@swirrl.com>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
CC: "m.riechert@reading.ac.uk" <m.riechert@reading.ac.uk>
Message-ID: <1652f5fe-7b97-8560-5fb8-471e6f8ab772@anu.edu.au>
Hi Jon,

I suspect that Simon is referring to use of SPARQL to manipulate the QB
RDF graph directly, similar to what you were doing with your "raster
SPARQL"[0] work. Our group at ANU has been working on something similar,
and we've previously written a bit about what that might look like[1].
In short, complex subsetting operations could be expressed like this:

# Get a tile which contains Lake Lefroy (arbitrary time)
# Could also sort by bounding box size to get the /smallest/ tile containing
# Lake Lefroy
SELECT ?satData ?lakeGeo WHERE {
     ?l rdf:type someNS:Lake .
     ?l someNS:name "Lake Lefroy" .
     ?l geo:hasGeometry ?lakeGeo .
     ?o rdf:type qb:Observation .
     # ?satData might be literal containing actual data, or URL pointing to
     # data
     ?o :sensorValue ?satData .
     ?o :refArea ?satBBox .
     FILTER (geof:sfWithin(?lakeGeo, ?satBBox))
} LIMIT 1

Of course, the main challenge this this approach is that you can't store
very large coverages (e.g. each pixel in a satellite coverage) in an
ordinary triple store; instead, you have to write your own SPARQL
endpoint which calculates the portion of the graph required by the
client and generates it on the fly! We (the ANU group) have been working
towards a demonstration of this technique for satellite coverages;
curious observers can find it on Github[2].

Cheers,
Sam

[0] https://bitbucket.org/jonblower/raster-sparql
[1] 
https://github.com/ANU-Linked-Earth-Data/main-repo/wiki/Coverage-Recommendation-20-4-16
[2] https://github.com/ANU-Linked-Earth-Data/middleware

On 20/07/16 09:49, Jon Blower wrote:
> Hi Simon,
>
>
>
> Ø  QB provides a data model that allows you to express sub-setting
> operations in SPARQL. That looks like a win to me. I.e. think of QB as
> an API, not a payload.
>
>
>
> I’m not an expert in QB by any means, but I understand that the
> subsetting in QB essentially means taking a Slice (in their
> terminology), which is a rather limited kind of subset. I didn’t see a
> way of taking arbitrary subsets (e.g. by geographic coordinates) in the
> way that WCS could. Can you expand on this, perhaps giving some examples
> of different subset types that can be expressed in SPARQL using QB?
>
>
>
> Cheers,
> Jon
>
>
>
> *From: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au>
> *Date: *Wednesday, 20 July 2016 00:02
> *To: *"bill@swirrl.com" <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
>
>
>
> Ø  The main potential drawback of the RDF Data Cube approach in this
> context is its verbosity for large coverages.
>
>
>
> For sure. You wouldn’t want to deliver large coverages serialized as RDF.
>
>
>
> **But** - QB provides a data model that allows you to express
> sub-setting operations in SPARQL. That looks like a win to me. I.e.
> think of QB as an API, not a payload.
>
>
>
> *From:*Bill Roberts [mailto:bill@swirrl.com]
> *Sent:* Wednesday, 20 July 2016 6:42 AM
> *To:* public-sdw-wg@w3.org
> *Cc:* Maik Riechert <m.riechert@reading.ac.uk>; Jon Blower
> <j.d.blower@reading.ac.uk>
> *Subject:* Coverage subgroup update
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
Received on Wednesday, 20 July 2016 23:22:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:23 UTC