Jump to Table of Contents Collapse Sidebar

Abstract

This document describes use cases that demand a combination of geospatial and non-geospatial data sources and techniques. It underpins the collaborative work of the Spatial Data on the Web Working Groups operated by both W3C and OGC.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

For OGC This is a Public Draft of a document prepared by the Spatial Data on the Web Working Group (SDWWG) - a joint W3C-OGC project (see charter). The document is prepared following W3C conventions. The document is released at this time to solicit public comment.

The Working Group does not expect to publish further iterations of this document.

This document was published by the Spatial Data on the Web Working Group as a Working Group Note. If you wish to make comments regarding this document, please send them to public-sdw-comments@w3.org (subscribe, archives). All comments are welcome.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

1. Introduction

The mission of the Spatial Data on the Web Working Group, as described in its charter, is to clarify and to formalize standards on spatial data on the Web. In particular:

  1. to determine how spatial information can best be integrated with other data on the Web;
  2. to determine how machines and people can discover that different facts in different datasets relate to the same place, especially when 'place' is expressed in different ways and at different levels of granularity;
  3. to identify and assess existing methods and tools and then create a set of best practices for their use;
  4. where desirable, to complete the standardization of informal technologies already in widespread use.

This document describes the results of the first steps of working towards these goals. Members of the Working Group and other stakeholders have come up with a number of use cases that describe how spatial data on the Web could work. From these use cases, a number of requirements for further work are derived. In this document, use cases, requirements and their relationships are described. Requirements and use cases are also related to the deliverables of the Working Group.

The requirements described in this document will be the basis for development of the other four deliverables of the Working Group.

2. Deliverables

The deliverables of this Working Group are described in the Working Group Charter. For convenience those deliverables are replicated in this chapter. The charter remains the authoritative source of the definition of deliverables.

2.1 Use Cases and Requirements

A document setting out the range of problems that the Working Groups are trying to solve (this document).

2.2 Spatial Data on the Web Best Practices

This will include:

2.3 Time Ontology in OWL

The WG will work with the authors of the existing Time Ontology in OWL to complete the development of this widely used ontology through to Recommendation status. Further requirements already identified in the geospatial community will be taken into account.

2.4 Semantic Sensor Network Vocabulary

The WG will work with the members of the former Semantic Sensor Network Incubator Group to develop its ontology into a formal Recommendation, noting the work to split the ontology into smaller sections to offer simplified access.

2.5 Coverage in Linked Data

The WG will develop a formal Recommendation for expressing discrete coverage data conformant to the ISO 19123 abstract model. Existing standard and de facto ontologies will be examined for applicability; these will include the RDF Data Cube. The Recommendation will include provision for describing the subset of coverages that are simple timeseries datasets - where a time-varying property is measured at a fixed location. OGC's WaterML 2 Part 1 - Timeseries will be used as an initial basis.

Given that coverage data can often be extremely large in size, publication of the individual data points as Linked Data may not always be appropriate. The Recommendation will include provision for describing an entire coverage dataset and subsets thereof published in more compact formats using Linked Data. For example where a third party wishes to annotate a subset of a large coverage dataset or a data provider wishes to publish a large coverage dataset in smaller subsets to support convenient reuse.

Note

The OGC is currently working on refinements of ISO 19123 (in particular, the OGC Coverage Implementation Schema 1.1), which could result in specifications that allow a higher level of interoperability of implementations. The Working Group will also consider these forthcoming standards.

3. Methodology

In order to find out the requirements for the deliverables of the Working Group, use cases were collected. For the purpose of the Working Group, a use case is a story that describes challenges with respect to spatial data on the Web for existing or envisaged information systems. It does not need to adhere to certain standardized format. Use cases are primarily used as a source of requirements, but a use case could be revisited near the time the work of the Working Group will reach completion, to demonstrate that it is now possible to make the use case work.

The Working Group has derived requirements from the collected use cases. A requirement is something that needs to be achieved by one or more deliverables and is phrased as a specification of functionality. Requirements can lead to one or more tests that can prove whether the requirement is met.

Care was taken to only derive requirements that are considered to in scope for the further work of the Working Group. The scope of the Working Group is determined by the charter. To help keeping the requirements in scope, the following questions were applied:

  1. Is the requirement specifically about spatial data on the Web?
  2. Is the use case including data published, reused, and accessible via Web technologies?
  3. Has a use case a description that can lead to a testable requirement?

4. Use Cases

Use cases that describe current problems or future opportunities for spatial data on the Web have been gathered as a first activity of the Working Group. They were mainly contributed by members of Working Group, but there were also contributions from other interested parties. In this chapter these use cases are listed and identified. Each use case is related to one or more Working Group deliverables and to one or more requirements for future deliverables.

4.1 Meteorological data rescue

Chris Little, based on scenarios used for the WMO infrastructure requirements.

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.42 Spatial metadata, 5.7 Coverage temporal extent, 5.9 CRS definition, 5.10 Date, time and duration, 5.12 Different time models, 5.13 Discoverability, 5.18 Georeferenced spatial data, 5.23 Linkability, 5.29 Multilingual support, 5.32 Nominal temporal references, 5.34 Observed property in coverage, 5.35 Provenance, 5.36 Quality per sample, 5.37 Reference data chunks, 5.40 Sensing procedure, 5.39 Sensor metadata, 5.41 Space-time multi-scale, 5.45 Spatial vagueness, 5.54 Temporal reference system, 5.57 Uncertainty in observations, 5.8 Crawlability

4.2 Habitat zone verification for designation of Marine Conservation Zones

Jeremy Tandy

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.18 Georeferenced spatial data, 5.20 Identify coverage type, 5.35 Provenance, 5.37 Reference data chunks, 5.39 Sensor metadata, 5.9 CRS definition, 5.26 Mobile sensors, 5.23 Linkability, 5.31 Nominal observations, 5.19 Humans as sensors, 5.51 Support for 3D, 5.16 Ex-situ sampling, 5.40 Sensing procedure, 5.43 Spatial relationships

4.3 Real-time wildfire monitoring

Manolis Koubarakis

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

5.9 CRS definition, 5.11 Determinable CRS, 5.17 Georectification, 5.23 Linkability, 5.20 Identify coverage type, 5.35 Provenance, 5.39 Sensor metadata, 5.14 Dynamic sensor data, 5.46 SSN-like representation

4.4 Diachronic burnt scar Mapping

Manolis Koubarakis

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

5.9 CRS definition, 5.11 Determinable CRS, 5.17 Georectification, 5.23 Linkability, 5.20 Identify coverage type, 5.35 Provenance, 5.39 Sensor metadata, 5.46 SSN-like representation

4.5 Harvesting of Local Search Content

Ed Parsons

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL,

5.2 Avoid coordinate transformations, 5.6 Coordinate precision, 5.8 Crawlability, 5.10 Date, time and duration, 5.11 Determinable CRS, 5.13 Discoverability, 5.24 Linking geometry to CRS

4.6 Locating a thing

Ed Parsons

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.11 Determinable CRS, 5.21 Independence on reference systems, 5.24 Linking geometry to CRS, 5.53 Time dependencies in CRS definitions, 5.25 Machine to machine, 5.43 Spatial relationships

4.7 Publishing geographical data

Frans Knibbe

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.51 Support for 3D, 5.3 Bounding box and centroid, 5.4 Compatibility with existing practices, 5.24 Linking geometry to CRS, 5.30 Multiple CRSs, 5.43 Spatial relationships

4.8 Consuming geographical data in a Web application

Frans Knibbe

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.2 Avoid coordinate transformations, 5.3 Bounding box and centroid, 5.5 Compressibility, 5.8 Crawlability, 5.11 Determinable CRS, 5.21 Independence on reference systems, 5.24 Linking geometry to CRS, 5.52 Support for tiling

4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities

Frans Knibbe, Karl Grossner

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL

5.2 Avoid coordinate transformations, , 5.6 Coordinate precision, 5.10 Date, time and duration, 5.11 Determinable CRS, 5.24 Linking geometry to CRS, 5.30 Multiple CRSs, 5.32 Nominal temporal references, 5.41 Space-time multi-scale, 5.55 Temporal vagueness, 5.53 Time dependencies in CRS definitions, 5.21 Independence on reference systems, 5.43 Spatial relationships

4.10 Publishing geospatial reference data

Clemens Portele

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.60 Validation, 5.23 Linkability, 5.44 Spatial operators, 5.18 Georeferenced spatial data

4.11 Integration of governmental and utility data to enable smart grids

Frans Knibbe

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary

5.11 Determinable CRS, 5.13 Discoverability, 5.23 Linkability, 5.39 Sensor metadata, 5.42 Spatial metadata, 5.48 SSN usage examples

4.12 Using spatial data during emergency response operations

Bart van Leeuwen

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.2 Avoid coordinate transformations, 5.4 Compatibility with existing practices, 5.11 Determinable CRS, 5.13 Discoverability, 5.23 Linkability, 5.24 Linking geometry to CRS, 5.42 Spatial metadata, 5.43 Spatial relationships, 5.50 Subject equality

4.13 Publication of air quality data aggregations

Alejandro Llaves, Miguel Angel García-Delgado (OEG-UPM), Rubén Notivol, Javier Celma (Ayuntamiento de Zaragoza)

▶ Full use case description (click to expand):

2.4 Semantic Sensor Network Vocabulary, 2.3 Time Ontology in OWL

5.10 Date, time and duration, 5.33 Observation aggregations

4.14 Publication of transport card validation and recharging data

Alejandro Llaves (OEG-UPM)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary

5.53 Time dependencies in CRS definitions, 5.48 SSN usage examples

4.15 Combining spatial RDF data for integrated querying in a triplestore

Matthew Perry (Oracle)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.2 Avoid coordinate transformations, 5.11 Determinable CRS, 5.15 Encoding for vector geometry, 5.24 Linking geometry to CRS, 5.42 Spatial metadata

4.16 Dutch Base Registry

Linda van den Brink

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.2 Avoid coordinate transformations, 5.5 Compressibility, , 5.6 Coordinate precision, 5.11 Determinable CRS, 5.23 Linkability, 5.24 Linking geometry to CRS, 5.30 Multiple CRSs

4.17 Publishing Cultural heritage data

Lars G. Svensson

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.5 Coverage in Linked Data

5.7 Coverage temporal extent, 5.10 Date, time and duration, 5.18 Georeferenced spatial data, 5.32 Nominal temporal references, 5.21 Independence on reference systems, 5.58 Update datatypes in OWL Time, 5.41 Space-time multi-scale, 5.55 Temporal vagueness, 5.45 Spatial vagueness, 5.60 Validation

4.18 Dissemination of 3D geological data

Rachel Heaven

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data

5.13 Discoverability, 5.18 Georeferenced spatial data, 5.20 Identify coverage type, 5.24 Linking geometry to CRS, 5.34 Observed property in coverage, 5.36 Quality per sample, 5.37 Reference data chunks, 5.51 Support for 3D, 5.59 Use in computational models, 5.42 Spatial metadata, 5.52 Support for tiling, 5.5 Compressibility, 5.23 Linkability

4.19 Publication of raw subsurface monitoring data

Rachel Heaven

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.19 Humans as sensors, 5.9 CRS definition, 5.14 Dynamic sensor data, 5.18 Georeferenced spatial data, 5.20 Identify coverage type, 5.23 Linkability, 5.24 Linking geometry to CRS, 5.1 4D model of space-time, 5.31 Nominal observations, 5.33 Observation aggregations, 5.38 Sampling topology, 5.40 Sensing procedure, 5.39 Sensor metadata, 5.42 Spatial metadata, 5.45 Spatial vagueness, 5.51 Support for 3D, 5.41 Space-time multi-scale, 5.48 SSN usage examples, 5.56 Time series, 5.57 Uncertainty in observations, 5.62 Virtual observations

4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches

Rachel Heaven

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

5.12 Different time models, 5.10 Date, time and duration, 5.51 Support for 3D, 5.32 Nominal temporal references, 5.54 Temporal reference system, 5.55 Temporal vagueness, 5.45 Spatial vagueness, 5.43 Spatial relationships, 5.61 Valid time, 5.42 Spatial metadata

4.21 Driving to work in the snow

Cory Henson (Bosch RTC)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.19 Humans as sensors, 5.10 Date, time and duration, 5.11 Determinable CRS, 5.13 Discoverability, 5.14 Dynamic sensor data, 5.18 Georeferenced spatial data, 5.22 Lightweight API, 5.27 Model actuation, 5.28 Moving features, 5.31 Nominal observations, 5.32 Nominal temporal references, 5.39 Sensor metadata, 5.25 Machine to machine, 5.5 Compressibility

4.22 Intelligent Transportation System

Antoine Zimmermann

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.10 Date, time and duration, 5.26 Mobile sensors, 5.27 Model actuation, 5.28 Moving features, 5.31 Nominal observations, 5.41 Space-time multi-scale, 5.48 SSN usage examples, 5.54 Temporal reference system

4.23 Optimizing energy consumption, production, sales and purchases in Smart Grids

Antoine Zimmermann

▶ Full use case description (click to expand):

2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

5.23 Linkability, 5.27 Model actuation, 5.48 SSN usage examples

4.24 Linked Data for tax assessment

Luigi Selmi (via public-sdw-comments)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.11 Determinable CRS, 5.13 Discoverability, 5.23 Linkability, 5.24 Linking geometry to CRS

4.25 Images, e.g. a time series of a water course

Kerry Taylor (on behalf of Jamie Baker, Australian Commonwealth Department of Communications)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.13 Discoverability, 5.18 Georeferenced spatial data, 5.20 Identify coverage type, 5.37 Reference data chunks, 5.41 Space-time multi-scale, 5.56 Time series, 5.51 Support for 3D, 5.39 Sensor metadata, 5.9 CRS definition, 5.23 Linkability, 5.35 Provenance, 5.38 Sampling topology, 5.10 Date, time and duration, 5.36 Quality per sample, 5.61 Valid time

4.26 Droughts in geological complex environments where groundwater is important

Chris Little (on behalf of Andrew G Hughes, British Geological Survey)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.23 Linkability, 5.35 Provenance, 5.36 Quality per sample, 5.31 Nominal observations, 5.51 Support for 3D, 5.62 Virtual observations, 5.14 Dynamic sensor data, 5.59 Use in computational models, 5.56 Time series

4.27 Soil data applications

Simon Cox (on behalf of Peter Wilson, Bruce Simons @ CSIRO)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.13 Discoverability, 5.20 Identify coverage type, 5.33 Observation aggregations, 5.34 Observed property in coverage, 5.36 Quality per sample, 5.41 Space-time multi-scale, 5.62 Virtual observations, 5.40 Sensing procedure, 5.19 Humans as sensors

4.28 Bushfire response coordination centre

Simon Cox (on behalf of Paul Box, Simon Cox and Ryan Fraser @ CSIRO)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary

5.2 Avoid coordinate transformations, 5.23 Linkability, 5.39 Sensor metadata, 5.45 Spatial vagueness, 5.48 SSN usage examples

4.29 Observations on geological samples

Simon Cox

▶ Full use case description (click to expand):

2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

5.10 Date, time and duration, 5.12 Different time models, 5.18 Georeferenced spatial data, 5.23 Linkability, 5.35 Provenance, 5.39 Sensor metadata, 5.16 Ex-situ sampling, 5.38 Sampling topology, 5.40 Sensing procedure, 5.48 SSN usage examples, 5.19 Humans as sensors, 5.54 Temporal reference system

4.30 Spatial sampling

Simon Cox

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.9 CRS definition, 5.18 Georeferenced spatial data, 5.23 Linkability, 5.26 Mobile sensors, 5.39 Sensor metadata, 5.41 Space-time multi-scale, 5.48 SSN usage examples, 5.45 Spatial vagueness, 5.38 Sampling topology, 5.57 Uncertainty in observations, 5.42 Spatial metadata

4.31 Select hierarchical geographical regions for use in data analysis or visualisation

Bill Roberts (based on needs arising from Swirrl's own work)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL

5.10 Date, time and duration, 5.44 Spatial operators, 5.43 Spatial relationships, 5.61 Valid time

4.32 Satellite data processing

Kerry Taylor (informed by Matt Paget and Juan Guerschman, CSIRO)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.9 CRS definition, 5.18 Georeferenced spatial data, 5.24 Linking geometry to CRS, 5.26 Mobile sensors, 5.20 Identify coverage type, 5.35 Provenance, 5.39 Sensor metadata, 5.19 Humans as sensors, 5.62 Virtual observations, 5.40 Sensing procedure, 5.21 Independence on reference systems, 5.42 Spatial metadata, 5.47 SSN profiles

4.33 Marine observations - eMII

Simon Cox (on behalf of IMOS eMII)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.13 Discoverability, 5.26 Mobile sensors, 5.33 Observation aggregations, 5.34 Observed property in coverage, 5.36 Quality per sample, 5.39 Sensor metadata, 5.51 Support for 3D, 5.38 Sampling topology

4.34 Marine observations - data providers

Simon Cox (on behalf of IMOS eMII)

▶ Full use case description (click to expand):

2.4 Semantic Sensor Network Vocabulary

5.18 Georeferenced spatial data, 5.31 Nominal observations, 5.19 Humans as sensors, 5.51 Support for 3D, 5.48 SSN usage examples, 5.57 Uncertainty in observations

4.35 Marine observations - data consumers

Simon Cox (on behalf of IMOS eMII)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary

5.2 Avoid coordinate transformations, 5.11 Determinable CRS, 5.24 Linking geometry to CRS, 5.40 Sensing procedure

4.36 Building information management and data sharing

Linda van den Brink (with thanks to Henk Schaap - Gobar)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.51 Support for 3D, 5.11 Determinable CRS, 5.24 Linking geometry to CRS, 5.43 Spatial relationships, 5.42 Spatial metadata, 5.60 Validation, 5.11 Determinable CRS

4.37 Landsat data services

Kerry Taylor (on behalf of Aaron Sedgmen of Geoscience Australia)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.5 Coverage in Linked Data

5.10 Date, time and duration, 5.13 Discoverability, 5.37 Reference data chunks, 5.56 Time series, 5.7 Coverage temporal extent, 5.52 Support for tiling

4.38 Metadata and search granularity

Kerry Taylor (on behalf of Aaron Sedgmen of Geoscience Australia)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

5.11 Determinable CRS, 5.12 Different time models, 5.16 Ex-situ sampling, 5.32 Nominal temporal references, 5.45 Spatial vagueness, 5.51 Support for 3D, 5.41 Space-time multi-scale, 5.54 Temporal reference system

4.39 Crowdsourced earthquake observation information

Kerry Taylor (on behalf of Aaron Sedgmen of Geoscience Australia)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary

5.8 Crawlability, 5.13 Discoverability, 5.11 Determinable CRS, 5.15 Encoding for vector geometry, 5.24 Linking geometry to CRS, 5.31 Nominal observations, 5.29 Multilingual support, 5.19 Humans as sensors, 5.45 Spatial vagueness, 5.39 Sensor metadata, 5.18 Georeferenced spatial data, 5.33 Observation aggregations, 5.26 Mobile sensors, 5.51 Support for 3D, 5.14 Dynamic sensor data, 5.49 Streamable data, 5.42 Spatial metadata, 5.23 Linkability, 5.25 Machine to machine, 5.44 Spatial operators, 5.48 SSN usage examples

4.40 TCGA / microscopy imaging

Erich Bremer

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data

5.7 Coverage temporal extent, 5.11 Determinable CRS, 5.24 Linking geometry to CRS, 5.37 Reference data chunks, 5.51 Support for 3D, 5.13 Discoverability, 5.42 Spatial metadata, 5.52 Support for tiling, 5.21 Independence on reference systems, 5.35 Provenance, 5.56 Time series, 5.44 Spatial operators

4.41 Crop yield estimation using multiple satellites

Kerry Taylor with Zheng-Shu Zhou, CSIRO

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.51 Support for 3D, 5.2 Avoid coordinate transformations, 5.7 Coverage temporal extent, 5.24 Linking geometry to CRS, 5.46 SSN-like representation, 5.62 Virtual observations, 5.39 Sensor metadata, 5.18 Georeferenced spatial data, 5.23 Linkability, 5.41 Space-time multi-scale, 5.57 Uncertainty in observations, 5.36 Quality per sample, 5.34 Observed property in coverage, 5.20 Identify coverage type, 5.37 Reference data chunks, 5.59 Use in computational models, 5.35 Provenance, 5.56 Time series, 5.9 CRS definition, 5.56 Time series, 5.44 Spatial operators, 5.48 SSN usage examples

4.42 Enabling cross-domain sharing and re-use of geospatial metadata

Andrea Perego, European Commission, Joint Research Centre (JRC)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.3 Bounding box and centroid, 5.8 Crawlability, 5.10 Date, time and duration, 5.12 Different time models, 5.13 Discoverability, 5.15 Encoding for vector geometry, 5.21 Independence on reference systems, 5.23 Linkability, 5.24 Linking geometry to CRS, 5.32 Nominal temporal references, 5.25 Machine to machine, 5.29 Multilingual support, 5.35 Provenance, 5.36 Quality per sample, 5.42 Spatial metadata, 5.54 Temporal reference system, 5.45 Spatial vagueness, 5.55 Temporal vagueness, 5.56 Time series, 5.61 Valid time

4.43 Improving discovery of spatial data on the Web

Andrea Perego, European Commission, Joint Research Centre (JRC)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.8 Crawlability, 5.13 Discoverability, 5.11 Determinable CRS, 5.15 Encoding for vector geometry, 5.21 Independence on reference systems, 5.23 Linkability, 5.25 Machine to machine, 5.29 Multilingual support, 5.32 Nominal temporal references, 5.35 Provenance, 5.36 Quality per sample, 5.42 Spatial metadata, 5.45 Spatial vagueness, 5.55 Temporal vagueness

4.44 INSPIRE compliance using Web standards

Erwin Folmer, Dutch Cadastre (via public-sdw-comments@w3.org)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.4 Compatibility with existing practices

4.45 Event-like geographic features

Karl Grossner, Stanford Libraries

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL

5.10 Date, time and duration, 5.1 4D model of space-time, 5.41 Space-time multi-scale, 5.54 Temporal reference system, 5.55 Temporal vagueness, 5.61 Valid time

4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model

Jeremy Tandy, Met Office

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

5.35 Provenance, 5.62 Virtual observations, 5.40 Sensing procedure, 5.57 Uncertainty in observations, 5.39 Sensor metadata, 5.9 CRS definition, 5.18 Georeferenced spatial data, 5.33 Observation aggregations, 5.48 SSN usage examples, 5.56 Time series

4.47 Incorporating geospatial data (e.g. geo-referenced geometry) into interactive 3D graphics on the Web

Stefan Lemme, DFKI/Saarland University

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.23 Linkability, 5.49 Streamable data, 5.5 Compressibility, 5.51 Support for 3D, 5.52 Support for tiling

4.48 Smart Cities

Payam Barnaghi (on behalf of the EU FP7 CityPulse Project)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary

5.23 Linkability, 5.11 Determinable CRS, 5.14 Dynamic sensor data, 5.19 Humans as sensors, 5.26 Mobile sensors, 5.27 Model actuation, 5.31 Nominal observations, 5.22 Lightweight API, 5.48 SSN usage examples

4.49 Provenance of climate data

Bruce Bannerman (Australian Bureau of Meteorology)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

5.13 Discoverability, 5.33 Observation aggregations, 5.34 Observed property in coverage, 5.35 Provenance, 5.36 Quality per sample, 5.39 Sensor metadata, 5.40 Sensing procedure, 5.42 Spatial metadata, 5.48 SSN usage examples, 5.51 Support for 3D, 5.56 Time series, 5.62 Virtual observations

4.50 Representing geospatial data in RDF

Phil Archer on behalf of the SmartOpendata project

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data

5.4 Compatibility with existing practices, 5.23 Linkability, 5.29 Multilingual support

4.51 Modelling in the construction sector

Sander Stolk (Semmtech)

▶ Full use case description (click to expand):

2.2 Spatial Data on the Web Best Practices

5.50 Subject equality


5. Requirements

This chapter lists the requirements for the deliverables of the Working Group, in alphabetical order.

Note

In some requirements the expression 'recommended way' is used. This means that a single best way of doing something is sought. It does not say anything about the form this recommended way should have, or who should make the recommendation. A recommended way could be a formal recommendation or standard from an authoritative standards body like the OGC or W3C, but it could just as well be a more informal specification, as long as it is arguably the best way of doing something.

5.1 4D model of space-time

It should be possible to represent spatial extent directly bound to time, e.g. journey trajectories.

2.3 Time Ontology in OWL

4.45 Event-like geographic features, 4.19 Publication of raw subsurface monitoring data

5.2 Avoid coordinate transformations

Data consumers should be helped in avoiding coordinate transformations when spatial data from multiple sources are combined.

Note

When geometric data from different sources have no shared Coordinate Reference System (CRS), a data consumer will have to transform the coordinates of at least one data source to another CRS to spatially combine the data. Such a transformation takes time and could introduce errors in the output, so it is preferable to avoid it. Having multiple CRSs to choose from, and different data publishers using common CRSs can help in avoiding coordinate transformations.

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data

4.8 Consuming geographical data in a Web application, 4.5 Harvesting of Local Search Content, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.12 Using spatial data during emergency response operations, 4.15 Combining spatial RDF data for integrated querying in a triplestore, 4.16 Dutch Base Registry, 4.28 Bushfire response coordination centre, 4.35 Marine observations - data consumers, 4.41 Crop yield estimation using multiple satellites

5.3 Bounding box and centroid

There should be a recommended way for publishing and requesting the bounding box and centroid of a spatial thing.

2.2 Spatial Data on the Web Best Practices

4.7 Publishing geographical data, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata

5.4 Compatibility with existing practices

Standards or recommendations for spatial data on the Web should be compatible with existing methods of making spatial data available (like WFS, WMS, CSW, WCS) and with existing information models.

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

4.7 Publishing geographical data, 4.12 Using spatial data during emergency response operations, 4.13 Publication of air quality data aggregations, 4.44 INSPIRE compliance using Web standards, 4.18 Dissemination of 3D geological data, 4.29 Observations on geological samples, 4.19 Publication of raw subsurface monitoring data, 4.27 Soil data applications, 4.30 Spatial sampling, 4.33 Marine observations - eMII, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.49 Provenance of climate data, 4.50 Representing geospatial data in RDF

5.5 Compressibility

Spatial data on the Web should be compressible (for optimization of data transfer).

2.2 Spatial Data on the Web Best Practices

4.16 Dutch Base Registry, 4.21 Driving to work in the snow, 4.47 Incorporating geospatial data (e.g. geo-referenced geometry) into interactive 3D graphics on the Web

5.6 Coordinate precision

The use of precision that matches uncertainty in coordinate data should be facilitated and encouraged.

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data

4.16 Dutch Base Registry, 4.30 Spatial sampling, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities

5.7 Coverage temporal extent

It should be possible to add temporal references to spatial coverage data.

2.5 Coverage in Linked Data

4.19 Publication of raw subsurface monitoring data, 4.3 Real-time wildfire monitoring, 4.32 Satellite data processing, 4.30 Spatial sampling, 4.2 Habitat zone verification for designation of Marine Conservation Zones,

4.41 Crop yield estimation using multiple satellites, 4.1 Meteorological data rescue, 4.17 Publishing Cultural heritage data, 4.40 TCGA / microscopy imaging, 4.37 Landsat data services, 4.21 Driving to work in the snow

5.8 Crawlability

Spatial data on the Web should be crawlable, allowing data to be found and indexed by external agents.

2.2 Spatial Data on the Web Best Practices

4.1 Meteorological data rescue, 4.5 Harvesting of Local Search Content, 4.8 Consuming geographical data in a Web application, 4.39 Crowdsourced earthquake observation information, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web

5.9 CRS definition

There should be a recommended way of referencing a Coordinate Reference System (CRS) with a HTTP URI, and to get useful information about the CRS when that URI is dereferenced.

Note

Useful things to know about a CRS are the extent of its applicability and its units of measurement.

2.4 Semantic Sensor Network Vocabulary, 2.2 Spatial Data on the Web Best Practices

4.4 Diachronic burnt scar Mapping, 4.1 Meteorological data rescue, 4.25 Images, e.g. a time series of a water course, 4.41 Crop yield estimation using multiple satellites, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model

5.10 Date, time and duration

It should be possible to represent dates, time and duration.

2.3 Time Ontology in OWL

4.21 Driving to work in the snow, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.45 Event-like geographic features, 4.5 Harvesting of Local Search Content, 4.22 Intelligent Transportation System, 4.37 Landsat data services, 4.1 Meteorological data rescue, 4.29 Observations on geological samples, 4.13 Publication of air quality data aggregations, 4.31 Select hierarchical geographical regions for use in data analysis or visualisation, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.17 Publishing Cultural heritage data, 4.25 Images, e.g. a time series of a water course, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata

5.11 Determinable CRS

For users of geometric spatial data it should always be possible to determine which coordinate reference system (CRS) is used.

2.2 Spatial Data on the Web Best Practices

4.3 Real-time wildfire monitoring, , 4.5 Harvesting of Local Search Content, , 4.6 Locating a thing, 4.8 Consuming geographical data in a Web application, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.11 Integration of governmental and utility data to enable smart grids,4.12 Using spatial data during emergency response operations, 4.15 Combining spatial RDF data for integrated querying in a triplestore, 4.16 Dutch Base Registry, 4.21 Driving to work in the snow, 4.24 Linked Data for tax assessment, 4.35 Marine observations - data consumers, 4.36 Building information management and data sharing, 4.38 Metadata and search granularity, 4.39 Crowdsourced earthquake observation information, 4.40 TCGA / microscopy imaging, 4.43 Improving discovery of spatial data on the Web, 4.48 Smart Cities

5.12 Different time models

It should be possible to represent data using different time models, such as geological time and non-Gregorian calendars.

2.3 Time Ontology in OWL

4.38 Metadata and search granularity, 4.1 Meteorological data rescue, 4.29 Observations on geological samples, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata

5.13 Discoverability

It should be easy to find spatial data on the Web, e.g. by means of metadata aimed at discovery. When spatial data are published on the Web, both humans and machines should be able to discover those data.

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data

4.28 Bushfire response coordination centre, 4.8 Consuming geographical data in a Web application, 4.41 Crop yield estimation using multiple satellites, 4.18 Dissemination of 3D geological data, 4.21 Driving to work in the snow, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.5 Harvesting of Local Search Content, 4.25 Images, e.g. a time series of a water course, 4.43 Improving discovery of spatial data on the Web, 4.11 Integration of governmental and utility data to enable smart grids, 4.22 Intelligent Transportation System, 4.37 Landsat data services, 4.33 Marine observations - eMII, 4.1 Meteorological data rescue, 4.38 Metadata and search granularity, 4.27 Soil data applications, 4.12 Using spatial data during emergency response operations, 4.40 TCGA / microscopy imaging, 4.39 Crowdsourced earthquake observation information, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.49 Provenance of climate data

5.14 Dynamic sensor data

It should be possible to represent near real-time streaming sensor measurements.

2.4 Semantic Sensor Network Vocabulary

4.39 Crowdsourced earthquake observation information, 4.3 Real-time wildfire monitoring, 4.21 Driving to work in the snow, 4.26 Droughts in geological complex environments where groundwater is important, 4.19 Publication of raw subsurface monitoring data, 4.48 Smart Cities

5.15 Encoding for vector geometry

There should be a recommended way of encoding vector geometry (an expression of spatial data that uses coordinates) when such data are published on the Web.

2.2 Spatial Data on the Web Best Practices

4.7 Publishing geographical data, 4.8 Consuming geographical data in a Web application, 4.15 Combining spatial RDF data for integrated querying in a triplestore, 4.22 Intelligent Transportation System, 4.44 INSPIRE compliance using Web standards, 4.17 Publishing Cultural heritage data, 4.39 Crowdsourced earthquake observation information, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web

5.16 Ex-situ sampling

It should be possible to represent ex-situ (remote) sampling or sensing.

2.4 Semantic Sensor Network Vocabulary

4.38 Metadata and search granularity, 4.29 Observations on geological samples, 4.2 Habitat zone verification for designation of Marine Conservation Zones

5.17 Georectification

The coverage data model should consider the inclusion of metadata to allow georectification to an arbitrary grid.

2.5 Coverage in Linked Data

4.4 Diachronic burnt scar Mapping, 4.3 Real-time wildfire monitoring

5.18 Georeferenced spatial data

It should be possible to georeference spatial data.

2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

4.18 Dissemination of 3D geological data, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.25 Images, e.g. a time series of a water course, 4.1 Meteorological data rescue, 4.17 Publishing Cultural heritage data, 4.32 Satellite data processing, 4.41 Crop yield estimation using multiple satellites, 4.39 Crowdsourced earthquake observation information, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.21 Driving to work in the snow, 4.25 Images, e.g. a time series of a water course, 4.29 Observations on geological samples, 4.30 Spatial sampling, 4.32 Satellite data processing, 4.34 Marine observations - data providers, 4.19 Publication of raw subsurface monitoring data, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.10 Publishing geospatial reference data

5.19 Humans as sensors

It should be possible to represent observations taken by human individuals or communities acting as sensors perceiving the environment.

2.4 Semantic Sensor Network Vocabulary

4.21 Driving to work in the snow, 4.32 Satellite data processing, 4.34 Marine observations - data providers, 4.39 Crowdsourced earthquake observation information, 4.19 Publication of raw subsurface monitoring data, 4.29 Observations on geological samples, 4.27 Soil data applications, 4.48 Smart Cities, 4.2 Habitat zone verification for designation of Marine Conservation Zones

5.20 Identify coverage type

Many different types of coverage exist. When coverage data are published on the Web it should be easy to identify the coverage type.

2.5 Coverage in Linked Data

4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.4 Diachronic burnt scar Mapping, 4.3 Real-time wildfire monitoring, 4.18 Dissemination of 3D geological data, 4.25 Images, e.g. a time series of a water course, 4.27 Soil data applications, 4.32 Satellite data processing, 4.41 Crop yield estimation using multiple satellites

5.21 Independence on reference systems

Standards or recommendations for spatial data on the Web should be independent on the reference systems that are used for data.

Note

This requirement reflects that spatial data incorporate geographical data, but can also be data that are not directly related to Earth or its scale.

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data, 2.4 Semantic Sensor Network Vocabulary

4.6 Locating a thing, 4.8 Consuming geographical data in a Web application, 4.17 Publishing Cultural heritage data, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.32 Satellite data processing, 4.40 TCGA / microscopy imaging, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web

5.22 Lightweight API

Show how the SSN ontology can be applied in the context of lightweight needs for the Internet of Things (IoT).

2.4 Semantic Sensor Network Vocabulary

4.21 Driving to work in the snow, 4.48 Smart Cities

5.23 Linkability

Spatial data on the Web should be linkable (by explicit relationships between different data in different data sets), to other spatial data and to or from other types of data.

2.4 Semantic Sensor Network Vocabulary, 2.2 Spatial Data on the Web Best Practices

4.28 Bushfire response coordination centre, 4.41 Crop yield estimation using multiple satellites, 4.4 Diachronic burnt scar Mapping, 4.26 Droughts in geological complex environments where groundwater is important, 4.29 Observations on geological samples, 4.23 Optimizing energy consumption, production, sales and purchases in Smart Grids, 4.3 Real-time wildfire monitoring, 4.30 Spatial sampling, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.10 Publishing geospatial reference data, 4.16 Dutch Base Registry, 4.1 Meteorological data rescue, 4.19 Publication of raw subsurface monitoring data, 4.48 Smart Cities, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.25 Images, e.g. a time series of a water course, 4.39 Crowdsourced earthquake observation information, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web, 4.50 Representing geospatial data in RDF, 4.47 Incorporating geospatial data (e.g. geo-referenced geometry) into interactive 3D graphics on the Web

5.24 Linking geometry to CRS

There should be a recommended way of linking vector geometry/geometries to the Coordinate Reference System (CRS) that is used for positions in the geometry/geometries.

2.2 Spatial Data on the Web Best Practices

4.5 Harvesting of Local Search Content, 4.6 Locating a thing, 4.7 Publishing geographical data, 4.8 Consuming geographical data in a Web application, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.12 Using spatial data during emergency response operations, 4.15 Combining spatial RDF data for integrated querying in a triplestore, 4.16 Dutch Base Registry, 4.18 Dissemination of 3D geological data, 4.19 Publication of raw subsurface monitoring data, 4.24 Linked Data for tax assessment, 4.32 Satellite data processing, 4.35 Marine observations - data consumers, 4.36 Building information management and data sharing, 4.39 Crowdsourced earthquake observation information, 4.40 TCGA / microscopy imaging, 4.41 Crop yield estimation using multiple satellites, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata

5.25 Machine to machine

Standards or recommendations for spatial data on the Web should work well in machine to machine environments.

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary

4.6 Locating a thing, 4.21 Driving to work in the snow, 4.39 Crowdsourced earthquake observation information, 4.43 Improving discovery of spatial data on the Web

5.26 Mobile sensors

It should be possible to represent sensors that change their location, as well as the current location of the sensor at the observation time.

2.4 Semantic Sensor Network Vocabulary

4.39 Crowdsourced earthquake observation information, 4.21 Driving to work in the snow, 4.22 Intelligent Transportation System, 4.33 Marine observations - eMII, 4.13 Publication of air quality data aggregations, 4.30 Spatial sampling, 4.32 Satellite data processing, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.48 Smart Cities, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata

5.27 Model actuation

It should be possible to model actuation functions of sensing devices.

Note

Actuation of a sensing device is its ability to change something in its environment upon receiving a signal.

2.4 Semantic Sensor Network Vocabulary

4.21 Driving to work in the snow, 4.22 Intelligent Transportation System, 4.23 Optimizing energy consumption, production, sales and purchases in Smart Grids, 4.48 Smart Cities

5.28 Moving features

It should be possible to refer to features that change their location.

2.4 Semantic Sensor Network Vocabulary

4.21 Driving to work in the snow, 4.22 Intelligent Transportation System

5.29 Multilingual support

All vocabularies that will be developed or revised should have annotation in multiple languages.

Note

We assume that is technically possible to have human readable annotation in multiple languages in vocabularies for spatiotemporal data on the Web. With English being the default language, as many other languages as possible should be supported. This will mean that in such cases we will have to call upon WG members that are fluent in languages other than English to provide annotation.

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data, 2.3 Time Ontology in OWL

4.1 Meteorological data rescue, 4.39 Crowdsourced earthquake observation information, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web, 4.50 Representing geospatial data in RDF

5.30 Multiple CRSs

There should be a recommended way of publishing geometric data with multiple Coordinate Reference Systems (CRSs).

2.2 Spatial Data on the Web Best Practices

4.16 Dutch Base Registry, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.7 Publishing geographical data

5.31 Nominal observations

It should be possible to represent qualitative and nominal observations.

2.4 Semantic Sensor Network Vocabulary

4.39 Crowdsourced earthquake observation information, 4.19 Publication of raw subsurface monitoring data, 4.32 Satellite data processing, 4.27 Soil data applications, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.48 Smart Cities

5.32 Nominal temporal references

It should be possible to refer to time intervals by nominal temporal references (e.g. January, a named event in a calendar, a geological period, a dynastic period).

2.3 Time Ontology in OWL

4.21 Driving to work in the snow, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.38 Metadata and search granularity, 4.1 Meteorological data rescue, 4.17 Publishing Cultural heritage data, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.43 Improving discovery of spatial data on the Web

5.33 Observation aggregations

It should be possible to represent aggregations of observations.

2.4 Semantic Sensor Network Vocabulary

4.39 Crowdsourced earthquake observation information, 4.33 Marine observations - eMII, 4.13 Publication of air quality data aggregations, 4.19 Publication of raw subsurface monitoring data, 4.27 Soil data applications, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.49 Provenance of climate data

5.34 Observed property in coverage

It should be possible to describe the observed property represented by a coverage.

2.5 Coverage in Linked Data

4.41 Crop yield estimation using multiple satellites, 4.18 Dissemination of 3D geological data, 4.33 Marine observations - eMII, 4.1 Meteorological data rescue, 4.27 Soil data applications, 4.49 Provenance of climate data

5.35 Provenance

Ensure alignment of models or vocabularies for describing provenance that exist in the geospatial and Semantic Web domains. Examples are the W3C provenance ontology (PROV-O) and the OGC metadata specification (ISO-19115).

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data, 2.3 Time Ontology in OWL

4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.41 Crop yield estimation using multiple satellites, 4.4 Diachronic burnt scar Mapping, 4.26 Droughts in geological complex environments where groundwater is important, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.1 Meteorological data rescue, 4.29 Observations on geological samples, 4.3 Real-time wildfire monitoring, 4.32 Satellite data processing, 4.25 Images, e.g. a time series of a water course, 4.40 TCGA / microscopy imaging, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web, 4.49 Provenance of climate data

5.36 Quality per sample

It should be possible to describe properties of data quality (e.g. uncertainty) per data sample.

2.5 Coverage in Linked Data

4.41 Crop yield estimation using multiple satellites, 4.1 Meteorological data rescue, 4.18 Dissemination of 3D geological data, 4.26 Droughts in geological complex environments where groundwater is important, 4.33 Marine observations - eMII, 4.27 Soil data applications, 4.25 Images, e.g. a time series of a water course, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web, 4.49 Provenance of climate data

5.37 Reference data chunks

It should be possible to identify and reference chunks of data, e.g. for processing, citation, provenance, cataloging.

2.5 Coverage in Linked Data

4.41 Crop yield estimation using multiple satellites, 4.18 Dissemination of 3D geological data, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.25 Images, e.g. a time series of a water course, 4.37 Landsat data services, 4.1 Meteorological data rescue, 4.40 TCGA / microscopy imaging

5.38 Sampling topology

It should be possible to represent topological relationships between observation samples, e.g. specimens located along a borehole or probe spots found on a polished section of rocks.

2.4 Semantic Sensor Network Vocabulary

4.30 Spatial sampling, 4.33 Marine observations - eMII, 4.19 Publication of raw subsurface monitoring data, 4.29 Observations on geological samples, 4.25 Images, e.g. a time series of a water course

5.39 Sensor metadata

It should be possible to include metadata about the sensors producing the observations.

2.4 Semantic Sensor Network Vocabulary

4.41 Crop yield estimation using multiple satellites, 4.39 Crowdsourced earthquake observation information, 4.1 Meteorological data rescue, 4.3 Real-time wildfire monitoring, 4.4 Diachronic burnt scar Mapping, 4.11 Integration of governmental and utility data to enable smart grids, 4.21 Driving to work in the snow, 4.28 Bushfire response coordination centre, 4.29 Observations on geological samples, 4.30 Spatial sampling, 4.32 Satellite data processing, 4.33 Marine observations - eMII, 4.19 Publication of raw subsurface monitoring data, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.25 Images, e.g. a time series of a water course, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.49 Provenance of climate data

5.40 Sensing procedure

It should be possible to attach the procedural description of a sensing method.

2.4 Semantic Sensor Network Vocabulary

4.32 Satellite data processing, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.1 Meteorological data rescue, 4.19 Publication of raw subsurface monitoring data, 4.35 Marine observations - data consumers, 4.29 Observations on geological samples, 4.27 Soil data applications, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.49 Provenance of climate data

5.41 Space-time multi-scale

It should be possible to represent and integrate data over spatial and temporal scales.

2.4 Semantic Sensor Network Vocabulary, 2.3 Time Ontology in OWL

4.41 Crop yield estimation using multiple satellites, 4.25 Images, e.g. a time series of a water course, 4.22 Intelligent Transportation System, 4.1 Meteorological data rescue, 4.27 Soil data applications, 4.30 Spatial sampling, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.45 Event-like geographic features, 4.38 Metadata and search granularity, 4.17 Publishing Cultural heritage data, 4.19 Publication of raw subsurface monitoring data, 4.49 Provenance of climate data

5.42 Spatial metadata

There should be recommended ways for describing the spatial characteristics of data (data objects, data sets or data services), like:

2.2 Spatial Data on the Web Best Practices

4.1 Meteorological data rescue, 4.5 Harvesting of Local Search Content, 4.7 Publishing geographical data, 4.8 Consuming geographical data in a Web application, 4.12 Using spatial data during emergency response operations, 4.15 Combining spatial RDF data for integrated querying in a triplestore, 4.19 Publication of raw subsurface monitoring data, 4.22 Intelligent Transportation System, 4.25 Images, e.g. a time series of a water course, 4.27 Soil data applications, 4.37 Landsat data services, 4.38 Metadata and search granularity, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web, 4.36 Building information management and data sharing, 4.44 INSPIRE compliance using Web standards, 4.40 TCGA / microscopy imaging, 4.18 Dissemination of 3D geological data, 4.39 Crowdsourced earthquake observation information

5.43 Spatial relationships

There should be a recommended way for expressing spatial relationships between spatial entities. These relationships can be topological, mereological (part-whole), directional or distance related.

2.2 Spatial Data on the Web Best Practices

4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.6 Locating a thing, 4.7 Publishing geographical data, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.31 Select hierarchical geographical regions for use in data analysis or visualisation, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.36 Building information management and data sharing

5.44 Spatial operators

There should be a recommended way for the definition and use of spatial operators. Spatial things can have spatial relations: topological relations, directional or distance relations. Operators based on these relations (e.g. 'Contains'. 'Intersects', 'Nearest', 'within a radius of') should be well defined and easy to use.

2.2 Spatial Data on the Web Best Practices

4.8 Consuming geographical data in a Web application, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.31 Select hierarchical geographical regions for use in data analysis or visualisation, 4.38 Metadata and search granularity, 4.43 Improving discovery of spatial data on the Web, 4.10 Publishing geospatial reference data, 4.40 TCGA / microscopy imaging, 4.41 Crop yield estimation using multiple satellites, 4.39 Crowdsourced earthquake observation information

5.45 Spatial vagueness

It should be possible for vague or informal expressions of locations or spatial relationships to be useful as spatial data.

Examples of vague or informal expressions of locations are:

Examples of vague or informal expressions of spatial relationships are:

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

4.28 Bushfire response coordination centre, 4.38 Metadata and search granularity, 4.1 Meteorological data rescue, 4.30 Spatial sampling, 4.39 Crowdsourced earthquake observation information, 4.17 Publishing Cultural heritage data, 4.19 Publication of raw subsurface monitoring data, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web

5.46 SSN-like representation

It should be possible to represent satellite data using the SSN model, including sensor descriptions.

2.5 Coverage in Linked Data

4.41 Crop yield estimation using multiple satellites, 4.4 Diachronic burnt scar Mapping, 4.3 Real-time wildfire monitoring

5.47 SSN profiles

There should be a recommended way for defining profiles (constrained subsets) of the SSN model and for checking compliance of profiles against the SSN model.

2.4 Semantic Sensor Network Vocabulary

4.32 Satellite data processing

5.48 SSN usage examples

There should be examples of how the SSN ontology can be used together with other vocabularies.

2.4 Semantic Sensor Network Vocabulary

4.11 Integration of governmental and utility data to enable smart grids, 4.14 Publication of transport card validation and recharging data, 4.19 Publication of raw subsurface monitoring data, 4.22 Intelligent Transportation System, 4.23 Optimizing energy consumption, production, sales and purchases in Smart Grids, 4.28 Bushfire response coordination centre, 4.29 Observations on geological samples, 4.30 Spatial sampling, 4.34 Marine observations - data providers, 4.39 Crowdsourced earthquake observation information, 4.41 Crop yield estimation using multiple satellites, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.48 Smart Cities, 4.49 Provenance of climate data

5.49 Streamable data

Data should be streamable, a consumer should be able to do something meaningful before the end of the data message is received.

Note

This could be considered a general requirement for data on the Web, but it is recorded here because spatial data often consist of large chunks of data.

2.2 Spatial Data on the Web Best Practices

4.8 Consuming geographical data in a Web application, 4.47 Incorporating geospatial data (e.g. geo-referenced geometry) into interactive 3D graphics on the Web

5.50 Subject equality

There should be a recommended way to express that data based on different models are about the same real world spatial thing.

2.2 Spatial Data on the Web Best Practices

4.51 Modelling in the construction sector, 4.12 Using spatial data during emergency response operations

5.51 Support for 3D

Standards or recommendations for spatial data on the Web should be applicable to three-dimensional data.

2.2 Spatial Data on the Web Best Practices, 2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

4.18 Dissemination of 3D geological data, 4.7 Publishing geographical data, 4.19 Publication of raw subsurface monitoring data, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.25 Images, e.g. a time series of a water course, 4.26 Droughts in geological complex environments where groundwater is important, 4.36 Building information management and data sharing, 4.39 Crowdsourced earthquake observation information, 4.40 TCGA / microscopy imaging, 4.33 Marine observations - eMII, 4.34 Marine observations - data providers, 4.41 Crop yield estimation using multiple satellites, 4.38 Metadata and search granularity, 4.2 Habitat zone verification for designation of Marine Conservation Zones, 4.49 Provenance of climate data, 4.47 Incorporating geospatial data (e.g. geo-referenced geometry) into interactive 3D graphics on the Web

5.52 Support for tiling

Standards or recommendations for spatial data on the Web should support tiling (for raster and vector data). Tiling of spatial data can drastically improve the speed of data retrieval and allows having simple caches of data around the Web.

2.2 Spatial Data on the Web Best Practices, 2.5 Coverage in Linked Data

4.8 Consuming geographical data in a Web application, 4.47 Incorporating geospatial data (e.g. geo-referenced geometry) into interactive 3D graphics on the Web

5.53 Time dependencies in CRS definitions

It should be possible for Coordinate Reference Systems to have time dependent components such as the point of origin.

2.2 Spatial Data on the Web Best Practices

4.6 Locating a thing, 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.14 Publication of transport card validation and recharging data

5.54 Temporal reference system

If a temporal reference is used, the definition of the temporal reference system (e.g. Unix date, Gregorian Calendar, Japanese Imperial Calendar, Carbon Date, Geological Date) should be referenceable online.

2.3 Time Ontology in OWL

4.45 Event-like geographic features, 4.22 Intelligent Transportation System, 4.38 Metadata and search granularity, 4.1 Meteorological data rescue, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.29 Observations on geological samples, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata

5.55 Temporal vagueness

It should be possible to describe time points and intervals in a vague, imprecise manner. For example:

2.3 Time Ontology in OWL

4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities, 4.45 Event-like geographic features, 4.17 Publishing Cultural heritage data, 4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.43 Improving discovery of spatial data on the Web

5.56 Time series

It should be possible to represent time series of data.

2.3 Time Ontology in OWL, 2.5 Coverage in Linked Data, 2.4 Semantic Sensor Network Vocabulary

4.41 Crop yield estimation using multiple satellites, 4.26 Droughts in geological complex environments where groundwater is important, 4.25 Images, e.g. a time series of a water course, 4.37 Landsat data services, 4.19 Publication of raw subsurface monitoring data, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.25 Images, e.g. a time series of a water course, 4.40 TCGA / microscopy imaging, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata, 4.49 Provenance of climate data

5.57 Uncertainty in observations

It should be possible to represent uncertainty in observations.

2.4 Semantic Sensor Network Vocabulary

4.41 Crop yield estimation using multiple satellites, 4.34 Marine observations - data providers, 4.1 Meteorological data rescue, 4.19 Publication of raw subsurface monitoring data, 4.30 Spatial sampling, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model

5.58 Update datatypes in OWL Time

OWL Time should be updated to align with the 2012 update of OWL datatypes and 2012 update of xsd datatypes

2.3 Time Ontology in OWL

4.17 Publishing Cultural heritage data

5.59 Use in computational models

It should be possible to use coverage data as input or output of computational models, e.g. geological models.

2.5 Coverage in Linked Data

4.41 Crop yield estimation using multiple satellites, 4.18 Dissemination of 3D geological data, 4.26 Droughts in geological complex environments where groundwater is important

5.60 Validation

It should be possible to validate spatial data on the Web; to automatically detect conflicts with standards or definitions.

Note

Although data validation is a general topic, this requirement is included because validation of spatial data requires specialist spatial techniques.

2.2 Spatial Data on the Web Best Practices

4.10 Publishing geospatial reference data, 4.17 Publishing Cultural heritage data, 4.36 Building information management and data sharing

5.61 Valid time

Ensure alignment with existing methods for expressing the time in which data are valid (e.g. dcterms:valid).

Note

This requirement does not mean that the way expressions of time can be used is considered in scope for the Time Ontology, but it does mean that being able to express temporal validity using the Time Ontology is considered important for location data.

2.3 Time Ontology in OWL

4.20 Use of a place name ontology for geo-parsing text and geo-enabling searches, 4.25 Images, e.g. a time series of a water course, 4.31 Select hierarchical geographical regions for use in data analysis or visualisation, 4.45 Event-like geographic features, 4.42 Enabling cross-domain sharing and re-use of geospatial metadata

5.62 Virtual observations

It must be possible to represent synthetic observations made by computational procedures or inference.

2.4 Semantic Sensor Network Vocabulary

4.26 Droughts in geological complex environments where groundwater is important, 4.27 Soil data applications, 4.32 Satellite data processing, 4.41 Crop yield estimation using multiple satellites, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model, 4.19 Publication of raw subsurface monitoring data, 4.49 Provenance of climate data

6. Requirements by deliverable

For convenience, this chapter lists requirements grouped by Working Group deliverable.

6.1 Requirements for deliverable Spatial Data on the Web Best Practices

  1. Avoid coordinate transformations
  2. Bounding box and centroid
  3. Compatibility with existing practices
  4. Compressibility
  5. Coordinate precision
  6. Crawlability
  7. CRS definition
  8. Determinable CRS
  9. Discoverability
  10. Encoding for vector geometry
  11. Independence on reference systems
  12. Linkability
  13. Linking geometry to CRS
  14. Machine to machine
  15. Multilingual support
  16. Multiple CRSs
  17. Provenance
  18. Spatial metadata
  19. Spatial relationships
  20. Spatial operators
  21. Spatial vagueness
  22. Streamable data
  23. Subject equality
  24. Support for 3D
  25. Support for tiling
  26. Time dependencies in CRS definitions
  27. Validation

6.2 Requirements for deliverable Time Ontology in OWL

  1. 4D model of space-time
  2. Date, time and duration
  3. Different time models
  4. Multilingual support
  5. Nominal temporal references
  6. Provenance
  7. Space-time multi-scale
  8. Temporal reference system
  9. Temporal vagueness
  10. Time series
  11. Update datatypes in OWL Time
  12. Valid time

6.3 Requirements for deliverable Semantic Sensor Network Vocabulary

  1. Compatibility with existing practices
  2. CRS definition
  3. Dynamic sensor data
  4. Ex-situ sampling
  5. Georeferenced spatial data
  6. Humans as sensors
  7. Independence on reference systems
  8. Lightweight API
  9. Linkability
  10. Machine to machine
  11. Mobile sensors
  12. Model actuation
  13. Moving features
  14. Multilingual support
  15. Nominal observations
  16. Observation aggregations
  17. Provenance
  18. Sampling topology
  19. Sensor metadata
  20. Sensing procedure
  21. Space-time multi-scale
  22. Spatial vagueness
  23. SSN profiles
  24. SSN usage examples
  25. Support for 3D
  26. Time series
  27. Uncertainty in observations
  28. Virtual observations

6.4 Requirements for deliverable Coverage in Linked Data

  1. Avoid coordinate transformations
  2. Compatibility with existing practices
  3. Coordinate precision
  4. Coverage temporal extent
  5. Discoverability
  6. Georectification
  7. Georeferenced spatial data
  8. Identify coverage type
  9. Independence on reference systems
  10. Multilingual support
  11. Observed property in coverage
  12. Provenance
  13. Quality per sample
  14. Reference data chunks
  15. Spatial vagueness
  16. SSN-like representation
  17. Support for 3D
  18. Support for tiling
  19. Time series
  20. Use in computational models

7. Acknowledgments

The editors are grateful for all contributions made to this document. In particular we thank the people that have contributed use cases (their names are mentioned with each use case) and the Working Group members that helped in mining and refining the requirements.

8. Appendix A: History of changes

8.1 Changes between the First Public Working Draft and Second Public Working Draft

A summary of the main changes between the First Public Working Draft (published 2015-07-23) and the Second Public Working Draft (this version) of this document:

8.2 Changes between the Second Public Working Draft and Third Public Working Draft

A summary of the main changes between the Second Public Working Draft (published 2015-12-17) and the Third Public Working Draft (this version) of this document: