Alignment of QB4ST with DCAT-2

[dr-shorthair]

DCAT-2 has added a lightweight treatment of spatial- [1] and temporal-resolution [2] to the existing spatial- [3] and temporal-coverage (extent) [4] capability (which use the DC properties). QB4ST should either re-use or provide a mapping to these - see Bounding Envelopes and Coordinate granularity.

[1] https://w3c.github.io/dxwg/dcat/#Property:dataset_spatialresolution [2] https://w3c.github.io/dxwg/dcat/#Property:dataset_spatial [3] https://w3c.github.io/dxwg/dcat/#Property:dataset_temporalresolution [4] https://w3c.github.io/dxwg/dcat/#Property:dataset_temporal

[chris-little]

@dr-shorthair Spatial: This seems sensible. Originally I was disconcerted by 'dataset_spatialresolution' being in metres. The two 'edgy' cases from earth system modelling are:

1. Lat Long grid, specified in term of N-S, pole to equator, resolution or number of grid lengths, and the corresponding E-W resolution actually varying from a decimal value to zero at the poles.
2. (Polar) Sterographic grid, where the resolution varies from a decimal value to infinity at the other pole or equator. In practice, we can pick locations, such as latitude 60N, where the decimal value is accurate, and hopefully the varying detail can be represented in the Data Quality Vocabulary [VOCAB-DQV].

Temporal However, even though I am happy that 'dataset_temporal' is a named timespan or an interval specified by two instants (which makes it 'calendar orthogonal'), it does not seem to fit with 'dataset_temporalresolution' which is a duration, the result of differencing two instants, which is fine with a single UoM CRS but not necessarily simple arithmetic within a calendar system.

In very simple terms, a time interval specified by two end-points, and a time interval specified by an end point and a duration, are not always equivalent.

I am not sure whether this matters or is just me splitting theological temporal hairs. What does the DCAT community think?

[dr-shorthair]

Indeed - generic DCAT is not the place for hair-splitting.

There are many special and not-so special cases that cannot be handled by the proposed predicates (e.g. differing vertical and horizontal resolutions are almost ubiquitous). But we want to provide a basic solution that is good enough for 80%, simple enough to not alienate non-spatial/temporal practitioners, but without being meaningless. A rule-of-thumb is to avoid nesting structures until you have to. So, indeed, DQV would be the next step, but these were deemed good enough for now.

I think I understand the point you are making about temporal, but again I'm not sure its really in scope for DCAT. The primary use-case is discovery. Temporal Coverage tells you which time interval the dataset relates to. Temporal Resolution tells you what the temporal granularity of points in the dataset are, so you can quickly judge if it might be fit for your purpose. Yeah, the interval might not be an integer multiple of the granules, but that's not really the issue. Or am I missing your point?

[chris-little]

@dr-shorthair: No, you are spot on. I was thinking about detailed processing, rather than initial discovery.

[rob-metalinkage]

might this best be done by providing a profile of DCAT for describing spatio-temporal aspects of data using QB4ST? under open world nothing stops these being used for QB4ST now.

[andrea-perego]

Just an addition to what @dr-shorthair reported:

For spatial coverage, DCAT2 now includes additional properties for specifying geometries as bboxes and centroids. All the relevant properties are described in the following section:

https://w3c.github.io/dxwg/dcat/#Class:Location

As the lack of agreed RDF properties for bboxes and centroids has been an outstanding issue in SDWWG, feedback from SDWIG would be very much welcome.