diff --git a/UseCases/SDWUseCasesAndRequirements.html b/UseCases/SDWUseCasesAndRequirements.html index 254cf810..2ddd18a0 100644 --- a/UseCases/SDWUseCasesAndRequirements.html +++ b/UseCases/SDWUseCasesAndRequirements.html @@ -174,7 +174,7 @@

Meteorological Data Rescue

She receives the pamphlet as a scanned image of each page, and she decides that the quantitative information in the paper is useful, so she arranges transcription of the tabular numerical data and their summary values into a digital form and publishes the dataset, with a persistent identifier, and links it to a detailed coverage extent, the original paper source, the scanned pages and her paper when it is published. She also incorporates scanned charts and graphs from the original pamphlet into her paper. Her organization creates a catalog record for her research paper dataset and publishes it in the WIS global catalog, which makes it also visible to the GEO System of Systems broker portal.

, , ,

-

, , , , , , , , , , , , , , , , , , , , , ,

+

, , , , , , , , , , , , , , , , , , , , ,

Habitat zone verification for designation of Marine Conservation Zones

@@ -324,7 +324,7 @@

Consuming geographical data in a web application

  • How can I ensure responsiveness of my application (low wait times when accessing data)?
  • -

    , , , ,

    +

    , , , ,

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

    @@ -385,7 +385,7 @@

    Integration of governmental and utility data to enable smart grids

    The research project CERISE-SG aims to integrate data from different domains: government, energy utilities and geography, in order to enable establishment of smart energy grids.

    The project has recognized Linked Data as an appropriate concept for integration of data from separate semantic domains. One approach of achieving cross-domain interoperability is to switch from domain-specific semantics to common semantics. For example, the concept of an address has its own definitions in governmental standards and utility standards. Using a common definition improves interoperability.

    An example of a domain model that is an international standard in electric utilities is the Common Information Model (CIM). Its data model provides definitions for an important entity: the electricity meter. These meters provide useful data on consumption and production of energy. If it is possible to view these devices as sensors, it could be possible to move from domain specific semantics (CIM) to common semantics (SSN), and to have ready linkage to geographical semantics (location and network topology). What is required in this case is a low-threshold way of using sensor semantics, because people involved in integration of data from multiple domains should not be burdened with having to grasp the full complexity of each domain.

    -

    ,

    +

    ,

    , , ,

    @@ -413,7 +413,7 @@

    Publication of air quality data aggregations

    How: We use the Location Core vocabulary to model the address, e.g. :station locn:address "C/ Gran Vía (Paraninfo)"^^xsd:string. We use xsd:dateTime to represent hourly observations, e.g. :obs ssn:observationResultTime "2003-03-08T11:00:00Z"^^xsd:dateTime.

    Open challenges: The combination of hourly observations and daily aggregations in the same dataset may cause confusion because the granularity of the observation is not explicit. For daily aggregations, we suggest using time:Interval from the Time Ontology. To make the temporal modeling more homogeneous, time:Instant could be used for the hourly observations. [LINK TO DATA SAMPLE TO BE ADDED]

    -

    ,

    +

    ,

    , , ,

    @@ -425,7 +425,7 @@

    Publication of transport card validation and recharging data

    What: The Regional Transport Consortium of Madrid (CRTM) wants to make available data about transport card validations and transport card recharging. In the case of transport card validations, the NFC sensors are located on buses, and at the entrance and (some) exit points of metro stations. The observation value of a validation includes data related to the transport card, such as the card identifier and the user profile. The sensors for transport card recharging are ATMs and ticket selling points distributed around Madrid. The observation value of a recharging includes the card identifier and the type of recharging.

    How: To model transport card validations, we consider two observed properties: user entry (EntradaUsuario) and user exit (SalidaUsuario). Validation sensors at metro stations have a fixed location and a unique identifier, e.g. 02_L12_P2. A bus validation sensor is moving continuously, so for the sake of pragmatism, there is a unique sensor identifier for each bus stop in every line, e.g. 03_L20_P837. Those identifiers point to an address and geographic coordinates. The observed property when a user adds money to her transport card is the act of recharging (CargaTTP). In both cases, validation and recharging observations, the feature of interest is the transport card.

    -

    ,

    +

    ,

    @@ -434,19 +434,20 @@

    Combining spatial RDF data for integrated querying in a triplestore

    -

    RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets. +

    RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets.

    For example, Ordnance Survey linked data uses British National Grid SRS and represents geometries with an Ordnance Survey-developed ontology, and LinkedGeoData uses WGS84 longitude latitude and represents geometries as GeoSPARQL WKT literals.

    -

    Best practices in the following areas would help make integration more straightforward. -

  • Agreed-upon vocabulary for metadata about spatial datasets
  • -
  • Agreed-upon URIs for common spatial reference systems
  • -
  • Recommendations for a default, canonical spatial reference system for spatial data published on the Web
  • -
  • Recommendations for serializing geometries as RDF
  • -

    Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.

    +

    Best practices in the following areas would help make integration more straightforward.

    +

    Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.

    , ,

    @@ -459,7 +460,7 @@

    Dutch Base Registry

    Dutch government data is for a large part open data. However, at the moment the data is difficult to find, and it cannot be easily linked to other data. It is not helping that most registrations are making use of their heavy backoffice standards for opening their data. These problems are counteracted by copying data of others, involving heavy expenses for collecting, converting and synchronizing the data, or by building expensive national provisions. The result is an abundance of copies and much doubt regarding the authenticity of the information.

    A better solution would be to make the authentic data permanently available as linked data, so that everyone can use it and the datasets can be interlinked, resulting in more coherence and improved traceability and no more need for copying and synchronization.

    -

    There are now 13 Dutch ‘base registries’ containing government reference data: e.g. +

    There are now 13 Dutch ‘base registries’ containing government reference data: e.g.

    Publication of Raw Subsurface Monitoring Data

    @@ -662,7 +663,7 @@

    Images, e.g. a Time series of a Water Course

    This additional information supports a broader need for SSN, Coverage and Time considerations for the above three current use cases.

    , , ,

    -

    , , , , , , , , , , , , , , ,

    +

    , , , , , , , , , , , , , , ,

    Droughts in geological complex environments where groundwater is important

    @@ -684,7 +685,7 @@

    References

    , , ,

    @@ -732,8 +733,8 @@

    User story

  • Related places [uc7.2] – e.g. a local government area that contains the suburb, or hydrological reporting units cover the suburb.
  • information about related places e.g.:
  • @@ -809,7 +810,7 @@

    Satellite data processing

    1. Data from the TM (Landsat 5) and ETM+ (Landsat 7) sensors were downloaded from the United States Geological Survey (USGS) and corrected for atmosphere, topographic and bi-directional surface reflectance effects, standardized to a nadir view (i.e., satellite zenith angle is zero) and a solar zenith angle of 45°)
    2. The MODIS 16-Day Nadir BRDF-Adjusted Reflectance product (MCD43A4) provides surface reflectance data as if they were taken from the nadir view and uses the solar angle calculated at local solar noon (Schaaf et al., 2002). MCD43A4 data were obtained from the Land Processes Distributed Active Archive Center (LPDAAC). These data were resampled to a geographic coordinate system.
    3. -
    4. The MODIS surface reflectance products from the Terra satellite (MOD09) provide an estimate of the surface spectral reflectance as it would be measured at ground level in the absence of atmospheric scattering and absorption (Vermote et al, 2011; Vermote & Kotchenova, 2008). The 8-day composite (MOD09A1) selects the best possible observation from an 8-day window, selected on the basis of high observation coverage, low viewing angle, cloud free and low aerosol loading, with a spatial resolution of 500 meters and seven spectral bands. The MOD09A1 surface reflectance data used here were subject to the same geometric processing as the MCD43A4 data.
    5. +
    6. The MODIS surface reflectance products from the Terra satellite (MOD09) provide an estimate of the surface spectral reflectance as it would be measured at ground level in the absence of atmospheric scattering and absorption (Vermote et al, 2011; Vermote & Kotchenova, 2008). The 8-day composite (MOD09A1) selects the best possible observation from an 8-day window, selected on the basis of high observation coverage, low viewing angle, cloud free and low aerosol loading, with a spatial resolution of 500 meters and seven spectral bands. The MOD09A1 surface reflectance data used here were subject to the same geometric processing as the MCD43A4 data.
    7. Field measurements of fractional cover were obtained at 913 sites across Australia (ABARES, 2013). Exactly 78 of those sites were sampled repeatedly, resulting in a total of 127 observations (a measurement taken at a given site on a specific date). The field observations did not systematically record soil color or soil moisture. Recent observations include soil color (Munsell Soil Color Charts, 1994), yet soil moisture is only subjectively measured (i.e., wet or dry). To derive these two soil properties consistently and objectively for the entire series we used information derived from other sources.

    As a result, a combined product is proposed which gives flexibility to use MODIS-derived estimates when large areas and high temporal repetition is desired, and Landsat-derived estimates when high spatial resolution is essential and/or when data prior to 2000 is needed. The algorithms needed for implementing a fractional cover product based on a blended Landsat-MODIS product are given [1].

    @@ -855,7 +856,7 @@

    Atlas of Living Australia (ALA)

    Reef Life Survey (RLS)

    RLS have visited 2500+ coral and rocky reef sites and have conducted approx 6000 surveys across those sites. Each survey is conducted at a nominal ‘site’.

    -
    Methods 1 & 2
    +
    Methods 1 & 2

    During a survey observations are recorded of each of (1) vertebrate species abundance and biomass and (2) invertebrate species abundance.

    @@ -993,7 +994,7 @@

    TCGA / Microscopy Imaging

    Studying the morphology of disease at the cellular and sub-cellular levels using high resolution tissue images is extremely important to help understand the nature of various cancers. The Cancer Genome Atlas (TCGA) contains over 32,000 de-identified whole-slide microscopy images (WSI) of over two dozen cancer types. These images can contain between 100K-1M nuclei each. Biomedical informatics researcher have developed (and continue to develop) software to automatically segment nuclei for study. The spatial features of each nucleus and groups of nuclei as it relates to other nuclei combined with other linked data such as other morphological features (crypts, ducts, etc.) and/or patient lab results are used in analyzing and categorizing tissues and patients into groups and in comparing such groupings to understand disease mechanisms in a particular cancer type as well as across cancer types.

    -

    Representing nuclear segmentations is often done with binary masks or through polygon representations (e.g., the use of Well Known Text (WKT) representations) and also by leveraging work from the Geospatial community. However, in the case of nuclear segmentations, coordinate systems are 2D & 3D Cartesian based. Although the majority of work is this area is 2D-based, a growing segment of microscopy is also 3D-based as the technology develops and become more sophisticated. As living tissue can change over time through growth, infection, cancer, damage, etc, (as well as its associated organism’s various properties) it is important that spatial locations of features such as nuclear segmentation be also represented in a temporal aspect for proper comparisons.

    +

    Representing nuclear segmentations is often done with binary masks or through polygon representations (e.g., the use of Well Known Text (WKT) representations) and also by leveraging work from the Geospatial community. However, in the case of nuclear segmentations, coordinate systems are 2D & 3D Cartesian based. Although the majority of work is this area is 2D-based, a growing segment of microscopy is also 3D-based as the technology develops and become more sophisticated. As living tissue can change over time through growth, infection, cancer, damage, etc, (as well as its associated organism’s various properties) it is important that spatial locations of features such as nuclear segmentation be also represented in a temporal aspect for proper comparisons.

    Samples of TCGA WSI data can be viewed at: http://cancer.digitalslidearchive.net

    ,

    @@ -1126,7 +1127,7 @@

    Incorporating geospatial data (e.g. geo-referenced geometry) into interactiv

    -

    , , , ,

    +

    , , , ,

    Smart Cities

    @@ -1308,7 +1309,7 @@

    4D model of space-time

    Model reuse

    -

    Spatial data modeling issues solved in existing models shall be considered for adoption, e.g. O&M or SoilML.

    +

    Spatial data modeling issues solved in existing models shall be considered for adoption, e.g. O&M or SoilML.

    ,

    , , , , , , ,

    diff --git a/UseCases/snapshots/Spatial Data on the Web Use Cases & Requirements (First Public Working Draft).html b/publishing-snapshots/FPWD-2015-06-11-UseCases/Overview.html similarity index 58% rename from UseCases/snapshots/Spatial Data on the Web Use Cases & Requirements (First Public Working Draft).html rename to publishing-snapshots/FPWD-2015-06-11-UseCases/Overview.html index 49ba4344..9f83cb2d 100644 --- a/UseCases/snapshots/Spatial Data on the Web Use Cases & Requirements (First Public Working Draft).html +++ b/publishing-snapshots/FPWD-2015-06-11-UseCases/Overview.html @@ -1,7 +1,7 @@ - - - + + + Spatial Data on the Web Use Cases & Requirements @@ -221,19 +221,19 @@ margin: 0 0.35em 0.25em -1.6em; vertical-align: middle; } - -

    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.40 Spatial metadata, 5.4 Coverage temporal extent, 5.6 CRS definition, 5.7 Date, time and duration, 5.9 Different time models, 5.10 Discoverability, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.25 Multilingual support, 5.28 Nominal temporal references, 5.31 Observed property in coverage, , 5.32 Provenance, 5.33 Quality metadata, 5.34 Reference data chunks, 5.35 Reference external vocabularies, 5.38 Sensing procedure, 5.37 Sensor metadata, 5.39 Space-time multi-scale, 5.43 Spatial vagueness, 5.48 Temporal reference system, 5.52 Uncertainty in observations, 5.5 Crawlability

    +

    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.40 Spatial metadata, 5.4 Coverage temporal extent, 5.6 CRS definition, 5.7 Date, time and duration, 5.9 Different time models, 5.10 Discoverability, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.25 Multilingual support, 5.28 Nominal temporal references, 5.31 Observed property in coverage, 5.32 Provenance, 5.33 Quality metadata, 5.34 Reference data chunks, 5.35 Reference external vocabularies, 5.38 Sensing procedure, 5.37 Sensor metadata, 5.39 Space-time multi-scale, 5.43 Spatial vagueness, 5.48 Temporal reference system, 5.52 Uncertainty in observations, 5.5 Crawlability

    -
    -

    4.2 Habitat zone verification for designation of Marine Conservation Zones

    +
    +

    4.2 Habitat zone verification for designation of Marine Conservation Zones

    Jeremy Tandy

    @@ -446,11 +446,11 @@

    These information types are varied in type and size. In particular, the acoustic survey (e.g. side-scan sonar) is difficult to manage as these survey results can be many gigabytes in size and cover large areas. A way is needed to refer to just a small part of these coverage data sets that are relevant to a particular habitat zone analysis.

    -

    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.15 Georeferenced spatial data, 5.26 Multiple types of coverage, 5.32 Provenance, 5.34 Reference data chunks, 5.37 Sensor metadata, 5.6 CRS definition, 5.35 Reference external vocabularies, 5.21 Mobile sensors, 5.19 Linkability, 5.27 Nominal observations, 5.16 Humans as sensors, 5.46 Support for 3D, 5.13 Ex-situ sampling, 5.38 Sensing procedure

    +

    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.15 Georeferenced spatial data, 5.26 Multiple types of coverage, 5.32 Provenance, 5.34 Reference data chunks, 5.37 Sensor metadata, 5.6 CRS definition, 5.35 Reference external vocabularies, 5.21 Mobile sensors, 5.19 Linkability, 5.27 Nominal observations, 5.16 Humans as sensors, 5.46 Support for 3D, 5.13 Ex-situ sampling, 5.38 Sensing procedure

    -
    -

    4.3 Real-time Wildfire Monitoring

    +
    +

    4.3 Real-time Wildfire Monitoring

    Manolis Koubarakis

    @@ -478,11 +478,11 @@

    < Some of the data used in the operational service is available separately.

    -

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

    -

    5.6 CRS definition, 5.14 Georectification, 5.19 Linkability, 5.26 Multiple types of coverage, 5.32 Provenance, 5.37 Sensor metadata, 5.11 Dynamic sensor data, 5.44 SSN-like representation

    +

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

    +

    5.6 CRS definition, 5.14 Georectification, 5.19 Linkability, 5.26 Multiple types of coverage, 5.32 Provenance, 5.37 Sensor metadata, 5.11 Dynamic sensor data, 5.44 SSN-like representation

    -
    -

    4.4 Diachronic Burnt Scar Mapping

    +
    +

    4.4 Diachronic Burnt Scar Mapping

    Manolis Koubarakis

    @@ -493,11 +493,11 @@

    <

    Finally, the post-processing stage consists of (i) a visual refinement step to ensure product thematic accuracy and consistency, (ii) attribute enrichment of the product by overlaying the polygons with geoinformation layers and finally (iii) generation of thematic maps. It would be interesting for NOA to see where the standards to be developed in this working group could be used.

    The burnt scar mapping service is operational.

    -

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

    -

    5.6 CRS definition, 5.14 Georectification, 5.19 Linkability, 5.26 Multiple types of coverage, 5.32 Provenance, 5.37 Sensor metadata, 5.44 SSN-like representation

    +

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

    +

    5.6 CRS definition, 5.14 Georectification, 5.19 Linkability, 5.26 Multiple types of coverage, 5.32 Provenance, 5.37 Sensor metadata, 5.44 SSN-like representation

    -
    -

    4.5 Harvesting of Local Search Content

    +
    +

    4.5 Harvesting of Local Search Content

    Ed Parsons

    @@ -515,11 +515,11 @@

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

    -

    5.7 Date, time and duration, 5.5 Crawlability, 5.10 Discoverability

    +

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

    +

    5.7 Date, time and duration, 5.5 Crawlability, 5.10 Discoverability

    -
    -

    4.6 Locating a thing

    +
    +

    4.6 Locating a thing

    Ed Parsons

    @@ -527,11 +527,11 @@

    With the increasing availability of small, mobile location aware devices the requirement to identify a location human terms is becoming more important. While the determination of sensor in space to a high level of precision is a largely solved problem we are less able to express the location in terms meaningful to humans. The fact that the Bluetooth-LE tracker attached to my bag is at 51.4256853,-0.3317991,4.234500 is much less useful than the description, "Under your bed at home". At others times the location descriptions "24 Bridgeman Road, Teddington, TW11 8AH, UK" might be equally valid, as might "Teddington", "South West London", "England", "UK", "Inside", "Where you left it Yesterday", "Upstairs", "45 minutes from here" or "150 meters from the Post Office".

    A better understanding of how we describe places in human terms, the hierarchical nature of places and the fuzzy nature of many geographical entities will be needed to make the "Internet of Things" manageable. A new scale of geospatial analysis may be required using a reference frame based on the locations of individuals rather than a global spherical co-ordinate, allowing a location of your keys and their attached bluetooth tag to be described as "in the kitchen".

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.17 Independence on reference systems, 5.47 Time dependencies in CRS definitions, 5.20 Machine to machine

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.17 Independence on reference systems, 5.47 Time dependencies in CRS definitions, 5.20 Machine to machine

    -
    -

    4.7 Publishing geographical data

    +
    +

    4.7 Publishing geographical data

    Frans Knibbe

    @@ -548,11 +548,11 @@

    <

    From the last two questions it follows that the WG could also be involved in enabling conformance testing and stimulating development of benchmarks for software.

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.46 Support for 3D, 5.1 Bounding box and centroid, 5.2 Compatibility with existing practices

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.46 Support for 3D, 5.1 Bounding box and centroid, 5.2 Compatibility with existing practices

    -
    -

    4.8 Consuming geographical data in a web application

    +
    +

    4.8 Consuming geographical data in a web application

    Frans Knibbe

    @@ -573,11 +573,11 @@

    2.2 Spatial Data on the Web Best Practices

    -

    5.1 Bounding box and centroid, 5.5 Crawlability, 5.50 Support for tiling, 5.17 Independence on reference systems,

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.1 Bounding box and centroid, 5.5 Crawlability, 5.50 Support for tiling, 5.17 Independence on reference systems, 5.3 Compressible

    -
    -

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

    +
    +

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

    Frans Knibbe, Karl Grossner

    @@ -603,11 +603,11 @@

    Temporal

  • Temporal references are frequently inexact, or relational with variable precision. The above referenced data set has a mix, including "around March 1832," "before 1750," "after WW II."
  • -

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

    -

    5.7 Date, time and duration, 5.28 Nominal temporal references, 5.39 Space-time multi-scale, 5.49 Temporal vagueness, 5.47 Time dependencies in CRS definitions, 5.17 Independence on reference systems

    +

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

    +

    5.7 Date, time and duration, 5.28 Nominal temporal references, 5.39 Space-time multi-scale, 5.49 Temporal vagueness, 5.47 Time dependencies in CRS definitions, 5.17 Independence on reference systems

    -
    -

    4.10 Publishing geospatial reference data

    +
    +

    4.10 Publishing geospatial reference data

    Clemens Portele

    @@ -623,11 +623,11 @@

    2.2 Spatial Data on the Web Best Practices

    -

    5.54 Validation, 5.19 Linkability, 5.42 Spatial operators, 5.15 Georeferenced spatial data

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.54 Validation, 5.19 Linkability, 5.42 Spatial operators, 5.15 Georeferenced spatial data

    -
    -

    4.11 Integration of governmental and utility data to enable smart grids

    +
    +

    4.11 Integration of governmental and utility data to enable smart grids

    Frans Knibbe

    @@ -635,11 +635,11 @@

    CERISE-SG aims to integrate data from different domains: government, energy utilities and geography, in order to enable establishment of smart energy grids.

    The project has recognized Linked Data as an appropriate concept for integration of data from separate semantic domains. One approach of achieving cross-domain interoperability is to switch from domain-specific semantics to common semantics. For example, the concept of an address has its own definitions in governmental standards and utility standards. Using a common definition improves interoperability.

    An example of a domain model that is an international standard in electric utilities is the Common Information Model (CIM). Its data model provides definitions for an important entity: the electricity meter. These meters provide useful data on consumption and production of energy. If it is possible to view these devices as sensors, it could be possible to move from domain specific semantics (CIM) to common semantics (SSN), and to have ready linkage to geographical semantics (location and network topology). What is required in this case is a low-threshold way of using sensor semantics, because people involved in integration of data from multiple domains should not be burdened with having to grasp the full complexity of each domain.

    -

    2.2 Spatial Data on the Web Best Practices,

    -

    5.37 Sensor metadata, 5.19 Linkability, 5.10 Discoverability, 5.40 Spatial metadata

    +

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

    +

    5.37 Sensor metadata, 5.19 Linkability, 5.10 Discoverability, 5.40 Spatial metadata

    -
    -

    4.12 Using spatial data from the web in GIS systems during emergency response operations

    +
    +

    4.12 Using spatial data from the web in GIS systems during emergency response operations

    Bart van Leeuwen

    @@ -650,11 +650,11 @@

    GIS data (in e.g. WFS services) and data on the Web and vice versa, express that a certain linked data resource is also available through a GIS service (rdfs:seeAlso is considered by many to be too limited) or describe the spatial component in the linked data directly.

    Being able to plot and exchange data about active incidents through the Web and visualize them in GIS tools with open standards would be a huge leap forward for Emergency response services.

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.2 Compatibility with existing practices, 5.10 Discoverability, 5.40 Spatial metadata, 5.19 Linkability

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.2 Compatibility with existing practices, 5.10 Discoverability, 5.40 Spatial metadata, 5.19 Linkability

    -
    -

    4.13 Publication of air quality data aggregations

    +
    +

    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)

    @@ -663,11 +663,11 @@

    Location Core vocabulary to model the address, e.g. :station locn:address "C/ Gran Vía (Paraninfo)"^^xsd:string. We use xsd:dateTime to represent hourly observations, e.g. :obs ssn:observationResultTime "2003-03-08T11:00:00Z"^^xsd:dateTime.

    Open challenges: The combination of hourly observations and daily aggregations in the same dataset may cause confusion because the granularity of the observation is not explicit. For daily aggregations, we suggest using time:Interval from the Time Ontology. To make the temporal modeling more homogeneous, time:Instant could be used for the hourly observations. [LINK TO DATA SAMPLE TO BE ADDED]

    -

    , 2.3 Time Ontology in OWL

    -

    5.7 Date, time and duration, 5.23 Model reuse, 5.30 Observation aggregations, 5.35 Reference external vocabularies

    +

    2.4 Semantic Sensor Network Vocabulary, 2.3 Time Ontology in OWL

    +

    5.7 Date, time and duration, 5.23 Model reuse, 5.30 Observation aggregations, 5.35 Reference external vocabularies

    -
    -

    4.14 Publication of transport card validation and recharging data

    +
    +

    4.14 Publication of transport card validation and recharging data

    Alejandro Llaves (OEG-UPM)

    @@ -675,42 +675,43 @@

    2.2 Spatial Data on the Web Best Practices,

    -

    5.47 Time dependencies in CRS definitions

    +

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

    +

    5.47 Time dependencies in CRS definitions

    -
    -

    4.15 Combining spatial RDF data for integrated querying in a triplestore

    +
    +

    4.15 Combining spatial RDF data for integrated querying in a triplestore

    Matthew Perry (Oracle)

    -

    RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets. -

      +

      RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets.

      +
      • Inconsistent, incomplete, and non-standard metadata descriptions of spatial data
      • Different representations of geometry data across different datasets
      • Different spatial reference systems used across different datasets
      • Different scales used across different datasets

      For example, Ordnance Survey linked data uses British National Grid SRS and represents geometries with an Ordnance Survey-developed ontology, and LinkedGeoData uses WGS84 longitude latitude and represents geometries as GeoSPARQL WKT literals.

      -

      Best practices in the following areas would help make integration more straightforward. -

    • Agreed-upon vocabulary for metadata about spatial datasets
    • -
    • Agreed-upon URIs for common spatial reference systems
    • -
    • Recommendations for a default, canonical spatial reference system for spatial data published on the Web
    • -
    • Recommendations for serializing geometries as RDF
    • -

      Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.

      +

      Best practices in the following areas would help make integration more straightforward.

      +
        +
      • Agreed-upon vocabulary for metadata about spatial datasets
      • +
      • Agreed-upon URIs for common spatial reference systems
      • +
      • Recommendations for a default, canonical spatial reference system for spatial data published on the Web
      • +
      • Recommendations for serializing geometries as RDF
      • +

      Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.8 Default CRS, 5.12 Encoding for vector geometry, 5.40 Spatial metadata

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.8 Default CRS, 5.12 Encoding for vector geometry, 5.40 Spatial metadata

    -
    -

    4.16 Dutch Base Registry

    +
    +

    4.16 Dutch Base Registry

    Linda van den Brink

    Dutch government data is for a large part open data. However, at the moment the data is difficult to find, and it cannot be easily linked to other data. It is not helping that most registrations are making use of their heavy backoffice standards for opening their data. These problems are counteracted by copying data of others, involving heavy expenses for collecting, converting and synchronizing the data, or by building expensive national provisions. The result is an abundance of copies and much doubt regarding the authenticity of the information.

    A better solution would be to make the authentic data permanently available as linked data, so that everyone can use it and the datasets can be interlinked, resulting in more coherence and improved traceability and no more need for copying and synchronization.

    -

    There are now 13 Dutch ‘base registries’ containing government reference data: e.g. -

      +

      There are now 13 Dutch ‘base registries’ containing government reference data: e.g.

      +
      • BAG (Buildings and Addresses)
      • NHR (Businesses, organizations)
      • BRP (Citizens)
      • @@ -725,11 +726,11 @@

        here. BAG linked data is here (“Begrippen”: the vocabulary; “BAG Data”: the data)

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.3 Compressible, 5.19 Linkability

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.3 Compressible, 5.19 Linkability

    -
    -

    4.17 Publishing Cultural Heritage Data

    +
    +

    4.17 Publishing Cultural Heritage Data

    Lars G. Svensson

    @@ -739,24 +740,24 @@

    Time Instants). +
  • In addition to that, OWL reasoning over cultural heritage datasets is severely hampered since OWL only accepts the datatypes xsd:dateTime and xsd:dateTimeStamp as temporal datatypes (cf. Time Instants).
  • Little or no possibilities to perform validation of temporal and/or spatial data formats (e.g. WKT).
  • -

    Note: This use case has similarities to 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities.

    +

    Note: This use case has similarities to 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities.

    -

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

    -

    2.5 Coverage in Linked Data5.4 Coverage temporal extent, 5.7 Date, time and duration, 5.15 Georeferenced spatial data, 5.28 Nominal temporal references, 5.29 Non-geographic reference system, 5.39 Space-time multi-scale, 5.49 Temporal vagueness, 5.43 Spatial vagueness, 5.54 Validation

    +

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

    +

    2.5 Coverage in Linked Data5.4 Coverage temporal extent, 5.7 Date, time and duration, 5.15 Georeferenced spatial data, 5.28 Nominal temporal references, 5.29 Non-geographic reference system, 5.39 Space-time multi-scale, 5.49 Temporal vagueness, 5.43 Spatial vagueness, 5.54 Validation

    -
    -

    4.18 Dissemination of 3D geological data

    +
    +

    4.18 Dissemination of 3D geological data

    Rachel Heaven

    The British Geological Survey (BGS), like all Geological Survey Organizations (GSOs), has as one of its principal roles to be the primary provider of geoscience information within its national territory. Increasingly the information provided is digital and dissemination is over the internet, and there is a trend towards making more information freely available. For BGS’s 2D information this requirement has been met by the provision of various OGC Web map services.

    However, geological units and structures are three-dimensional bodies and their traditional depiction on two-dimensional geological maps leads to a loss of information and the requirement of quite a high level of geological understanding on the part of the user to interpret them. The geoscience data user community includes scientific users, but also includes many other stakeholders such as exploration companies, civil engineers, local authority planners, as well as the general public. It is therefore the aim of many Geological Surveys, including BGS, to move towards the provision of geological information as spatial 3D datasets on the Web that are accessible and useable by non-experts.

    -

    We have implemented a few ways of disseminating the 3D data on the Web (http://www.bgs.ac.uk/services/3Dgeology/lithoframeSamples.html, http://www.bgs.ac.uk/services/3Dgeology/virtualBoreholeViewer.html,http://earthserver.bgs.ac.uk/, investigation of augmented reality smartphone application) but the remaining issues are -

    -
    -

    4.19 Publication of Raw Subsurface Monitoring Data

    +
    +

    4.19 Publication of Raw Subsurface Monitoring Data

    Rachel Heaven

    @@ -789,11 +790,11 @@

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

    -

    5.16 Humans as sensors, 5.6 CRS definition, 5.11 Dynamic sensor data, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.22 4D model of space-time, 5.23 Model reuse, 5.27 Nominal observations, 5.30 Observation aggregations, 5.35 Reference external vocabularies, 5.36 Sampling topology, 5.38 Sensing procedure, 5.37 Sensor metadata, 5.40 Spatial metadata, 5.43 Spatial vagueness, 5.46 Support for 3D, 5.39 Space-time multi-scale, 5.51 Time series, 5.52 Uncertainty in observations, 5.56 Virtual observations

    +

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

    +

    5.16 Humans as sensors, 5.6 CRS definition, 5.11 Dynamic sensor data, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.22 4D model of space-time, 5.23 Model reuse, 5.27 Nominal observations, 5.30 Observation aggregations, 5.35 Reference external vocabularies, 5.36 Sampling topology, 5.38 Sensing procedure, 5.37 Sensor metadata, 5.40 Spatial metadata, 5.43 Spatial vagueness, 5.46 Support for 3D, 5.39 Space-time multi-scale, 5.51 Time series, 5.52 Uncertainty in observations, 5.56 Virtual observations

    -
    -

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

    +
    +

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

    Rachel Heaven

    @@ -806,11 +807,11 @@

    Each named feature should have a spatial attribute, either as topological relations to other named features, or as spatial-temporal extent appropriate for various scales and with appropriate uncertainties (i.e. fuzzy definitions of geometry and time periods). Versioning will be important e.g. for administrative boundaries that change frequently.

    (NB Geonames goes much of the way to meeting this requirement)

    -

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

    -

    5.9 Different time models, 5.7 Date, time and duration, 5.46 Support for 3D, 5.28 Nominal temporal references, 5.48 Temporal reference system, 5.49 Temporal vagueness, 5.43 Spatial vagueness, 5.41 Spatial meronymy, 5.55 Valid time, 5.40 Spatial metadata

    +

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

    +

    5.9 Different time models, 5.7 Date, time and duration, 5.46 Support for 3D, 5.28 Nominal temporal references, 5.48 Temporal reference system, 5.49 Temporal vagueness, 5.43 Spatial vagueness, 5.41 Spatial meronymy, 5.55 Valid time, 5.40 Spatial metadata

    -
    -

    4.21 Driving to work in the snow

    +
    +

    4.21 Driving to work in the snow

    Cory Henson (Bosch RTC)

    @@ -846,11 +847,11 @@

    represent "high-level" qualitative observations (such as observations of user behavior, e.g., Sue stopped at the coffee shop). -

    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.16 Humans as sensors, 5.7 Date, time and duration, 5.10 Discoverability, 5.11 Dynamic sensor data, 5.15 Georeferenced spatial data, 5.24 Moving features, 5.27 Nominal observations, 5.28 Nominal temporal references, 5.37 Sensor metadata, 5.20 Machine to machine, 5.3 Compressible

    +

    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.16 Humans as sensors, 5.7 Date, time and duration, 5.10 Discoverability, 5.11 Dynamic sensor data, 5.15 Georeferenced spatial data, 5.24 Moving features, 5.27 Nominal observations, 5.28 Nominal temporal references, 5.37 Sensor metadata, 5.20 Machine to machine, 5.3 Compressible

    -
    -

    4.22 Intelligent Transportation System

    +
    +

    4.22 Intelligent Transportation System

    Antoine Zimmermann

    @@ -861,11 +862,11 @@

    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.7 Date, time and duration, 5.21 Mobile sensors, 5.24 Moving features, 5.27 Nominal observations, 5.39 Space-time multi-scale, 5.48 Temporal reference system

    +

    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.7 Date, time and duration, 5.21 Mobile sensors, 5.24 Moving features, 5.27 Nominal observations, 5.39 Space-time multi-scale, 5.48 Temporal reference system

    -
    -

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

    +
    +

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

    Antoine Zimmermann

    @@ -875,31 +876,31 @@

    There is a need for a temporal model that covers historical data for statistical analysis, short term timestamped sensed data, and data about future predictions.

    The need for spatio-temporal information is even increased if the smart grid is including electric vehicles that can serve as energy producers when they are not consuming electricity for recharging.

    -

    2.3 Time Ontology in OWL

    -

    5.19 Linkability

    +

    2.3 Time Ontology in OWL

    +

    5.19 Linkability

    -
    -

    4.24 Linked Data for Tax Assessment

    +
    +

    4.24 Linked Data for Tax Assessment

    Luigi Selmi (via public-sdw-comments)

    Tax assessments are based on the comparison of what is due by a citizen in a year for her ownership of real estates in the area administered by a municipality and what has been paid. The tax amount is regulated by laws and based on many criteria like the size of the real estate, the area in which it is located, its type: house, office, farm, factory and others. Taxpayers can save money from the original due depending on the usage of the estate. A family that owns the house in which they live can save the entire amount. Many other regulations lighten in different ways the burden of the tax for other categories of taxpayers. Furthermore the situation about a taxpayer changes over the years in relation to her properties share and family status. Due to the many different situations met, an employee in charge of performing tax assessments on behalf of a municipality must collect many information before being able to assert with a good degree of confidence that a difference between the original amount and what has been paid is not justified and an advice has to be sent to the taxpayer starting a long and expensive process to recover the difference. Currently each single assessment requires the employee to collect information from different public administrations Web sites, archives, registries, documents. Data scattered in so many silos and formats dramatically reduce employees productivity and assessment effectiveness at the point that it is not always clear whether the money recovered is worth the cost of the assessment. A Linked Data approach for sharing spatial and temporal data would certainly increase the productivity of the assessor.

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.10 Discoverability, 5.19 Linkability

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.10 Discoverability, 5.19 Linkability

    -
    -

    4.25 Images, e.g. a Time series of a Water Course

    +
    +

    4.25 Images, e.g. a Time series of a Water Course

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

    This use case is provided to extend three primary use cases already before the Working Group:

    More broadly the Commonwealth of Australia has developed a National Map Web platform which is currently making available authoritative national datasets. There is a need to recognize that data can an image (e.g. an image-based tile set for example) and therefore in itself also create a time series-based resource (for example, the change in a water course over time which can be visualized as time series layers). Indeed both the ISO and OGC have recognized this in their standards. It is the Australian Government Department of Communication’s view, as the lead agency stewarding spatial data policy, that image-based resources should also be included in the consideration of this working group as it relates to geographic and spatial features geometries. Wheresoever possible the Commonwealth view is to maintain the highest applicability of a standard or best practice guide and not limit conformance options for data holdings (especially of public origin). This also applies to cadastral and other data at the state/territory level which could show the change in land parcel, development or other property and built environment features over time. In terms of our future cities, sensors and other data sources may also need linkage to image-based resources for citizen use. As such:

      @@ -911,11 +912,11 @@

      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 Discoverability, 5.15 Georeferenced spatial data, 5.26 Multiple types of coverage, 5.34 Reference data chunks, 5.39 Space-time multi-scale, 5.51 Time series, 5.46 Support for 3D, 5.37 Sensor metadata, 5.6 CRS definition, 5.35 Reference external vocabularies, 5.19 Linkability, 5.32 Provenance, , 5.7 Date, time and duration, 5.33 Quality metadata, 5.55 Valid time

      +

      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 Discoverability, 5.15 Georeferenced spatial data, 5.26 Multiple types of coverage, 5.34 Reference data chunks, 5.39 Space-time multi-scale, 5.51 Time series, 5.46 Support for 3D, 5.37 Sensor metadata, 5.6 CRS definition, 5.35 Reference external vocabularies, 5.19 Linkability, 5.32 Provenance, 5.36 Sampling topology, 5.7 Date, time and duration, 5.33 Quality metadata, 5.55 Valid time

    -
    -

    4.26 Droughts in geological complex environments where groundwater is important

    +
    +

    4.26 Droughts in geological complex environments where groundwater is important

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

    @@ -937,11 +938,11 @@

    References

  • Matrosov E.S., Harou, J.J. and Loucks D.P., 2010. A computationally efficient open-source water resource system simulator - Application to London and the Thames Basin. Environmental Modeling & Software. Volume 26, Issue 12, December 2011, Pages 1599–1610.
  • -

    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 Linkability, 5.32 Provenance, 5.33 Quality metadata, 5.27 Nominal observations, 5.46 Support for 3D, 5.56 Virtual observations, 5.11 Dynamic sensor data, 5.53 Use in computational models, 5.51 Time series

    +

    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 Linkability, 5.32 Provenance, 5.33 Quality metadata, 5.27 Nominal observations, 5.46 Support for 3D, 5.56 Virtual observations, 5.11 Dynamic sensor data, 5.53 Use in computational models, 5.51 Time series

    -
    -

    4.27 Soil data applications

    +
    +

    4.27 Soil data applications

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

    @@ -952,11 +953,11 @@

    Agronomist needs observations of soil properties such as pH, Nitrogen, and soil-type and derive new properties using locally defined pedo-transfer functions ... Access observed and interpreted soil properties (by soil type and/or by spatial distribution) in a standard format that allows using algorithms/pedotransfer functions to use these properties to calculate additional interpreted soil properties. -

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

    -

    5.10 Discoverability, 5.23 Model reuse, 5.26 Multiple types of coverage, 5.30 Observation aggregations, 5.31 Observed property in coverage, 5.33 Quality metadata, 5.35 Reference external vocabularies, 5.39 Space-time multi-scale, 5.56 Virtual observations, 5.38 Sensing procedure, 5.16 Humans as sensors

    +

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

    +

    5.10 Discoverability, 5.23 Model reuse, 5.26 Multiple types of coverage, 5.30 Observation aggregations, 5.31 Observed property in coverage, 5.33 Quality metadata, 5.35 Reference external vocabularies, 5.39 Space-time multi-scale, 5.56 Virtual observations, 5.38 Sensing procedure, 5.16 Humans as sensors

    -
    -

    4.28 Bushfire response coordination centre

    +
    +

    4.28 Bushfire response coordination centre

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

    @@ -993,11 +994,11 @@

    User story

    She is now able to see that Springwood suburb will be within the predicted fire polygon and will need to be evacuated. The analyst clicks linked information resources for Springwood (the synonym in the ASGS dataset) and a graph of related resources is displayed [uc 7.1, 7.2, 6]. This shows a link to a suburb profile based on the most recent national population and census data is available the analyst clicks on this and a query for predefined measurements (plus the place identifier) is passed to a census data cube service. The analyst visualizes and saves the result set locally.

    The analyst also notices that information resources are connected to Springwood (in the gazetteer dataset) [uc 7.1, 7.2, 6]. These include a link to a containing local government area (LGA) and links to LGA emergency management resources on the Website. This lists contact information and evacuation centers information which is used to inform development of the evacuation plan.

    -

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

    -

    5.19 Linkability, 5.37 Sensor metadata, 5.43 Spatial vagueness

    +

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

    +

    5.19 Linkability, 5.37 Sensor metadata, 5.43 Spatial vagueness

    -
    -

    4.29 Observations on geological samples

    +
    +

    4.29 Observations on geological samples

    Simon Cox

    @@ -1008,11 +1009,11 @@

    2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

    -

    5.7 Date, time and duration, 5.9 Different time models, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.23 Model reuse, 5.32 Provenance, 5.35 Reference external vocabularies, 5.37 Sensor metadata, 5.13 Ex-situ sampling, 5.36 Sampling topology, 5.38 Sensing procedure, 5.16 Humans as sensors, 5.48 Temporal reference system

    +

    2.3 Time Ontology in OWL, 2.4 Semantic Sensor Network Vocabulary

    +

    5.7 Date, time and duration, 5.9 Different time models, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.23 Model reuse, 5.32 Provenance, 5.35 Reference external vocabularies, 5.37 Sensor metadata, 5.13 Ex-situ sampling, 5.36 Sampling topology, 5.38 Sensing procedure, 5.16 Humans as sensors, 5.48 Temporal reference system

    -
    -

    4.30 Spatial Sampling

    +
    +

    4.30 Spatial Sampling

    Simon Cox

    @@ -1029,11 +1030,11 @@

    -

    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.6 CRS definition, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.21 Mobile sensors, 5.23 Model reuse, 5.37 Sensor metadata, 5.39 Space-time multi-scale, 5.43 Spatial vagueness, 5.36 Sampling topology, 5.52 Uncertainty in observations, 5.40 Spatial metadata

    +

    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.6 CRS definition, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.21 Mobile sensors, 5.23 Model reuse, 5.37 Sensor metadata, 5.39 Space-time multi-scale, 5.43 Spatial vagueness, 5.36 Sampling topology, 5.52 Uncertainty in observations, 5.40 Spatial metadata

    -
    -

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

    +
    +

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

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

    @@ -1044,11 +1045,11 @@

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

    -

    5.7 Date, time and duration, 5.42 Spatial operators, 5.41 Spatial meronymy, 5.55 Valid time

    +

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

    +

    5.7 Date, time and duration, 5.42 Spatial operators, 5.41 Spatial meronymy, 5.55 Valid time

    -
    -

    4.32 Satellite data processing

    +
    +

    4.32 Satellite data processing

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

    @@ -1066,54 +1067,54 @@

    Now, this fractional cover coverage product over Australia is computed monthly and distributed by the NSW government, where it is used for their Dustwatch program amongst other things. The Dustwatch program publishes monthly (PDF) reports of wind-related erosion and groundcover change.

    [1] Guerschman et al, "Assessing the effects of site heterogeneity and soil properties when unmixing photosynthetic vegetation, non-photosynthetic vegetation and bare soil fractions from Landsat and MODIS data", Remote Sensing of Environment, to appear 2015.(Note that this paper provides several references to similar approaches to using multispectral coverages to determine vegetation).

    -

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

    -

    5.6 CRS definition, 5.15 Georeferenced spatial data, 5.21 Mobile sensors, 5.26 Multiple types of coverage, 5.32 Provenance, 5.37 Sensor metadata, 5.16 Humans as sensors, 5.56 Virtual observations, 5.38 Sensing procedure, 5.17 Independence on reference systems, 5.40 Spatial metadata

    +

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

    +

    5.6 CRS definition, 5.15 Georeferenced spatial data, 5.21 Mobile sensors, 5.26 Multiple types of coverage, 5.32 Provenance, 5.37 Sensor metadata, 5.16 Humans as sensors, 5.56 Virtual observations, 5.38 Sensing procedure, 5.17 Independence on reference systems, 5.40 Spatial metadata

    -
    -

    4.33 Marine observations - eMII

    +
    +

    4.33 Marine observations - eMII

    Simon Cox (on behalf of IMOS eMII)

    -
    -

    Water column observations

    +
    +

    Water column observations

    I am a modeler and I want to find, filter and extract water column data that has been collected by profiling instruments (e.g. CTD, XBT, ARGO Floats, CTD’s mounted on animals) so that I can prime my models. I want to easily be able to discover these data either by nominating the collection device type, or by nominating data parameters of interest. Once I can see which datasets meet my broad discovery criteria, and whilst still in the Portal, I want to be able to filter out data that is not of interest (e.g. those data outside of my region of interest, those not covering my features of interest, data which is unqualified, data below a certain depth and data from institutions I don’t trust). I want to extract these data in a harmonized format (i.e. receive a single file of aggregated data expressed using common data fields, or in multiple files where each file has a similar syntactic and semantic encoding). I don’t want to have to spend time transforming datasets with differing formats, nor guess which data fields in datasets from different sources are semantically covering the same information. I need to know what each field in the downloaded data represents.

    -
    -

    Reconfiguring data ingestion process

    +
    +

    Reconfiguring data ingestion process

    I am an eMII Project Officer. I spend my day pulling data from partner services and transforming it so that it can be published through the 1-2-3 Portal. Just when I think I have tweaked all of the systems I need to in order to successfully ingest and publish provider data, the provider changes his/her data format, schema syntax or semantics. I then have to re-write or re-configure systems to obtain any new data. This happens very frequently. Even data providers who supply me with data from the same instruments use different data encodings and formats so I have to create individualized database tables to manage their incoming data. I would like data providers to agree on common schema for expressing similar data types and in collaboration develop some ‘governance’ rules surrounding data publication to the Portal to reduce the time I spend on repetitive (and often unnecessary) tasks.

    -
    -

    Observations along profiles

    +
    +

    Observations along profiles

    I am an eMII Project Officer and I manage multiple profile type datasets (e.g.: Argo profile, seals profile, XBT profile …). I want to be able to assess the quality of the data provided by partners before inclusion into the IMOS database and making it available through the IMOS portal. I want to set up a system whereby every new profile will be compared with existing profiles available in the IMOS database. The incoming profile will have to conform to a standard format so that it is relatively easy to implement and develop different set of rules to enable comparison with existing profiles. The system will send me an alert if one or multiple profiles failed some tests. Then I will be able to follow up more quickly with the corresponding partners to check if an error occurs during the processing of the data or if actually the data is correct. In the end, this process will enable an increase of the quality of the data provided to the end user.

    -

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

    -

    5.10 Discoverability, 5.21 Mobile sensors, 5.23 Model reuse, 5.30 Observation aggregations, 5.31 Observed property in coverage, 5.33 Quality metadata, 5.37 Sensor metadata, 5.46 Support for 3D, 5.36 Sampling topology

    +

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

    +

    5.10 Discoverability, 5.21 Mobile sensors, 5.23 Model reuse, 5.30 Observation aggregations, 5.31 Observed property in coverage, 5.33 Quality metadata, 5.37 Sensor metadata, 5.46 Support for 3D, 5.36 Sampling topology

    -
    -

    4.34 Marine observations - data providers

    +
    +

    4.34 Marine observations - data providers

    Simon Cox (on behalf of IMOS eMII)

    -
    -

    Atlas of Living Australia (ALA)

    +
    +

    Atlas of Living Australia (ALA)

    The ALA would like to integrate their data into the AODN. The ALA serves a range of Web services including WMS and corresponding ISO19115/MCP metadata. The ALA's use case is unusual in that it has tens of thousands of WMS layers and metadata records. This data cannot be added to version 2 of the AODN portal because it is too large to be harvested into the menu tree. ALA will need to be integrated with the 123 portal. Dave Martin's team has created a proof of concept integration. There would be a single metadata record for ALA, which will allow it to be discovered in Step 1 of the portal. After proceeding to Step 2 the user would see something like this mockup.

    -
    -

    Reef Life Survey (RLS)

    +
    +

    Reef Life Survey (RLS)

    RLS have visited 2500+ coral and rocky reef sites and have conducted approx 6000 surveys across those sites. Each survey is conducted at a nominal ‘site’. -

    -
    Methods 1 & 2
    +

    +
    Methods 1 & 2

    During a survey observations are recorded of each of (1) vertebrate species abundance and biomass and (2) invertebrate species abundance.

    -
    -
    Method 3
    +
    +
    Method 3

    During a survey downward looking photographs are taken. The photographs are sequenced 1-20 for each site and are not geolocated. Subsequently, the photographs are scored at 5 points within each image. Each point is scored into one of 36 categories. Parameters are date, depth, resolution, major category, minor category, numerical value.

    -
    -
    User Story 1
    +
    +
    User Story 1

    I’m interested in ecosystems, reef assemblages and inter-species interactions. Show me what vertebrate and invertebrate species were found at this site (and any corresponding location/depth/habitat information).

    What I want to see:

      @@ -1121,8 +1122,8 @@
      By site, all invertebrate abundance values (for each survey?)
    -
    -
    User Story 2
    +
    +
    User Story 2

    I have a large-scale question to ask about a particular species, for example, I am interested in broad distribution patterns of lobsters, plankton dispersal and settling rates. Show me all of the sites that were surveyed and the presence/absence of a particular species at each of those sites.

    What I want to see:

      @@ -1131,59 +1132,59 @@
    -
    -

    Institute for Marine and Antarctic Studies (IMAS)

    +
    +

    Institute for Marine and Antarctic Studies (IMAS)

    The IMAS use case includes a number of data collections. The main requirements is a mechanism to easily install the necessary applications. Ideally the AODN will host the applications (GeoNetwork, Geoserver etc) in the NeCTAR Cloud. This cloud based infrastructure will be managed by the AODN, but IMAS will have administrator accounts on each application and will be responsible for data content.

    -

    2.4 Semantic Sensor Network Vocabulary

    -

    5.15 Georeferenced spatial data, 5.27 Nominal observations, 5.16 Humans as sensors, 5.46 Support for 3D, 5.52 Uncertainty in observations

    +

    2.4 Semantic Sensor Network Vocabulary

    +

    5.15 Georeferenced spatial data, 5.27 Nominal observations, 5.16 Humans as sensors, 5.46 Support for 3D, 5.52 Uncertainty in observations

    -
    -

    4.35 Marine observations - data consumers

    +
    +

    4.35 Marine observations - data consumers

    Simon Cox (on behalf of IMOS eMII)

    -
    -

    Download Temperature and Velocity Data from NSW Moorings

    +
    +

    Download Temperature and Velocity Data from NSW Moorings

    The user would like to download temperature and velocity data from NSW moorings without downloading large numbers of NetCDF files, and without needing many clicks.

    (Based on feedback from Robin Robertson).

    -
    -

    Download Glider Data

    +
    +

    Download Glider Data

    The user would like an easy way to download the calibrated glider data. The user does not want the data delivered manually via drop box, or to face the difficulty of downloading NetCDF files in the way they are currently provided.

    (Based on feedback from Robin Robertson).

    -
    -

    Download ANMN Timor South moorings data

    +
    +

    Download ANMN Timor South moorings data

    The user would like to download the ANMN Timor South moorings data - without needing 160 clicks.

    (Based on feedback from Rebecca Cowley).

    -
    -

    Download XBT data

    +
    +

    Download XBT data

    The user would like to download XBT data from the portal. Not just the metadata - but the actual data.

    (Based on feedback from Rebecca Cowley).

    -
    -

    Download NRS data

    The user would like to be able to download NRS moorings data.

    (Based on feedback by Peter Thompson)

    +
    +

    Download NRS data

    The user would like to be able to download NRS moorings data.

    (Based on feedback by Peter Thompson)

    -
    -

    Understandable by scientists from other fields

    +
    +

    Understandable by scientists from other fields

    The user would like to be able to understand the portal even though she is from another field (e.g. genomics).

    (Based on feedback from Levente Bodrossy).

    -
    -

    Filter moorings data by deployment and instrument type

    The user would like to be able to filter moorings data by deployment and instrument type.

    (Based on feedback from Craig Steinberg)

    +
    +

    Filter moorings data by deployment and instrument type

    The user would like to be able to filter moorings data by deployment and instrument type.

    (Based on feedback from Craig Steinberg)

    -
    -

    Download data as CSV

    The user would like to download sea surface temperature from the Bass Straight as a CSV file - not NetCDF

    (Based on feedback from Andre Chiaradia)

    +
    +

    Download data as CSV

    The user would like to download sea surface temperature from the Bass Straight as a CSV file - not NetCDF

    (Based on feedback from Andre Chiaradia)

    -
    -

    Argo float data in a bounding box in the Southern Ocean.

    The user would like to download argo data from a particular region in the Southern Ocean.

    (Based on feedback from Esmee)

    +
    +

    Argo float data in a bounding box in the Southern Ocean.

    The user would like to download argo data from a particular region in the Southern Ocean.

    (Based on feedback from Esmee)

    Also see additional stories in un-edited emails.

    -

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

    -

    5.38 Sensing procedure

    +

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

    +

    5.38 Sensing procedure

    -
    -

    4.36 Building information management and data sharing

    +
    +

    4.36 Building information management and data sharing

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

    @@ -1192,11 +1193,11 @@

    2.2 Spatial Data on the Web Best Practices

    -

    5.46 Support for 3D, 5.41 Spatial meronymy, 5.54 Validation

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.46 Support for 3D, 5.41 Spatial meronymy, 5.54 Validation

    -
    -

    4.37 Landsat data services

    +
    +

    4.37 Landsat data services

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

    @@ -1207,11 +1208,11 @@

    GA has had much success with OGC and ISO standards in the sharing of data with government, research and industry partners and clients who are power users of spatial data and savvy in the standards. The less traditional users who are not spatial data specialists are less likely to access GA’s data delivered using OGC and ISO standards, and this is a section of the user community that can potentially apply the data to highly innovative and entrepreneurial uses.

    GA does use proprietary and quasi-standard light weight data exchange formats (e.g. JSON) and Web APIs (e.g. ESRI RESTful API) for delivering some geospatial data, although, in accordance with government policy, it is GA’s preference to adopt standards when possible to maximize interoperability.

    -

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

    -

    5.7 Date, time and duration, 5.10 Discoverability, 5.34 Reference data chunks, 5.51 Time series, 5.4 Coverage temporal extent, 5.50 Support for tiling

    +

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

    +

    5.7 Date, time and duration, 5.10 Discoverability, 5.34 Reference data chunks, 5.51 Time series, 5.4 Coverage temporal extent, 5.50 Support for tiling

    -
    -

    4.38 Metadata and Search Granularity

    +
    +

    4.38 Metadata and Search Granularity

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

    @@ -1221,11 +1222,11 @@

    WFS, and Web applications with GIS capability served by GA, e.g. the Rock Properties Explorer app, can provide some capability for searching within data collections.

    Usability of search and discovery systems would be enhanced by having standards that define the line between spatial data and metadata in the context of searches, and standard methodologies for searching across collection level and feature level data.

    -

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

    -

    5.9 Different time models, 5.13 Ex-situ sampling, 5.28 Nominal temporal references, 5.43 Spatial vagueness, 5.46 Support for 3D, 5.39 Space-time multi-scale, 5.48 Temporal reference system

    +

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

    +

    5.9 Different time models, 5.13 Ex-situ sampling, 5.28 Nominal temporal references, 5.43 Spatial vagueness, 5.46 Support for 3D, 5.39 Space-time multi-scale, 5.48 Temporal reference system

    -
    -

    4.39 Crowdsourced earthquake observation information

    +
    +

    4.39 Crowdsourced earthquake observation information

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

    @@ -1233,11 +1234,11 @@

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

    -

    5.27 Nominal observations, 5.25 Multilingual support, 5.16 Humans as sensors, 5.43 Spatial vagueness, 5.37 Sensor metadata, 5.15 Georeferenced spatial data, 5.30 Observation aggregations, 5.21 Mobile sensors, 5.46 Support for 3D, 5.11 Dynamic sensor data, 5.45 Streamable data, 5.40 Spatial metadata, 5.19 Linkability, 5.20 Machine to machine, 5.42 Spatial operators, 5.5 Crawlability, 5.10 Discoverability, 5.12 Encoding for vector geometry

    +

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

    +

    5.27 Nominal observations, 5.25 Multilingual support, 5.16 Humans as sensors, 5.43 Spatial vagueness, 5.37 Sensor metadata, 5.15 Georeferenced spatial data, 5.30 Observation aggregations, 5.21 Mobile sensors, 5.46 Support for 3D, 5.11 Dynamic sensor data, 5.45 Streamable data, 5.40 Spatial metadata, 5.19 Linkability, 5.20 Machine to machine, 5.42 Spatial operators, 5.5 Crawlability, 5.10 Discoverability, 5.12 Encoding for vector geometry

    -
    -

    4.40 TCGA / Microscopy Imaging

    +
    +

    4.40 TCGA / Microscopy Imaging

    Erich Bremer

    @@ -1246,11 +1247,11 @@

    Representing nuclear segmentations is often done with binary masks or through polygon representations (e.g., the use of Well Known Text (WKT) representations) and also by leveraging work from the Geospatial community. However, in the case of nuclear segmentations, coordinate systems are 2D & 3D Cartesian based. Although the majority of work is this area is 2D-based, a growing segment of microscopy is also 3D-based as the technology develops and become more sophisticated. As living tissue can change over time through growth, infection, cancer, damage, etc, (as well as its associated organism’s various properties) it is important that spatial locations of features such as nuclear segmentation be also represented in a temporal aspect for proper comparisons.

    Samples of TCGA WSI data can be viewed at: http://cancer.digitalslidearchive.net

    -

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

    -

    5.4 Coverage temporal extent, 5.29 Non-geographic reference system, 5.34 Reference data chunks, 5.46 Support for 3D, 5.10 Discoverability, 5.40 Spatial metadata, 5.50 Support for tiling, 5.17 Independence on reference systems, 5.32 Provenance, 5.51 Time series, 5.42 Spatial operators

    +

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

    +

    5.4 Coverage temporal extent, 5.29 Non-geographic reference system, 5.34 Reference data chunks, 5.46 Support for 3D, 5.10 Discoverability, 5.40 Spatial metadata, 5.50 Support for tiling, 5.17 Independence on reference systems, 5.32 Provenance, 5.51 Time series, 5.42 Spatial operators

    -
    -

    4.41 Crop yield estimation using multiple satellites

    +
    +

    4.41 Crop yield estimation using multiple satellites

    Kerry Taylor with Zheng-Shu Zhou, CSIRO

    @@ -1259,11 +1260,11 @@

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

    -

    5.4 Coverage temporal extent, 5.44 SSN-like representation, 5.46 Support for 3D, 5.56 Virtual observations, 5.37 Sensor metadata, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.39 Space-time multi-scale, 5.52 Uncertainty in observations, 5.33 Quality metadata, 5.31 Observed property in coverage, 5.26 Multiple types of coverage, 5.34 Reference data chunks, 5.53 Use in computational models, 5.32 Provenance, 5.51 Time series, 5.6 CRS definition, 5.51 Time series, 5.42 Spatial operators

    +

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

    +

    5.4 Coverage temporal extent, 5.44 SSN-like representation, 5.46 Support for 3D, 5.56 Virtual observations, 5.37 Sensor metadata, 5.15 Georeferenced spatial data, 5.19 Linkability, 5.39 Space-time multi-scale, 5.52 Uncertainty in observations, 5.33 Quality metadata, 5.31 Observed property in coverage, 5.26 Multiple types of coverage, 5.34 Reference data chunks, 5.53 Use in computational models, 5.32 Provenance, 5.51 Time series, 5.6 CRS definition, 5.51 Time series, 5.42 Spatial operators

    -
    -

    4.42 Geospatial extensions to domain-independent metadata schemas

    +
    +

    4.42 Geospatial extensions to domain-independent metadata schemas

    Andrea Perego (European Commission - Joint Research Centre)

    @@ -1287,16 +1288,16 @@

    4.15 Combining spatial RDF data for integrated querying in a triplestore -
  • 4.10 Publishing geospatial reference data
  • -
  • 4.43 Improving discovery of spatial data on the Web
  • +
  • 4.15 Combining spatial RDF data for integrated querying in a triplestore
  • +
  • 4.10 Publishing geospatial reference data
  • +
  • 4.43 Improving discovery of spatial data on the Web
  • -

    2.2 Spatial Data on the Web Best Practices

    -

    5.1 Bounding box and centroid

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.1 Bounding box and centroid

    -
    -

    4.43 Improving discovery of spatial data on the Web

    +
    +

    4.43 Improving discovery of spatial data on the Web

    Andrea Perego (European Commission - Joint Research Centre)

    @@ -1313,15 +1314,15 @@

    SDW WG BPs may contribute to this by recommending best practices for publishing geospatial metadata on the Web. For example, by proposing standard serializations of geospatial metadata in formats and vocabularies used by search engines to index Web resources - e.g., RDFa, Microdata, Microformats.

    Related use cases:

    -

    2.2 Spatial Data on the Web Best Practices

    +

    2.2 Spatial Data on the Web Best Practices

    -
    -

    4.44 INSPIRE compliance using web standards

    +
    +

    4.44 INSPIRE compliance using web standards

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

    @@ -1329,11 +1330,11 @@

    INSPIRE directive leads to the availability of many datasets with geographical aspects. Unfortunately the burden for data providers to comply with INSPIRE is high, which leads to the potential danger that the means (INSPIRE) becomes more important than the end (to have interoperable data). For many data providers the sole purpose is to state that they are INSPIRE compliant. This limited but understandable approach of data providers results in potential users being overlooked. Implementations of more user-friendly Web-related solutions will be very difficult and limited in the next few years, unless we find a (documented, proven and accepted) way to comply with INSPIRE by using Web standards (Linked Data).

    The Dutch Cadastre is a major provider of INSPIRE data in the Netherlands. It also maintains the portal PDOK, a central facility for making INSPIRE-compliant geographical data available in the Netherlands.

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.2 Compatibility with existing practices

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.2 Compatibility with existing practices

    -
    -

    4.45 Event-like geographic features

    +
    +

    4.45 Event-like geographic features

    Karl Grossner, Stanford Libraries

    @@ -1345,11 +1346,11 @@

    Taken together these share a requirement to consider space and time together.

    There is ongoing work in several research communities to arrive at better general models for representing and computing over such spatial-temporal and dynamic phenomena. One approach aims at 4-dimensional model of space-time (e.g. CIDOC-CRM E92-Spacetime Volume). Another seeks to add a "when" component to the "where" (geometry) of GeoJSON and GeoJSON-LD.

    -

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

    -

    5.7 Date, time and duration, 5.22 4D model of space-time, 5.39 Space-time multi-scale, 5.48 Temporal reference system, 5.49 Temporal vagueness, 5.55 Valid time

    +

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

    +

    5.7 Date, time and duration, 5.22 4D model of space-time, 5.39 Space-time multi-scale, 5.48 Temporal reference system, 5.49 Temporal vagueness, 5.55 Valid time

    -
    -

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

    +
    +

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

    Jeremy Tandy, Met Office

    @@ -1358,16 +1359,16 @@

    -

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

    -

    5.32 Provenance, 5.56 Virtual observations, 5.38 Sensing procedure, 5.52 Uncertainty in observations, 5.37 Sensor metadata, 5.6 CRS definition, 5.15 Georeferenced spatial data, 5.23 Model reuse, 5.35 Reference external vocabularies, 5.30 Observation aggregations, 5.51 Time series

    +

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

    +

    5.32 Provenance, 5.56 Virtual observations, 5.38 Sensing procedure, 5.52 Uncertainty in observations, 5.37 Sensor metadata, 5.6 CRS definition, 5.15 Georeferenced spatial data, 5.23 Model reuse, 5.35 Reference external vocabularies, 5.30 Observation aggregations, 5.51 Time series

    -
    -

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

    +
    +

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

    Stefan Lemme, DFKI/Saarland University

    -

    This use case relates to 4.8 Consuming geographical data in a web application and maintains the bridge 3D-web applications (without targeting the actual rendering process, which is out-of-scope).

    +

    This use case relates to 4.8 Consuming geographical data in a web application and maintains the bridge 3D-web applications (without targeting the actual rendering process, which is out-of-scope).

    Visualizing geospatial data, such as geo-referenced 3D geometry of building, is a crucial capability even for Web applications. This use case targets Web developers that are using 3D graphics in their (existing) Web applications. To ease the pick up of 3D graphics for Web developers, since they are usually non-graphics experts, the Declarative 3D for the Web Architecture Community Group of W3C did previous work to determine the requirements, options, and use cases for an integration of interactive 3D graphics capabilities into the W3C technology stack. Thereby, they propose a declarative approach to describe the 3D scene content as an extension of HTML5 rather than interfacing low-level APIs for rendering. Several implementations, such as X3D, X3DOM, and XML3D, address this approach. However, Web developers are usually non-geospatial experts. Thus, to achieve a similar low-entrance barrier for them to incorporate geospatial data into interactive 3D graphics on the Web, any (web)service providing geospatial data (including geometry) might consider a compatible content delivery format and API. Firstly, this implies none to only very little processing overhead on the client. In particular, when having mobile Web applications in mind an efficient content delivery (bandwidth-wise as well as client-side-processing-wise) is becoming important. Secondly, Web developers utilize established libraries, such as jQuery, to interface remote (RESTful) APIs. To ease interfacing geospatial services, Web developers tend to reuse their tools. Finally, existing best practices of the Web should be taken into account and applied to the access of geospatial data according, such as paging of result sets, caching of resources at several stages (server, browser), etc.

    1. Sample 3D client based on WCS/WCPS
    2. @@ -1375,11 +1376,11 @@

      Examples using XML3D and OSM data

    -

    2.2 Spatial Data on the Web Best Practices

    -

    5.19 Linkability, 5.45 Streamable data, , 5.46 Support for 3D, 5.50 Support for tiling

    +

    2.2 Spatial Data on the Web Best Practices

    +

    5.19 Linkability, 5.45 Streamable data, 5.3 Compressible, 5.46 Support for 3D, 5.50 Support for tiling

    -
    -

    4.48 Smart Cities

    +
    +

    4.48 Smart Cities

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

    @@ -1392,8 +1393,8 @@

    Stimulating green behavior: The city council has an interest in making citizens aware of their own environmental impacts in an attractive way without forcing the issue. The council provides citizens and interested parties with a dashboard, so they can follow the "environmental heartbeat" of the city as well as their own impacts and contributions. Now citizens will be able to see and measure the environmental impact on the city as a whole as well as their own personal actions, indicating noise levels, air quality, waste index, recycling activities, fresh water quality, sea water quality etc. Anyone can now compare behavior and activities to that of other groups such as neighbors, neighborhoods or city districts, resulting in competitions between these to collect "Green Points". Not only the fun of competition is stimulating, but Green Points can be traded for rebates on public transport and other environmentally friendly actions which forms a "green economy" ("green coins"). -

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

    -

    5.19 Linkability, 5.11 Dynamic sensor data, 5.16 Humans as sensors, 5.21 Mobile sensors, 5.27 Nominal observations, 5.18 Lightweight API

    +

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

    +

    5.19 Linkability, 5.11 Dynamic sensor data, 5.16 Humans as sensors, 5.21 Mobile sensors, 5.27 Nominal observations, 5.18 Lightweight API


    -
    -

    5. Requirements

    +
    +

    5. Requirements

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

    -
    -

    5.1 Bounding box and centroid

    +
    +

    5.1 Bounding box and centroid

    There should be a common standard 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 Geospatial extensions to domain-independent metadata schemas

    +

    2.2 Spatial Data on the Web Best Practices

    +

    4.7 Publishing geographical data, 4.42 Geospatial extensions to domain-independent metadata schemas

    -
    -

    5.2 Compatibility with existing practices

    +
    +

    5.2 Compatibility with existing practices

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

    -

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

    -

    4.7 Publishing geographical data, 4.12 Using spatial data from the web in GIS systems during emergency response operations, 4.44 INSPIRE compliance using web standards

    +

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

    +

    4.7 Publishing geographical data, 4.12 Using spatial data from the web in GIS systems during emergency response operations, 4.44 INSPIRE compliance using web standards

    -
    -

    5.3 Compressible

    +
    +

    5.3 Compressible

    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

    +

    2.2 Spatial Data on the Web Best Practices

    +

    4.16 Dutch Base Registry, 4.21 Driving to work in the snow

    -
    -

    5.4 Coverage temporal extent

    +
    +

    5.4 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

    +

    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.5 Crawlability

    +
    +

    5.5 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

    +

    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

    -
    -

    5.6 CRS definition

    +
    +

    5.6 CRS definition

    The URI of the Coordinate Reference System (CRS) shall be specified when geographic coordinates are present in the data.

    -

    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.7 Date, time and duration

    +
    +

    5.7 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

    +

    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

    -
    -

    5.8 Default CRS

    +
    +

    5.8 Default CRS

    There should be a default Coordinate Reference System (CRS) that can be assumed to be used for coordinates that otherwise have no specification of the CRS.

    -

    2.2 Spatial Data on the Web Best Practices

    -

    4.15 Combining spatial RDF data for integrated querying in a triplestore

    +

    2.2 Spatial Data on the Web Best Practices

    +

    4.15 Combining spatial RDF data for integrated querying in a triplestore

    -
    -

    5.9 Different time models

    +
    +

    5.9 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

    +

    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

    -
    -

    5.10 Discoverability

    +
    +

    5.10 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 from the web in GIS systems during emergency response operations, 4.40 TCGA / Microscopy Imaging, 4.39 Crowdsourced earthquake observation information

    +

    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 from the web in GIS systems during emergency response operations, 4.40 TCGA / Microscopy Imaging, 4.39 Crowdsourced earthquake observation information

    -
    -

    5.11 Dynamic sensor data

    +
    +

    5.11 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

    +

    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.12 Encoding for vector geometry

    +
    +

    5.12 Encoding for vector geometry

    There should be a standard for 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

    +

    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

    -
    -

    5.13 Ex-situ sampling

    +
    +

    5.13 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

    +

    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.14 Georectification

    +
    +

    5.14 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

    +

    2.5 Coverage in Linked Data

    +

    4.4 Diachronic Burnt Scar Mapping, 4.3 Real-time Wildfire Monitoring

    -
    -

    5.15 Georeferenced spatial data

    +
    +

    5.15 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

    +

    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.16 Humans as sensors

    +
    +

    5.16 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

    +

    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.17 Independence on reference systems

    +
    +

    5.17 Independence on reference systems

    Standards 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.4 Semantic Sensor Network Vocabulary

    -

    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.32 Satellite data processing, 4.40 TCGA / Microscopy Imaging

    +

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

    +

    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.32 Satellite data processing, 4.40 TCGA / Microscopy Imaging

    -
    -

    5.18 Lightweight API

    +
    +

    5.18 Lightweight API

    A lightweight API is needed for implementation on Internet of Things (IoT) devices.

    -

    2.4 Semantic Sensor Network Vocabulary

    -

    4.21 Driving to work in the snow, 4.48 Smart Cities

    -
    -
    -

    5.19 Linkability

    +
    +

    5.19 Linkability

    Spatial data on the Web should be linkable (by explicit relationships between different features), 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

    -
    -
    -

    5.20 Machine to machine

    +
    +

    5.20 Machine to machine

    Standards 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

    +

    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

    -
    -

    5.21 Mobile sensors

    +
    +

    5.21 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

    +

    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

    -
    -

    5.22 4D model of space-time

    +
    +

    5.22 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

    +

    2.3 Time Ontology in OWL

    +

    4.45 Event-like geographic features, 4.19 Publication of Raw Subsurface Monitoring Data

    -
    -

    5.23 Model reuse

    +
    +

    5.23 Model reuse

    Spatial data modeling issues solved in existing models shall be considered for adoption, e.g. O&M or SoilML.

    -

    2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

    -

    4.33 Marine observations - eMII, 4.18 Dissemination of 3D geological data, 4.29 Observations on geological samples, 4.13 Publication of air quality data aggregations, 4.27 Soil data applications, 4.30 Spatial Sampling, 4.19 Publication of Raw Subsurface Monitoring Data, 4.46 Creation of “virtual observations” from “analysis” phase of weather prediction model

    -
    -
    -

    5.24 Moving features

    +
    +

    5.24 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

    +

    2.4 Semantic Sensor Network Vocabulary

    +

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

    -
    -

    5.25 Multilingual support

    +
    +

    5.25 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

    +

    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

    -
    -

    5.26 Multiple types of coverage

    +
    +

    5.26 Multiple types of coverage

    It should be possible to represent many different types of coverage. For instance, to classify coverage data by grid complexity: GridCoverage (GML 3.2.1), RectifiedGridCoverage, ReferenceableGridCoverage, etc.

    -

    2.5 Coverage in Linked Data

    -

    4.41 Crop yield estimation using multiple satellites, 4.4 Diachronic Burnt Scar Mapping, 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.3 Real-time Wildfire Monitoring, 4.32 Satellite data processing, 4.27 Soil data applications

    -
    -
    -

    5.27 Nominal observations

    +
    +

    5.27 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

    +

    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.28 Nominal temporal references

    +
    +

    5.28 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

    +

    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

    -
    -

    5.29 Non-geographic reference system

    +
    +

    5.29 Non-geographic reference system

    It should be possible to use non-geographic spatial reference systems.

    -

    2.5 Coverage in Linked Data

    -

    4.17 Publishing Cultural Heritage Data, 4.40 TCGA / Microscopy Imaging

    +

    2.5 Coverage in Linked Data

    +

    4.17 Publishing Cultural Heritage Data, 4.40 TCGA / Microscopy Imaging

    -
    -

    5.30 Observation aggregations

    +
    +

    5.30 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

    +

    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

    -
    -

    5.31 Observed property in coverage

    +
    +

    5.31 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

    +

    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

    -
    -

    5.32 Provenance

    +
    +

    5.32 Provenance

    It should be possible to add provenance metadata.

    -

    2.4 Semantic Sensor Network Vocabulary, 2.5 Coverage in Linked Data

    -

    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

    -
    -
    -

    5.33 Quality metadata

    +
    +

    5.33 Quality metadata

    It should be possible to describe properties of the data quality, e.g. uncertainty.

    -

    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

    +

    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

    -
    -

    5.34 Reference data chunks

    +
    +

    5.34 Reference data chunks

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

    -

    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

    +

    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.35 Reference external vocabularies

    +
    +

    5.35 Reference external vocabularies

    It should be possible to refer to externally-managed controlled vocabularies.

    -

    2.4 Semantic Sensor Network Vocabulary

    -

    4.13 Publication of air quality data aggregations, 4.19 Publication of Raw Subsurface Monitoring Data, 4.29 Observations on geological samples, 4.27 Soil data applications, 4.1 Meteorological Data Rescue, 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

    -
    -
    -

    5.36 Sampling topology

    +
    +

    5.36 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

    +

    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.37 Sensor metadata

    +
    +

    5.37 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

    +

    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

    -
    -

    5.38 Sensing procedure

    +
    +

    5.38 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

    +

    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

    -
    -

    5.39 Space-time multi-scale

    +
    +

    5.39 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

    +

    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

    -
    -

    5.40 Spatial metadata

    +
    +

    5.40 Spatial metadata

    There should be standards that allow describing the spatial characteristics of data (data objects, data sets or data services), like:

    -
    -

    5.41 Spatial meronymy

    +
    +

    5.41 Spatial meronymy

    There should be a standard for describing spatial hierarchy. The Dublin Core metadata vocabulary contains the terms hasPart and isPartOf. Can those terms be recommended for specifying spatial hierarchy? Or is something else needed?

    -

    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.42 Spatial operators

    +
    +

    5.42 Spatial operators

    There should be common standards for spatial operators. Spatial things can have spatial relations: topological relations, directional or distance relations. Operators based on these relations (e.g. 'Contains'. 'Intersects', 'Nearest') should be standardized.

    -

    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.43 Spatial vagueness

    +
    +

    5.43 Spatial vagueness

    It should be possible to describe locations in a vague, imprecise manner. For instance, to represent spatial descriptions from crowdsourced observations, such as "we saw a wildfire at the bottom of the hillside" or "we felt a light tremor while walking by Los Angeles downtown". Another related use case deals with spatial locations identified in historical texts, e.g. a battle occurred at the south west boundary of the Roman Empire.

    -

    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

    +

    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

    -
    -

    5.44 SSN-like representation

    +
    +

    5.44 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

    +

    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.45 Streamable data

    +
    +

    5.45 Streamable data

    Data should be streamable, a consumer should be able to do something meaningful before the end of the data message is received. 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

    +

    2.2 Spatial Data on the Web Best Practices

    +

    4.8 Consuming geographical data in a web application

    -
    -

    5.46 Support for 3D

    +
    +

    5.46 Support for 3D

    All standards 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

    +

    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

    -
    -

    5.47 Time dependencies in CRS definitions

    +
    +

    5.47 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

    +

    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.48 Temporal reference system

    +
    +

    5.48 Temporal reference system

    If a temporal reference is used, the description of the temporal reference system (e.g. Unix date, Gregorian Calendar, Japanese Imperial Calendar, Carbon Date, Geological Date) needs to 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

    -
    -
    -

    5.49 Temporal vagueness

    +
    +

    5.49 Temporal vagueness

    It should be possible to describe time points and intervals in a vague, imprecise manner. For instance, to represent an event happened on the afternoon of June 1st or at the second quarter of the 9th century.

    -

    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

    -
    -
    -

    5.50 Support for tiling

    +
    +

    5.50 Support for tiling

    Standards 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

    -

    4.8 Consuming geographical data in a web application

    +

    2.2 Spatial Data on the Web Best Practices

    +

    4.8 Consuming geographical data in a web application

    -
    -

    5.51 Time series

    +
    +

    5.51 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

    +

    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

    -
    -

    5.52 Uncertainty in observations

    +
    +

    5.52 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

    +

    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.53 Use in computational models

    +
    +

    5.53 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

    +

    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.54 Validation

    +
    +

    5.54 Validation

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

    -

    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

    +

    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.55 Valid time

    +
    +

    5.55 Valid time

    It should be possible to represent the time of validity that applies to a thing, state or fact.

    -

    2.2 Spatial Data on the Web Best Practices

    -

    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

    -
    -
    -

    5.56 Virtual observations

    +
    +

    5.56 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

    +

    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

    -

    6. Acknowledgements

    +

    6. Acknowledgements

    The editors are grateful for all contributions made to this document, in particular the use case authors.