creativecommons.org
creativecommons.org copied to clipboard
license pages do not respond to Accept headers (ex. for requesting RDF)
Expected Behavior
Sending an Accept
header with the desired content-type (e.g., RDF) should result in CC returning the RDF for a license, rather than the HTML:
curl -iL -H 'Accept: application/rdf+xml' https://creativecommons.org/licenses/by-nc/4.0/
Actual Behavior
The server ignores the Accept
header and returns HTML.
This is a separate issue from https://github.com/creativecommons/creativecommons.org/issues/542; in that case it was a separate URL that was down.
@robmyers @little-wow
I've checked the code and we do not currently implement this behaviour.
Currently, the rdf files are treated as distinct documents rather than different content types for the same document. Since the rdf is not simply a different marking-up of the same text, I think it is reasonable to keep them as distinct documents.
If we want RDF, should we just be appending /rdf
to the URIs?
Out of curiosity, was this behavior implemented at some point in the past? At least one RDF library uses the non-RDF URIs, apparently assuming sending the Accept
headers will work: https://github.com/curationexperts/oargun/blob/master/lib/oargun/vocabularies/cclicenses.rb
I believe I remember that there was some content negotiation as some point in the past. The reason that I believe this was the case is twofold.
- you recommend it in section 5.2 of the ccrel primer.
- Over at rightsstatements.org a lot of the insights of CC have been mimicked and that platform has content negotiation.
Also I would argue the RDF is the same document as the deed, not as the legal text, and could be dealt with Accept headers.
Dunn, I'm not a CC-developer. I just been around a long time around cc tech. I am member of the tech. working group at rightsstatements.org
👍 to adding support for content negotiation. I think the RDF and HTML are different formats of the same information, and the fact that the RDF subject URI is the same as the HTML URI supports this view.
Note
Any further consideration about (re)adding this behavior?
We're adding this to our queue of issues to consider/work on but we can't promise a timeline.