api icon indicating copy to clipboard operation
api copied to clipboard

Allow provision of label for navDate, navPlace

Open azaroth42 opened this issue 7 years ago • 8 comments

(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".

azaroth42 avatar Nov 17 '17 18:11 azaroth42

One for the Newspapers WG to bounce around @kestlund @glenrobson

More discussion in https://github.com/IIIF/api/issues/1296

tomcrane avatar Nov 20 '17 14:11 tomcrane

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..

zimeon avatar Nov 22 '17 14:11 zimeon

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.

azaroth42 avatar Dec 13 '17 04:12 azaroth42

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.

workergnome avatar Dec 17 '17 17:12 workergnome

Given that #1246 is defer, and the label is unnecessary to solve #1296, I propose to also defer this issue along with navPlace.

azaroth42 avatar Dec 17 '17 20:12 azaroth42

Community call 12/20: defer

mikeapp avatar Dec 20 '17 17:12 mikeapp

Not needed for navDate, will solve if navPlace is undefered.

azaroth42 avatar Apr 18 '18 13:04 azaroth42

Editors agree at Naples to reopen for 4.0

azaroth42 avatar Jun 07 '23 15:06 azaroth42

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.

azaroth42 avatar Jun 07 '24 21:06 azaroth42

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.

azaroth42 avatar Jun 07 '24 21:06 azaroth42

Spawned #2303 for further uses of nav* properties on annotations

azaroth42 avatar Jun 07 '24 21:06 azaroth42