URI
URIs sind das Identitätsfundament des semantischen Webs — ohne persistente, konsistente Kennungen zerfällt jede Wissensstruktur.
URI als Identitätsfundament
Du kannst die brillanteste Wissensstruktur der Welt gebaut haben: wenn niemand weiß, wie er sie ansprechen soll, nützt sie nichts. Genau das passiert, wenn du URIs als bloße technische Pflichtübung behandelst statt als das, was sie wirklich sind: die Identitätsschicht deiner gesamten semantischen Infrastruktur.
URI steht für Uniform Resource Identifier. Der entscheidende Begriff ist nicht "Uniform", sondern Identifier. Eine URI identifiziert. Sie sagt: dieses Ding, genau dieses, und kein anderes. Eine URL (Uniform Resource Locator) ist davon ein Spezialfall: Sie identifiziert durch Standort, also "wo findest du es". Eine URN (Uniform Resource Name) identifiziert durch Namen, losgelöst vom Ort. Der Unterschied klingt akademisch, ist er aber nicht. Eine URL kann morgen broken sein. Ein Identifier, der auf einem Standort basiert, verliert mit dem Standort seine Seele.
Persistenz ist deshalb kein Nice-to-have, sondern ein Designprinzip. Wenn du eine URI vergibst (für ein Produkt, ein Konzept, eine Person in deinem Knowledge Graph) machst du ein Versprechen. Das Ding dahinter existiert, und es bleibt unter dieser Adresse erreichbar. Brichst du dieses Versprechen, bricht die Verlinkung, das Reasoning, das Vertrauen.
Kurz: URIs sind keine Adressen. Sie sind Verträge mit der Infrastruktur.
URI-Strategien für semantische Infrastrukturen
Das W3C hat es 2008 auf den Punkt gebracht, und es gilt heute mehr denn je: Cool URIs don't change. Nicht weil Tim Berners-Lee es gesagt hat, sondern weil jede Änderung einer URI eine stille Katastrophe auslöst. Broken Links in Dokumenten sind ärgerlich. Broken URIs in einem Knowledge Graph sind strukturelle Gewalt gegen das eigene Datenmodell.
Wenn du Namensräume definierst, triffst du Architekturentscheidungen, die dich jahrelang begleiten. Ein guter Namespace ist stabil, kontrolliert und trägt deine Domain. Namensräume sind Territorien: Du willst Herr über dein Territorium sein.
Dann die ewige Debatte: opake URIs versus sprechende URIs. Opak bedeutet: eine kryptische ID (nichts verraten, nur identifizieren). Sprechend bedeutet: ein lesbarer Pfad (sofort verständlich). (Wikidata macht es opak, Schema.org macht es sprechend. Beide haben Recht, in ihrem Kontext.) Die Wahrheit? Sprechende URIs verführen zur Instabilität. Wenn das rote Sofa plötzlich blau wird: änderst du die URI? Hoffentlich nicht. Aber der Drang ist real.
Opake URIs sind robuster. Sprechende sind menschenfreundlicher. Deine Strategie entscheidet, welche Priorität zählt.
URI in der unternehmerischen Praxis
Kanonische URLs: das ist der Punkt, an dem das Thema aus dem Semantic-Web-Seminar in die echte Welt kracht. Hast du Produkte, die unter mehreren Pfaden erreichbar sind? Filtervarianten, Tracking-Parameter, Sprachversionen? Dann weißt du bereits, was passiert, wenn du keine klare kanonische URI definierst: Google verteilt deinen PageRank auf drei halbgare Duplikate, und dein Knowledge Graph weiß nicht, welche Entität die echte ist. Ein Ding, eine URI. Das ist keine Ideologie, das ist Überlebenstaktik.
In Knowledge Graphs wird dieses Prinzip noch kritischer. Wenn dein Entity-Identifier für ein Produkt heute unter einem Pfad liegt und morgen unter einem anderen, hast du nicht eine URI gebrochen, du hast eine Entität gespalten. Systeme, die auf diesen Identifier referenziert haben (interne Verlinkungen, externe Datenquellen, NLP-Pipelines), reden plötzlich an deiner Realität vorbei. Daten, die nicht mehr wissen, worüber sie reden, sind teurer Lärm.
Was passiert, wenn URIs brechen? Im besten Fall: 404-Fehler, die du siehst und fixen kannst. Im schlechtesten Fall: stille Entkopplung. Referenzen zeigen ins Nichts, niemand merkt es, und das semantische Netz deiner Infrastruktur fault von innen. Redirects helfen, aber sie sind Pflaster, keine Heilung.
Die Konsequenz ist simpel, wenn auch unbequem: URI-Strategie gehört in den Architektur-Entscheid, nicht ins Nachprojekt. Wer zuerst baut und dann benennt, zahlt doppelt.