Capture the temporal extent of the data resource

[AlasdairGray]

Extend the metadata model to enable the specification of the temporal coverage and resolution of the data asset.

Note that this is about covering the time period of data items rather than the metadata of the resource, i.e. the data values span the calendar year 2019 rather than the fact that the data was published in 2020. The latter is already captured with the properties dcterms: issued and dcterms:modified.

DCAT includes the following properties for capturing temporarl coverage and resolution:

• dcterms:temporal
• dcat:temporalResolution

[AlasdairGray]

Unless there are requirements meaning that we need to model time using OWL-TIME, I would suggest that we use the simplest direct approach as shown in examples 23 and 27 in the DCATv3 recommendation.

This would mean that a dataset that covers the period 4 March 2016 until 5 August 2018 would be captured as

ex:ds257 dcterms:temporal [ 
    a dcterms:PeriodOfTime ;
    dcat:startDate "2016-03-04"^^xsd:date ;
    dcat:endDate   "2018-08-05"^^xsd:date ;
  ] .

One that is an open interval with no end date would be captured as

ex:ds257 dcterms:temporal [ 
    a dcterms:PeriodOfTime ;
    dcat:startDate "2016-03-04"^^xsd:date ;
  ] .

One that is an open interval with no start date would be captured as

ex:ds257 dcterms:temporal [ 
    a dcterms:PeriodOfTime ;
    dcat:endDate   "2018-08-05"^^xsd:date ;
  ] .

The use of dcterms:temporal would be recommended.

@cyberdudeuk do we know if there are use cases where we need to capture discontiguous temporal ranges, e.g. a dataset covers 2013, 2015, and 2017 but not 2014 or 2016?

[cyberdudeuk]

i'm not aware of any but can ask the WG, not sure if census data sets could fall in this scenario?

…

On Wed, 25 Oct 2023 at 15:33, Alasdair Gray ***@***.***> wrote: Unless there are requirements meaning that we need to model time using OWL-TIME <https://www.w3.org/TR/owl-time/>, I would suggest that we use the simplest direct approach as shown in examples 23 <https://www.w3.org/TR/vocab-dcat-3/#ex-temporal-coverage-closed-interval> and 27 <https://www.w3.org/TR/vocab-dcat-3/#ex-temporal-coverage-open-end-interval> in the DCATv3 recommendation <https://www.w3.org/TR/vocab-dcat-3/>. This would mean that a dataset that covers the period 4 March 2016 until 5 August 2018 would be captured as ex:ds257 dcterms:temporal [ a dcterms:PeriodOfTime ; dcat:startDate "2016-03-04"^^xsd:date ; dcat:endDate "2018-08-05"^^xsd:date ; ] . One that is an open interval with no end date would be captured as ex:ds257 dcterms:temporal [ a dcterms:PeriodOfTime ; dcat:startDate "2016-03-04"^^xsd:date ; ] . One that is an open interval with no start date would be captured as ex:ds257 dcterms:temporal [ a dcterms:PeriodOfTime ; dcat:endDate "2018-08-05"^^xsd:date ; ] . The use of dcterms:temporal would be recommended. @cyberdudeuk <https://github.com/cyberdudeuk> do we know if there are use cases where we need to capture discontiguous temporal ranges, e.g. a dataset covers 2013, 2015, and 2017 but not 2014 or 2016? — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQLNRKLWANSN43FKHVKBTITYBEPLTAVCNFSM6AAAAAAXFXZFCSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZZGQYTSNZUGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AlasdairGray]

I would think that each census would be described as a separate dataset where each one covers a single year. This is somewhere where you would want to think about introducing the Dataset Series as well. However, it may be the case that the Dataset Series would then only have certain years of coverage so it might well be the case.

If it is, then we need to make the property multivalued.