BP Requirements

This is a preliminary list of requirements identified in the UC partial review carried out during the 1st SDW WG f2f (see Minutes from Best Practice deliverable group).

Requirements specific to spatial data

Be able to get the data with coordinates that match the coordinate system of my map

Andrea Perego (talk): Should we re-phrase the requirement to include the "ability to get the data at the zoom level of my map"?

Relevant use cases:

• UC-9: Consuming geographical data in a web application (Best Practice)

Be able to mix spatial operators with general ones in queries

Relevant use cases:

• UC-9: Consuming geographical data in a web application (Best Practice)

Named places can overlap and change over time

Bill: suggest separating this into two requirements: (a) named places can overlap and (b) named places can change over time

Relevant use cases:

• UC-10: Enabling publication, discovery and analysis of spatiotemporal data in the humanities (Best Practice, Time)
• UC-34: Select hierarchical geographical regions for use in data analysis or visualisation (Best_practices, Time)

Places can be movable objects

Relevant use cases:

• UC-15: Publication of transport card validation and recharging data (SSN, Best Practice)

Places can be fictional

[Chaals will contribute a use case on this.]

Common vocabulary for metadata about spatial datasets

Relevant use cases:

• UC-16: Combining spatial RDF data for integrated querying in a triplestore (Best Practice)
• UC-45 (to be discussed): Geospatial extensions to domain-independent metadata schemas (Best Practice)

URIs for common spatial reference systems

Relevant use cases:

• UC-8
• UC-16: Combining spatial RDF data for integrated querying in a triplestore (Best Practice)

Recommendations for a default, canonical spatial reference system for spatial data published on the web

Relevant use cases:

• UC-16: Combining spatial RDF data for integrated querying in a triplestore (Best Practice)

Recommendations for serializing geometries as RDF

Linda van den Brink: Does this include: How should I publish vector data? What is the best encoding to use? (UC-8)

Relevant use cases:

• UC-16: Combining spatial RDF data for integrated querying in a triplestore (Best Practice)
• UC-45 (to be discussed): Geospatial extensions to domain-independent metadata schemas (Best Practice)

Be able to validate data, specifically geometries

Relevant use cases:

• UC-19: Publishing Cultural Heritage Data (Best Practice, Time, Coverage)

Be able to consume data whether it's valid or not

Relevant use cases:

• UC-19: Publishing Cultural Heritage Data (Best Practice, Time, Coverage)

Be able to find spatial data based on point coordinates, bouding box, polygon, current location, place name.

Relevant use cases:

• UC-17
• UC-31
• UC-46

References to a location can be fuzzy

Relevant use cases:

• UC-7
• UC-10
• UC-19
• UC-22

A location can be indoor

Relevant use cases:

• UC-7

Relationships between locations can be hierarchic

Relevant use cases:

• UC-7
• UC-34

3D geometry

Relevant use cases:

• UC-9
• UC-20
• UC-29
• UC-39
• UC-43
• UC-44

Common vocabulary for spatial data

Relevant use cases:

• UC-17

Requirements not specific to spatial data

Use (persistent and dereferenceable) URIs to make (spatial) data visible on the Web

See the discussion on URIs in the BP session minutes.

Relevant use cases:

• UC-2 : Meteorological Data Rescue Use Case (Best Practice, Time, SSN, Coverage)
• UC-11 : Publishing geospatial reference data (Best Practice)
• UC-15 : Publication of transport card validation and recharging data (SSN, Best Practice)
• UC-31 : Bushfire response coordination centre (Best practice, SSN)
• UC-45 (to be discussed): Geospatial extensions to domain-independent metadata schemas (Best Practice)

Related DWBP WG BP (24 Feb 2015):

• Best Practice 11: Use unique identifiers

How this should be implemented for spatial data?

TBD

Design systems that are largely machine-to-machine

See the discussion on URIs in the BP session minutes.

Relevant use cases:

• UC-9: Consuming geographical data in a web application (Best Practice)
• UC-46 (to be discussed): Improving discovery of spatial data on the Web (Best Practice)

Related DWBP WG BPs (24 Feb 2015):

• Best Practice 2: Use machine-readable formats to provide metadata
• Best Practice 12: Use machine-readable standardized data formats
• Best Practice 23: Follow REST principles when designing APIs

How this should be implemented for spatial data?

TBD - issue about support to different formats and APIs

Content need to be crawlable, then able to ask search engine or other service

See the discussion on URIs in the BP session minutes.

Relevant use cases:

• UC-9: Consuming geographical data in a web application (Best Practice)
• UC-46 (to be discussed): Improving discovery of spatial data on the Web (Best Practice)

Related DWBP WG BPs (24 Feb 2015):

• Best Practice 2: Use machine-readable formats to provide metadata
• Best Practice 12: Use machine-readable standardized data formats

How this should be implemented for spatial data?

TBD

Be able to annotate data with a specification of what the information is / where do you find the geographic information for the wellknown reference like a zip code

Relevant use cases:

• UC-11 : Publishing geospatial reference data (Best Practice)

How this should be implemented for spatial data?

TBD

Be able to use data coming from different systems, not only linked data

Relevant use cases:

• UC-13 : Using spatial data from the web in GIS systems during emergency response operations

Related DWBP WG BPs (24 Feb 2015):

• Best Practice 14: Provide data in multiple formats

How this should be implemented for spatial data?

TBD

Be able to ask an endpoint what questions it can answer

Relevant use cases:

• UC-9: Consuming geographical data in a web application (Best Practice)

How this should be implemented for spatial data?

TBD - issue about support to spatial / temporal queries (e.g., GeoSPARQL, stSPARQL)

Data need to be streamable

Relevant use cases:

• UC-23: Driving to work in the snow (SSN, Time, Coverage)

Related DWBP WG BP (24 Feb 2015):

• Best Practice 24: Provide real-time access

How this should be implemented for spatial data?

TBD

It should be possible for a system using (spatial) data on the Web to be fast

Relevant use cases:

• UC-9: Consuming geographical data in a web application (Best Practice)

How this should be implemented for spatial data?

TBD - issue about size, formats and granularity of spatial data

• coverages, as they tend to be large, server-side subsetting must be possible with arbitrary selection by the client (trimming and slicing in space and time). See OGC Web Coverage Service (WCS) for an abstract (protocol-independent) service doing this (in the WCS Core), plus more common functionality (in extensions).
• Furthermore, server-side coverage filtering and processing should be supported. Filtering means: deliver only those coverages that fulfill some selection criterion (such as: less than 30% clouds in an image). Processing (i) relieves the client from doing that and (ii) has a potential to further reduce the data delivered over the wire (example: deliver vegetation index, NDVI, as a single band rather than a full 36-band hyperspectral image or the 2 bands required to compute the NDVI). A standardized high-level, declarative query language on n-D spatio-temporal raster data capable of filtering and processing is the OGC Web Coverage Processing Service (WCPS). It has been demonstrated how to effectively optimize and parallelize queries on server side.

(NB: above edits on coverages done by pebau - newbie, hence probably editing in wrong style and in wrong place. Kindly educate me on doing better.)