Specifying spatial / temporal resolution

[andrea-perego]

ℹ️ Copy-pasted from SEMICeu/Core-Location-Vocabulary#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]

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

• dcat:spatialResolutionInMeters
• dcat:temporalResolution

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]

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

• dcat:spatialResolutionInMeters
• dcat:temporalResolution

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 SEMICeu/DCAT-AP#76 & SEMICeu/DCAT-AP#78), so they should be inherited by GeoDCAT-AP.

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

[andrea-perego]

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/