Warum überhaupt SemanticWeb?

Wenn man den Begriff des SemanticWeb nicht kennt, könnte man meinen, es ist wie das DarkWeb, noch ein Web neben dem WWW. Dies ist es jedoch nicht! Einige bezeichnen das SemanticWeb, in Anlehnung an das Web 2.0, auch das kommende Web 3.0. Es werden außerdem die Begriffe LinkedOpenData und WebOfData verwendet, sie bezeichnen alle das selbe.

SemanticWeb laut Wiki

Das SemanticWeb beschreibt eine Erweiterung zum bekannten WWW, bei dem der Computer mitliest. Der erste Entwurf vom SemanticWeb stammt vom Gründer des WWW Tim Berner Lee (TBL), von ihm stammt auch die Idee des SemanticWeb. Web-Seiten sind meist so gestaltet, dass man sie als Mensch lesen kann. Häufig sind Informationen in Sätzen formuliert statt in Tabellen, die ein Computer strukturiert verstehen kann. Das SemanticWeb ermöglicht an dieser Stelle, die Sätze anhand eines Datenschemas zu strukturieren. Wikipedia hat dazu dieses Beispiel:

Auf der Webseite wird für den menschlichen Konsumenten folgender Satz dargestellt: “Paul Schuster wurde in Dresden geboren.”

Der Computer könnte einen Parser einsetzen um diesen Satz in seine Einzelteile zu zerlegen. Mit etwas mehr Aufwand, würde der Computer auch herausfinden, dass Paul Schuster eine Person ist, Dresden eine Ort bzw. Stadt ist und dass scheinbar Paul dort geboren wurde. Falls der Computer eine anderssprachige Webseite lesen möchte, müsste man ihm vorher den entsprechenden Parser beibringen. Bei der Parser-Lösung müsste man nicht nur die Sprache beachten, sondern der Computer müsste auch erst herausfinden, wo auf der Webseite der wichtige Inhalt steht.

Das SemanticWeb sieht vor, dass man die Webseite mit einigen Annotationen versieht, sodass der Computer direkt einen Graphen (mit Knoten und Kanten) daraus erstellen kann. Setzt man in den Beispiel-Satz die HTML-Annotationen ein, sieht der Satz wie folgt aus:

<div vocab="http://schema.org/" typeof="Person">
  <span property="name">Paul Schuster</span> wurde in
    <span property="birthPlace" typeof="Place" href="http://www.wikidata.org/entity/Q1731">
      <span property="name">Dresden</span>
    </span> geboren.</div>

Dort wurde festgelegt, dass alles innerhalb des div-Element Person die Person definiert. Innerhalb des div-Elements befinden sich einige span-Elemente, die jeweils einen Propertynamen gesetzt haben. Diese span-Element beinhalten den Wert des jeweiligen Property. Ein RDFa-Parser würde aus diesem HTML-Block folgenden Graph bilden können:

RDF example.svg
Von DennyEigenes Werk, CC0, https://commons.wikimedia.org/w/index.php?curid=38335508

 

Das SemanticWeb bietet eine standardisierte Form um Daten in HTML-Dokumenten zu strukturieren. Aber dies ist nur ein kleiner Teil von dem was das SemanticWeb bietet.

SemanticWeb ist mehr!

Der Wow-Effekt kommt mit der bereits vorgestellten OWL und der darauf aufbauenden Ideen. Durch OWL lassen sich mittels definierter Inferenzen aus vorhandenen Daten weitere Schlüsse ziehen. Das klingt schon gut, aber die W3C möchte noch weiter gehen. Die W3C hat dazu einen Layer Cake konstruiert:

sw-tower
vgl. https://www.w3.org/RDF/Metalog/docs/sw-easy

In dem Layer-Cake sind die einzelnen SemanticWeb-Technologien aufgeführt und wie sie aufeinander basieren. Die unteren vier Schichten bis zur Ontology vocabulary wurden in diesem Blog bereits behandelt. Bei den auf OWL aufbauenden Schichten gibt es Uneinigkeit im Netz:

Nach Medić und Golubović sind die Schichten Logic und Proof von TBL nicht im Detail definiert worden und im ersten Entwurf treten sie als eine Schicht auf. Zieht man sie auf zwei Layer, dann wird vermutlich der Logic-Layer dafür sorgen, dass Daten gemäß einer Logik aus dem Web extrahiert werden. Der Proof-Layer hingegen prüft, ob und weshalb ein Agent extrahierten Daten vertrauen soll.

Craig Knoblock von der University of Southern California zeigt dies anhand von Beispielen. Nach ihm wendet man im Logic-Layer Prädikatenlogik auf die Daten an, um neue Informationen zu generieren. Dazu gibt er auch dieses Beispiel:
Angenommen man hat folgendes Datenschema entwickelt:

data_schema
vgl. http://www.isi.edu/integration/courses/csci548_2010/slides/Semantic_Web.pdf

Dort möchte man nun die neue Klasse “rabies animal” einführen. Da man nicht alles neu definieren möchte, verwendet man die bereits vorhandenen Klassen. Für die neue Klasse muss man also irgendwie den Zusammenhang zwischen den Klassen animal und rabies herstellen. Dazu legt man eine Klasse “rabies animal” an, die von der Klasse sick animal erbt und eine has-Relation zu rabies hat. Gezeigt in folgendem Diagramm:

advanced_data_schema
vgl. http://www.isi.edu/integration/courses/csci548_2010/slides/Semantic_Web.pdf

Aber: Alle Layer nach dem OWL-Layer sind laut Wiki noch nicht realisiert und sind daher noch Wunschkonstrukte.

Fazit

Das SemanticWeb ist eine von TBL entwickelte Idee, die schon weit spezifiziert und entwickelt wurde, aber noch nicht komplett fertig gestellt ist. Es ist bereits jetzt verwendbar. Wie im Datenbank-Artikel gezeigt, gibt es leider eine zu geringe Verbreitung der SemanticWeb-Technologien. Dies könnte sich in nächster Zeit ändern, da mehr Projekte ihre Daten öffentlich bereitstellen, wozu häufig SemanticWeb-Technologien verwendet werden.

RDFS vs. SQL vs. NoSQL

Die letzten Posts haben sich mit den SemanticWeb-Technologien beschäftigt, wie man sie anwenden kann und welchen Nutzen sie bringen. Wie bereits im OWL-Post erwähnt, basiert OWL auf RDF(-S). Wenn man sich einen Moment das RDF Konzept auf der Zunge zergehen lässt, merkt man, dass RDF erstaunlich ähnlich zum Konzept einer Datenbank ist. Ich werde daher im Folgenden RDF mit zwei Datenbank-Ideologien vergleichen und Unterschiede aufzeigen.

RDF vs. SQL

Das RDF-Konzeptberuht im wesentlichen auf Klassen und Properties. Wobei Die Instanz einer Klasse durch beliebig viele Properties beschrieben wird. Relationale Datenbanken, wie z.B. eine SQL-Datenbank, bestehen im wesentlichen aus Tabellen, deren Entitäten durch Attribute (Spalten) beschrieben werden.

Nun kann man die RDF-Klassen mit den SQL-Tabellen und die RDF-Properties mit den SQL-Attribute gleichstellen. Dem aufmerksamen Leser wird auffallen, dass eine RDF-Instanz durch beliebige Properties mit beliebigen Werten beschrieben werden kann. Dies entspricht nicht dem SQL-Konzept, bei dem man die Tabellen-Attribute streng typisieren kann und per Constraint validieren kann.

Der Vergleich mit einer SQL-Datenbank hinkt an dieser Stelle also etwas. Dennoch sind die Konzepte sich sehr ähnlich.

RDF vs. NoSQL

Wie bereits aufgezeigt sind die Konzepte  RDF und SQL sich sehr ähnlich bis auf, dass eine SQL-Tabelle im Gegensatz zu RDF ein festes Daten-Schema hat. Möchte man eine schemalose Datenbank, dann findet man viel Auswahl bei den sog. NoSQL-Datenbanken. Als Beispiel werde ich hier die dokumentenorientierte NoSQL-Datenbank MongoDB verwenden.

Datenschema

Eine NoSQL-Datenbank zeichnet sich vor allem dadurch aus, dass sie schemalos ist. Es gibt einige NoSQL-Datenbanken – wie z.B. ElasticSearch – die ein dynamisches Schema haben. Das sind allerdings Sonderfälle, die hier nicht weiter betrachtet werden. Eine MongoDB beruht im wesentlichen auf sog. Collections, die eine Ansammlung von beliebigen JSON-Objekten darstellen. Diese JSON-Objekte können beliebige Key-Value-Pairs enthalten.

Man kann also die gleichen schemalosen Daten in RDF persistieren wie auch in einer MongoDB. In diesem Punkt sind sie gleich.

Schnittstelle

Um Daten in einer NoSQL-Datenbank zu persistieren oder abzufragen, braucht es häufig eine je nach Datenbank unterschiedliche Syntax. MongoDB hat eine eigene Anfragesprache, die spziell für die Datenbank entwickelt wurde. Inzwischen gibt es für nahezu jede Programmiersprache einen MongoDB-Adapter, sodass man programmatisch auf die Datenbank zugreifen kann. Nichts destotrotz verwendet MongoDB eine mächtige proprietäre Anfragesprache. In der Sprache können beispielsweise komplexe Map-Reduce-Anfragen gestellt werden.

RDF hingegen ist abfragbar durch SPARQL, was durch die W3C definiert und spezifiziert ist. SPARQL-Anfragen können über HTTP gestellt werden und unterstützen damit alles, was HTTP hergibt. Alle mit dem Internet verbundenen Computer verfügen heutzutage über einen Browser und können daher mit dem Interface agieren. HTTP ist ebenfalls durch die W3C definiert und hat sich als Protokoll zum Daten-Austausch in verteilten Systemen etabliert. REST-API’s bspw. kommunizieren ebenfalls über HTTP und haben bereits ihren Mehrwert gegenüber proprietären Protokollen und Frameworks zum Datenaustausch bewiesen.

Viele NoSQL-Datenbanken haben inzwischen ebenfalls eine HTTP-Schnittstelle, welche allerdings meist nur “der Vollständigkeit halber” nachgebessert wurde. MongoDB bspw. hat ab Werk keine HTTP-Stelle. Es gibt allerdings Tools in allerlei Sprachen, die von der Community geschrieben wurden, um dieses Manko auszubessern.

SemanticWeb vs. NoSQL

Es gibt Stimmen, die sagen, dass viel von der Aufmerksamkeit, die NoSQL inzwischen bekommt, auch der SemanticWeb-Community gehören könnte. Als NoSQL aufkam, war es DIE Technologie um Datenbanken flexibler und skalierbarer zu machen. Und es ist immernoch die Technologie für diese Zwecke.

SemanticWeb kann mit OWL das gleiche und noch viel mehr. Es kann durch die Definition von OWL-spezifischen Properties weitere Informationen und Zusammenhänge in den Daten aufdecken. Diese Zusammenhänge muss man in NoSQL-Datenbanken durch komplexe Anfragen oder durch entsprechende Code-Zeilen herstellen.

Bednar et al. (2014) haben RDF und NoSQL-Datenbanken miteinander verglichen. Sie kamen zu dem Ergebnis, dass sie was die Daten-Persistierung von schemalosen Daten gleich sind. RDF hat durch die Verwendung einer standardisierten einen Vorteil gegenüber der heterogenen Anfragesprache der einzelnen NoSQL-Datenbanken. Sie stellen allerdings auch fest, dass NoSQL-Datenbanken durch die Unterstützung von Transaktionen, Replikation und Lastverteilung einen Vorteil beim Betrieb der Datenbank bieten. Sie empfehlen daher die Entwicklung und Verwendung einer standardisierten Anfrage-Sprache für NoSQL-Datenbanken, dann wäre auch dieses Problem gelöst.

Es gibt also einige Texte die davon ausgehen, dass das SemanticWeb- und NoSQL-Technolgien miteinander konkurieren. Wenn man sich die beiden Technologien genauer ansieht, wird man feststellen, dass die versuchen völlig unterschiedliche Probleme zu lösen. NoSQL-Datenbanken versuchen die Datenhaltung flexibel, verteilt und einfach zu halten. NoSQL versucht nicht irgendeine Logik in seine Daten zu bringen. SemanticWeb-Technologien beinhalten zwar unter anderem das RDF, was mit einer NoSQL-Datenbank konkurieren könnte. Allerdings stellt das RDF nur eine Definition der Daten dar, die das SemanticWeb verwenden möchte. Eigentlich geht es dem SemanticWeb um den Teil, den OWL erweitert: Das hinzufügen von Meta-Daten um neue Informationen zu generieren und Schlüsse zuzulassen.

Decentralyze und ein Beitrag von InfoQ reden davon, dass man diese beiden Ideen miteinander verbinden sollte. Da die NoSQL-Produkte bereits sehr ausgereift sind, was die Datenhaltung angeht. Daher könnte man die SemanticWeb-Ideen auf NoSQL-Datenbanken übertragen. Damit würde das Konzept des SemanticWeb nicht verloren gehen, sondern es würde durch eine mächtige Datenhaltung erweitert werden. Und NoSQL-Datenbanken würden durch diese Fusion ihr Wissen erweitern. Was dann noch fehlt, ist die standardisierte Anfrage-Sprache für NoSQL-Datenbanken und die bislang konkurrienden Technologien wären beide Gewinner.

Fazit

Ja, es gibt Unterschiede zwischen dem SemanticWeb und NoSQL-Datenbanken, obwohl beide eine schemalose Datenhaltung anstreben. Sie können allerdings voneinander profitieren, wenn sie aufeinander zugehen anstatt sich als Rivalen zu sehen.

Referenzen

[1] Bednar, Peter, Martin Sarnovsky, and Viktor Demko. “RDF vs. NoSQL databases for the semantic web applications.” Applied Machine Intelligence and Informatics (SAMI), 2014 IEEE 12th International Symposium on. IEEE, 2014.

OWL- Das Web mit Sinn

Wir hatten uns bereits mit RDF(-S) beschäftigt, womit man Daten im SemanticWeb strukturieren kann. Wir sind nun also in der Lage alle unsere Daten im Web zu hinterlegen und mittels SPARQL abfragbar zu machen. Was braucht man mehr?

SemanticWeb mit Semantik

Wie wäre es mit Semantik? Da wir uns im Gebiet der SemanticWeb bewegen, wäre es langsam Zeit dafür! Alles was dieser Blog bislang behandelt hat, kann man auch mit einer simplen SQL-Datenbank abbilden.

Mit RDF kann man zwar Daten strukturieren, aber RDF kann keine Beschränkungen über Properties abbilden. Da fehlt die Ausdrucksstärke von RDF, die im Folgenden korrigiert wird.

Erweiterung durch OWL

Um Semantik ins SemanticWeb zu bringen, bedient sich die W3C der Ontologien. Dazu hat es sogar eine eigene Sprache aufgestellt, die OWL – Web Ontology Language. Eine Ontologie ist eine Definition und Klassifikation von Konzepten, Entitäten und der Relationen zwischen ihnen.

Wir fangen mit etwas an, was wir schon kennen: RDF-S.  OWL basiert auf den bekannten RDF-S Strukturen und ist daher grundsätzlich mit allen RDF-Werkzeugen kompatibel. OWL fügt lediglich einige Vokabularien hinzu, um der Datenstruktur eine Semantik zu verleihen.

Rachel Lovinger fasst in ihren RDF-OWL-Slides die OWL-Erweiterungen gegenüber RDF gut und kompakt zusammen. Laut den Slides erweiter OWL das RDF um folgende Elemente:

  • Relationen zwischen Klassen:
    • disjointWith: Eine Entität von einer Klasse a kann nicht von einer Klasse b sein, z.B.
       <Person> <disjointWith> <Country>
    • complementOf: Eine Entität, die nicht von der Klasse a ist, ist von der Klasse b, z.B.
       <InanimateThings> <complementOf> <LivingThings>
  • Gleichheit zwischen Entitäten:
    • sameAs: Zeigt, dass zwei Entitäten dieselbe Identität haben, z.B.
       <wills> <sameAs> <wismith>
    • equivalentClass: Zeigt, dass zwei Klassen die gleichen Mitglieder haben, z.B.
       <CoopBoardMembers> <equivalentClass> <CoopResidents>
  • Richer Properties:
    • Symmetrie: Wenn es eine Relation x zwischen den Entitäten a und b gibt, dann gibt es die Relation x auch zwischen den Entitäten b und a, z.B.
       <WillSmith> <marriedTo> <JadaPinkettSmith> impliziert <JadaPinkettSmith> <marriedTo> <WillSmith>
    • Transitivität: Wenn es eine Relation x zwischen den Entitäten a und b gibt, und die Relation x zwischen den Entitäten b und c gibt, dann gibt es die Relation x ebenso zwischen den Entitäten a und c, z.B.
       <piston> <isPartOf> <engine>
      
       <engine> <isPartOf> <automobile> impliziert
      
       <piston> <isPartOf> <automobile>
    • inverseOf: Eine Relation x zwischen den Entitäten a und b impliziert eine Relation y zwischen den Entitäten b und a, z.B.
       <starsIn> <inverseOf> <hasStar>
      
       <MenInBlack> <hasStar> <WillSmith> impliziert
      
       <WillSmith> <starsIn> <MenInBlack>

Mit den Erweiterungen durch OWL lassen sich einige Datensätze kompakter speichern. Möchte man bspw. symmetrische Relationen erfassen, dann ist es in OWL nicht nötig, dass jede symmetrische Relation gespeichert wird. Man muss lediglich die Relation in eine Richtung abspeichern und diese Relationsart als symmetrisch definieren.

Dadurch lässt sich viel Wissen aus Meta-Daten generieren, ohne dass es dediziert erfasst wird.

Sind wir nicht alle ein wenig SPARQL?

Wir haben uns damit beschäftigt, wie man RDF und RDF-S benutzt. Dort haben wir gesehen, dass man dort viele Daten einpflegen kann und über aufwändige programmatische Schleifen auswerten kann.

Aber ist es unbedingt nötig, dass man erst Java-Profi wird, bevor man RDF-Daten auswerten kann?

Nein, und jetzt werden SQL-Freunde auf ihre Kosten kommen: Es gibt eine Anfragesprache für RDF-Daten, die sehr SQL-ähnlich ist. Das Konzept heißt SPARQL und steht für SPARQL Query Language. Das folgende Beispiel kommt von Wikipedia:

PREFIX abc: http://example.com/exampleOntology
  SELECT ?capital ?country
  WHERE {
    ?x abc:cityname ?capital ;
       abc:isCapitalOf ?y .
    ?y abc:countryname ?country ;
       abc:isInContinent abc:Africa .
  }

Die Variablen werden in SPARQL mit einem ‘?’ vorangestellt. Die Anfrage liefert alle afrikanischen Länder mit deren Hauptstadt.

Diese Anfrage würde man an einen sog. SPARQL-Endpoint stellen. Ein Endpoint ist ein HTTP-Service, der die Anfrage entgegennimmt, verarbeitet und das Ergebnis zurückliefert. Einige Endpoints hat die W3C hier zusammengefasst. Darunter auch übrigens öffentliche Daten der US-Regierung. 😉 Es gibt allerdings noch viele mehr, die nur zu wenig kommuniziert werden. Dessen hat sich die Seite linkeddata.org angenommen, die versuchen Open Linked Data Sets zueinander zu führen.

Das folgende Beispiel kommt vom Projekt DisGeNet:


SELECT ?gda ?label ?comment ?title ?id ?voidSubset

FROM http://rdf.disgenet.org WHERE {

?gda rdf:type sio:SIO_001120 ; rdfs:label ?label ; rdfs:comment ?comment ; dcterms:title ?title ; dcterms:identifier ?id ; void:inDataset ?voidSubset

}

LIMIT 20

Führt man diese Anfrage auf den SPARQL-Endpoint von DisGeNet aus, wie hier gezeigt, dann erhält man das Ergebnis der Anfrage als HTML-Dokument. Ändert man den Parameter format der URI auf bspw. “json”, dann erhält man ein maschinenlesbares Ergebnis der Anfrage. Ähnlich verhalten sich auch andere der SPARQL-Endpoints.

RDF mit Schema -> RDF-S

RDF-S bietet dem einfachen RDF gegenüber einige Vorteile, die sich im “S” verstecken:

Das “S” steht für ein Schema , das dem RDF-Modell nun hinzugefügt wird. Das Schema erlaubt einem eine Klassen- und Property-Hierarchie darzustellen. Als Beispiel sei folgendes RDF-S Modell-Snippet mit Apache Jena gegeben:

//vocabulary namespace
String termsNS = "http://example.com/terms#";
//instance namespace
String instanceNS = "http://example.com/instances#";
Model model = ModelFactory.createDefaultModel();
//create properties and put them into a hierarchy
Property subProp = model.createProperty(termsNS, "subProp");
Property superProp = model.createProperty(termsNS, "superProp");
model.add(subProp, RDFS.subPropertyOf, superProp);
//create classes and put them into a hierarchy
Resource classA = model.createResource(termsNS + "A");
Resource classB = model.createResource(termsNS + "B");
classB.addProperty(RDFS.subClassOf, classA);
//create a resource of type A with property subProp
Resource a = model.createResource(instanceNS + "a", classB)
.addProperty(subProp, "foo");

Wer sich mit Objektorientierter Programmierung beschäftigt, würde jetzt erwarten, dass man einer Klasse bestimmte Properties zuweisen kann. Evtl. auch, dass man bei einer Property nur bestimmte Klassen als Objekte verwenden darf. Dies ist nicht so! Jede Klasse kann jedes Property mit jedem beliebigen Objekt zugeordnet werden. RDF-S schenkt also einen Hauch von OOP, sodass man sich fast heimisch fühlt. Es verhält sich allerdings anders, als es zunächst scheint.

Angenommen man verwendet o.g. Modell und möchte die Ressource analysieren. Dann wird man feststellen, dass sie wie erwartet von der Klasse B ist und die Eigenschaft subProp mit dem Wert “foo” hat. Außerdem wird man feststellen, dass sie ebenfalls von der Klasse A ist und die Eigenschaft superProp mit dem Wert “foo” hat. Zusätzlich zu dem erwarteten Klassenvererbungs-Mechanismus wurden hier auch Eigenschaften “vererbt”.

TL;DR;

Mit RDF-S kann man Objekten eine Klasse zuteilen, die Unter- bzw. Oberklassen haben und damit Objekte typisieren. Außerdem kann man Properties mittels Unter- und Oberproperties klassifizieren. Was allerdings nicht geht ist, dass man mit einem Property nur bestimmte Klassen in Relation stellt. Eine Klasse kann jedes beliebige Property verwenden!

Erste Schritte mit Apache Jena

Wir haben uns damit beschäftigt, wie man RDF und RDF-S benutzt. Dort haben wir gesehen, dass man dort viele Daten einpflegen kann und über aufwändige programmatische Schleifen auswerten kann.

Aber ist es unbedingt nötig, dass man erst Java-Profi wird, bevor man RDF-Daten auswerten kann?

Nein, und jetzt werden SQL-Freunde auf ihre Kosten kommen: Es gibt eine Anfragesprache für RDF-Daten, die sehr SQL-ähnlich ist. Das Konzept heißt SPARQL und steht für SPARQL Query Language. Das folgende Beispiel kommt von Wikipedia:

PREFIX abc: http://example.com/exampleOntology
  SELECT ?capital ?country
  WHERE {
    ?x abc:cityname ?capital ;
       abc:isCapitalOf ?y .
    ?y abc:countryname ?country ;
       abc:isInContinent abc:Africa .
  }

Die Variablen werden in SPARQL mit einem ‘?’ vorangestellt. Die Anfrage liefert alle afrikanischen Länder mit deren Hauptstadt.

Diese Anfrage würde man an einen sog. SPARQL-Endpoint stellen. Ein Endpoint ist ein HTTP-Service, der die Anfrage entgegennimmt, verarbeitet und das Ergebnis zurückliefert. Einige Endpoints hat die W3C hier zusammengefasst. Darunter auch übrigens öffentliche Daten der US-Regierung. 😉 Es gibt allerdings noch viele mehr, die nur zu wenig kommuniziert werden. Dessen hat sich die Seite linkeddata.org angenommen, die versuchen Open Linked Data Sets zueinander zu führen.

Das folgende Beispiel kommt vom Projekt DisGeNet:


SELECT ?gda ?label ?comment ?title ?id ?voidSubset

FROM http://rdf.disgenet.org WHERE {

?gda rdf:type sio:SIO_001120 ; rdfs:label ?label ; rdfs:comment ?comment ; dcterms:title ?title ; dcterms:identifier ?id ; void:inDataset ?voidSubset

}

LIMIT 20

Führt man diese Anfrage auf den SPARQL-Endpoint von DisGeNet aus, wie hier gezeigt, dann erhält man das Ergebnis der Anfrage als HTML-Dokument. Ändert man den Parameter format der URI auf bspw. “json”, dann erhält man ein maschinenlesbares Ergebnis der Anfrage. Ähnlich verhalten sich auch andere der SPARQL-Endpoints.