Many kinds of scienti c data, including satellite imagery, climate simulations and sensor data, can be represented as coverages, which are essentially mappings from points in space and time to data values. Coverage data are typically encoded as multidimensional arrays in compact binary forms such as NetCDF, HDF and GeoTIFF, most of which require specialist knowledge and tools to process and manipulate. There is considerable current interest in helping the wider Web community use coverage data, by providing data in more general formats such as JSON and RDF, and by using commonly-accepted vocabularies. This short discussion paper outlines some current work in the area and highlights some of the main inherent issues.
A coverage is a general data structure that can hold many di erent kinds of
geospatial and temporal data. It is de ned in the ISO19123 speci cation [
Coverages are typically published on the Web in one of two ways: (i) as static
les, in formats such as GeoTIFF, NetCDF [
The user base of coverage data could potentially be widened if it were possible
to make data available in more general formats that are familiar to the Web and
Semantic Web communities. In addition, the use of well-de ned vocabularies
would help to describe coverage data better, and help it to be related more
accurately to other related data sources. Therefore, it is interesting to consider
how coverage data could be encoded in RDF [
The joint OGC/W3C \Spatial Data on the Web" working group1 is developing several strands of work in this area, and this work has been partly motivated by the activities of this group. This short paper highlights some of the issues revealed, with the intention of stimulating discussion. It is not intended to be a complete treatment of this complex area, nor does it represent the totality of the work of the group. 2
A useful general structure for a Coverage can be found in the Open
Geospatial Consortium Coverage Implementation Schema (CIS) [
{ The range metadata, which describes the range values (e.g. units of measure). The only structural di erence between di erent types of coverage (images, timeseries, vertical pro les etc.) is the spatiotemporal geometry and topology of the domain. The range and range metadata can be encoded consistently, irrespective of the domain type.
(We note that an alternative model is possible, in which the domain and range are interleaved. This model can be convenient in some cases { for example where streaming capabilities are required { but we do not discuss it further in this paper.) 3
CoverageJSON (or \CovJSON" for short) is a JSON-based [
A sample CovJSON document is given in Appendix A.
CovJSON makes use of JSON-LD [
The result of converting the CovJSON document in Appendix A to RDF, using the information in the currently-supplied JSON-LD context document, is shown in Appendix B. It can be seen that the range metadata (coming from the CovJSON Parameter objects) is well represented in the resulting RDF, as well as the domain type (a two-dimensional grid in this case) and certain domain metadata such as the coordinate reference systems (CRSs). However, the actual data values that make up the domain and range do not survive the conversion. Other information is also missing, such as the mapping between the axes of the domain and the coordinate reference systems.
The two main reasons for this are: 1. Much of a coverage's data is array-based in CovJSON, including the range and key parts of the domain. JSON arrays can be converted to RDF lists through JSON-LD, but this is probably not a usable way to represent arrays that can potentially be very large. 2. CovJSON uses data structures that are equivalent to associative arrays. The keys of these arrays are important and are used to map between di erent pieces of information in the CovJSON document. For example, the arrays representing each variable in the coverage are keyed to short identi er strings, which are also used in Parameters { see the use of \TEMP" in Appendix A. These keys cannot be easily converted to an RDF representation with the current version of JSON-LD (a change to JSON-LD has been requested and may appear in future versions 2). One potential solution is to craft a di erent JSON-LD context document for each CovJSON document, but we feel it would be much more desirable to use a single, standard context document that works across all CovJSON documents.
We therefore conclude that, for the foreseeable future, the automated \full" conversion of CovJSON to RDF will remain limited. However, some applications may nd the resulting limited RDF useful, particularly for describing the range metadata and the types of the main objects in the coverage. Applications that do not require RDF will hopefully appreciate the simple nature of the format and the use of URIs to bring in some semantic content. 2 https://github.com/json-ld/json-ld.org/issues/430
The RDF Data Cube vocabulary [
In fact, the way in which CovJSON models coverages is conducive to such a conversion. In CovJSON, all types of domain are modelled using a set of orthogonal axes, even where the domain consists of polygons. Each of these axes could map neatly to a dimension in the data cube. (It is worth noting that CIS does not always model domains using orthogonal axes, and so conversion from CIS to Data Cube may be less obvious in some cases.)
The Data Cube vocabulary is designed to encode statistical data, in which the dimensions of the data cube are relatively small and unordered. The axes of a coverage can be large (satellite images can be tens of thousands of pixels across) and ordering of the axis values is important. Therefore the Data Cube vocabulary may require some specialisation to re ect this.
As with CovJSON and JSON-LD, the encoding of the range values (particularly for large coverages) will be an important issue to resolve. Possible solutions include: 1. encode the range values individually as RDF triples, which will be very ine cient for large coverages; 2. de ne a microformat (i.e. encode all range values in a single long string).
This will be more e cient, but less exible and still problematic for large coverages; or 3. encode the range values in a separate document in a more e cient format.
The last option is likely to be the most productive. Various formats for the range are possible, but one attractive possibility is CovJSON itself, which provides a JSON encoding for a standalone multidimensional array (this can be compressed during data transfer for much greater e ciency). It may also, of course, be possible to use binary formats like NetCDF for this purpose. But many of these formats encode the full coverage (not just the range), and care must be taken to ensure that the RDF representation of the domain is consistent with that in the linked le.
RDF can provide a highly expressive means to encode coverage information.
Through the use of other vocabularies that provide contextual information (such
as DCAT [
CovJSON provides a general data model for a wide range of coverages (based on CIS concepts), making signi cant use of semantic information. It de nes a kind of ontology for coverages, although currently not a complete one. The incompleteness is partly due to the current limitations of the current version of JSON-LD. The RDF Data Cube may provide a more useful \canonical" RDF format, and we are hopeful that CovJSON and DataCube representations are su ciently conceptually similar that they can be converted readily to each other. This would be an interesting area of research.
The Semantic Sensor Network (SSN) [
It is likely that any attempt to encode coverages as RDF will meet practical limitations in encoding the range values (and, in some cases, the domain values). Given that range values will probably be given in separate documents outside the \RDF world" it is critical that the RDF and non-RDF information can be related unambiguously to each other. A
This is a coverage that measures a single parameter (air temperature) on a regular global grid of 1 degree resolution. { "type" : "Coverage", "domain" : { "type": "Domain", "domainType": "Grid", "axes": { "x": { "start": -179.5, "stop": 179.5, "num": 360 }, "y": { "start": -89.5, "stop": 89.5, "num": 180 }, "t": { "values": ["2013-01-13T00:00:00Z"] } }, "referencing": [{ "coordinates": ["x","y"], "system": { "type": "GeographicCRS", "id": "http://www.opengis.net/def/crs/OGC/1.3/CRS84" } }, { "coordinates": ["t"], "system": { "type": "TemporalRS", "calendar": "Gregorian" }]
} }, "parameters" : { "TEMP": { "type" : "Parameter", "description" : {
"en": "The air temperature measured in degrees Celsius." }, "unit" : { "label": {
"en": "Degree Celsius" }, "symbol": { "value": "Cel", "type": "http://www.opengis.net/def/uom/UCUM/" } }, "observedProperty" : { "id" : "http://vocab.nerc.ac.uk/standard_name/air_temperature/", "label" : { "en": "Air temperature", "de": "Lufttemperatur" } B } } }
} }, "ranges" : { "TEMP" : "http://example.com/coverages/123/TEMP"
The following document (in the Turtle notation) shows the result of automatically converting the coverage from Appendix A to RDF using the JSON-LD context. Some information has been omitted for brevity and clarity. <http://example.com/mycoverage> a covjson:Coverage; covjson:domain [ a covjson:Domain; covjson:domainType covjsondt:Grid; covjson:referencing: [
covjson:referenceSystem: <http://www.opengis.net/def/crs/OGC/1.3/CRS84> ], [ covjson:referenceSystem: [ a inspiregloss:TemporalReferenceSystem ; covjson:calendar: <http://www.opengis.net/def/uom/ISO-8601/0/Gregorian> . ] ] ; covjson:parameter [ a covjson:Parameter ; dct:description "The air temperature measured in degrees Celsius."@en ; qudt:unit [ qudt:symbol "Cel"^^<http://www.opengis.net/def/uom/UCUM/> ; skos:prefLabel "Degree Celsius"@en ] ; ssn:observedProperty <http://vocab.nerc.ac.uk/standard_name/air_temperature/> ] . <http://www.opengis.net/def/crs/OGC/1.3/CRS84> a ignf:GeodeticCRS . <http://vocab.nerc.ac.uk/standard_name/air_temperature/> skos:prefLabel "Lufttemperatur"@de ; skos:prefLabel "Air temperature"@en .