Systemarchitektur

Technik

  • Webserver (nginx)
  • Property-Graph Datenbanksystem (Neo4J)
  • Triple-Store (Fuseki)
  • Skripte in Python und NodeJS
  • Docker

Workflow

Der gesamte Prozess zur Integration von Daten in den Knowledge Graphen beinhaltet besteht aus folgenden Schritten:

  1. Annahme, Prüfung und Bereinigung

  2. Konvertierung

  3. Einspielung

    Implementierung siehe https://github.com/nfdi4objects/n4o-property-graph

  4. Anreicherung

  5. Bereitstellung

    Noch nicht umgesett

Etwas genauer lässt sich der Prozess etwa wie in Abbildung 9.1 dargestellt veranschaulichen.

flowchart LR
    APIs["<b>APIs</b><br/><i>repo: n4o-graph-apis</i><br/><i>status: ready</i>"]
    LIDO["<b>LIDO</b>"]
    LIDOConverter["<b>LIDOConverter</b><br/><i>tool: X3ML</i><br/><i>repo: ?</i><br/><i>status: prototype</i>"]
    Property_Graph["<b>Property_Graph</b><br/><i>status: prototype</i>"]
    RDF["<b>RDF</b>"]
    RDFConverter["<b>RDFConverter</b><br/><i>status: planned</i><br/><i>repo: ?</i>"]
    Terminologies["<b>Terminologies</b><br/><i>repo: n4o-terminologies</i><br/><i>status: prototype</i>"]
    TerminologyConverter["<b>TerminologyConverter</b><br/><i>status: planned</i><br/><i>repo: ?</i>"]
    Triple_Store["<b>Triple_Store</b><br/><i>status: prototype</i>"]
    sources["<b>sources</b><br/><i>repo: n4o-databases</i><br/><i>status: prototype</i>"]
    sources -- "<u>pgraph</u>" --> Property_Graph
    sources --> Triple_Store
    sources --> LIDO
    sources --> RDF
    LIDO -- "<u>n4o-import</u>" --> LIDOConverter
    LIDOConverter -- "<u>pgraph</u>" --> Property_Graph
    RDF -- "<u>n4o-import</u>" --> RDFConverter
    RDFConverter -- "<u>load-rdf</u>" --> Triple_Store
    RDFConverter -- "<u>pgraph</u>" --> Property_Graph
    Property_Graph -- "<u>enrich</u>" --> Property_Graph
    LIDOConverter --> RDFConverter
    Property_Graph -- "<u>Cypher</u>" --> APIs
    Triple_Store -- "<u>SPARQL</u>" --> APIs
    Terminologies --> TerminologyConverter
    TerminologyConverter -- "<u>load-rdf</u>" --> Triple_Store
    TerminologyConverter -- "<u>pgraph</u>" --> Property_Graph
Abbildung 9.1: Datenfluss

Annahme

Zur Datenannahme, Prüfung und Bereinigung siehe https://github.com/nfdi4objects/n4o-import.

Dort findet sich unter anderem das offizielle XML-Schema für LIDO-Daten.

Konvertierung

LIDO

LIDO-XML-Daten werden mit Hilfe von X3ML ins Property Graph Format konvertiert.

RDF

Zur Konvertierung von RDF-Daten ins Property Graph Format dient das Skript rdf2cypher.py (wird derzeit überarbeitet), das eine Cypher-Datei (in Zukunkft CYPHERL und/oder PG-JSONL) ausgibt.

Einspielung

RDF-Daten in den Property-Graph

Zum Einspielen der Cypher-Datei in eine Neo4J-Datenbank kann das Kommando cypher-shell verwendet werden, das im Neo4J-Docker-Container enthalten ist oder separat installiert werden kann.

Da Neo4J aus dem Docker-Container nicht auf die Cypher-Datei zugreifen kann, muss ihr Inhalt per Pipe eingelesen werden:

<file.cypher | docker exec -t neo4j \
  cypher-shell -a <ADDRESS> -u <USERNAME> -p <PASSWORD>

Ein neuer Docker Container kann mit diesem Kommando erstellt werden. Ein Ordner für Volume muss bereits existieren.

docker run -d \
    --name=neo4j \
    --publish=7474:7474 --publish=7687:7687 \
    --env NEO4J_AUTH=none \
    --user $(id -u):$(id -g) \
    --volume=$cwd/data:/data \
    neo4j

RDF-Daten

Siehe https://github.com/nfdi4objects/n4o-import

Anreicherung

Expansion der Klassenhierarchie

Da Property-Graphen im Gegensatz zu RDF keine Inferenz-Regeln beinhalten und weil Inferenz-Regeln sowieso umständlich sind, werden die Daten im Property-Graphen expandiert. Grundlage ist ein eigener Property-Graph mit der Klassenhierarchie des CIDOC-CRM Datenmodell samt zwischenzeitlich umbenannter oder veralteter Klassen in der Datei crm-classes.pg (siehe SVG-Diagram). Der Graph aller Klassen enthält Informationen darüber welche Klassen sich aus einer anderen ergeben, z.B.

  • E22_Man_Made_Object => E22_Human_Made_Object (renamedTo)
  • E50_Date => E41_Appellation (replacedBy)
  • E7_Activity=> E5_Event (superClass)

Aus diesen Daten wird die Expansionstabelle crm-expand.txt erzeugt, z.B.:

  • E22_Human_Made_Object => E22, E71, E70, E24 E77 und E1

Zum Ausführen der Expansion:

./pg-expand-labels.py [Neo4j login file] < crm-expand.txt

Ohne Konfigurationsdatei für Neo4J werden Cypher-Kommandos ausgegeben. Mit Konfiguration wird die Expansion in der betreffenden Neo4J-Datenbank ausgeführt.

Nach der Expansion ist die Abfrage nach allen Knoten mit einem bestimmten Label wie z.B. E22_Human_Made_Object möglich oder nach allen Knoten, die direkt oder indirekt er Klasse E22 angehören.

Die Expansion ist auf gleiche Weise für andere Ontologien möglich, sofern diese auf CRM gemappt wurden.