Ga naar hoofdinhoud

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

· 10 minuten leestijd
Bob Coret
David de Boer
Software Architect & Developer

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.

Update 2 april 2026

Deze post adviseerde oorspronkelijk http://schema.org/ (HTTP) op basis van de hieronder beschreven redenen. Dat leidde tot precies de discussie die we hoopten: een gestructureerd gesprek met betrokkenen van NDE, CLARIAH, ODISSEI en erfgoedinstellingen. Op 2 april 2026 bereikten de deelnemers consensus over https://schema.org/ (HTTPS). Deze post is bijgewerkt om dat besluit te weerspiegelen – zie de aanbeveling.

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.

Kan een eigen context helpen?​

Met JSON-LD 1.1's @import is het mogelijk een eigen context te maken die alles naar https://schema.org/ remapt:

{
  "@context": {
    "@version": 1.1,
    "@import": "https://schema.org/docs/jsonldcontext.jsonld",
    "@vocab": "https://schema.org/",
    "schema": "https://schema.org/"
  }
}

Dit overschrijft zowel @vocab als het schema-prefix, waardoor alle termen expanderen naar https://schema.org/ met behoud van type-coercions (bijv. url en sameAs blijven IRI's, geen platte strings).

Zie een gedeelde context voor afnemers voor hoe NDE dit toepast.

De impact is beperkt​

De JSON-LD-contextmismatch raakt alleen tooling die JSON-LD verwerkt en expandeert naar RDF-triples. Het raakt niet:

  • Data gepubliceerd in Turtle, N-Triples of andere RDF-serialisaties – die gebruiken volledige URI’s, dus bronhouders schrijven gewoon https://schema.org/.
  • SPARQL-query’s en SHACL-shapes – die verwijzen naar volledige URI’s en worden niet beïnvloed door JSON-LD-contextgedrag, zolang de data waarop ze werken niet is geëxpandeerd vanuit JSON-LD (waar de context http://-URI’s produceert).
  • Zoekmachines zoals Google, die beide varianten normaliseren.

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.

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.

De aanbeveling​

Op 2 april 2026 bereikten vertegenwoordigers van NDE, onderzoeksinfrastructuren (CLARIAH, ODISSEI) en erfgoedinstellingen (IISG en anderen) consensus: gebruik https://schema.org/.

De argumenten die de doorslag gaven:

  • Toekomstbestendig. Schema.org’s eigen FAQ wijst HTTPS aan als de gewenste richting. Nu HTTP kiezen zou een tweede migratie riskeren als Schema.org die transitie voltooit.
  • Makkelijker te communiceren. Instellingen vertellen dat ze http:// moeten gebruiken – terwijl hun browser https:// toont – leidt tot verwarring en vereist telkens uitleg over het verschil tussen identifier en transport.
  • Netwerkeffect. Vocabulaires zoals PiCo en tools zoals rdflib gebruiken al https://schema.org/. Aansluiten versterkt de interoperabiliteit binnen NDE, CLARIAH, ODISSEI en daarbuiten.

Het NDE Schema-applicatieprofiel adviseert nu:

  • Nieuwe datasets MOETEN https://schema.org/-URI’s gebruiken.
  • Bestaande datasets zouden naar https://schema.org/ moeten migreren (SHOULD).
  • Afnemers MOETEN beide varianten (http:// en https://) accepteren. NDE biedt tooling (zoals de gedeelde JSON-LD-context) om te normaliseren naar https://schema.org/.

Dit volgt het robuustheidsprincipe: publiceer strikt, accepteer ruim.

Een gedeelde context voor afnemers​

Bij JSON-LD ligt de verantwoordelijkheid niet bij de bronhouder maar bij de afnemer. Bronhouders blijven gewoon "@context": "https://schema.org" gebruiken – geen extra afhankelijkheden. Afnemers passen een gedeelde context toe bij het verwerken van binnenkomende JSON-LD-data, waarmee http://-termen worden herschreven naar https:// bij inname.

NDE biedt deze context aan via het @import-mechanisme dat hierboven is beschreven. Afnemers vervangen de context van binnenkomende documenten vóór expansie:

// Node (jsonld.js)
document['@context'] = 'https://docs.nde.nl/schema.org/context.jsonld';
const expanded = await jsonld.expand(document);
# Python (pyld)
document["@context"] = "https://docs.nde.nl/schema.org/context.jsonld"
expanded = jsonld.expand(document)

Deze aanpak is stack-onafhankelijk: één URL die werkt in elke JSON-LD 1.1-processor, ongeacht taal of platform. Geen stream transforms per stack nodig. Als alternatief kunnen afnemers de context inline opnemen om de externe afhankelijkheid te vermijden.

Upstream-afhankelijkheden​

Sommige upstream-standaarden zoals RO-Crate en CodeMeta gebruiken nog http://schema.org/-URI’s. Dit raakt de NDE-aanbeveling niet direct – onze Requirements for Datasets gebruiken al https:// – maar het betekent dat afnemers nog http://-data kunnen tegenkomen van bronnen buiten het NDE-netwerk. Dit is nog een reden waarom normalisatie aan de afnemerskant belangrijk is.

Conclusie​

https://schema.org/ is de canonieke vorm voor Schema.org-URI’s in het Nederlandse cultureel-erfgoednetwerk. De JSON-LD-contextmismatch is een reëel maar beperkt probleem, opgelost door een gedeelde context voor afnemers. Bij het publiceren van gestructureerde data: gebruik https://schema.org/. Bij het consumeren: accepteer beide en normaliseer naar https://.

Deze post is bijgewerkt naar aanleiding van een besluit op 2 april 2026. De oorspronkelijke versie adviseerde http://schema.org/ – de bijgewerkte aanbeveling is https://schema.org/. Met dank aan deelnemers vanuit erfgoedinstellingen, onderzoeksinfrastructuren en de academische wereld – en aan Ivo Zandhuis, Richard Zijdeman en Leon van Wissen voor hun vroege feedback.