[API] Accept-Language not always relevant for RDF representations

[RubenVerborgh]

The language of the response should match the language in the Accept-Language Header.

RDF supports multi-lingual labels, so this might or might not apply.

[jhoobergs]

I added it because it would mean less data needs to be send. In RDF it might indeed be useless, but for an api I think the concept is usefull.

[RubenVerborgh]

The API returns RDF…

[jhoobergs]

The api returns RDF but can't we see it more flexible that we still use the Accept-language header so we don't have the RDF multilanguage overhead?

[RubenVerborgh]

I think it's not the API's job to choose that; it should point in the right direction.

For instance, you say "overhead", but implementing language-based-conneg is equally an overhead. In order to host the API at, let's say, a static file server, you could just serve multilingual RDF. In order to host the API at a more advanced server, and to save on bandwidth, you can negotiate and serve specific languages.

To obtain correct JSON-LD, you would still have to specify that language in the document or context anyway (https://www.w3.org/TR/json-ld/#string-internationalization); Content-Language alone is not sufficiently detailed.