Das Semantic Web und die verknüpften Daten ähneln dem nahen Raum: Das Leben ist nicht da. Um mehr oder weniger lange dorthin zu gehen ... nun, ich weiß nicht, was sie dir in der Kindheit als Antwort auf "Ich möchte Astronaut werden" erzählt haben. Aber Sie können beobachten, was passiert und auf der Erde ist. Es ist viel einfacher, Amateurastronom oder sogar Profi zu werden.
Der Artikel konzentriert sich auf neue Trends aus der Welt der RDF-Repositories, die nicht älter als einige Monate sind. Die Metapher im ersten Absatz wurde von diesem epischen Werbebild inspiriert.
Inhalt
I. GraphQL für den Zugriff auf RDF
II. Adapter an MongoDB
III. OLTP vs. OLAP
IV. RocksDB
V. LPG-Unterstützung
V.1. Datenmodelle
V.1.1. Singleton-Eigenschaft
V.1.2. Reifikation richtig gemacht
V.1.3. Andere Ansätze
V.2. Abfragesprachen
VI. Strengere Lizenzen
I. GraphQL für den Zugriff auf RDF
Sie sagen, dass GraphQL behauptet, eine universelle Sprache für den Zugriff auf Datenbanken zu sein. Was ist mit der Möglichkeit, mit GraphQL auf RDF zuzugreifen?
Diese Möglichkeit wird sofort bereitgestellt von:
Wenn das Repository keine solche Möglichkeit bietet, wird es unabhängig implementiert, indem der entsprechende Resolver geschrieben wird. Dies wurde beispielsweise im französischen Projekt DataTourisme durchgeführt . Oder Sie können schon nichts schreiben, sondern nur HyperGraphQL nehmen.
Aus der Sicht des orthodoxen Nachfolgers von Semantic Web und Linked Data ist dies alles natürlich traurig, da es für Integrationen gedacht zu sein scheint, die auf regulären Datensilos basieren und für diese Plattform nicht geeignet sind (natürlich RDF-Speicher).
Der Vergleich von GraphQL mit SPARQL hat zwei Eindrücke.
- Einerseits sieht GraphQL wie ein entfernter Verwandter von SPARQL aus: Es löste die REST-spezifischen Probleme des erneuten Abrufs und der Vielzahl von Abfragen - ohne die es wahrscheinlich unmöglich wäre, selbst für das Web als Abfragesprache zu gelten und "-QL" im Namen zu haben.
- Auf der anderen Seite stören die steifen Schaltkreise von GraphQL. Dementsprechend scheint seine "Introspektivität" im Vergleich zur vollen Reflexivität von RDF sehr begrenzt zu sein. Und es gibt kein Analogon zu Eigenschaftspfaden, daher ist nicht klar, warum es sich um "Graph-" handelt.
II. Adapter an MongoDB
Ein Trend, der den vorherigen ergänzt.
- In Stardog ist es jetzt möglich - insbesondere alle auf demselben GraphQL -, die Zuordnung von MongoDB-Daten zu virtuellen RDF-Diagrammen zu konfigurieren.
- Mit Ontotext GraphDB können Sie kürzlich Fragmente in SPARQL on MongoDB Query einfügen.
Wenn man allgemeiner über Adapter für JSON-Quellen spricht, die es mehr oder weniger "on the fly" ermöglichen, JSON als RDF darzustellen, sollte an das ziemlich lange existierende SPARQL-Generat erinnert werden , das beispielsweise an Apache Jena angehängt werden kann.
Zusammenfassend lässt sich sagen, dass RDF-Speicher ihre volle Bereitschaft zur Integration und Funktionsweise unter den Bedingungen der „multivariaten Speicherung“ (polyglotte Persistenz) demonstrieren. Es ist jedoch bekannt, dass letzteres längst aus der Mode gekommen ist und das Multimodell es ersetzen wird. Und was ist mit Multimodelling in der Welt des RDF-Speichers?
Kurz gesagt, auf keinen Fall. Ich möchte dem Thema Multimodell-DBMS einen separaten Artikel widmen. In der Zwischenzeit können Sie feststellen, dass es keine Multimodell-DBMS gibt, in denen das Hauptmodell ein Graph (RDF) wäre, jetzt ist es keine Sorte. Einige kleine Multimodelle - RDF-Repository-Unterstützung für ein alternatives LPG- Diagrammmodell - werden in Abschnitt V erläutert .
III. OLTP vs. OLAP
Derselbe Gartner schreibt jedoch, dass Multimodellierung eine unabdingbare Voraussetzung ist, vor allem für betriebsbereite DBMS. Es ist verständlich: In einer Situation des „multivariaten Speichers“ treten die Hauptprobleme bei der Transaktionsfähigkeit auf.
Aber wo sind die RDF-Repositorys auf der OLTP-OLAP-Skala? Ich würde so antworten: weder dort noch hier. Um anzugeben, wofür sie bestimmt sind, wird eine dritte Abkürzung benötigt. Alternativ würde ich OLIP - Online Intellectual Processing vorschlagen .
Dennoch:
- Mit MongoDB implementierte GraphDB-Integrationsmechanismen sollen nicht zuletzt Probleme mit der Schreibleistung umgehen.
- Stardog geht noch weiter und schreibt die Engine komplett neu, um die Aufnahmeleistung zu verbessern.
Lassen Sie mich nun einen neuen Player auf den Markt bringen. Von den Machern von IBM Netezza und Amazon Redshift - AnzoGraph . Das darauf basierende Bild aus der Produktwerbung wurde am Anfang des Artikels platziert. AnzoGraph positioniert sich als GOLAP-Lösung. Wie gefällt Ihnen SPARQL mit Fensterfunktionen? - -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
IV. RocksDB
Oben gab es bereits einen Link zur Ankündigung von Stardog 7 Beta, der besagte, dass Stardog RocksDB als zugrunde liegendes Speichersystem verwenden würde - Schlüsselwertspeicher, Facebook-Gabel von Googles LevelDB. Warum lohnt es sich, über einen bestimmten Trend zu sprechen?
Nach dem Wikipedia-Artikel werden zunächst nicht nur RDF-Repositories an RocksDB übertragen. Es gibt Projekte zur Verwendung von RocksDB als Speicher-Engine in ArangoDB, MongoDB, MySQL und MariaDB, Cassandra.
Zweitens werden bei RocksDB Projekte (d. H. Keine Produkte) des entsprechenden Themas durchgeführt.
Beispielsweise verwendet eBay RocksDB in der Plattform für sein "Wissensdiagramm". Übrigens macht das Lesen Spaß: Die Abfragesprache begann als einheimisches Format, wurde aber in jüngerer Zeit viel ähnlicher wie SPARQL . Wie im Witz: Egal wie viel Wissensgraph wir machen, wir bekommen immer noch RDF.
Ein weiteres Beispiel ist der Wikidata History Query Service , der vor einigen Monaten veröffentlicht wurde. Vor seinem Erscheinen musste Wikidata über MWAPI auf die Standard-Mediawiki-API zugreifen . Mit reinem SPARQL ist jetzt viel möglich. "Unter der Haube" gibt es auch RocksDB. Übrigens hat WDHQS anscheinend die Person, die Freebase in das Google Knowledge Graph importiert hat.
V. LPG-Unterstützung
Ich möchte Sie an den Hauptunterschied zwischen LPG- Diagrammen und RDF- Diagrammen erinnern.
In LPG können Skalareigenschaften an Kanteninstanzen aufgehängt werden, während sie in RDF nur an die "Arten" von Kanten aufgehängt werden können (aber nicht nur Skalareigenschaften, sondern auch reguläre Beziehungen). Diese Einschränkung von RDF im Vergleich zu LPG wird durch verschiedene Modellierungstechniken überwunden . Die Einschränkungen von LPG im Vergleich zu RDF sind schwieriger zu überwinden, aber LPG-Diagramme sind größer als RDF-Diagramme, ähnlich wie Bilder aus dem Harari-Lehrbuch, sodass die Leute sie wollen.
Offensichtlich besteht die Aufgabe der Unterstützung von Flüssiggas aus zwei Teilen:
- Einführung von Änderungen am RDF-Modell, die es ermöglichen, LPG-Konstruktionen darin zu simulieren;
- Vornehmen von Änderungen an der RDF-Abfragesprache, die den Zugriff auf Daten in diesem modifizierten Modell ermöglichen, oder Implementierung der Möglichkeit, Abfragen an diesem Modell in gängigen LPG-Abfragesprachen vorzunehmen.
V.1. Datenmodelle
Es gibt mehrere mögliche Ansätze.
V.1.1. Singleton-Eigenschaft
Der wörtlichste Ansatz zur Harmonisierung von RDF und LPG ist wahrscheinlich die Singleton-Eigenschaft :
- Stattdessen werden zum Beispiel
:isMarriedTo Prädikate verwendet :isMarriedTo1 usw. - Dann werden diese Prädikate zu Subjekten neuer Drillinge ::
:isMarriedTo1 :since "2013-09-13"^^xsd:date usw. - Die Beziehung dieser Instanzen von Prädikaten zu einem gemeinsamen Prädikat wird durch Tripletts der Form
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo . rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type , aber denken Sie darüber nach, warum Sie nicht einfach schreiben sollten :isMarriedTo1 rdf:type :isMarriedTo .
Die Aufgabe der Unterstützung von LPG wird hier auf RDFS-Ebene gelöst. Eine solche Lösung erfordert die Aufnahme in den entsprechenden Standard . In RDF-Repositorys, die das Anhängen von Effekten unterstützen, sind möglicherweise einige Änderungen erforderlich. Derzeit kann die Singleton-Eigenschaft jedoch einfach als eine andere Modellierungstechnik verwendet werden.
V.1.2. Reifikation richtig gemacht
Weniger naive Ansätze ergeben sich aus der Erkenntnis, dass Instanzen von Eigenschaften durch Tripletts instanziiert werden. Wenn wir die Möglichkeit haben, etwas über Drillinge zu sagen, haben wir die Möglichkeit, über Instanzen von Eigenschaften zu sprechen.
Der solideste dieser Ansätze ist RDF * , auch bekannt als RDR, geboren im Darm des Blazegraph. AnzoGraph hat ihn von Anfang an für sich ausgewählt. Die Solidität des Ansatzes wird durch die Tatsache bestimmt, dass in seinem Rahmen entsprechende Änderungen in der RDF-Semantik vorgeschlagen werden . Der Punkt ist jedoch äußerst einfach. In der Turtle-Serialisierung kann RDF jetzt wie folgt geschrieben werden:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .
V.1.3. Andere Ansätze
Sie können sich nicht mit formaler Semantik beschäftigen, sondern einfach davon ausgehen, dass Triplets bestimmte Bezeichner haben, die natürlich URIs sind, und mit diesen URIs neue Triplets erstellen. Sie müssen lediglich in SPARQL auf diese URIs zugreifen. Das macht Stardog.
Allegrograph ging einen Zwischenweg. Es ist bekannt, dass Triplett-IDs in Allegrograph vorhanden sind, aber bei der Implementierung von Triple-Attributen stechen sie nicht hervor. Die formale Semantik ist jedoch sehr weit entfernt. Es ist bemerkenswert, dass die Attribute von Triplets keine URIs sind und die Werte dieser Attribute auch nur Literale sein können. LPG-Anhänger bekommen genau das, was sie wollten. Im speziell erfundenen NQX-Format sieht ein ähnliches Beispiel wie oben für RDF * folgendermaßen aus:
:bob :marriedTo :alice {"since" : "2013-09-13"}
V.2. Abfragesprachen
Nachdem Sie LPG auf Modellebene auf die eine oder andere Weise unterstützt haben, müssen Sie die Möglichkeit geben, Datenanforderungen in einem solchen Modell zu stellen.
- Blazegraph für RDF * -Abfragen unterstützt SPARQL * und Gremlin . Die Abfrage für SPARQL * sieht folgendermaßen aus:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }
- Anzograph unterstützt auch SPARQL * und wird Cypher unterstützen , eine Abfragesprache in Neo4j.
- Stardog unterstützt seine eigene SPARQL- Erweiterung und erneut Gremlin. Sie können Triplett- und „Metainformationen“ in SPARQL URI abrufen, indem Sie Folgendes verwenden:
SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since }
- Allegrograph unterstützt auch eine eigene SPARQL- Erweiterung :
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }
Übrigens unterstützte GraphDB einmal Tinkerpop / Gremlin, während LPG nicht unterstützt wurde, aber in Version 8.0 oder 8.1 wurde dies gestoppt.
VI. Strengere Lizenzen
In letzter Zeit wurden keine Ergänzungen am Schnittpunkt der Sets "Triplestore of Choice" und "Open Source Triplestore" vorgenommen. Die neuen Open-Source-RDF-Repositorys sind keine gute Wahl für den täglichen Gebrauch, und der Quellcode der neuen Triplestors, die wir verwenden möchten (derselbe AnzoGraph), ist geschlossen. Vielmehr können wir über Abnahmen sprechen ...
Bisher wird Open Source-Code natürlich nicht geschlossen, aber einige Open Source-Repositorys werden nach und nach nicht mehr als wahlwürdig angesehen. Virtuose, der meiner Meinung nach eine Open-Source-Edition hat, ertrinkt in Fehlern. Blazegraph wurde von AWS gekauft und bildete die Basis von Amazon Neptune; Jetzt ist nicht klar, ob es mindestens eine weitere Veröffentlichung geben wird. Alles was bleibt ist Jena ...
Wenn Open Source nicht sehr wichtig ist, Sie es aber nur versuchen möchten, ist auch alles weniger rosig als zuvor. Zum Beispiel:
- Stardog stellt die Verbreitung der kostenlosen Version ein (es hat jedoch die Testzeit der regulären Version verdoppelt).
- In der GraphDB Cloud , in der Sie zuvor einen kostenlosen Basisplan auswählen konnten, wird die Registrierung neuer Benutzer ausgesetzt.
Im Allgemeinen wird der Platz für einen durchschnittlichen IT-Laien immer unzugänglicher, und seine Entwicklung wird zu einer Vielzahl von Unternehmen.