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

Alternative proposals for how to implement the requirement for te download service to advertise the natural languages it supports? #5

Open
michellutz opened this issue Dec 5, 2019 · 3 comments
Labels
question Further information is requested

Comments

@michellutz
Copy link

Do you have any other proposals for how to implement the requirement for the download service to advertise the natural languages it supports?

@michellutz michellutz added the question Further information is requested label Dec 5, 2019
@cportele
Copy link
Contributor

cportele commented Dec 5, 2019

(From the related discussion in an OGC GitHub issue)

For datasets available in multiple languages, another option could be to declare the languages in the metadata, if DCAT is used (not sure about 19115). In DCAT each language would be a separate Distribution, so this would advertise the languages available via the API.

There could be a link to the DCAT metadata from the landing page (which is also not required by the standard, but easier to support than full language support). This way the list of languages would be "retrievable from the download service".

@cportele
Copy link
Contributor

cportele commented Dec 5, 2019

Another approach that is equivalent to the language selectors on webpages is to send a HEAD request and look for self/alternate links with an hreflang attribute:

% curl -I "https://example.com/api/collections" -H "Accept-Language: de" -H "Accept: application/json"

HTTP/1.1 200 OK
Date: Thu, 05 Dec 2019 20:52:53 GMT
Content-Type: application/geo+json
Content-Language: de
Link: <https://example.com/api/collections?lang=de>; rel="self"; title="Dieses Dokument"; type="application/json"; hreflang="de"
Link: <https://example.com/api/collections?lang=en>; rel="alternate"; title="This document"; type="application/json"; hreflang="en"
Vary: Accept-Language
Content-Length: 968

However, I don't think this is a solution for INSPIRE as it requires support for HEAD and Link headers (both are only recommendations in OGC API Features Core) and it requires that hreflang is used in the links and alternate links are created for other languages. HEAD is not strictly required as GET would also work, but is unnecessary as the request is only to determine the complete list of languages and the payload is not relevant.

@heidivanparys
Copy link
Contributor

Proposed way forward: please read Annex D and comment on that. It contains most considerations made, for reference. Probably the suggestion above should be added too, again for reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants