Das semantische Web und Linked Data sind wie der nahe Weltraum: Es gibt dort kein Leben. Um für einen mehr oder weniger längeren Zeitraum dorthin zu reisen… nun, ich weiß nicht, was man Ihnen in Ihrer Kindheit als Antwort auf ‚Ich möchte Astronaut werden‘ gesagt hat. Aber man kann das Geschehen auch von der Erde aus beobachten; Astronom zu werden, sei es als Hobby oder professionell, ist viel einfacher.
In diesem Artikel geht es um frische, nicht älter als einige Monate, Trends aus der Welt der RDF-Speicher. Die Metapher im ersten Absatz wurde von einem epischen Werbebild unter dem Schnitt inspiriert.
Das epische Bild
I. GraphQL für den Zugriff auf RDF
, dass GraphQL den Anspruch erhebt, eine universelle Sprache für den Zugriff auf Datenbanken zu werden. Wie steht es jedoch um die Möglichkeit des Zugriffs auf RDF über GraphQL?
Diese Möglichkeit bieten:
- Stardog (, );
- Produkte von TopQuadrant (, ).
Wenn das Speicher nicht die Möglichkeit bietet, wird sie selbst implementiert, indem man einen entsprechenden ‚Resolver‘ schreibt. So handhabte es beispielsweise das französische Projekt . Oder man kann bereits alles so lassen, wie es ist, und einfach .
Aus der Sicht eines orthodoxen Befürworters des Semantic Web und von Linked Data ist das alles natürlich bedauerlich, da es scheinbar für Integrationen gedacht ist, die um neue Daten-Silos herum gebaut werden, anstatt für Plattformen (selbstverständlich die RDF-Speicher).
Die Eindrücke vom Vergleich zwischen GraphQL und SPARQL sind zwiespältig.
- Einerseits wirkt GraphQL wie ein entfernter Verwandter von SPARQL: Es adressiert typische Probleme von REST wie Überabfragen und die Vielzahl an Anfragen – ohne die man wohl kaum als Abfragesprachegilt, auch wenn es nur für das Web ist;
- Andererseits enttäuscht die strenge Schemata von GraphQL. Entsprechend scheint seine „Introspektivität“ im Vergleich zur vollständigen Reflexivität von RDF sehr eingeschränkt. Und es gibt kein Äquivalent zu Property Paths, sodass unklar bleibt, warum es „Graph-“ genannt wird.
II. Adapter für MongoDB
Ein Trend, der komplementär zu vorherigen ist.
- In Stardog ist es jetzt – insbesondere alles in demselben GraphQL – möglich, die Daten von MongoDB in virtuelle RDF-Grafen abzubilden;
- GraphDB hat kürzlich Fragmenten für MongoDB-Queries in SPARQL einzufügen.
Wenn wir breiter über JSON-Adapter sprechen, die es ermöglichen, den in diesen Quellen gespeicherten JSON mehr oder weniger ‚on the fly‘ als RDF darzustellen, können wir auch an die bereits seit einiger Zeit existierende erinnern, die an Apache Jena angepasst werden kann.
Zusammenfassend lässt sich zu den ersten beiden Trends sagen, dass RDF-Speicher vollständig bereit für Integrationen sind und unter Bedingungen der ‚polyglotten Persistenz‘ operieren. Es ist jedoch bekannt, dass Letzteres schon seit einiger Zeit nicht mehr en vogue ist, und es seinem die Multimodalität gibt. Wie steht es um die Multimodalität in der Welt der RDF-Speicher?
Kurz gesagt: gar nicht. Das Thema multimodale DBMS verdient einen eigenen Artikel, doch derzeit kann festgestellt werden, dass es derzeit keine multimodalen DBMS gibt, die ‚auf‘ dem Graphmodell basieren (eine Variante davon könnte man als RDF betrachten). Über eine gewisse kleine Multimodalität – die Unterstützung alternativer Graphmodelle durch RDF-Speicher – wird im .
III. OLTP vs. OLAP
Übrigens, auch Gartner sagt, dass Multimodalität eine conditio sine qua non vor allem für operative Datenbankmanagementsysteme. Das liegt auf der Hand: Bei der Situation der 'multivariaten Speicherung' treten die größten Probleme mit der Transaktionsfähigkeit auf.
Nur wo stehen RDF-Speicher auf der Skala von OLTP zu OLAP? Ich würde sagen: weder hier noch da. Um zu kennzeichnen, wofür sie gedacht sind, benötigt man eine dritte Abkürzung. Eine Möglichkeit wäre. OLIP — Online Intellektuelle Verarbeitung.
Aber dennoch:
- Die in GraphDB realisierten Integrationsmechanismen mit MongoDB sind nicht zuletzt um Probleme bei der Schreibperformance zu umgehen;
- Stardog geht sogar noch weiter und die Engine komplett, wiederum mit dem Ziel, die Schreibperformance zu steigern.
Und nun erlauben Sie mir, einen neuen Akteur auf dem Markt vorzustellen. Vom Schöpfer von IBM Netezza und Amazon Redshift — . Das Bild aus der Produktwerbung wurde zu Beginn des Artikels angefügt. AnzoGraph positioniert sich als GOLAP-Lösung. Wie wäre es mit SPARQL und Fensterfunktionen? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB
Oben war bereits für die Ankündigung von Stardog 7 Beta, in der erwähnt wurde, dass Stardog RocksDB als zugrunde liegendes Speichersystem verwenden wird – ein Key-Value-Speicher, der aus Facebooks Fork von Googles LevelDB hervorgegangen ist. Warum ist es jetzt sinnvoll, von einem Trend zu sprechen?
Erstens, laut , wird nicht nur auf RDF-Speicherlösungen auf RocksDB umgestiegen. Es gibt Projekte, die RocksDB als Speicher-Engine in ArangoDB, MongoDB, MySQL und MariaDB sowie Cassandra nutzen.
Zweitens werden auf RocksDB thematisch entsprechende Projekte (d. h. keine Produkte) entwickelt.
Zum Beispiel nutzt eBay RocksDB in der für sein „Wissensgraph“. Übrigens ist es interessant zu lesen: die Abfragesprache begann als selbstentwickeltes Format, hat aber in letzter Zeit den Übergang zu etwas vollzogen, das viel mehr wie SPARQL aussieht. Wie in einem Witz: so viele Wissensgraphen wir auch erstellen, es bleibt immer RDF.
Ein weiteres Beispiel ist der kürzlich erschienene . Vor seiner Einführung musste man für historische Informationen zu Wikidata über auf die Standard-API von Mediawiki zugreifen. Jetzt ist vieles mit reinem SPARQL möglich. „Unter der Haube“ steckt auch RocksDB. Übrigens wurde WDHQS anscheinend von jemandem entwickelt, der sich mit dem Import von Freebase in den Google Knowledge Graph beschäftigt hat.
V. Unterstützung für LPG
Ich erinnere an den Hauptunterschied zwischen LPG-Grafen und RDF-Grafen.
Bei LPG können Skalareigenschaften an die Kanteninstanzen angehängt werden, während sie bei RDF nur an die "Typen" der Kanten angehängt werden können (wobei nicht nur Skalareigenschaften, sondern auch gewöhnliche Beziehungen möglich sind). Diese Einschränkung von RDF im Vergleich zu LPG durch unterschiedliche Modellierungstechniken. Die Einschränkungen von LPG im Vergleich zu RDF sind schwieriger zu überwinden, aber LPG-Grafen sind mehr als RDF-Grafen wie Abbildungen aus Hararis Lehrbuch, weshalb sie von Menschen bevorzugt werden.
Offensichtlich lässt sich die Aufgabe der "Unterstützung von LPG" in zwei Teile gliedern:
- Änderungen am RDF-Modell vorzunehmen, die es ermöglichen, LPG-Konstruktionen zu simulieren;
- Änderungen an der RDF-Abfragesprache vorzunehmen, die es ermöglichen, auf Daten in diesem veränderten Modell zuzugreifen, oder die Möglichkeit zu schaffen, Anfragen an dieses Modell in gängigen Abfragesprachen zu stellen.
V.1. Datenmodell
Hier gibt es mehrere mögliche Ansätze.
V.1.1. Singleton-Eigenschaft
Der direkteste Ansatz zur Harmonisierung von RDF und LPG ist wohl :
- Anstelle von beispielsweise dem Prädikat
:isMarriedTowerden die Prädikate:isMarriedTo1,:isMarriedTo2usw. verwendet. - Dann werden diese Prädikate zu Subjekten neuer Tripel:
:isMarriedTo1 :seit "2013-09-13"^^xsd:dateund so weiter. - Die Verbindung dieser Instanzen von Prädikaten mit dem gemeinsamen Prädikat wird durch Tripel der Art hergestellt
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Offensichtlich
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, aber denken Sie daran, warum es nicht sinnvoll ist, einfach zu schreiben:isMarriedTo1 rdf:type :isMarriedTo.
Die Aufgabe der „Unterstützung von LPG“ wird hier auf RDFS-Ebene gelöst. Diese Lösung erfordert Änderungen an dem entsprechenden Einige Änderungen können von RDF-Speichern erforderlich sein, die die Anbindung von Folgerungen unterstützen, während Singleton Property vorerst einfach als weitere Modellierungstechnik betrachtet werden kann.
V.1.2. Richtig ausgeführte Reifikation
Weniger naive Ansätze ergeben sich aus dem Bewusstsein, dass Instanzen von Eigenschaften durchaus durch Tripel instanziiert werden. Wenn wir in der Lage sind, etwas über Tripel zu sagen, erlangen wir auch die Möglichkeit, über Instanzen von Eigenschaften zu sprechen.
Der solideste dieser Ansätze ist , auch RDR genannt, in den Tiefen von Blazegraph. Es wurde von Anfang an RDF Semantics bestimmt. соответствующие изменения в Die Grundidee ist jedoch äußerst einfach. Bei der Turtle-Serialisierung von RDF kann man jetzt etwa so schreiben:
<> :since "2013-09-13"^^xsd:date .V.1.3. Andere Ansätze
Man kann sich die formale Semantik ersparen und einfach annehmen, dass Tripel bestimmte Identifikatoren haben, die natürlich URIs sind, und mit diesen URIs neue Tripel bilden. Es bleibt nur, den Zugriff auf diese URIs in SPARQL zu ermöglichen. So Stardog.
In Allegrograph einen Zwischenweg. Es ist bekannt, dass die Identifikatoren von Tripeln in Allegrograph , aber bei der Implementierung von Triple-Attributen nicht nach außen sichtbar sind. Dennoch ist die formale Semantik noch weit entfernt. Bemerkenswert ist, dass die Attribute von Tripeln keine URIs sind und die Werte dieser Attribute ebenfalls nur Literale sein können. Die Anhänger der LPG erhalten genau das, was sie wollten. In einem eigens entwickelten NQX-Format sieht ein Beispiel, ähnlich dem oben für RDF*, so aus:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Abfragesprachen
Nachdem LPG in irgendeiner Form auf Modellebene unterstützt wurde, muss es möglich sein, Abfragen an Daten in einem solchen Modell zu stellen.
- Blazegraph unterstützt für Abfragen an RDF* und . Eine Anfrage in SPARQL* sieht so aus:
SELECT * { <> :since ?since }- AnzoGraph unterstützt auch und plant, weiterhin zu unterstützen , die Abfragesprache in Neo4j.
- Stardog bietet ein eigenes von SPARQL an und Gremlin. Um in SPARQL die URI eines Tripels und "Meta-Informationen" zu erhalten, kann folgende Konstruktion verwendet werden:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- AllegroGraph unterstützt ebenfalls sein eigenes SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Übrigens unterstützte GraphDB eine Zeit lang Tinkerpop/Gremlin, während sie LPG nicht unterstützte, jedoch wurde dies in Version 8.0 oder 8.1 eingestellt.
VI. Verschärfung der Lizenzen
In letzter Zeit gab es keine Ergänzungen im Schnittpunkt zwischen "triplestore of choice" und "open source triplestore". Neuen RDF-Speichern mit offenem Quellcode fehlen noch die Eigenschaften, um eine gute Wahl für den täglichen Gebrauch zu sein, und der Quellcode neuer RDF-Speicher, die genutzt werden möchten (wie AnzoGraph), ist geschlossen. Man könnte sogar von Rückgängen sprechen…
Natürlich wird Open Source nicht geschlossen, aber einige Open-Source-Repositories werden zunehmend nicht mehr als wählenswert angesehen. Virtuoso, das eine Open-Source-Edition hat, ist meiner Meinung nach von Bugs geplagt. Blazegraph wurde von AWS übernommen und bildet die Grundlage für Amazon Neptune; nun ist unklar, ob es überhaupt noch eine weitere Veröffentlichung geben wird. Bleibt nur noch Jena…
Wenn Open Source jedoch nicht besonders wichtig ist und man es einfach ausprobieren möchte, sieht es auch nicht besser aus als früher. Zum Beispiel:
- Stardog kostenloses Modell ein (die Testphase wurde allerdings verdoppelt);
- in , wo man früher einen kostenlosen Basisplan wählen konnte, wurde die Registrierung neuer Nutzer ausgesetzt.
Im Allgemeinen wird der Weltraum für den durchschnittlichen IT-Nutzer immer unzugänglicher, seine Erschließung bleibt den Unternehmen vorbehalten.
Quelle: habr.com
