Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow provision of label for navDate, navPlace #1315

Closed
azaroth42 opened this issue Nov 17, 2017 · 11 comments
Closed

Allow provision of label for navDate, navPlace #1315

azaroth42 opened this issue Nov 17, 2017 · 11 comments

Comments

@azaroth42
Copy link
Member

(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 azaroth42 added this to the Presentation 3.0 milestone Nov 17, 2017
@tomcrane
Copy link
Contributor

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

More discussion in #1296

@zimeon
Copy link
Member

zimeon commented Nov 22, 2017

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

@azaroth42
Copy link
Member Author

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.

@workergnome
Copy link

I'm still a strong 👎 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.

@azaroth42
Copy link
Member Author

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

@mikeapp
Copy link
Member

mikeapp commented Dec 20, 2017

Community call 12/20: defer

@mikeapp mikeapp added the defer label Dec 20, 2017
@azaroth42 azaroth42 removed the discuss label Feb 9, 2018
@azaroth42 azaroth42 removed this from the Presentation 3.0 milestone Apr 12, 2018
@azaroth42
Copy link
Member Author

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

@azaroth42
Copy link
Member Author

Editors agree at Naples to reopen for 4.0

@azaroth42 azaroth42 reopened this Jun 7, 2023
@azaroth42 azaroth42 added this to the Presentation 4.0 milestone Jun 7, 2023
@azaroth42 azaroth42 removed the defer label Jun 7, 2023
@azaroth42
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants