search

SEMICeu / GeoDCAT-AP

Repository of the geospatial extension to DCAT-AP (GeoDCAT-AP)
https://joinup.ec.europa.eu/solution/geodcat-application-profile-data-portals-europe
Creative Commons Attribution 4.0 International
19 stars 6 forks source link

Specifying spatial / temporal resolution #3

Closed andrea-perego closed 3 years ago

andrea-perego commented 6 years ago

:information_source: Copy-pasted from https://github.com/SEMICeu/Core-Location-Vocabulary/issues/2

GeoDCAT-AP currently models spatial / temporal resolution as free text (with rdfs:comment), recognising that, at the time when the GeoDCAT-AP specification was released, no existing vocabularies provided a means to model this information.

However, this requirement has been brought to the attention of the W3C Data on Web Working Group, and a solution has been documented in the W3C Data Quality Vocabulary (DQV), as reported here:

https://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2016-May/000367.html

Basically, DQV models this information as observations / measurements of a given quality metric (which corresponds to a given type of resolution).

This solution was also included by the SDW Working Group in their best practices, and it could be readily adopted in LOCN.

This would however require the definition of two groups of individuals:

  1. Those corresponding to the different types of resolution (denoting a quality metric).
  2. Those corresponding to each of the different levels of resolution (denoting the measurement of a specific quality metric).

As far as the first group is concerned (i.e., the different types of resolution), these individuals can be defined in DQV as follows:

:SpatialResolutionAsEquivalentScale a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as equivalent scale,
      by using a representative fraction (e.g., 1:1,000, 1:1,000,000)."@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .

:SpatialResolutionAsDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .

This initial list can be further extended. E.g.:

:SpatialResolutionAsHorizontalGroundDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as horizontal ground distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .

:SpatialResolutionAsVerticalDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as vertical distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .

:SpatialResolutionAsAngularDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as angular distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .

The question is in which space such individuals should be defined (inside LOCN? in a separate code list - as the ones maintained by the EU Publications Office?).

The definition of individuals in the second group is however more problematic, since the level of resolution and unit of measurement are arbitrary (1:1000, 1:100, 1m, 1km, 100m, 10 decimal degrees, etc.).

Possible options include the following ones:

  1. Define only the individuals corresponding to the types of spatial / temporal resolution, whereas the individuals expressing the actual resolution will be defined at the data level. This solution is not optimal, since it will result in multiple definitions of the same individuals.
  2. Define individuals only for some levels of resolution and units of measurements - e.g., the most common ones. This solution may address the majority of (but not all) the cases.
  3. Set up a URI space supporting arbitrary levels of resolution and units of measurements. This register will dynamically generate the corresponding individuals based on information included in their URI.

An example of the last option, including also a proposal for how these individuals could be defined, is available at:

http://geodcat-ap.semic.eu/id/resolution/

andrea-perego commented 5 years ago

The new version of DCAT includes two properties to address this:

They could be possibly added in GeoDCAT-AP - taking into account backward compatibility.

It is worth noting, however, that dcat:spatialResolutionInMeters cannot express spatial resolution as equivalent scale, so it is to be decided if it is worth defining a specific property in the GeoDCAT-AP namespace.

andrea-perego commented 4 years ago

The new version of DCAT includes two properties to address this:

They could be possibly added in GeoDCAT-AP - taking into account backward compatibility.

It is worth noting, however, that dcat:spatialResolutionInMeters cannot express spatial resolution as equivalent scale, so it is to be decided if it is worth defining a specific property in the GeoDCAT-AP namespace.

These properties have been adopted in DCAT-AP 2 (see https://github.com/SEMICeu/DCAT-AP/issues/76 & https://github.com/SEMICeu/DCAT-AP/issues/78), so they should be inherited by GeoDCAT-AP.

About the problem with property dcat:spatialResolutionInMeters, I will create a separate issue.

andrea-perego commented 3 years ago

This revision has been implemented in the first working draft for GeoDCAT-AP 2.0.0:

https://semiceu.github.io/GeoDCAT-AP/drafts/2.0.0-draft-0.1/