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

license pages do not respond to Accept headers (ex. for requesting RDF) #253

Open
dunn opened this issue Feb 5, 2018 · 9 comments
Open
Labels
🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing feature 🟩 priority: low Low priority and doesn't need to be rushed 🏁 status: ready for work Ready for work

Comments

@dunn
Copy link

dunn commented Feb 5, 2018

Expected Behavior

Sending an Accept header with the desired content-type (e.g., RDF/XML) should result in CC returning the RDF/XML 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 the following issue (in that case it was a separate URL that was down):

@robmyers @little-wow

@rheaplex rheaplex self-assigned this Feb 6, 2018
@rheaplex
Copy link

rheaplex commented Feb 6, 2018

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.

@dunn
Copy link
Author

dunn commented Feb 6, 2018

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

@mzeinstra
Copy link

mzeinstra commented Feb 7, 2018

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.

  1. you recommend it in section 5.2 Microformats of the ccREL: The Creative Commons Rights Expression Language.
  2. 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

@escowles
Copy link

escowles commented Feb 7, 2018

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

@pornpailin

This comment has been minimized.

@dunn
Copy link
Author

dunn commented Aug 28, 2018

Any further consideration about (re)adding this behavior?

@rheaplex rheaplex removed their assignment Sep 7, 2018
@kgodey
Copy link
Member

kgodey commented Feb 28, 2019

We're adding this to our queue of issues to consider/work on but we can't promise a timeline.

@TimidRobot TimidRobot changed the title license pages do not respond to Accept headers license pages do not respond to Accept headers (ex. for requesting RDF) Jan 30, 2020
@cc-open-source-bot cc-open-source-bot added the 🏷 status: label work required Needs proper labelling before it can be worked on label Dec 2, 2020
@TimidRobot TimidRobot transferred this issue from creativecommons/creativecommons.org Oct 23, 2023
@TimidRobot TimidRobot moved this to Triage in Systems Sep 10, 2024
@TimidRobot TimidRobot added 🟩 priority: low Low priority and doesn't need to be rushed 🏁 status: ready for work Ready for work ✨ goal: improvement Improvement to an existing feature 🕹 aspect: interface Concerns end-users' experience with the software and removed 🏷 status: label work required Needs proper labelling before it can be worked on labels Sep 18, 2024
@TimidRobot TimidRobot moved this from Triage to Backlog in Systems Sep 18, 2024
@TimidRobot
Copy link
Member

Anyone here have opinions on the implementation in dev:

@TimidRobot TimidRobot moved this from Backlog to Ready in Systems Oct 3, 2024
@mzeinstra
Copy link

Looks elegant to me. Do we have a fallback when the rdf does not exist?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing feature 🟩 priority: low Low priority and doesn't need to be rushed 🏁 status: ready for work Ready for work
Projects
Status: Ready
Development

No branches or pull requests

8 participants