[Proposal] Top level temporal resolution field

[odscrachel]

What is your proposed change?

To create a top level temporal_resolution field with the following attributes

Title	Field name	Description	Field Type	Codelist
Temporal resolution	temporal_resolution	The unit(s) of time covered by the dataset.	array of strings	daily, weekly, monthly, annually

Why is this not covered by the existing model?

This replaces temporal_resolution (E.g. "monthly", "daily", "annual", if applies to data.) which appeared in DDH_v0.2.xlsx.

[stufraser1]

@matamadio what is the use case for this field? I'm not clear on its use in this context at this level. If applicable to hazard, it should be at hazard level, I'm not sure it's relevant to others H V L

[matamadio]

It is not a mandatory attribute, however it was proposed as it could be relevant for:

• hazard, e.g. annual wildfires, or monthly drought maps
• exposure, e.g. a collection of annual land use change
• loss data, e.g. annual losses vs monthly losses

[duncandewhurst]

I think it's fine to have this as an optional field at the top (dataset) level in RDLS based on DCAT's dataset-level temporalResolution property:

Definition: Minimum time period resolvable in the dataset.
Usage note: If the dataset is a time-series this should correspond to the spacing of items in the series. For other kinds of dataset, this property will usually indicate the smallest time difference between items in the dataset.

Presumably, the reason for specifying the minimum time period, rather than a range or list of durations, is that higher resolution data (e.g. daily) can be aggregated to a lower resolution (e.g. monthly). Is there a particular use case for risk data that can't be met by that model?

In terms of modelling, is the proposed codelist (daily, weekly, monthly, annually) sufficient? What about bi-weekly data or data by decade? A better approach might be to follow DCAT's approach of using ISO8601 durations, e.g. P1M for monthly, P1Y for annual, P2W for bi-weekly etc. JSON Schema offers a 'duration' format that can be used to validate that type of data.

[odscjen]

we decided in #62 (comment) to have a Temporal object in both the 'dataset' top level and at the Resource level to accommodate when a dataset has a range of times with different resources corresponding to each of those different times. (although I know realise the PR to create Temporal only put it into Resource)

Should this temporal resolution field be added to the Temporal object and therefore be available at both dataset and resource level? @stufraser1 @matamadio

[duncandewhurst]

Temporal resolution and temporal coverage are two different concepts so I think this should be a separate field from the temporal (period) object. That's in line with DCAT's approach to modelling the concepts. As for whether it should exist at both dataset and resource level, given that resources in RDLS can be more than just different distributions/representations of the same dataset, I think it should go at resource level.

[stufraser1]

It is helpful to have an indication of the temporal coverage at the top level because we need to be able to understand the full range of scenarios e.g. 2020, 2030, 2060... in the overall dataset. However, we also need the specific year/range (coverage) referenced at the resource level for whatever single event date or year scenario the resource refers to.
Temporal resolution probably sits at top level too, given use case where it would describe the collection, not individual file, see #68 (comment), but wouldn't be needed at resource level, I think.

[duncandewhurst]

In #54 we established that resources can be more than just different distributions/representaitons of the same dataset. In particular, we're allowing temporal coverage to differ between resources so we could have a situation in which a dataset has a resource covering 2014 whose temporal resolution is monthly and a resource covering 2015 whose temporal resolution is weekly. In that case, presumably, we'd set the dataset-level temporal resolution field to 'weekly' since that is the minimum temporal resolution resolvable amongst the dataset's resources. However, that's not terribly helpful to users, since the 2014 resource's temporal resolution is actually only monthly. That is why I now think that it makes more sense to have temporal resolution at the resource level.

[odscjen]

Is the answer to this maybe to have temporal resolution at both the dataset and resource level but similar to how we've agreed to do with hazard event_set vs event include in the description of temporal resolution at the dataset level that this should only be used it the temporal resolution is the same for all resources included, otherwise the resource level temporal resolution field should be used?

[matamadio]

Agreed on Jen proposal to use the top level, unless resources have different resolutions - then use the resource level.