Semantic Web und Linked Data. Korrekturen und Ergänzungen

Ich möchte der Öffentlichkeit einen Auszug aus diesem kürzlich veröffentlichten Buch vorstellen:

Ontologische Modellierung von Unternehmen: Methoden und Technologien [Text]: Monografie / [S. V. Gorschkov, S. S. Kralin, O. I. Mushtak u. a.; verantwortlicher Redakteur S. V. Gorschkov]. — Jekaterinburg: Verlag der Ural-Universität, 2019. — 234 S.: ill., Tab.; 20 cm. — Die Autoren sind auf der Rückseite des Titelblatts angegeben. — Bibliografie am Ende des Kapitels. — ISBN 978-5-7996-2580-1: 200 Ex.

Die Ziele dieser Veröffentlichung auf Habr sind vielfältig:

• Wahrscheinlich wird niemand in der Lage sein, dieses Buch in die Hände zu bekommen, es sei denn, er ist Kunde des geschätzten SergeIndex; im Handel ist es definitiv nicht erhältlich.
• Der Text wurde überarbeitet (die Änderungen sind nicht hervorgehoben) und es wurden Ergänzungen vorgenommen, die nicht besonders mit dem Format einer Druckmonografie vereinbar sind: aktuelle Anmerkungen (in Spoilern) und Hyperlinks.
• Ich möchte Fragen und Anmerkungen sammeln, um diese bei der Überarbeitung dieses Textes für mögliche andere Veröffentlichungen zu berücksichtigen.
• Viele Anhänger des Semantic Web und von Linked Data glauben nach wie vor, dass ihr Kreis so klein ist, weil der breiten Öffentlichkeit bisher nicht ausreichend erklärt wurde, wie großartig es ist, ein Anhänger des Semantic Web und von Linked Data zu sein. Der Autor dieses Abschnitts, obwohl er zu diesem Kreis gehört, teilt diese Meinung nicht. Dennoch fühlt er sich verpflichtet, einen weiteren Versuch zu unternehmen.

Also,

Semantic Web

Die Evolution des Internets lässt sich wie folgt darstellen (oder man kann von seinen Segmenten sprechen, die in der unten angegebenen Reihenfolge entstanden sind):

1. Dokumente im Internet. Schlüsseltechnologien – Gopher, FTP usw.
   Das Internet ist ein globales Netzwerk zum Austausch lokaler Ressourcen.
2. Internet der Dokumente. Schlüsseltechnologien – HTML und HTTP.
   Die Art der bereitgestellten Ressourcen berücksichtigt die Besonderheiten des Übertragungsmediums.
3. Daten im Internet. Schlüsseltechnologien – REST und SOAP API, XHR usw.
   Die Ära der Internet-Anwendungen, bei denen nicht nur Menschen Ressourcen konsumieren.
4. Internet der Daten. Schlüsseltechnologien – Linked Data-Technologien.
   Die vierte Phase, die von Tim Berners-Lee, dem Schöpfer der Schlüsseltechnologien der zweiten Phase und Direktor des W3C, vorhergesagt wurde, wird als Semantic Web bezeichnet; die Linked Data-Technologien sollen die Daten im Web nicht nur maschinenlesbar, sondern auch "maschinenverständlich" machen.

Im Folgenden wird dem Leser die Übereinstimmung der Schlüsselbegriffe der zweiten und vierten Phase deutlich:

• Die Entsprechungen von URLs sind URIs,
• das Pendant zu HTML ist RDF,
• Ähnlichkeiten zwischen HTML-Hyperlinks und URI-Einträgen in RDF-Dokumenten bestehen.

Das Semantic Web ist eher eine systematische Vision der Zukunft des Internets als ein konkreter unkontrollierter oder lobbyierter Trend, obwohl es auch diese Letzteren berücksichtigen kann. Ein wichtiges Merkmal des, was als Web 2.0 bezeichnet wird, ist der „von Nutzern erzeugte Inhalt“. Dies wird insbesondere durch die W3C-Empfehlung „Web Annotation Ontology“ und Initiativen wie Solid.

Ist das Semantic Web tot?

Wenn man von unrealistischen Erwartungen absieht,ist die Situation mit dem Semantic Web ähnlich der des Kommunismus zur Zeit des entwickelten Sozialismus (ob die Treue zu den hypothetischen Lehren Lenins tatsächlich gewahrt bleibt, muss jeder für sich selbst entscheiden). Suchmaschinen sind ziemlich erfolgreich Webseiten sind gezwungen, RDFa und JSON-LD zu verwenden, und setzen selbst Technologien ein, die mit den nachfolgend beschriebenen verwandt sind (Google Knowledge Graph, Bing Knowledge Graph).

Im Großen und Ganzen kann der Autor nicht sagen, was einer breiteren Verbreitung entgegensteht, kann jedoch auf der Grundlage persönlicher Erfahrungen sprechen. Es gibt Aufgaben, die unter SW-Bedingungen 'out of the box' gelöst werden könnten, obwohl sie nicht sehr verbreitet sind. Folglich haben diejenigen, die mit diesen Aufgaben konfrontiert sind, keine Mittel, um Druck auf diejenigen auszuüben, die in der Lage sind, Lösungen zu bieten; die eigenständige Bereitstellung dieser Lösungen widerspricht den Geschäftsmodellen dieser letzteren. Daher setzen wir weiterhin HTML in Parsing um und kombinieren verschiedene APIs, was das eine schlechter als das andere macht.

Die Technologien der verlinkten Daten haben jedoch auch über das Massennetz hinaus Verbreitung gefunden; diesen Anwendungen ist das Buch gewidmet. Derzeit erwartet die Linked Data-Community, dass diese Technologien dank der Feststellung (oder Verkündung, wie auch immer man es nennt) von Gartner über solche Trends wie Knowledge Graphs und Data Fabric. Es bleibt zu hoffen, dass nicht die „Bicycle“-Umsetzungen dieser Konzepte Erfolg haben werden, sondern solche, die sich auf die im Folgenden betrachteten W3C-Standards beziehen.

Linked Data

Berners-Lee definierte Linked Data als das „richtig umgesetzte“ semantische Web: Eine Kombination aus Ansätzen und Technologien, die es ermöglicht, die letztendlichen Ziele zu erreichen. Die Grundprinzipien von Linked Data, die Berners-Lee hervorhob sind die folgenden.

Prinzip 1. Verwendung von URIs zur Benennung von Entitäten.

URIs sind globale Identifikatoren für Entitäten im Gegensatz zu lokalen Zeichenfolgenidentifikatoren von Datensätzen. Später fand dieser Grundsatz seinen besten Ausdruck im Slogan des Google Knowledge Graph „Dinge, nicht Zeichenfolgen».

Prinzip 2. Verwendung von URIs im HTTP-Schema, damit sie dereferenziert werden können.

Durch den Zugriff auf URIs sollte es möglich sein, das Bedeutete zu erhalten, das dem Zeichen zugrunde liegt (hier ist die Analogie zum Namen des „*Operators“ in C klar); genauer gesagt, eine bestimmte Darstellung dieses Bedeuteten zu erhalten — abhängig vom Wert des HTTP-Headers Accept:. Möglicherweise wird man mit dem Aufkommen der AR/VR-Ära an den tatsächlichen Zugriff auf die Ressource gelangen, doch bislang wird es wahrscheinlich ein RDF-Dokument sein, das aus der Ausführung einer SPARQL-Abfrage resultiert. BESCHREIBEN.

Prinzip 3. Die Nutzung von W3C-Standards, insbesondere RDF(S) und SPARQL, ist notwendig, wenn es um das Dereferenzieren von URIs geht.

Diese einzelnen „Schichten“ des Linked Data-Technologiestacks, auch bekannt als Semantic Web Layer Cake, werden wir im Folgenden beschreiben.

Prinzip 4. Bei der Beschreibung von Entitäten sollten Links zu anderen URIs verwendet werden.

RDF erlaubt es, Ressourcen nur mit einer verbalen Beschreibung in natürlicher Sprache zu kennzeichnen. Das vierte Prinzip fordert jedoch auf, dies zu vermeiden. Wenn das erste Prinzip von allen beachtet wird, besteht die Möglichkeit, andere, auch „fremde“ Ressourcen bei der Beschreibung zu referenzieren, weshalb die Daten als verbunden gelten. Tatsächlich ist die Verwendung von URIs, die im RDFS-Wörterbuch benannt sind, nahezu unvermeidlich.

RDF

RDF (Resource Description Framework) – ein Formalismus zur Beschreibung von miteinander verknüpften Entitäten.

In Bezug auf Entitäten und deren Beziehungen werden Aussagen in der Form "Subjekt-Prädikat-Objekt" getroffen, die als Tripel bezeichnet werden. Im einfachsten Fall sind sowohl Subjekt als auch Prädikat und Objekt URIs. Derselbe URI kann in verschiedenen Tripeln in unterschiedlichen Positionen vorkommen: er kann sowohl Subjekt als auch Prädikat und Objekt sein; damit bilden die Tripel eine Art Graph, der als RDF-Graph bezeichnet wird.

Subjekte und Objekte können nicht nur URIs sein, sondern auch sogenannte leere Knoten, während Objekte zudem auch Literalesein können. Literale sind Instanzen primitiver Typen, die aus einer String-Darstellung und einem Typ-Hinweis bestehen.

Beispiele für die Darstellung von Literalen (im Turtle-Syntax, dazu später mehr): "5.0"^^xsd:float und "five"^^xsd:string. Literale mit dem Typ rdf:langString können zudem mit einem Sprach-Tag versehen werden, was in Turtle so dargestellt wird: "five"@en und "пять"@ru.

Leere Knoten sind "anonyme" Ressourcen ohne globale Identifikatoren, über die jedoch Aussagen getroffen werden können; eine Art existenzialer Variablen.

Also (das ist eigentlich die gesamte Essenz von RDF):

• Ein Subjekt ist ein URI oder ein leerer Knoten,
• ein Prädikat ist ein URI,
• ein Objekt ist ein URI, ein leerer Knoten oder ein Literal.

Warum können Prädikate keine leeren Knoten sein?

Ein möglicher Grund ist der Wunsch, Dreiergruppen informell zu verstehen und in die Sprache der Prädikatenlogik erster Ordnung zu übersetzen. s p o als etwas Ähnliches , wobei — Prädikat, und — Konstanten. Spuren dieses Verständnisses finden sich im Dokument „LBase: Semantics for Languages of the Semantic Web“, das den Status einer Arbeitsgruppennotiz des W3C hat. Bei diesem Verständnis wird die Dreiergruppe s p [], wobei [] — leere Knoten, als , wobei — Variable übersetzt. Aber wie soll dann s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semantics“ schlägt eine andere Übersetzungsmethode vor, betrachtet jedoch die Möglichkeit, dass Prädikate leere Knoten sind, nicht.

Übrigens, Manu Sporni erlaubte.

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

Ein und dasselbe RDF kann auf verschiedene Weisen in RDF/XML serialisiert werden. Daher ist es beispielsweise unsinnig, das resultierende XML mit XSD zu validieren oder Daten mit XPath zu extrahieren. Genauso wird man mit JSON-LD wahrscheinlich nicht die Erwartungen eines durchschnittlichen Javascript-Entwicklers erfüllen, wenn es darum geht, mit RDF in Punkt- und eckiger Klammernotation von Javascript zu arbeiten (obwohl JSON-LD in diese Richtung tendiert und einen Mechanismus bietet. Framing).

Die meisten Syntaxe bieten Möglichkeiten, lange URIs abzukürzen. Zum Beispiel ermöglicht die Deklaration @prefix rdf: in Turtle, anstatt <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 einführt sowie Eigenschaften wie rdf:type, rdfs:subClassOf, rdfs:domain und rdfs:range. Mit dem RDFS-Wörterbuch können beispielsweise folgende gültige Ausdrücke formuliert 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 Vokabular zur Beschreibung und Modellierung, jedoch kein Einschränkungsprache (obwohl die offizielle Spezifikation und lässt eine solche Verwendung zu). Das Wort „Schema“ sollte nicht im gleichen Sinne verstanden werden wie im Ausdruck „XML-Schema“. 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 gesagt 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 übereinstimmen. In den Mustern können an den Positionen für Subjekte, Prädikate und Objekte Variablen stehen.

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

Zum Beispiel wird bei dem oben genannten Satz aus sieben RDFS-Axiomen die folgende Abfrage zurückgeben rdfs:domain und rdfs:range als Werte ?s und ?p entsprechend:

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

Es ist zu beachten, dass SPARQL deklarativ ist und keine Sprache zur Beschreibung von Graph Traversierungen darstellt (obwohl einige RDF-Speicher Methoden zur Anpassung des Abfrageplans anbieten). Daher können einige Standard-Graphenprobleme, wie z. B. die Suche nach dem kürzesten Weg, nicht mit SPARQL gelöst werden, auch nicht mit dem Mechanismus Eigenschaftspfade (aber wiederum bieten einige RDF-Speicher spezielle Erweiterungen zur Lösung dieser Probleme an).

SPARQL trennt nicht die Annahme der Offenheit der Welt und folgt einem Ansatz des „negation as failure“; darin sind möglich solche Konstrukte wie FILTER NOT EXISTS {…}. Die Verteilung der Daten wird durch den Mechanismus föderativer Abfragen berücksichtigt..

Der SPARQL-Endpunkt ist ein RDF-Speicher, der in der Lage ist, SPARQL-Abfragen zu verarbeiten – und hat keine direkten Entsprechungen aus der zweiten Phase (siehe Beginn dieses Absatzes). Er kann mit einer Datenbank verglichen werden, auf deren Basis HTML-Seiten generiert wurden, jedoch für externe Zugriffe verfügbar ist. Der SPARQL-Endpunkt ähnelt eher einem API-Endpunkt aus der dritten Phase, weist jedoch zwei Hauptunterschiede auf. Erstens besteht die Möglichkeit, mehrere "atomare" Abfragen zu einer einzigen zusammenzufassen (was als wesentliches Merkmal von GraphQL gilt), und zweitens ist eine solche API vollständig selbstdokumentiert (was HATEOAS zu erreichen versuchte).

Polemisierender Hinweis

RDF ist eine Methode zur Veröffentlichung von Daten im Web, weshalb RDF-Speicher als dokumentenorientierte DBMS betrachtet werden sollten. Allerdings, da RDF ein Graph und kein Baum ist, sind sie gleichzeitig auch graphenbasiert. Es ist erstaunlich, dass sie überhaupt existieren. Wer hätte gedacht, dass es Leute geben würde, die blank nodes implementieren. Bei Codd ist das nicht gelungen..

Es gibt auch weniger funktionsreiche Möglichkeiten, um auf RDF-Daten zuzugreifen, wie zum Beispiel Linked Data Fragments (LDF) und Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) — ein Formalismus zur Wissensdarstellung, eine syntaktische Variante der Deskriptiven Logik (an dieser Stelle wäre es präziser, von OWL 2 zu sprechen, da die erste Version von OWL basierte auf ).

In OWL entsprechen den Konzepten der deskriptiven Logik Klassen, den Rollen — Eigenschaften, die Individuen behalten ihre vorherigen Bezeichnungen. Axiome werden ebenfalls Axiome genannt.

Zum Beispiel wird im sogenannten Manchester-Syntax das uns bereits bekannte Axiom folgendermaßen notiert:

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

Es gibt auch andere Syntaxformen zur Notierung von OWL, wie beispielsweise die funktionale Syntax, die in der offiziellen Spezifikation verwendet wird, und OWL/XML. Darüber hinaus kann OWL in die abstrakte RDF-Syntax und später — in jede der spezifischen Syntaxen serialisiert werden.

OWL hat ein doppeldeutiges Verhältnis zu RDF. Einerseits kann es als eine Art Wörterbuch betrachtet werden, das RDFS erweitert. Andererseits ist es ein leistungsfähigerer Formalismus, für den RDF lediglich ein Serialisierungsformat ist. Nicht alle elementaren Konstrukte von OWL lassen sich durch einen einzigen RDF-Tripel darstellen.

Je nachdem, welches Teilset von OWL-Konstruktionen zulässig ist, spricht man von den sogenannten OWL-Profilen. Die standardisierten und bekanntesten sind OWL EL, OWL RL und OWL QL. Die Wahl des Profils hat Auswirkungen auf die rechnerische Komplexität typischer Aufgaben. Das vollständige Set an OWL-Konstruktionen, das entsprechend , wird als OWL DL bezeichnet. Manchmal spricht man auch von OWL Full, in dem OWL-Konstruktionen mit voller Freiheit verwendet werden dürfen, wie sie in RDF vorkommen, ohne semantische oder rechnerische Einschränkungen . Zum Beispiel kann etwas sowohl eine Klasse als auch eine Eigenschaft sein. OWL Full ist nicht entscheidbar.

Die Schlüsselprinzipien für das Ableiten von Folgerungen in OWL sind die Annahme der offenen Welt (open world assumption, OWA) und die Ablehnung der Annahme der einzigartigen Namen (unique name assumption, UNA). Unten sehen wir, welche Ergebnisse diese Prinzipien hervorbringen können, und lernen einige OWL-Konstruktionen kennen.

Angenommen, die Ontologie enthält den folgenden Abschnitt (im Manchester-Syntax):

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

Wird aus dem Gesagten folgen, dass John viele Kinder hat? Der Verzicht auf UNA zwingt den Schlussfolgerungsmechanismus zu einer negativen Antwort, denn Alice und Bob könnten durchaus dieselbe Person sein. Damit eine solche Beziehung besteht, müsste man eine zusätzliche Axiom hinzufügen:

DifferentIndividuals: Alice, Bob, Carol, John

Lassen Sie uns nun den Ontologieausschnitt folgendermaßen gestalten (John wird als vielfacher Vater deklariert, hat jedoch nur zwei Kinder):

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 Indiz für die Ungültigkeit der Daten interpretiert werden kann)? Die Annahme von OWA führt dazu, dass der Schlussfolgerungsmechanismus negativ antwortet: "Irgendwo" anders (in einer anderen Ontologie) könnte es durchaus 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 weiterer Kinder auszuschließen, sagen wir, dass alle Werte der Eigenschaft „hat ein Kind“ die Personen sind, von denen wir insgesamt vier haben:

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

Jetzt wird die Ontologie widersprüchlich, was der Ausgabemotor nicht versäumen wird, zu melden. Mit dem letzten Axiom haben wir die Welt in gewissem Sinne "geschlossen", und beachten Sie, wie die Möglichkeit ausgeschlossen ist, dass John sein eigener Sohn ist.

Verknüpfung von Unternehmensdaten

Die Sammlung von Ansätzen und Technologien für Linked Data wurde ursprünglich zur Veröffentlichung von Daten im Web entwickelt. Ihre Verwendung in einer unternehmensinternen Umgebung stößt jedoch auf verschiedene Schwierigkeiten.

Zum Beispiel erweist sich in einer geschlossenen Unternehmensumgebung die deduktive Kraft von OWL, die auf der Akzeptanz von OWA und der Ablehnung von UNA basiert – Entscheidungen, die durch die offene und verteilte Natur des Webs bedingt sind – als zu schwach. Hier sind folgende Lösungen möglich.

• Die Ausstattung von OWL mit Semantik, was die Ablehnung von OWA und die Akzeptanz von UNA impliziert, sowie die Implementierung eines entsprechenden Ausgabemotors. - Auf diesem Weg geht das RDF-Speicher von Stardog.
• Die Ablehnung der deduktiven Fähigkeiten von OWL zugunsten von Regel-Engines. - Stardog unterstützt SWRL; Jena und GraphDB bieten eigene Regel Sprachen.
• Die Ablehnung der deduktiven Möglichkeiten von OWL und die Verwendung zur Modellierung eines bestimmten Teilmengen, die RDFS nahe steht. - Siehe dazu im Folgenden.

Ein weiteres Problem ist die deutlich höhere Aufmerksamkeit, die im Unternehmensumfeld auf die Datenqualität gerichtet werden kann, sowie das Fehlen von Validierungswerkzeugen im Linked Data-Stack. Die Auswege sind folgende.

• Erneut wird die Verwendung von OWL-Konstruktionen mit closed-world Semantik und Namens-Eindeutigkeit hervorgehoben, sofern ein entsprechender Inferenz-Engine vorhanden ist.
• Nutzung SHACL, das standardisiert wurde, nachdem die Schichten des Semantic Web Layer Cake festgelegt wurden (es kann jedoch auch als Regel-Engine verwendet werden), oder ShEx.
• Das Bewusstsein, dass letztlich alles durch SPARQL-Abfragen realisiert wird, führt zur Schaffung eines eigenen einfachen Datenvalidierungsmechanismus unter deren Verwendung.

Dennoch lässt selbst ein vollständiger Verzicht auf deduktive Möglichkeiten und Validierungswerkzeuge den Linked Data-Stack in Aufgaben, die aus der Perspektive einer offenen und verteilten Weblandschaft ähnlich sind – insbesondere bei Datenintegrationsaufgaben – konkurrenzlos.

Wie wäre es mit einem typischen Unternehmensinformationssystem?

Es ist möglich, aber man sollte sich natürlich bewusst sein, welche Probleme die entsprechenden Technologien lösen müssen. Ich werde hier die typische Reaktion der Entwickler beschreiben, um zu zeigen, wie dieser Technologiestack aus der Sicht der konventionellen IT aussieht. Es erinnert ein wenig an die Parabel vom Elefanten:

• Business Analyst: RDF ist so etwas wie ein direkt gespeichertes logisches Modell.
• Systemanalytiker: RDF ist wie EAV, nur mit einer Menge von Indizes und einer angenehmen Abfragesprache.
• Der Entwickler: nun, das passt alles in den Geist von Konzepten wie Rich Model und Low Code, ich habe neulich darüber gelesen.
• Der Projektleiter: ja, das ist collapsing the stack!

Die Praxis zeigt, dass der Stack am häufigsten in Aufgaben verwendet wird, die mit der Verteilung und Heterogenität von Daten zu tun haben, beispielsweise beim Aufbau von Systemen der Klasse MDM (Master Data Management) oder DWH (Data Warehouse). Solche Aufgaben gibt es in jeder Branche.

Was spezielle Anwendungen angeht, so sind Technologien des Linked Data derzeit in den folgenden Branchen am beliebtesten.

• biomedizinische Technologien (wo ihre Popularität offenbar mit der Komplexität des Fachgebiets zusammenhängt);

aktuell

Vor kurzem fand in der „Tetka Kipyeniya“ eine von der Vereinigung „Nationale Datenbank 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 Erdgasförderung; häufig geht es um den Standard ISO 15926);

aktuell

Hier ist ebenfalls die Komplexität des Fachgebiets eine Herausforderung, wenn man zum Beispiel im Upstream-Bereich der Erdöl- und Erdgasindustrie spricht, wo eine einfache Buchhaltung einige CAD-Funktionen erfordert.

Im Jahr 2008 fand eine von Chevron organisierte repräsentative Eröffnungsveranstaltung statt Konferenz.

ISO 15926 erwies sich schließlich als etwas zu kompliziert für die Erdöl- und Erdgasindustrie (und fand kaum mehr Anwendung im Maschinenbau). Nur Statoil (Equinor) hat sich intensiv damit beschäftigt, und in Norwegen hat sich um ihn herum ein ganzes Ökosystemgebildet. Andere versuchen, selbst etwas zu entwickeln. Gerüchten zufolge plant das russische Ministerium für Energie, ein „konzeptionelles ontologisches Modell des Energiesektors“ zu erstellen, das offensichtlich dem, das für die Elektroenergieerzeugung geschaffen wurde, ähnlich ist..

• Finanzinstitute (sogar XBRL kann als eine Art Hybrid zwischen SDMX und der RDF Data Cube Ontologie betrachtet werden);

aktuell

LinkedIn hat zu Beginn des Jahres aktiv den Autor mit Stellenangeboten von nahezu allen Giganten der Finanzbranche bombardiert, die er aus der Serie "Billions" kennt: Goldman Sachs, JPMorgan Chase und/oder Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, die Fed, Deutsche Bank… Wahrscheinlich suchten alle jemanden, den sie schicken können nach Knowledge Graph Conference. Viele konnten gefunden werden: Finanzinstitutionen dominierten den gesamten Morgen des ersten Tages.

Auf HeadHunter fanden sich interessante Angebote nur bei der Sberbank, es ging um ein "EAV-Speicher mit einer RDF-ähnlichen Datenmodellierung".

Wahrscheinlich ist das unterschiedliche Maß an Begeisterung für die entsprechenden Technologien bei inländischen und westlichen Finanzinstitutionen auf den transnationalen Charakter der letztgenannten zurückzuführen. Offensichtlich erfordert die Integration über Staatsgrenzen hinweg qualitativ andere organisatorische und technische Lösungen.

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

aktuell

Übrigens ist Thomas Gruber, der Schöpfer von Siri, der Autor der Definition von Ontologie (im IT-Kontext) als "Spezifizierung von Konzeptualisierung". Meiner Meinung nach ändert die Umstellung der Worte in dieser Definition deren Sinn nicht, was möglicherweise darauf hindeutet, dass er dort nicht vorhanden ist.

• Die Veröffentlichung von strukturierten Daten (mit großem Grund kann dies bereits zu Linked Open Data gezählt werden).

aktuell

Die großen Anhänger von Linked Data sind die sogenannten GLAM: Galerien, Bibliotheken, Archive und Museen. Hier sei nur erwähnt, dass die Library of Congress anstelle von MARC21 BIBFRAME, der eine Grundlage für die Zukunft der bibliografischen Beschreibung bietet und natürlich auf RDF basiert.

Oft wird als Beispiel für ein erfolgreiches Projekt im Bereich Linked Open Data Wikidata genannt - eine Art maschinenlesbare Version der Wikipedia, deren Inhalte im Gegensatz zu DBPedia nicht durch den Import von Infoboxen aus Artikeln generiert werden, sondern mehr oder weniger manuell erstellt werden (und anschließend als Informationsquelle für dieselben Infoboxen dienen).

Wir empfehlen auch zur Einsichtnahme eine Liste die Benutzer des RDF-Speichers Stardog auf der Website von Stardog im Bereich "Customers".

Wie dem auch sei, im Gartner'schen "Hype Cycle for Emerging Technologies" aus dem Jahr 2016 Das «Enterprise Taxonomy and Ontology Management» befindet sich in der Mitte des Abwärtskurses der Enttäuschung, mit der Aussicht, nicht vor zehn Jahren auf das «Produktivitätsplateau» zu gelangen.

Verknüpfung unternehmensweiter Daten

Prognosen, Prognosen, Prognosen…

Aus historischem Interesse habe ich die Gartner-Prognosen aus verschiedenen Jahren zu den für uns relevanten Technologien in der folgenden Tabelle zusammengefasst.

Jedoch gab es bereits in dem «Hype Cycle…» von 2018 einen neuen aufkommenden Trend: Knowledge Graphs. Es fand eine Art Reinkarnation statt: Graphdatenbanken, auf die das Interesse von Nutzern und die Motivation von Entwicklern gelenkt wurde, begannen aufgrund der Anforderungen der ersten und der Gewohnheiten der letzten, Konturen und Positionierung ihrer früheren Konkurrenten zu gewinnen.

Fast jede Graphdatenbank erklärt sich mittlerweile zur geeigneten Plattform für den Aufbau eines Unternehmenswissensgraphen («linked data» wird manchmal durch «connected data» ersetzt), doch wie gerechtfertigt sind solche Ansprüche wirklich?

Graphdatenbanken bleiben weiterhin semantisch unspezifisch; die Daten in einer Graphdatenbank sind nach wie vor ein datensilo. String-IDs anstelle von URIs machen die Integration zweier Graphdatenbanken zu einer Herausforderung, während die Integration zweier RDF-Speicher oft lediglich auf das Zusammenführen zweier RDF-Grafen hinausläuft. Ein weiterer Aspekt der Semantiklosigkeit ist die Nichtreflexivität des LPG-Modells, was das Management von Metadaten auf derselben Plattform erschwert.

Zudem verfügen Graphdatenbanken über keine Inferenzmotoren oder Regel-Engines. Die Ergebnisse dieser Engines können durch kompliziertere Abfragen nachgebildet werden, was jedoch auch in SQL möglich ist.

Dennoch haben führende RDF-Speicher keine Probleme damit, das LPG-Modell zu unterstützen. Der als solideste geltende Ansatz stammt ursprünglich von Blazegraph: das RDF*-Modell, das RDF und LPG verbindet.

Mehr erfahren

Mehr über die Unterstützung des LPG-Modells durch RDF-Speicher können Sie in dem vorherigen Artikel auf Habr lesen: „Was passiert gerade mit RDF-Speichern“Ich hoffe, dass irgendwann ein eigener Artikel über Knowledge Graphs und Data Fabric geschrieben wird. Der abschließende Abschnitt, wie leicht zu verstehen ist, wurde in Eile verfasst, und nach einem halben Jahr mit diesen Konzepten ist es 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