Semantic Web und Linked Data sind wie der Weltraum: Dort gibt es kein Leben. Mehr oder weniger langfristig dorthin zu gehen ... Ich weiß nicht, was man einem als Kind als Antwort auf die Frage „Ich möchte Astronaut werden“ gesagt hat. Aber Sie können beobachten, was auf der Erde passiert. Es ist viel einfacher, Amateurastronom oder sogar Profi zu werden.
Der Artikel konzentriert sich auf aktuelle Trends aus der Welt der RDF-Speicherung, die nicht älter als ein paar Monate sind. Die Metapher im ersten Absatz ist von einem epischen Werbebild unter dem Schnitt inspiriert.
episches Bild
I. GraphQL für RDF-Zugriff
dass GraphQL behauptet, die universelle Datenbankzugriffssprache zu sein. Und wie sieht es mit der Möglichkeit aus, über GraphQL auf RDF zuzugreifen?
Out of the box wird diese Möglichkeit geboten durch:
- Stardog(, );
- TopQuadrant-Produkte (, ).
Wenn das Repository eine solche Möglichkeit nicht bietet, wird sie unabhängig implementiert, indem der entsprechende „Resolver“ (Resolver) geschrieben wird. Dies geschah beispielsweise im französischen Projekt . Oder Sie können schon nichts schreiben, sondern einfach nehmen .
Aus der Sicht eines orthodoxen Anhängers des Semantic Web und Linked Data ist das alles natürlich traurig, da es für Integrationen gedacht zu sein scheint, die um das nächste Datensilo herum aufgebaut sind, und nicht für geeignete Plattformen (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öst die für REST typischen Probleme der Neuauswahl und Mehrfachabfragen – ohne die es wahrscheinlich nicht möglich wäre, darüber nachzudenken Abfragesprache, zumindest für das Web;
- Andererseits stört das starre Schema 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 einmal ganz klar, warum es sich um „Graph-“ handelt.
II. Adapter für MongoDB
Ein Trend, der den vorherigen ergänzt.
- Jetzt bei Stardog - insbesondere alle auf demselben GraphQL - konfigurieren Sie die Anzeige von MongoDB-Daten in virtuellen RDF-Diagrammen;
- Ontotext GraphDB vor kurzem Einfügen in SPARQL-Fragmente in der MongoDB-Abfrage.
Wenn wir allgemeiner über Adapter für JSON-Quellen sprechen, die es mehr oder weniger „on the fly“ ermöglichen, das in diesen Quellen gespeicherte JSON als RDF darzustellen, dann können wir uns auch an das bereits seit geraumer Zeit vorhandene erinnern die angepasst werden kann , an Apache Jena.
Wenn wir die ersten beiden Trends zusammenfassen, können wir sagen, dass RDF-Repositories unter Bedingungen der „Mehrfachspeicherung“ (polyglotte Persistenz) voll integrierbar und funktionsfähig sind. Es ist jedoch bekannt, dass Letzteres längst aus der Mode gekommen ist und ersetzt werden soll Multimodellierung. Und wie sieht es mit Multimodellierung in der Welt der RDF-Speicherung aus?
Kurz gesagt, auf keinen Fall. Ich möchte dem Thema Multimodell-DBMS einen separaten Artikel widmen, aber im Moment können Sie sehen, dass es derzeit kein Multimodell-DBMS gibt, das auf dem Graphenmodell „basiert“ (RDF kann als eine Variation davon betrachtet werden). Einige kleine Multimodellierungen – die Unterstützung eines alternativen LPG-Grafikmodells durch RDF-Speicher – werden in besprochen .
III. OLTP vs. OLAP
Allerdings derselbe Gartner dass Multi-Modellierung in erster Linie eine unabdingbare Voraussetzung dafür ist Operationssäle DBMS. Das ist verständlich: In einer Situation der „Mehrfachspeicherung“ entstehen die Hauptprobleme bei der Transaktionalität.
Aber wo auf der OLTP-OLAP-Skala befinden sich RDF-Repositories? Ich würde so antworten: weder dort noch hier. Um anzugeben, wofür sie gedacht sind, ist eine dritte Abkürzung erforderlich. Als Option würde ich vorschlagen OLIP – Online-Intellektuelle Verarbeitung.
Dennoch:
- Die in GraphDB mit MongoDB implementierten Integrationsmechanismen sind nicht die geringsten um Probleme mit der Schreibleistung zu umgehen;
- Stardog geht noch weiter und vollständiger Engine, wiederum mit dem Ziel, die Schreibleistung zu verbessern.
Und jetzt möchte ich einen neuen Player auf dem Markt vorstellen. Von den Machern von IBM Netezza und Amazon Redshift – . Am Anfang des Artikels wurde ein Bild aus einer Werbung für ein darauf basierendes Produkt 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 bereits auf die Ankündigung von Stardog 7 Beta, die besagte, dass Stardog RocksDB als zugrunde liegendes Speichersystem verwenden würde – Schlüsselwertspeicher, Facebooks Fork von Googles LevelDB. Warum lohnt es sich, über einen bestimmten Trend zu sprechen?
Erstens, nach zu urteilen werden nicht nur RDF-Repositories nach RocksDB „transplantiert“. Es gibt Projekte zur Verwendung von RocksDB als Speicher-Engine in ArangoDB, MongoDB, MySQL und MariaDB, Cassandra.
Zweitens werden auf RocksDB Projekte (also keine Produkte) des entsprechenden Themas erstellt.
eBay verwendet beispielsweise RocksDB in für Ihr „Wissensdiagramm“. Übrigens ist es lustig zu lesen: Die Abfragesprache begann als selbst entwickeltes Format, hat sich jedoch in jüngerer Zeit dahingehend entwickelt, dass sie immer mehr SPARQL ähnelt. Wie im Scherz: Egal wie viel Wissensgraphen wir erstellen, wir erhalten immer noch RDF.
Ein weiteres Beispiel – erschien vor ein paar Monaten . Vor seiner Einführung musste auf die historischen Informationen von Wikidata zugegriffen werden zur Standard-Mediawiki-API. In reinem SPARQL ist jetzt viel möglich. „Unter der Haube“ gibt es auch RocksDB. Übrigens, WDHQS hat es getan, es sieht aus wie die Person, die am Import von Freebase in den Google Knowledge Graph beteiligt war.
V. LPG-Unterstützung
Ich möchte Sie an den Hauptunterschied zwischen LPG-Diagrammen und RDF-Diagrammen erinnern.
In LPG können skalare Eigenschaften an Edge-Instanzen angehängt werden, während sie in RDF nur an Edge-„Typen“ angehängt werden können (jedoch nicht nur an skalare Eigenschaften, sondern auch an gewöhnliche Links). Diese Einschränkung von RDF im Vergleich zu LPG eine Art Modellierungstechnik. Die Einschränkungen von LPG im Vergleich zu RDF sind schwieriger zu überwinden, aber LPG-Grafiken ähneln eher Bildern aus Hararis Lehrbuch als RDF-Grafiken, daher wollen die Leute sie.
Offensichtlich gliedert sich die Aufgabe der „Unterstützung von Flüssiggas“ in zwei Teile:
- Änderungen am RDF-Modell vornehmen, die es ermöglichen, darin LPG-Konstrukte zu simulieren;
- Vornahme von Änderungen an der RDF-Abfragesprache, die den Zugriff auf Daten in diesem modifizierten Modell ermöglichen, oder die Implementierung der Möglichkeit, dieses Modell in gängigen LPG-Abfragesprachen abzufragen.
V.1. Datenmodell
Hier gibt es mehrere mögliche Vorgehensweisen.
V.1.1. Singleton-Eigenschaft
Der wörtlichste Ansatz zur Harmonisierung von RDF und LPG ist wahrscheinlich :
- Anstelle beispielsweise des Prädikats
:isMarriedToPrädikate werden verwendet:isMarriedTo1,:isMarriedTo2usw. - Diese Prädikate werden dann Subjekte neuer Tripletts:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateusw. - Die Verbindung dieser Prädikateninstanzen mit einem gemeinsamen Prädikat wird durch Drillinge der Form hergestellt
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Offensichtlich ist der
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, aber überlegen Sie, warum Sie nicht einfach schreiben sollten:isMarriedTo1 rdf:type :isMarriedTo.
Die Aufgabe der „LPG-Unterstützung“ wird hier auf RDFS-Ebene gelöst. Eine solche Entscheidung bedarf der Einbeziehung in die einschlägigen . Bei RDF-Repositorys, die das Anhängen von Konsequenzen unterstützen, sind möglicherweise einige Änderungen erforderlich, aber im Moment kann man sich die Singleton-Eigenschaft lediglich als eine weitere Modellierungstechnik vorstellen.
V.1.2. Verdinglichung richtig gemacht
Weniger naive Ansätze beruhen auf der Erkenntnis, dass Eigenschaftsinstanzen durch Tripletts perfekt instanziiert werden. Indem wir über Drillinge sprechen können, können wir auch über Eigenschaftsinstanzen sprechen.
Der solideste dieser Ansätze ist auch bekannt als RDR, in den Eingeweiden von Blazegraph. Es ist von Anfang an für mich und AnzoGraph. Die Solidität des Ansatzes wird dadurch bestimmt, dass er innerhalb seines Rahmens erfolgt entsprechende Änderungen in . Der Punkt ist jedoch äußerst einfach. In der RDF Turtle-Serialisierung können Sie jetzt etwa Folgendes schreiben:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Andere Ansätze
Sie können sich nicht um die formale Semantik kümmern, sondern einfach bedenken, dass die Tripletts einige Bezeichner haben, die natürlich URIs sind, und mit diesen URIs neue Tripletts zusammenstellen. Es bleibt nur noch, den Zugriff auf diese URIs in SPARQL zu ermöglichen. So Stardog.
Im Allegrograph auf Zwischenweg. Es ist bekannt, dass die Bezeichner von Triolen im Allegrograph , aber wenn dreifache Attribute implementiert sind, fallen sie nicht auf. Allerdings ist selbst die formale Semantik sehr weit entfernt. Insbesondere sind Triplett-Attribute keine URIs und die Werte dieser Attribute können auch nur Literale sein. LPG-Anhänger bekommen genau das, was sie wollten. Im speziell erfundenen NQX-Format sieht ein ähnliches Beispiel wie oben für RDF* so aus:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Abfragesprachen
Nachdem Sie LPG auf der Modellebene auf die eine oder andere Weise unterstützt haben, müssen Sie die Abfrage von Daten in einem solchen Modell ermöglichen.
- Blazegraph unterstützt RDF*-Abfragen и . Eine SPARQL*-Abfrage sieht so aus:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph unterstützt auch und wird unterstützen , die Abfragesprache in Neo4j.
- Stardog unterhält sein eigenes SPARQL und Gremlin. Sie können den URI eines Tripletts und „Metainformationen“ in SPARQL folgendermaßen abrufen:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph unterstützt auch seine eigene SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Übrigens unterstützte GraphDB einmal Tinkerpop/Gremlin, ohne LPG zu unterstützen, aber das hörte in Version 8.0 oder 8.1 auf.
VI. Verschärfung der Lizenzen
Es gab in letzter Zeit keine Ergänzungen zur Schnittmenge der Sets „Triplestore of Choice“ und „Open-Source-Triplestore“. Neue Open-Source-RDF-Stores sind alles andere als eine gute Wahl für den täglichen Gebrauch, und der Quellcode für neue Triple-Stores, die ich verwenden möchte (z. B. AnzoGraph), ist geschlossen. Vielmehr können wir über Reduzierungen sprechen ...
Natürlich ist bisher Open Source nicht geschlossen, aber einige Open-Source-Repositories werden nach und nach nicht mehr als eine Wahl wert angesehen. Virtuoso, das eine Open-Source-Edition hat, ist meiner Meinung nach voller Fehler. Blazegraph wurde von AWS gekauft und bildete die Grundlage für Amazon Neptune; Nun ist unklar, ob es noch mindestens eine weitere Veröffentlichung geben wird. Nur Jenna bleibt...
Wenn Open Source nicht so wichtig ist, man es aber einfach mal ausprobieren möchte, dann ist alles auch weniger rosig als vorher. Zum Beispiel:
- Sternenhund die kostenlose Version vertreiben (die Testzeit der regulären Version hat sich jedoch verdoppelt);
- в , wo Sie bisher den kostenlosen Basisplan wählen konnten, wird die Registrierung neuer Benutzer ausgesetzt.
Im Allgemeinen wird der Weltraum für einen normalen IT-Laien immer unzugänglicher, seine Entwicklung wird für Unternehmen immer schwieriger.
Source: habr.com