Wie Schema.orgs Backstage funktioniert und warum Entwickler einen Blick darauf werfen sollten

Habt ihr euch jemals gefragt, warum Google weiß, dass eine Seite ein tatsächliches Apfelkuchen-Rezept enthält und nicht nur einen Text mit Zutaten? Oder wie E-Mail-Clients einen „Buchung bestätigen"-Button direkt in die Nachrichtenliste ziehen? Die Antwort ist immer dieselbe — Schema.org. Aber hinter den vertrauten ItemProp und JSON-LD Tags verbirgt sich ein riesiges GitHub-Repository, das nach eigenen, manchmal sehr seltsamen Regeln funktioniert.

Ich habe mich entschlossen, mir den Quellcode dieses Projekts anzusehen. Es stellt sich heraus, dass es nicht nur eine Sammlung von Referenzanleitungen ist, sondern eine vollwertige Softwareumgebung mit eigener Logik, Tests und sogar einer Philosophie des „nützlichen Chaos".

Was dieses Projekt eigentlich ist

Normalerweise nehmen wir Schema.org als Dokumentation wahr. Man geht dorthin, kopiert den benötigten Datentyp, fügt ihn in seinen Code ein. Aber das schemaorg/schemaorg Repository ist das, woraus die Website selbst aufgebaut ist. Es enthält alle Entitätsdefinitionen, Hunderte von Markup-Beispielen und Python-Software, die verstreute Dateien in eine Struktur umwandelt, die Suchmaschinen und Browser verstehen können.

Das Projekt wird von der W3C betreut, mit Beteiligung von Leuten von Google, Microsoft, Yahoo und Pinterest. Dies ist einer jener seltenen Fälle, in denen sich Branchenriesen auf eine gemeinsame Sprache geeinigt haben, damit sie nicht das Rad in jeder Ecke des Internets neu erfinden müssen.

Es stecken nicht nur Texte dahinter

Wenn man sich den data/ Ordner ansieht, kann man sehen, wie der Standard tatsächlich „atmet". Die Kernschemata werden im Turtle-Format gespeichert (.ttl). Dies ist eine Teilmenge von RDF, die wie eine Sammlung von Aussagen über die Welt aussieht.

Interessanterweise haben die Entwickler bewusst eine „schöne" Architektur abgelehnt. In der README sagen sie explizit: Wir streben nicht nach ontologischer Reinheit oder Eleganz. Wenn die Wahl zwischen strenger Logik und der Vereinfachung der Implementierung für Webmaster liegt, werden sie Einfachheit wählen. Zum Beispiel könnten sie einen Datentyp ohne Eigenschaften nur für Markup-Bequemlichkeit hinzufügen, auch wenn das für Fans formaler Modellierung wie Ketzerei klingt.

Hauptmerkmale des Repositories

1. Pragmatische Evolution. Das Projektteam steht großen Überarbeitungen skeptisch gegenüber. Wenn man vorschlägt, die Ereignishierarchie zu überarbeiten, weil „es korrekter wäre", werden sie wahrscheinlich höflich zuhören und das Ticket schließen. Ihnen ist wichtig, ob Änderungen tatsächlich von großen Datennutzern (Suchmaschinen oder Cloud-Diensten) verwendet werden.
2. Lokale Tests. Das Repository enthält Software, mit der man eine Kopie von Schema.org auf seinem Rechner bereitstellen kann. Das ist nützlich, wenn man einen neuen Datentyp vorschlagen und sehen möchte, wie er in die Gesamtstruktur passt.
3. Beispiele in Textdateien. Ein großer Teil des Werts des Projekts liegt in den examples.txt Dateien. Tausende von Fällen sind dort gesammelt: von der Auszeichnung von Busfahrplänen bis zur Beschreibung komplexer medizinischer Verfahren.

Die technische Seite

Das Projekt läuft auf Python (Version 3.6+ erforderlich). Um eine lokale Version der Website auszuführen, benötigt man Linux oder WSL2, wenn man unter Windows arbeitet.

Der Prozess sieht grob so aus:

• Abhängigkeiten installieren.
• Die Build-Skripte ausführen.
• Einen lokalen Server auf Port 8080 erhalten.

Die gesamte Software ist darauf ausgelegt, eine statische Kopie der Website zu erstellen. Die Infrastruktur wirkt etwas konservativ (mit Google App Engine, spezifischen Python-Skripten), aber sie funktioniert seit Jahren und verarbeitet ein kolossales Volumen an Bearbeitungen aus der Community.

Warum ein Entwickler sich in diese Tiefen wagen sollte

Es mag unnötig erscheinen, das Repository zu klonen, wenn es eine komfortable Website gibt. Es gibt einige Szenarien, in denen es wirklich hilft.

Erstens, wenn die Standarddokumentation unvollständig erscheint. Im Quellcode im data/ Ordner findet man oft Kommentare und Entwürfe (im Pending-Bereich), die noch nicht auf die Hauptseite ausgerollt wurden, aber bereits von großen Akteuren implementiert werden.

Zweitens, wenn man ein eigenes Tool für Datenparsing oder Validierung erstellt. Die Verwendung von schema.ttl als primäre Quelle ist viel zuverlässiger, als zu versuchen, die Website-Seiten zu scrapen. Es sind saubere Daten, bereit für die maschinelle Verarbeitung.

Drittens ist es eine großartige Schule dafür, wie man ein riesiges Open-Source-Projekt verwaltet, in dem die Interessen von Unternehmen und regulären Entwicklern aufeinandertreffen. Werfen Sie einen Blick auf Issue #1 — dort findet jahrelange Release-Planung statt, und es ist ein Beispiel dafür, wie man das Chaos unter Kontrolle hält.

Wer Updates abonnieren sollte

Wenn man in SEO, Suchmaschinenentwicklung arbeitet oder einfach möchte, dass die eigenen Daten im Web strukturiert sind, sollte dieses Repository in den Lesezeichen sein.

Erwartet hier keine schicken Frameworks oder perfekten Code. Dieses Projekt dreht sich um Inhalte, Vereinbarungen und Pragmatismus. Manchmal ist es nützlich zu sehen, dass selbst weltbekannte Standards nicht auf perfekten Formeln aufgebaut sind, sondern auf Kompromissen und der echten Erfahrung von Millionen von Menschen.

Um loszulegen, schaut euch einfach den data/examples.txt Ordner an. Vertraut mir, dort gibt es eine Menge Interessantes darüber, wie ein strukturiertes Internet tatsächlich aussehen sollte.