Open azaroth42 opened 4 years ago
aisaac
commented
4 years ago I would be strongly against changing the canonical RDF form to use HTTPs. This would probably break too many things, and does it really bring more value for users? Eventually with the HTTP URIs browsers end up on the HTTPs ones, no?
I'm also skeptical about "lining up the URIs" with owl:sameAs. What would be aligned? The URIs for the license deed have to be different from the URIs of the licenses anyway.
eroux
commented
4 years ago I don't think it makes a lot of sense to ask RDF providers using the http scheme to create new identifiers for https and have owl:sameAs between the two... why asking that to CC and not W3C for instance?
Looking at a iiif context, most external URIs (rdf, rdfs, etc.) use http. Actually, the URIs defined by IIIF use the http scheme too...
cubap
commented
4 years ago Awkwardly, this is very important, but already broken in so many ways. The Manifest URIs (for example) in all the tools I have built all have failure cases where "http://" and "https://" are sometimes the same, sometimes not, and never consistent, especially in collections across repositories. I imagine I'll be doing the same thing when it matters with the rights. In this way, I don't really care and wouldn't trust a declared opinion anyway.
That said, Manifests are funny because they are for machines, but their purpose is for display to humans. So is the rights property only for the consuming machine or is it the metadata provided to that machine for display to the human user? This question, in my opinion, only matters when funny cases like this come up anyway. I think we're in a transitional moment of the Internet and HTTP is an accommodation until Machine-Machine and Machine-Human gain separate protocols. I'm happy just being uncertain for awhile.
Edit: The confusion is apparent, but in 3.0, it looks like rights is strictly for the machines. So for this particular case, I vote 👍
aisaac
commented
4 years ago I'm voting in favour of the current solution (using HTTP) but not in favour of the suggestion made to CC to use HTTPS for the canonical URI!
azaroth42
commented
4 years ago +1: 29 [Siani81 ahankinson aisaac awead azaroth42 beaudet cubap dismorfo emulatingkat gigamorph hadro irv jonhartzler joshuago78 jpstroop jronallo jtweed julsraemy kzhr markpatton mattmcgrattan mcwhitaker mikeapp mixterj regisrob rsinghal sredick tomcrane zimeon] 0: 0 [] -1: 0 []
Super majority is in favor, issue is approved
Links
Background and Summary
A question was raised in the issue linked above as to whether the URIs for creative commons should be HTTPS or HTTP. They are currently HTTPS URIs, as that is what is listed as the "license deed". Also, all of our recommendations are to use HTTPS whenever possible. However the description of the licenses says there are three layers -- lawyers, regular people, and machines. As the presentation API usage is an enumeration for machines not directly for humans, it should use that layer ... and that layer uses HTTP.
Proposed Solution
Thus we believe that HTTP is the canonical form of the license URIs for software infrastructures, and as this is primarily a software-driven enumeration of values (the URIs), then the presentation API should require the HTTP form to be published.
However, for presentation to end users, if a client wants to create a link to the license itself, then it SHOULD rewrite the URI to use the HTTPS scheme, as that is the canonical form of the URI for humans (the "license deed").
We have created an issue for this in the creativecommons github and suggested two possible solutions:
If either of these are okay and implemented before the final version of the 3.0 APIs and thus creativecommons recommends using HTTPS, then we will instead use the https URIs, and would re-update our examples.