An HTTP 303 redirect may not always redirect to a 'doc', so perhaps a "should" instead of "must" is better.
Use case: as "temporarily" solution when organizations/websites are not using linked data, it might be useful to e.g. provide a service to resolve URIs and redirect to e.g. a page on Drupal website for browsers, and redirect linked data clients to a completely different URI (even on another domain) like a triple store provided by the federal/regional service integrator
And a case for not redirecting in e.g. SKOS thesauri / lists, that should be IMHO a choice and not an obligation, since it creates overhead for very little benefit.
E.g "dumb" and rather static list of languages, not worth the effort of a redirect to just serve a few labels that also do not describe the language...
Actually it should not matter whether or not a redirect takes places, LOD clients should be aware that this could be the case and act accordingly
Somewhat dogmatic.
An HTTP 303 redirect may not always redirect to a 'doc', so perhaps a "should" instead of "must" is better.
Use case: as "temporarily" solution when organizations/websites are not using linked data, it might be useful to e.g. provide a service to resolve URIs and redirect to e.g. a page on Drupal website for browsers, and redirect linked data clients to a completely different URI (even on another domain) like a triple store provided by the federal/regional service integrator
And a case for not redirecting in e.g. SKOS thesauri / lists, that should be IMHO a choice and not an obligation, since it creates overhead for very little benefit. E.g "dumb" and rather static list of languages, not worth the effort of a redirect to just serve a few labels that also do not describe the language...
Actually it should not matter whether or not a redirect takes places, LOD clients should be aware that this could be the case and act accordingly