Semantisches Web und verknüpfte Daten. Korrekturen und Ergänzungen

Übrigens hat Manu Sporny erlaubt.

RDF ist ein abstraktes Modell. RDF kann in verschiedenen Syntaxen aufgezeichnet (serialisiert) werden: RDF/XML, Turtle (am menschenlesbarsten), JSON-LD, HDT (binär).

Dasselbe RDF kann auf verschiedene Arten in RDF/XML serialisiert werden, daher macht es beispielsweise keinen Sinn, das resultierende XML mit XSD zu validieren oder zu versuchen, Daten mit XPath zu extrahieren. Ebenso wird JSON-LD wahrscheinlich dem Wunsch eines durchschnittlichen Javascript-Entwicklers, mit RDF unter Verwendung der Punkte- und eckigen Klammernotation von Javascript zu arbeiten, nicht gerecht (obwohl JSON-LD in diese Richtung geht und einen Mechanismus anbietet, Framing).

Die meisten Syntaxen bieten Möglichkeiten zur Verkürzung langer URIs. Beispielsweise ermöglicht die Deklaration @prefix rdf: in Turtle später zu schreiben anstelle von <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> einfach rdf:type.

RDFS

RDFS (RDF-Schema) - ein grundlegendes Modellwörterbuch, das die Konzepte von Eigenschaften und Klassen sowie Eigenschaften wie rdf:type, rdfs:subClassOf, rdfs:domain und rdfs:range. Mit dem RDFS-Wörterbuch können zum Beispiel die folgenden gültigen Aussagen aufgezeichnet werden:

rdf:type rdf:type rdf:Property .
rdf:Property rdf:type rdfs:Class .
rdfs:Class rdfs:subClassOf rdfs:Resource .
rdfs:subClassOf rdfs:domain rdfs:Class .
rdfs:domain rdfs:domain rdf:Property .
rdfs:domain rdfs:range rdfs:Class .
rdfs:label rdfs:range rdfs:Literal .

RDFS ist ein Wörterbuch für Beschreibung und Modellierung, aber keine Sprache für Einschränkungen (obwohl die offizielle Spezifikation und verblieben ist Eine solche Verwendung ist möglich). Das Wort „Schema“ sollte nicht im selben Sinne wie in dem Ausdruck „XML-Schema“ verstanden werden. Zum Beispiel, :author rdfs:range foaf:Person bedeutet, dass rdf:type alle Werte der Eigenschaft :author — foaf:Person, bedeutet jedoch nicht, dass dies im Voraus festgelegt werden muss.

SPARQL

SPARQL (SPARQL-Protokoll und RDF-Abfragesprache) ist eine Abfragesprache für RDF-Daten. Im einfachsten Fall stellt eine SPARQL-Abfrage eine Menge von Mustern dar, mit denen die Tripel des abgefragten Graphen abgeglichen werden. In den Mustern können an den Positionen von Subjekten, Prädikaten und Objekten Variablen stehen.

Die Abfrage gibt solche Werte der Variablen zurück, bei deren Ersetzung in die Muster ein Untergraph des befragten RDF-Graphen (eine Teilmenge seiner Tripel) entstehen kann. Gleichnamige Variablen in verschiedenen Mustern von Tripeln müssen dabei die gleichen Werte haben.

Zum Beispiel wird die folgende Abfrage auf der oben angegebenen Menge aus sieben RDFS-Axiomen rdfs:domain und rdfs:range als Werte zurückgeben ?s und ?p nämlich:

SELECT * WHERE {
 ?s ?p rdfs:Class .
 ?p ?p rdf:Property .
}

Es ist erwähnenswert, dass SPARQL deklarativ ist und keine Sprache zur Beschreibung der Graphdurchsuchung darstellt (in der Tat bieten einige RDF-Speicher Möglichkeiten zur Anpassung des Ausführungsplans einer Abfrage). Deshalb können einige Standardaufgaben in Graphen, wie z.B. die Suche nach dem kürzesten Weg, nicht mit SPARQL gelöst werden, auch nicht mit Hilfe des Eigenschaftspfad (aber wiederum bieten einige RDF-Speicher spezielle Erweiterungen zur Lösung dieser Probleme an).

SPARQL trennt nicht die Annahme einer offenen Welt und folgt dem Ansatz „Negation als Fehlschlag“, in dem solche Konstrukte möglich sind, wie FILTER NOT EXISTS {…} . Die Verteilung der Daten wird durch den Mechanismusfederated queries Ein SPARQL-Endpunkt – ein RDF-Speicher, der SPARQL-Abfragen verarbeiten kann – hat keine direkten Entsprechungen aus der zweiten Phase (siehe Anfang dieses Abschnitts). Er kann mit einer Datenbank verglichen werden, auf deren Inhalt HTML-Seiten generiert wurden, die jedoch extern zugänglich sind. Ein SPARQL-Endpunkt ist eher mit einem API-Endpunkt aus der dritten Phase vergleichbar, jedoch mit zwei wesentlichen Unterschieden. Erstens besteht die Möglichkeit, mehrere „atomare“ Abfragen in einer einzigen zu kombinieren (was als Schlüsselmerkmal von GraphQL angesehen wird), zweitens ist eine solche API vollständig selbstdokumentiert (was HATEOAS zu erreichen versuchte)..

Ein polemischer Hinweis

Polemic remark

RDF ist eine Methode zur Veröffentlichung von Daten im Web, weshalb RDF-Speicher als dokumentenorientierte Datenbanken betrachtet werden sollten. Tatsächlich sind sie auch graphenbasiert, da RDF ein Graph und kein Baum ist. Es ist erstaunlich, dass sie überhaupt existieren. Wer hätte gedacht, dass es kluge Köpfe gibt, die leere Knoten umsetzen? Bei Codd ist das nicht gelungen. Das ist nicht gelungen..

Es gibt auch weniger vollwertige Methoden zur Organisation des Zugriffs auf RDF-Daten, zum Beispiel Linked Data Fragments (LDF) und Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) ist ein Formalismus zur Wissensdarstellung, eine syntaktische Variante der beschreibenden Logik. (im Folgenden ist es richtiger, von OWL 2 zu sprechen; die erste Version von OWL basierte auf ).

Konzepten der beschreibenden Logik in OWL entsprechen Klassen, Rollen entsprechen Eigenschaften, Individuen behalten ihren früheren Namen. Axiome werden ebenfalls Axiome genannt.

Zum Beispiel wird im sogenannten Manchester-Syntax die uns bereits bekannte Axiom so aufgezeichnet:

Class: Human
Class: Parent
   EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent

Es gibt auch andere Syntaxe zur Aufzeichnung von OWL, zum Beispiel die funktionsbasierte Syntax, die in der offiziellen Spezifikation verwendet wird, sowie OWL/XML.Darüber hinaus kann OWL in einen abstrakten RDF-Syntax und anschließend in eine beliebige der spezifischen Syntaxe serialisiert werden.

OWL hat eine doppelte Beziehung zu RDF. Einerseits kann man es als eine Art Wörterbuch betrachten, das RDFS erweitert. Andererseits ist es ein leistungsfähigerer Formalismus, für den RDF nur ein Serialisierungsformat ist. Nicht alle elementaren Konstruktionen von OWL lassen sich durch ein einzelnes RDF-Triplet ausdrücken.

Je nachdem, welches Teilmengen von OWL-Konstruktionen erlaubt sind, wird von sogenannten OWL-Profilengesprochen. Die standardisierten und bekanntesten sind OWL EL, OWL RL und OWL QL. Die Wahl des Profils hat Einfluss auf die rechnerische Komplexität typischer Aufgaben. Das vollständige Set an OWL-Konstruktionen, das entspricht , wird als OWL DL bezeichnet. Man spricht manchmal auch von OWL Full, bei dem die Konstruktionen von OWL mit der vollständigen Freiheit von RDF verwendet werden dürfen, ohne semantische und rechnerische Einschränkungen. Zum Beispiel kann etwas sowohl eine Klasse als auch eine Eigenschaft sein. OWL Full ist nicht entscheidbar.

Die Schlüsselprinzipien zur Ableitung von Folgerungen in OWL sind die Annahme der offenen Weltenprämisse (open world assumption, OWA) und der Verzicht auf die Annahme der einzigartigen Benennung (unique name assumption, UNA). Unten werden wir sehen, wozu diese Prinzipien führen können, und einige OWL-Konstruktionen kennenlernen.

Angenommen, die Ontologie enthält folgendes Fragment (im Manchester-Syntax):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human
   Facts: hasChild Alice, hasChild Bob, hasChild Carol

Folgt aus dem Gesagten, dass John viele Kinder hat? Der Verzicht auf UNA wird dazu führen, dass der Schlussfolgerungs-Engine diese Frage negativ beantwortet, denn Alice und Bob könnten durchaus die gleiche Person sein. Damit die Schlussfolgerung gültig ist, müsste such eine Axiom hinzugefügt werden:

DifferentIndividuals: Alice, Bob, Carol, John

Nehmen wir nun an, das Fragment der Ontologie sieht wie folgt aus (John wird als viele Kinder habend erklärt, aber es sind nur zwei Kinder angegeben):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human, manyChildren
   Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, John

Wird diese Ontologie widersprüchlich sein (was als Hinweis auf die Ungültigkeit der Daten interpretiert werden kann)? Die Akzeptanz von OWA wird den Schlussfolgerungs-Engine veranlassen, mit Nein zu antworten: „Irgendwo“ könnte in einer anderen Ontologie gesagt werden, dass Carol ebenfalls Johns Kind ist.

Um diese Möglichkeit auszuschließen, fügen wir eine neue Tatsache über John hinzu:

Individual: John
   Facts: hasChild Alice, hasChild Bob, not hasChild Carol

Um das Auftreten anderer Kinder auszuschließen, nehmen wir an, dass alle Werte der Eigenschaft „hat Kind“ Personen sind, von denen es insgesamt nur vier gibt:

ObjectProperty: hasChild
   Domain: Human
   Characteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }

Nun wird die Ontologie widersprüchlich, was der Schlussfolgerungs-Engine nicht entgehen wird. Mit dem letzten Axiom haben wir gewissermaßen die Welt „geschlossen“, und beachten Sie, wie ausgeschlossen wird, dass John sein eigener Elternteil ist.

Verknüpfung von Unternehmensdaten

Der Ansatz und die Technologie von Linked Data wurden ursprünglich für die Veröffentlichung von Daten im Web entwickelt. Ihre Anwendung in einer Unternehmensumgebung steht vor mehreren Herausforderungen.

In einer geschlossenen Unternehmensumgebung erweist sich die deduktive Kraft von OWL, die auf der Annahme von OWA und dem Verzicht auf UNA basiert, als zu schwach – Entscheidungen, die durch die offene und verteilte Natur des Webs bedingt sind. Hier sind einige Auswege möglich.

• Die Verleihung von Semantik an OWL, die den Verzicht auf OWA und die Annahme von UNA umfasst, die Umsetzung der entsprechenden Schlussfolgerungs-Engine. – Auf diesem Weg schreitet voran RDF-Datenbank Stardog.
• Verzicht auf die deduktiven Möglichkeiten von OWL zugunsten von Regel-Engines. — Stardog unterstützt SWRL; Jena und GraphDB bieten eigene Regulierungssprachen. Verzicht auf die deduktiven Möglichkeiten von OWL, Verwendung zur Modellierung eines bestimmten Unterbereichs, der RDFS nahekommt. — Siehe dazu weiter.
• Ein weiteres Problem ist die größere Aufmerksamkeit, die im Unternehmensumfeld möglicherweise den Problemen der Datenqualität gewidmet werden kann, sowie das Fehlen von Validierungswerkzeugen im Linked Data-Stack. Die Ansätze hier sind die folgenden.

Wiederum die Verwendung zur Validierung von OWL-Konstruktionen mit Semantik der geschlossenen Welt und der Einzigartigkeit von Namen, wenn ein entsprechender Schlussschluss-Engine vorhanden ist.

• SHACL
• Verwendung , das bereits standardisiert wurde, nachdem die Schichten des Semantic Web Layer Cake festgelegt wurden (kann jedoch auch als Regel-Engine verwendet werden), oderShEx Das Bewusstsein, dass letztendlich alles mit SPARQL-Abfragen durchgeführt wird, und die Schaffung eines eigenen einfachen Validierungsmechanismus unter Verwendung dieser..
• Dennoch lässt selbst der vollständige Verzicht auf deduktive Möglichkeiten und Validierungswerkzeuge den Linked Data-Stack konkurrenzlos in Herausforderungen, die landschaftlich dem offenen und verteilten Web ähneln — bei Datenintegrationsproblemen.

Wie steht es um ein typisches Unternehmensinformationssystem?

Das ist möglich, aber man muss sich natürlich bewusst sein, welche Probleme die entsprechenden Technologien lösen müssen. Hier werde ich die typische Reaktion der Entwickler-Hauptdarsteller beschreiben, um zu zeigen, wie dieser Technologie-Stack aus der Sicht der konventionellen IT aussieht. Es erinnert ein wenig an die Fabel vom Elefanten:

Business Analyst

• : RDF ist etwas wie ein direkt gespeichertes logisches Modell.Systemanalytiker
• : RDF ist wie, nur mit einer Menge Indizes und einer benutzerfreundlichen Abfragesprache. EAV: nun, das ist alles im Sinne von Konzepten wie Rich Model und Low Code,
• Entwicklerich habe neulich darüber gelesen. Projektleiter : ja, das ist doch
• der Stapel zusammenbrechenDie Praxis zeigt, dass der Stack häufig in Aufgaben verwendet wird, die mit der Verteilung und Heterogenität von Daten verbunden sind, z. B. beim Aufbau von Systemen der Klasse MDM (Master Data Management) oder DWH (Data Warehouse). Solche Aufgaben gibt es in jeder Branche. Was die branchenspezifischen Anwendungen angeht, so sind zurzeit Linked Data-Technologien in den folgenden Branchen am beliebtesten.!

Was die Anwendungen mit branchenspezifischem Charakter betrifft, so sind die Technologien von Linked Data derzeit in den folgenden Branchen am beliebtesten.

Was die branchenspezifischen Anwendungen betrifft, sind zurzeit Linked Data-Technologien in den folgenden Branchen am populärsten.

• biomedizinische Technologien (deren Beliebtheit scheinbar mit der Komplexität des Fachgebiets verbunden ist);

aktuell

In der „Tschotka Kipienia“ fand kürzlich eine von der Assoziation „Nationale Basis medizinischer Kenntnisse“ organisierte Konferenz statt „Vereinigung von Ontologien. Von der Theorie zur praktischen Anwendung».

• Herstellung und Betrieb komplexer Produkte (großer Maschinenbau, Erdöl- und Gasförderung; meistens geht es um den Standard ISO 15926);

aktuell

Hier ist die Ursache ebenfalls die Komplexität des Fachgebiets, wenn man beispielsweise in der Upstream-Phase von der Erdöl- und Gasindustrie spricht, muss das einfache Rechnungswesen über einige CAD-Funktionen verfügen.

Im Jahr 2008 fand die von Chevron organisierte öffentliche Eröffnungs- Konferenz.

ISO 15926 erschien schließlich der Erdöl- und Gasindustrie als zu komplex (und fand kaum mehr Anwendung im Maschinenbau). Nur Statoil (Equinor) hat sich intensiv damit befasst, in Norwegen entstand rund um ihn ein ganzes Ecosystem. Andere versuchen, etwas Eigenes zu schaffen. Zum Beispiel plant, so wird gemunkelt, das russische Ministerium für Energie eine „konzeptionelle ontologische Modellierung des Energiesektors“ zu erstellen, ähnlich wohl dem, was für die Energieerzeugung geschaffen wurde.

• finanzielle Organisationen (sogar XBRL kann als eine Art Hybrid aus SDMX und RDF Data Cube-Ontologie betrachtet werden);

aktuell

LinkedIn hat zu Beginn des Jahres den Autor mit Stellenangeboten von nahezu allen Giganten der Finanzindustrie, die er aus der Serie „Suits“ kennt, aktiv bombardiert: Goldman Sachs, JPMorgan Chase und/oder Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank… Wahrscheinlich suchten alle nach jemanden, den man zur Knowledge Graph Conferenceschicken kann. Viele konnten erfolgreich gefunden werden: Finanzinstitute beschäftigten den ganzen Vormittag des ersten Tages.

Bei HeadHunter fanden sich hingegen nur interessante Stellenberichte bei Sberbank, es ging um ein „EAV-Speicher mit RDF-ähnlichem Datenmodell“.

Wahrscheinlich liegt der Unterschied im Grad der Zuneigung zu den entsprechenden Technologien zwischen heimischen und westlichen Finanzinstitutionen im transnationalen Charakter der letztgenannten Tätigkeit. Offensichtlich erfordert die Integration über Staatsgrenzen hinweg qualitativ andere organisatorische und technische Lösungen.

• Fragen-Antwort-Systeme mit kommerzieller Anwendung (IBM Watson, Apple Siri, Google Knowledge Graph);

aktuell

Übrigens ist Thomas Gruber, der Schöpfer von Siri, der Autor jener Definition der Ontologie (im IT-Sinn) als "Spezifikation der Konzeptualisierung". Meiner Meinung nach ändert die Umstellung der Wörter in dieser Definition ihren Sinn nicht, was möglicherweise darauf hindeutet, dass es diesen dort gar nicht gibt.

• Die Veröffentlichung strukturierter Daten (dies kann mit großer Gewissheit bereits zu Linked Open Data gezählt werden).

aktuell

Große Liebhaber von Linked Data sind die sogenannten GLAM: Galleries, Libraries, Archives und Museums. Hier soll gesagt werden, dass die Library of Congress als Ersatz für MARC21 BIBFRAME, der eine Grundlage für die Zukunft der bibliografischen Beschreibung bietet und selbstverständlich auf RDF basiert.

Oft wird als Beispiel für ein erfolgreiches Projekt im Bereich Linked Open Data Wikidata angeführt – eine Art maschinenlesbare Version von Wikipedia, deren Inhalte, im Gegensatz zu DBPedia, nicht durch den Import aus Infoboxen von Artikeln generiert werden, sondern mehr oder weniger manuell erstellt werden (und später zur Informationsquelle für ebendiese Infoboxen werden).

Wir empfehlen auch zur Einsichtnahme Liste Nutzern des RDF-Speichers Stardog auf der Website von Stardog im Bereich „Customers“.

Wie dem auch sei, im gartnerischen "Hype Cycle for Emerging Technologies" von 2016 wurde „Enterprise Taxonomy and Ontology Management“ in der Mitte des Abstiegs ins Tal der Enttäuschung eingestuft, mit der Perspektive, nicht vor 10 Jahren das „Plateau der Produktivität“ zu erreichen.

Connecting Enterprise Data

Prognosen, Prognosen, Prognosen…

Aus historischem Interesse habe ich die gartnerischen Prognosen verschiedener Jahre zu den uns interessierenden Technologien in der folgenden Tabelle zusammengefasst.

Doch schon im "Hype Cycle…" von 2018 ist ein anderer aufsteigender Trend – Knowledge Graphs – aufgetaucht. Es fand eine Art Reinkarnation statt: Graphdatenbanken, auf die die Aufmerksamkeit der Benutzer und die Kräfte der Entwickler gelenkt wurden, begannen, unter dem Einfluss der Anforderungen der einen und den Gewohnheiten der anderen, Konturen und die Positionierung ihrer Vorgänger-Wettbewerber zu gewinnen.

Fast jede Graphdatenbank erklärt sich nun zur geeigneten Plattform für den Aufbau eines Unternehmens-Wissensgraphen ("linked data" wird manchmal durch "connected data" ersetzt), aber wie gerechtfertigt sind solche Ansprüche?

Graphdatenbanken sind nach wie vor asemantisch, die Daten in einer graphbasierten DBMS sind nach wie vor ein Daten-Silo. String-Identifikatoren anstelle von URI machen die Integration zweier graphbasierter DBMS zu derselben Integrationsaufgabe, während die Integration zweier RDF-Speicher oft einfach auf die Zusammenführung zweier RDF-Grafen hinausläuft. Ein weiterer Aspekt der Asemantik ist die Nichtreflexivität des LPG-Graphmodells, die die Verwaltung von Metadaten unter Verwendung derselben Plattform erschwert.

Schließlich haben graphbasierte DBMS keine Ausgabemotoren und Regelmotoren. Die Ergebnisse solcher Motoren können durch die Komplexität von Abfragen reproduziert werden, aber das ist sogar auch in SQL möglich.

Die führenden RDF-Speicher haben jedoch keine Schwierigkeiten, das LPG-Modell zu unterstützen. Am solidesten ist der Ansatz, der einst in Blazegraph vorgeschlagen wurde: das RDF*-Modell, das RDF und LPG kombiniert.

Weitere Informationen

Mehr über die Unterstützung von LPG durch RDF-Speicher kann in dem vorherigen Artikel auf Habr gelesen werden: „Was passiert gerade mit RDF-Speichern“. Über Knowledge Graphs und Data Fabric wird hoffentlich eines Tages ein separater Artikel geschrieben. Der abschließende Abschnitt, wie man leicht verstehen kann, wurde hastig hinzugefügt, jedoch sind diese Konzepte auch nach einem halben Jahr nicht viel klarer.

Literatur

1. Halpin, H., Monnin, A. (Hrsg.) (2014). Philosophical Engineering: Toward a Philosophy of the Web
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2. Aufl.)
3. Staab, S., Studer, R. (Hrsg.) (2009) Handbook on Ontologies (2. Aufl.)
4. Wood, D. (Hrsg.). (2011) Linking Enterprise Data
5. Keet, M. (2018) An Introduction to Ontology Engineering

Quelle: habr.com