api
api copied to clipboard
Allow provision of label for navDate, navPlace
(Splitting from #1296)
In order to allow appropriate representation of a human readable label for the point on a timeline, calendar or map, it would be advantageous for the content provider to include this label directly, associated with the data that allows the point to be plotted. Date labels should not be modified to the viewers locale in terms of timezone, but should be modified in terms of language (en: January vs fr: Janvier). The internationalization expectation in IIIF is that the resource will provide the translations.
For example, the date label "January 1st 410, 00:00:00" is not really appropriate compared to "410 AD". Or "34 Quai du Louvre, 75001 Paris, France" compared to just "Paris".
One for the Newspapers WG to bounce around @kestlund @glenrobson
More discussion in https://github.com/IIIF/api/issues/1296
It seems that if we opted for adding a label
then there would be no motivation to remove the UTC requirement (#1296). It does seem like we might very quickly get into a UI nightmare because the client would have labels with lengths it does control that might not fit onto a small timeline or calendar, whereas if it is just a set of time values then the client can make choices about granularity to show based on the spread of data etc..
I think we need to be pretty clear on this one for 3.0, as it wouldn't be backwards compatible. If we're not comfortable doing it now, we should close the issue as wontfix
with a convincing argument as to why it's a bad idea.
I'm still a strong :-1: on this. navDate
and navPlace
are designed to provide hooks for software UI, not for presentational metadata. One they're labeled metadata with semantic meaning, we open ourselves up to the full discussion of the semantics of two of the hardest concepts to define semantically--place and time.
I think there's a strong use case for engaging with those questions, but I think it should not be as part of the core IIIF specification.
Given that #1246 is defer
, and the label is unnecessary to solve #1296, I propose to also defer this issue along with navPlace.
Community call 12/20: defer
Not needed for navDate, will solve if navPlace is undefered.
Editors agree at Naples to reopen for 4.0
Not that adding it to navDate would be a breaking change for the main prezi spec between 3.0 and 4.0 -- currently this would be the /only/ such change.
Editors agree - no labels for navDate/navPlace. It's for dropping pins into a timeline or a map for the resource that has the property -- so the label is the label of that resource.
Spawned #2303 for further uses of nav* properties on annotations