Allow navDate on Ranges

[azaroth42]

Which would enable this:
https://github.com/digirati-co-uk/nui-galway-viewer/blob/master/implementation.md#model---timeline

[tomcrane]

But can navDate be a date range?

1908-06-01/1932-01-20

If navPlace can be a shape as well as a point, then navDate should be allowed to take d1/d2.

Currently:

The value must be an xsd:dateTime literal in UTC, expressed in the form “YYYY-MM-DDThh:mm:ssZ”.

http://prezi3.iiif.io/api/presentation/3.0/#navdate

[tomcrane]

Additional: https://en.wikipedia.org/wiki/ISO_8601#Time_intervals

#1246 for navPlace consideration

[jpstroop]

I feel like we had a discussion around that language in order to explicitly to disallow ranges or other formats that are legal according to 8601. If we have a use case for dateTime ranges then we should loosen that language, but not too much.

[azaroth42]

True, it doesn't give ranges, but it would at least give points on the timeline that could be used to generate the date range between two IIIF Ranges. Plotting the points on the timeline seems like a reasonable compromise, for little effort.

Also, I think we should remove the UTC requirement ... that there isn't space a label is convincing to me that the auto-generated labels will be wrong when the datetime is in (e.g.) NZT or PST. Will make another issue for that, though.

[jpstroop]

I think we were trying to just follow what Solr allowed for: https://lucene.apache.org/solr/guide/6_6/working-with-dates.html

Not saying we need to do that, but it is a set of constraints people are used to.

[tomcrane]

The reason I used dcterms:temporal on the range, with a start and end, is that building a timeline from single points on ranges might give the wrong impression - there could be gaps in the coverage. This range (say it's a newspaper article) has temporal characteristics 8 Nov - 10 Nov, it's about stuff that happened in that date range. Article 2 is about 14 Nov - 17 Nov. There is no content that has any temporal characteristics (dcterms defn) for the 11-13 Nov.

[azaroth42]

Yup, true enough! So "enable" is a bit strong, it would allow a variation of the interface where each range had a datestamp. For chronicles, diaries, collections of letters or other temporally bound ranges, that still seems like a valuable addition to me.

[workergnome]

How expressive do we need to be? If we actually want semantics around time, Owl Time is a good option, but it's far more complex than it needs to be to support basic time options.

I feel like it's a flexibility vs. parsing complexity problem, here.

[tomcrane]

Definitely a valuable addition, but I would still use an extension (i.e., dcterms:temporal) on the range for this use case. I'd also put the first date as the single value of the navDate property on the range.

[azaroth42]

I think we should optimize for the simplest and most common cases for both navDate and navPlace. So at most a range/bounding box, and more likely both just single points.

[workergnome]

I'm all about single points for both, with community supported, but co-released extensions for ranges/bounding boxes for both.

[azaroth42]

Proposal: Allow navDate on Ranges as well as the current Manifests and Collections.

Not being proposed in this issue: Changing to date ranges, changing from only UTC (#1296), adding a manifest-specified label (#1315).

[tomcrane]

👍 to the proposal immediately above.

[zimeon]

👍 to the proposal immediately above the comment immediately above (#1295 (comment))

[mikeapp]

👍

[mikeapp]

Consensus on 12/20 community call is 👍

[zimeon]

Fixed by #1381