Future Support for Ranges in navDate Using Time Intervals

[markpbaggett]

At this year’s IIIF conference, James Misson presented a nifty new tool called IIIF Timeline, which allows users to explore collections chronologically using the navDate property. During the Q&A, several attendees asked whether the tool could display a date range rather than a single point in time for cases where exact dates may be unknown. James clarified that navDate currently only accepts a single xsd:dateTime literal, making the property inherently a timestamp rather than a time interval.

This made me wonder: why must navDate be limited to a single xsd:dateTime literal? In the same way that navPlace can represent a point, line, polygon, or multipolygon, shouldn't navDate be able to represent a temporal range rather than a time instant when exact dates might be unknown?

Someone in the audience mentioned EDTF, which I'd be opposed to due to complexities in how the value can be modelled and what a consuming application might need to make sense of the value, but why couldn't something like the W3C Time Ontology in OWL be used?

For example, maybe a range could may be represented as a time:Interval, like so:

"navDate": {
  "type": "time:Interval",
  "time:hasBeginning": "2009-01-01T00:00:00Z",
  "time:hasEnd": "2010-01-01T00:00:00Z"
}

This structure would allow viewers like IIIF Timeline to reflect temporal uncertainty, rather than forcing them to collapse that information into a moment in time.

I understand the desire to retain a single date for purposes like sorting or navigation. However, if navDate were expressed as an interval, deriving a representative date (e.g., the midpoint) by the viewer or consuming application seems trivial rather than by restricting the data model itself. Also, if I'm understanding the Time Ontology correctly, this seems like a valid way to represent an instant as an interval if everything needed to be an Interval:

"navDate": {
  "type": "time:Interval",
  "time:hasBeginning": "2009-01-01T00:00:00Z",
  "time:hasEnd": "2009-01-01T00:00:00Z"
}

I could be wrong, but I think it's fairly common for GLAMS to want to express time uncertainty in metadata and it seems like viewers like this could be poised to make use of the data. I admit also that I'm probably not fully understanding the purpose of navDate and that my proposal might be misinformed. I'm also not an ontologist, so my suggested model may too be wrong.

Regardless, I appreciate any consideration or feedback by the editors to help us better understand this.

[azaroth42]

This has been discussed several times in the past including especially:

• Consider how to support additional metadata for newspapers use case #442
• Allow navDate on Ranges #1295

The intent of navDate is to provide a navigation tool, not to deal with uncertainty or spans of time. At some level, the publisher of the manifest needs to make a decision about where they want this item to appear on a calendar or in a list of timestamps. It should be the publisher not the client software that makes the choice of the representative date ... is it the earliest, middle, latest or something else?

The next step however would be to create an extension -- say, navDateInterval and implement it in clients. If there's utility and adoption, then it could be rolled into a future minor version of the Presentation API.