...
Statement #1 of the Linked Data Principles says "Use URIs as names for things" and statement #2 says "Use http URIs to that people can look up those names" (This includes https URIs, too!). This stresses that URIs are used for the purpose of identification as well as to initiate data transfer.
...
Why are identifiers not independent from protocol?
That currently is the way it is defined in the RDF standardThe RDF specification says that identifiers are compared character bv character (as specified in RFC 3986). This means that for a generic RDF handler, http://example.org/foo and https://example.org/foo are different resources since a URI comparator would say that the fifth character in the string differs.
Linked Data, however, is about the web so we need web-actionable identifiers. Deploying something like a resolver in between breaks the web approach: you have to educate users to use the resolver instead (which btw. has other disadvantages - bad experience with resolvers with DOI because the resolvers behave so differently. BnF experience: It's not sufficient to set an ARK on everything)
...
We could assign https to new data and keep http for "old" data. However, that would be awkwardly inconsistent and hard to explain to non-LD people, particularly if the URIs are based on patterns (e. g. "Use the prefix http://example.com/data/ and add the foo-number"). And still involves http traffic.
...
The question is: why wait? Harry Halpin sees no reason to wait for RDF standard or client side changes because the (semantic) web is young enough to change to https.
What about URIs of RDF Element Sets|Vocabularies
Does it make sense to change them to https as long as rdf, owl, skos, xsl ... don't change? Policy of these is to wait and hope that HSTS and UIR will still become good.
Another point is that the semantics of most of those vocabularies are hard-coded in the relevant tools (such as the OWL-API or Jena) so the identifiers are not dereferenced before they are acted on. That means that it would not really matter if the rdf namespace is identified by http://www.w3.org/1999/02/22-rdf-syntax-ns# or https://www.w3.org/1999/02/22-rdf-syntax-ns# since the semantics are known and the namespace identifiers are not dereferenced anyway. Terms, classes and properties from other vocabularies building on RDF, RDFS and OWL need to be dereferenced in order for applications to act on the properly, so here it does matter if the identifiers use http or https.
DCMI has had only one request for https so far and therefore currently doesn't see urgent need for action.
...
Leans towards switching to https URIs as early as possible with advanced warning to data users.
Materials
...
- Harry Halpin: "Semantic Insecurity: Security and the Semantic Web", October 2017 (gist: switch now to https it's not too late yet and the web will be more secure immediately)
- 2017 "The use of https: IRIs on the semantic web" thread on semantic-web@w3.org (about https in vocabulary URI schemes in particular, gist: strong tendency to go for https)
- Discussion page of the Wikidata community 2017-2018 (gist: no change to https URIs. Possibly more due to the fact that the discussion subsided rather than an active decision)
- W3C Blog post "HTTPS and the Semantic Web/Linked Data", 20 May 2016 (gist: keep writing “http:” and trust in infrastructure and software to advance)
- Discussion 2015 in the W3C Web Annotation Working Group (gist: some statements for "never to don't use https URIs as identifiers" but discussion closed down for other, formal reasons)
- W3C Design Issues, Tim Berners-Lee "Web Security - TLS Everywhere, not https: URIs", 2015 (gist: the "s" breaks the web, use HTTPS but don't change the URI prefix)
- Discussion page of the Wikidata community 2017-2018 (gist: no change to https URIs. Possibly more due to the fact that the discussion subsided rather than an active decision)
More observations/inquiries results
- Wikidata has a 301 redirect from http to https URIs in place but retains http URIs as "Concept URIs", i.e. in RDF data.
- schema.org vocabulary retains http in the URIs, has a 301 redirect from http to https URIs and a triple in the RDF data connecting the two with schema:sameAs, e.g.
schema:CreativeWork schema:sameAs <https://schema.org/CreativeWork>. (https://schema.org/CreativeWork.ttl, Status 2019-02-01) In the FAQs there is a statement that both, http and https are fine right now and that over time migration to https is intended (Status 2109-04-16) - Library of Congress has so far decided not to switch URIs to HTTPS due to disruption but also lack of capacity to make a final decision. There are plans to review the decision and investigate further (Status February 2019)
- DOI URI prefixes are https://doi.org/, see http://www.doi.org/factsheets/DOIProxy.html#encoding
- ISNI URI prefixes are http://isni.org/isni/, see http://www.isni.org/how-isni-works
- ORCID URIs prefixes are https://orcid.org/, see https://support.orcid.org/hc/en-us/articles/360006897674-Structure-of-the-ORCID-Identifier
[Update 2019-03-12:] German National Library (DNB) decided to switch all URIs in domain d- nb.info to https in October 2019
The National Library of Sweden added new canonical "https" URIs for formal resources in the domains id.kb.se and libris.kb.se at the occasion of the introduction of their new infrastructure Libris XL. (The old "http" URIs are maintained using owl:sameAs in this new system. These will be issuing HTTP redirects to the new URIs as soon as possible.) (Status March 2019)
tbc