Is het http://schema.org of https://schema.org?

Schema.org is het meest gebruikte vocabulaire voor gestructureerde data op het web, ondersteund door Google, Bing en talloze dataplatforms. Het definieert typen als CreativeWork, Person en Organization, waarmee machines inhoud gestandaardiseerd kunnen verwerken. Precies daarom is het NDE-applicatieprofiel gebouwd op Schema.org. Correct gebruik maakt cultureel-erfgoeddata vindbaar en herbruikbaar tussen instellingen.

Maar als je met Schema.org in RDF hebt gewerkt, ben je dit tegengekomen: er is http://schema.org en er is https://schema.org. Dat ene lettertje verschil kan voor echte problemen zorgen: SPARQL-query’s die niets teruggeven, SHACL-validatie die goede data afwijst of slechte data negeert, of datasets die niet aan elkaar te koppelen zijn – vooral als je data uit meerdere bronnen combineert, zoals binnen NDE gebeurt.

Hoe is dit ontstaan?

Oorspronkelijk waren Schema.org-identifiers gedefinieerd met http://schema.org/. In 2018, als onderdeel van de bredere beweging richting HTTPS, verhuisde de website naar HTTPS. In de FAQ van Schema.org stond al langer (sinds 2015) dat “both 'https://schema.org' and 'http://schema.org' are fine.” Men begon dus vanzelf https:// te gebruiken – overgenomen van de site, de voorbeelden, en het FAQ-advies – ook al waren de vocabulaire-identifiers nog steeds gedefinieerd als HTTP.

Maar een webpagina is niet hetzelfde als een identifier. Je browser wordt doorverwezen naar https://schema.org/, maar voor elke tool die RDF verwerkt zijn http://schema.org/CreativeWork en https://schema.org/CreativeWork twee verschillende dingen.

Zoals Tim Berners-Lee schreef in Axioms of Web Architecture: “the significance of identity for a given URI is determined by the person who owns the URI, who first determined what it points to.” Wat heeft de eigenaar van Schema.org nu bepaald?

Waarom “both are fine” misleidend is

FAQ #19 van Schema.org stelt dat “both ‘https://schema.org’ and ‘http://schema.org’ are fine” en dat “there should be no urgency about migrating existing data” en vermeldt daarbij dat de site zelf is gemigreerd naar HTTPS. Dat advies klopt voor zoekmachines als Google, die beide varianten normaliseren. Maar voor JSON-LD-processors en RDF-tooling zijn http://schema.org/CreativeWork en https://schema.org/CreativeWork niet hetzelfde – en de JSON-LD-context definieert het vocabulaire nog steeds met HTTP-identifiers.

JSON-LD-contexten wijzen naar HTTP

JSON-LD is een veelgebruikt RDF-serialisatieformaat. Schema.org gebruikt het in de voorbeelden op de website. Schema.org in JSON-LD ziet er zo uit:

{
  "@context": "https://schema.org",
  "@type": "CreativeWork"
}

JSON-LD-processors volgen hiervoor het gestandaardiseerde mechanisme van remote document and context retrieval:

1. De processor ziet @context: "https://schema.org".
2. Hij haalt die URL op. De server antwoordt met een Link-header die naar de JSON-LD-context wijst: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json".
3. De processor volgt die link naar https://schema.org/docs/jsonldcontext.jsonld.

In dat document vind je iets belangrijks:

{
  "@context": {
    "@vocab": "http://schema.org/"
  }
}

Dit zegt tegen de JSON-LD-processor: alle Schema.org-termen expanderen naar http://schema.org/-URI's. Dus ook al gebruik je https://schema.org als context-URL, een processor expandeert "@type": "CreativeWork" naar http://schema.org/CreativeWork.

Je kunt dit in actie zien in de terminal:

echo '{"@context":"https://schema.org","@type":"CreativeWork","name":"Example"}' | riot --syntax=jsonld --output=nquads
_:B... <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/CreativeWork> .
_:B... <http://schema.org/name> "Example" .

Tools – waaronder validators, pipelines en libraries zoals Riot – normaliseren alles naar HTTP-URI's. Dat heeft niets met beveiliging te maken: ze volgen simpelweg de vocabulairedefinitie uit de officiële context. Op het moment van schrijven (Schema.org v29.4) is dat nog steeds zo.

Wat zegt de community?

De bredere community debatteert hier al jaren over, met geldige argumenten aan beide kanten.

Argumenten om bij HTTP te blijven:

• schemaorg#4404 (nog open): bijdragers wijzen erop dat “identifiers in the schema are technically URIs, not URLs. It’s actually better if they don't change over time and there is no security implication involved in a predicate or type,” en dat “Stable URIs that do not change over time are a MUST in the world of Linked Open Data.” Anderen noemen de huidige situatie een “ugly intermediate zone” – niet volledig HTTP en niet volledig HTTPS.
• schemaorg#1325 (gesloten, niet gepland): bevestigde dat er geen verplichte migratie naar HTTPS komt.
• schemaorg#2597: voorbeelden werden bijgewerkt naar HTTPS, maar de context bleef bewust op HTTP.
• schemaorg#2853: een poging bij v12.0 om de context naar HTTPS om te zetten werd meteen teruggedraaid vanwege problemen.
• ro-crate#427 en codemeta#373: zowel RO-Crate als CodeMeta overwegen HTTPS, maar gebruiken nog steeds HTTP.

Argumenten om naar HTTPS te gaan:

• FAQ #19 stelt dat “both are fine” en dat HTTPS “our preferred form in examples” is.
• rdflib definieert zijn Schema.org-namespace als https://schema.org/ (geëxporteerd als zowel SDO als schema).
• PiCo, een vocabulaire in de NDE-community, heeft in de praktijk al HTTPS geadopteerd.

Zelfs prefix-conventies weerspiegelen de tweedeling: prefix.cc koppelt schema: aan http://schema.org/ en sdo: aan https://schema.org/.

Hoe zit het met beveiliging?

Een veelgehoord argument voor HTTPS-identifiers is beveiliging: moeten we vocabulaire-definities niet ophalen via een beveiligde verbinding? In de praktijk is dit geen probleem. Als je http://schema.org/CreativeWork opvraagt, stuurt de server je door naar https://schema.org/CreativeWork – de definitie wordt hoe dan ook via HTTPS geserveerd. De HTTP in de URI is de identifier, niet het transportprotocol.

Hoe zit het met dereferenceerbaarheid?

Schema.org-URI's zijn niet zomaar ondoorzichtige strings – ze verwijzen wél naar bruikbare definities, en die dereferenceerbaarheid is een kernprincipe van linked data. Je kunt opzoeken wat CreativeWork betekent, welke eigenschappen het heeft en hoe het zich verhoudt tot andere typen. Dat werkt volledig met HTTP-identifiers: je krijgt gewoon de definities, gewoon via een beveiligde verbinding. Wat telt voor interoperabiliteit is dat iedereen dezelfde identifier gebruikt, welk URI-schema die ook heeft – en op dit moment is de canonieke vorm HTTP.

Cool URI's veranderen niet

Tim Berners-Lee schreef in zijn essay Cool URIs don't change: URI's moeten stabiel blijven. Zodra http://schema.org/CreativeWork eenmaal de identifier voor dat concept was, zou een wijziging naar https://schema.org/CreativeWork bestaande data, query’s en validatieregels breken.

Recent keek hij terug op de overgang van HTTP naar HTTPS in zijn boek This is for Everyone (p. 176):

“We hit an unfortunate snag when we changed the URL to add an 'S': it broke all existing links on the web! In retrospect, the web would be much more functional and simpler if HTTP and HTTPS pages both used the same URL, just with different protocols.”

De wijziging van het URI-schema had de identiteit niet mogen aantasten – maar dat deed het wel. Het gebruik van HTTP voor vocabulaire-identifiers is overigens heel gewoon: Dublin Core Terms gebruikt http://purl.org/dc/terms/ en is nooit overgestapt naar HTTPS.

Een duidelijke keuze

Het NDE Schema-applicatieprofiel adviseert:

• Bronhouders gebruiken bij voorkeur (SHOULD) http://schema.org/, omdat de JSON-LD-context daarnaar verwijst en het overeenkomt met het canonieke vocabulaire.
• Consumenten MOETEN (helaas) beide varianten accepteren. Er is veel Schema.org-data in omloop die HTTPS gebruikt – waaronder vocabulaires als PiCo – en wie die weigert, sluit valide datasets uit.

Dit is een interoperabiliteitsadvies gekoppeld aan het huidige gedrag van de JSON-LD-context, geen universeel beleid. Mocht Schema.org zijn context naar HTTPS migreren, dan verandert dit advies mee.

De onderbouwing staat in schema-profile#45. Deze pragmatische aanpak volgt het robuustheidsprincipe: publiceer strikt, accepteer ruim.

Conclusie

De community zal mogelijk uiteindelijk overgaan op HTTPS, maar zolang de JSON-LD-context van Schema.org dat niet weerspiegelt, blijft HTTP de meest interoperabele keuze. Bij het publiceren van gestructureerde data: gebruik http://schema.org/. Bij het consumeren: accepteer beide.