Guidance on use of temporal date interval with no final end date

[philipashlock]

This has come up while discussing many issues related to date fields and the use of ISO 8601 syntax (such as additional accrualPeriodicity values), but I don't think we've provided enough guidance for this with the temporal field in particular.

The temporal field is meant to denote the time period described by the data in the dataset. This is distinct from modified which denotes when the data was last modified regardless of the dates described by the data. This is also distinct from issued and accrualPeriodicity which are both about when the dataset was formally published and the frequency with which that happens.

temporal is meant to be an interval describing the range of dates covered by the data. If the dataset is based on new information being collected rapidly in realtime, the end date used for temporal would still ideally be a timestamp that was current to the moment when someone downloaded the current dataset. However, considering that this metadata is often entered manually or involves some delay in being published and is often not provided dynamically to generate a current timestamp for a regularly updated dateset, it would be helpful to have other approaches to indicate that temporal is open ended.

Unfortunately, ISO 8601 doesn't allow you to specify intervals without end dates unless you specify a repeating interval. I've come across two attempts to address this. One is the Dublin Core Collection Description : Open Date Range Format (DCCD ODRF) which states, "This representation of an open date range is not compatible with the representation of a time-interval defined by ISO8601:2000." and the other is the LOC Extended Date/Time Format (EDTF).

What you can do with 8601 is specify an ambiguous end date (eg 2005-05-30/2016 where you just know the end date is in 2016) or you can use repeating intervals.

Our updated guidance on accrualPeriodicity replaced the term "Continuously Updated" with a suggestion to use a repeating 1 second interval in ISO 8601 syntax (R/PT1S). I suppose we should document something similar for temporal when the end date is open ended?

For example you might describe a dataset with data about daily weather reports since May 30, 2005 continuing up through the present using the following for temporal

R/2005-05-30/P1D

Examples of using repeating intervals for temporal where recently removed from the documentation, but they are supported by the JSON Schema.

[akuckartz]

For most date intervals I am not happy with the use of ISO 8601 because it is a special syntax expressing a pair of two values. I think that should be avoided by having separate properties for start date and end date. An interval without end date then simply would not have an end date property.

Popolo and OpenGovLD use http://schema.org/startDate and http://schema.org/endDate

[danbri]

Belated response to @akuckartz regarding "An interval without end date then simply would not have an end date property." ... I think we need something more explicit. Not recording an end date is consistent with it having ended in the past, whereas we want to say that as far as we know it is still ongoing with no fixed end date planned. That information isn't captured if we simply omit endDate, because all schema.org properties (or other rdf) can be omitted for a wide variety of reasons.

Have there been any new developments on this topic?