Zusammenfassung

  • Die Fassung vom 24. September 2026 ist ein überarbeiteter Working Draft des SPARQL 1.2 Graph Store Protocol, weder sein erster öffentlicher Entwurf noch eine W3C Recommendation.
  • Gegenüber Dezember 2024 darf ein GET ohne Accept jede RDF-Serialisierung liefern; beim indirekten Parameter graph werden prozentdekodierte Bytes nun ausdrücklich als UTF-8 interpretiert.
  • Formatverhandlung, Graph-Identität und Schreibberechtigung sollten unabhängig geprüft werden. Das ist eine betriebliche Empfehlung dieses Beitrags, keine neue W3C-Pflicht.

Ein Client, der jahrelang Turtle erhält, kann leicht glauben, Turtle sei der Standardfall jedes Abrufs. Gerade ein nicht gesendeter Header macht diese Erwartung schwer zu erkennen. Der Working Draft vom Dezember 2024 beschränkte die Antwort auf ein GET ohne Accept noch auf RDF/XML, Turtle oder N-Triples. Im Text vom 24. September 2026 kann der Server jede RDF-Serialisierung wählen; JSON-LD wird ausdrücklich als Beispiel genannt. Daraus folgt weder, dass ein bestimmter Dienst sein Verhalten schon geändert hätte, noch, dass nun alle Server JSON-LD ausgeben. Eine bisher stillschweigend genutzte Einschränkung ist im Entwurf jedoch weggefallen.

Wer nur bestimmte Formate einlesen kann, sollte sie mit Accept anfordern und den tatsächlich gelieferten Medientyp prüfen. Ein RDF-Dokument ist die transportierte Darstellung des Graph-Inhalts. Sein Format bescheinigt nicht die Wahrheit der Aussagen und schafft keinen Anspruch darauf, den Graph zu bearbeiten. Für eine Migration müssen diese drei Fragen auseinandergehalten werden: Kann der Client die Antwort lesen, meint die Anfrage den richtigen Graph, und darf der handelnde Akteur ihn verändern?

Die zweite Textänderung betrifft die mittlere Frage. Ein Graph kann direkt über seine IRI oder indirekt über die URL des Graph Store mit ?graph= angesprochen werden. Das indirekte Verfahren gab es bereits. Der Entwurf von 2024 verlangte die Prozentdekodierung des Parameterwerts. Die neue Fassung ergänzt, dass die resultierenden Bytes als UTF-8-kodierte Zeichenfolge der Graph-IRI auszulegen sind. Die IRI muss absolut sein; andernfalls ist 400 vorgesehen. Eine IRI mit nicht-ASCII-Zeichen eignet sich als Test, ob Sender und Empfänger denselben Zielgraphen rekonstruieren. Die Quellen belegen keinen tatsächlichen Namenskonflikt und keinen ausgenutzten Fehler.

Die bekannten HTTP-Methoden dürfen in dieser Nachricht nicht als neue Befugnisse erscheinen. GET liest, PUT ersetzt Graph-Inhalt, POST führt Inhalte zusammen und DELETE entfernt einen Graphen. Schon das SPARQL-1.1-Protokoll von 2013 beschrieb solche Operationen. Welche Identitäten sie ausführen dürfen, entscheidet die jeweilige Implementierung; der aktuelle Entwurf berücksichtigt Antworten wegen fehlender Anmeldung oder unzureichender Rechte. Eine gültige Adresse ist kein Schlüssel. Umgekehrt muss eine berechtigte Automatisierung besonders vor PUT wissen, ob sie wirklich einen ganzen Graphen ersetzen und nicht nur Aussagen ergänzen will.

Eine brauchbare Abnahme dokumentiert deshalb den gesendeten Accept-Wert, den erhaltenen Content-Type, den codierten graph-Wert, die nach Dekodierung gemeinte absolute IRI sowie das für jede Schreibmethode berechtigte Konto. Ersetzen und Zusammenführen lassen sich zunächst an einem Testgraphen unterscheiden. Dieses knappe Protokoll ist eine redaktionelle Empfehlung, keine vom W3C vorgeschriebene Bescheinigung. Es verhindert, dass ein erfolgreiches HTTP-Ergebnis als Beleg für Formatverständnis, Zielidentität und Berechtigung zugleich ausgegeben wird.

Die W3C-Veröffentlichungsgeschichte reicht für den ersten öffentlichen SPARQL-1.2-Entwurf bis Mai 2023 zurück. Der Septembertext bleibt änderbar und meldet keine Messergebnisse aus konkreten Installationen. Die sachlich begrenzte Nachricht lautet: Zwei Client-Annahmen verdienen jetzt eine explizite Probe. Ob sie einen laufenden Dienst treffen, kann nur dessen Verhalten zeigen.

Quellen