First complete draft

Makefile

@@ -1,4 +1,4 @@
 .PHONY: html
 
 html:
-	quarto render && rm -f docs/*.ipynb
+	quarto render

_quarto.yml

@@ -5,4 +5,6 @@ project:
     - "!*.md"
 manuscript:
   article: index.qmd
-
+format:
+  html: default
+  docx: default

docs/index.qmd

@@ -7,21 +7,19 @@ authors:
 bibliography: references.bib
 ---
 
-*VORLÄUFIGER ARTIKEL-ENTWURF*
-
 Zu den Tätigkeiten der Stabstelle Forschung und Entwicklung der VZG gehört auch
 das Ausprobieren und Evaluieren neuer Verfahren und Techniken. So kommt es dass
 ich mich seit Anfang 2024, angeregt durch einen Anwendungsfall im Projekt
-NFDI4Objects, verstärkt mit so genannten **Property-Graphen** zur
-Strukturierung und Verarbeitung von (Meta)daten beschäftige. 
+NFDI4Objects, verstärkt mit so genannten Property-Graphen zur Strukturierung
+und Verarbeitung von (Meta)daten beschäftige. 
 
-Property-Graphen (oft auch als Labeled Property Graphen bezeichnet) bilden ein
-Datenbankmodell, das unter die so genannten NoSQL-Datenbanken und noch
-spezieller unter die Graphdatenbanken fällt. Hierbei werden Daten nicht wie bei
-SQL in Form von Tabellen sondern in Form von Graphen aus Knoten gespeichert,
-die durch Kanten miteinander verbunden sind. Eine Besonderheit von
-Property-Graphen ist, dass sowohl Knoten als auch Kanten jeweils ein oder
-mehrere Labels haben und mit Eigenschaften versehen werden können.
+Property-Graphen (oft auch *Labeled Property Graphen*) fallen als
+Datenbankmodell unter die so genannten NoSQL-Datenbanken und noch spezieller
+unter die Graphdatenbanken. Hierbei werden Daten nicht wie bei SQL in Form von
+Tabellen sondern in Form von Graphen aus *Knoten* gespeichert, die durch
+*Kanten* miteinander verbunden sind. Eine Besonderheit von Property-Graphen
+ist, dass sowohl Knoten als auch Kanten jeweils ein oder mehrere *Labels* haben
+und mit *Eigenschaften* versehen werden können.
 
 ## Beispiel
 
@@ -54,15 +52,13 @@ flowchart LR
    Luke -- "<i>owns</i><br><tt>episode:4</tt>" --> R2D2
 ```
 
-Mit Knoten, gerichteten und ungerichteten Kanten, Labels und Eigenschaften sind
-schon alle Elemente von Property-Graphen aufgezählt. Zur Kodierung dieser
-Graphen gibt es allerdings viele verschiedene Datenormate und Datenbanksysteme, die
-sich in Details wie den erlaubten Zeichen in Identifiern, der
-Wiederholbarkeit von Labels und Eigenschaften und in den möglichen Datentypen
+Zur Kodierung von Property-Graphen gibt es verschiedene Datenformate und
+Datenbanksysteme, die sich in Details wie den erlaubten Zeichen in Identifiern,
+der Wiederholbarkeit von Labels und Eigenschaften und in möglichen Datentypen
 von Eigenschaftswerten (im Beispiel Zeichenkette für die Eigenschaft `gender`
 und Zahl für die Eigenschaft `episode`) unterscheiden. Im Folgenden werden zwei
-mögliche Kodierungen für Property-Graphen vorgestellt und anschließend auf
-Gemeinsamkeiten und Unterschiede zum RDF-Format eingegangen.
+mögliche Kodierungen vorgestellt und Gemeinsamkeiten und Unterschiede zum
+RDF-Format erklärt.
 
 
 ## Property-Graph-Datenbanken
@@ -77,18 +73,16 @@ Gemeinsamkeiten und Unterschiede zum RDF-Format eingegangen.
 Etabliert wurden Property-Graphen insbesondere durch das
 Datenbankmanagementsystem (DBMS) [Neo4J]. Die Open-Source-Software war lange
 Marktführer in diesem Bereich und setze dort Standards wie die Abfragesprache
-**Cypher** (siehe @lst-cypher und @lst-match), die inzwischen auch von anderen
+*Cypher* (siehe @lst-cypher und @lst-match), die inzwischen auch von anderen
 Systemen unterstützt wird. Dazu zählen derzeit die Open-Source-DBMS [Kùzu],
-[Memgraph] und [FalkorDB], so dass wie bei Relationalen DBMS (RDBMS) die Gefahr
-für [Vendor Lock-In] gering ist. Im letzten Update des SQL-Standard (SQL:2023)
-wurde zumdem unter dem Namen SQL/PGQ eine Teilmenge von Cypher als
-Abfragesprache für Property-Graphen in SQL-Datenbanken definiert. Es ist also
-davon auszugehen, dass in Zukunft weitere DBMS Property-Graphen und Cypher
-unterstützen.
+[Memgraph] und [FalkorDB]. Im letzten Update des SQL-Standard (SQL:2023) wurde
+zumdem unter dem Namen SQL/PGQ eine Erweiterung für Property-Graphen in
+SQL-Datenbanken definiert. Es ist also davon auszugehen, dass in Zukunft
+weitere DBMS Property-Graphen unterstützen.
 
 Der Beispielgraph kann in Neo4J oder in einer damit kompatiblen Datenbank mit
-folgenden Cypher-Statements angelegt werden (@lst-cypher). Da Knoten-Identifier
-in der Datenbank rein intern sind, sind die Namen zusätzlich als Eigenschaft
+den Cypher-Statements in @lst-cypher angelegt werden. Da Knoten-Identifier in
+der Datenbank rein intern sind, sind die Namen zusätzlich als Eigenschaft
 `name` angegeben. Außerdem unterstützt Cypher nur gerichtete Kanten, daher ist
 die Beziehung zwischen Padmé und Anakin weggelassen.
 
@@ -119,19 +113,18 @@ sein wie die Datenbasis: so würde eine Frage nach den Kindern von Anakin nur
 Luke ergeben, weil seine Zwillingsschwester Leia im Beispiel-Graph fehlt.
 Grundsätzlich stellt die Modellierung von Property-Graphen aber ein
 leistungsfähiges und flexibels Werkzeug vor allem für semi-strukturierte und
-verknüpfte Daten da. Im Projekt NFDI4Objects haben wir uns deshalb dazu
-entschieden die Zusammenführung heterogener Daten aus verschiedenene Quellen in
-einem Property-Graphen durchzuführen.
+verknüpfte Daten da.
 
 
 ## Property Graph Exchange Format
 
 Während die Standardisierung der Datenbanksprache Cypher relativ weit
 fortgeschritten ist, gibt es noch kein etabliertes Dateiformat zum Austausch
 von Property-Graphen. Zusammen mit den Wissenschaftlern Hirokazu Chiba, Ryota
-Yamanaka und Shota Matsumoto entwickele ich deshalb das Property Graph Exchange
-Format [@pgspec]. @lst-pg zeigt die Kodierung des vollständigen
-Beispiel-Graphen im **PG-Format**.
+Yamanaka und Shota Matsumoto entwickele ich deshalb das *Property Graph
+Exchange Format* [@pgspec]. @lst-pg zeigt die Kodierung des vollständigen
+Beispiel-Graphen im PG-Format. Die Standardisierung beinhaltet äquivalente
+Kodierungen in JSON (PG-JSON und PG-JSONL). 
 
 ```{#lst-pg .pg lst-cap="Beispiel-Graph im PG Format"}
 # Knoten mit Knoten-Typ (Label) und Eigenschaften
@@ -149,8 +142,7 @@ Padmé  -> Luke   :child     episode:3
 Luke   -> R2D2   :owns      episode:4
 ```
 
-Die Standardisierung beinhaltet äquivalente Kodierungen in JSON (PG-JSON und
-PG-JSONL) und wird durch die Implementierung der Programmbibliothek
+und wird durch die Implementierung der Programmbibliothek
 [pgraphs](https://www.npmjs.com/package/pgraphs) zur Konvertierung zwischen
 verschiedenen Graph-Formaten und Datenbanksystemen begleitet. So wurde der
 Beispielgraph in Neo4J in @lst-cypher automatisch mit dem Aufruf 
@@ -159,31 +151,30 @@ Beispielgraph in Neo4J in @lst-cypher automatisch mit dem Aufruf
 
 ## Vergleich mit RDF
 
-Zu den Graphdatenbanken gehören auch die so genannten **Triple-Stores**, in
-denen Daten dem RDF-Datenmodell nach gespeichert werden.  Da RDF und die damit
-verbundenen Konzepte von Linked Data und Semantic bereits seit Jahrzehnten
-propagiert werden, ist die Frage berechtigt, ob nicht mal wieder mit
-Property-Graphen als neuem Trend das Rad neu erfunden wird. Tatsächlich sind
-RDF und Property Graphen aus unterschiedlicher Motivation heraus entstanden und
-haben daher verschiedene Schwerpunkte und Einsatzzwecke.
-
-RDF ist grundsätzlich ein Austauschformat zum Publizieren und Zusammenführen
-von Daten.  Grundstein bilden dabei die übergreifend nutzbaren URIs zur
-weltweit eindeutigen Identifizierung von Konzepten. Bei Property-Graphen geht
-es dagegen primär um die effiziente Speicherung und Auswertung von vernetzen
-Daten in einer abgeschlossenen Datenbank.
-
-Rein formal bestehen Daten auch im RDF-Modell aus Knoten und Kanten, wobei
-Knoten als "Ressourcen" und Kanten als "Triples" bezeichnet werden. Eine
-Entsprechung zu Eigenschaften gibt es in aber RDF nicht, Knoten haben keine
-Knoten-Label und Kanten-Label werden "Properties" genannt. Die Rolle der
-fehlenden Knoten-Label und Knoten-Eigenschaften übernehmen in RDF zusätzliche
-Kanten (die sich allerdings nicht von "normalen" Kanten unterscheiden lassen).
-@lst-ttl zeigt den Beispiel-Graphen in RDF-Turtle-Syntax und @lst-sparql die
-Entsprechung der ersten Cypher-Abfrage aus @lst-match in der RDF-eigenen
-Abfragesprache SPARQL. Obwohl der RDF-Graph (@fig-rdf-image) weniger
-Informationen enthält ist er im Vergleich zu @fig-image etwas unübersichtlicher. 
-
+RDF ist ein alternatives Graph-basiertes Datenmodell, das zusammen mit Konzepte
+wie Linked Data und Semantic seit Jahrzehnten propagiert wird. Rein formal
+bestehen Daten auch im RDF-Modell aus Knoten und Kanten, wobei Knoten als
+"Ressourcen" und Kanten als "Triples" bezeichnet werden. Kanten-Label heißen in
+RDF "Properties", Entsprechungen zu Knoten-Label und Eigenschaften gibt dagegen
+nicht.
+
+Abgesehen von formalen Unterschieden, die sich durch Datenkonvertierung
+weitgehend überbrücken lassen, ist hilfreich die unterschiedliche Motivationen
+zu verstehen, aus denen RDF und Property Graphen jeweils entstanden sind: RDF
+ist grundsätzlich ein Austauschformat zum Publizieren und Zusammenführen von
+Daten.  Grundstein bilden die übergreifend nutzbaren URIs zur weltweit
+eindeutigen Identifizierung von Konzepten. Bei Property-Graphen geht es dagegen
+primär um die effiziente Speicherung und Auswertung von vernetzen Daten in
+einer abgeschlossenen Datenbank.
+
+Zum Vergleich zeigt @lst-ttl den Beispiel-Graphen in RDF-Turtle-Syntax und
+@lst-sparql die Entsprechung der ersten Cypher-Abfrage aus @lst-match in der
+RDF-eigenen Abfragesprache SPARQL. Die Rolle der Knoten-Label und
+Knoten-Eigenschaften übernehmen in RDF zusätzliche Kanten. Kanten-Eigenschaften
+und ungerichteten Kanten sind in diesem Beispiel dagegen weggelassen, weil ihre
+Entsprechung in RDF etwas komplexer zu modellieren ist. Obwohl der RDF-Graph
+(@fig-rdf-image) weniger Informationen enthält, ist er im Vergleich zu
+@fig-image etwas unübersichtlicher. 
 
 ```{#lst-ttl .ttlr lst-cap="Beispiel-Graph in RDF/Turtle (ohne Kanten-Eigenschaften)"}
 <Padmé>  a <person> ; <gender> "female" .
@@ -221,13 +212,11 @@ flowchart LR
    Anakin -- gender --> male
 ```
 
-Unter dem Namen RDF 1.2 (auch RDF-star) wird derzeit eine Erweiterung von
-standardisiert, mit der RDF-Triple mit weiteren Tripeln angereichtert werden
-können, so dass auch eine Ensprechung zu Kanten-Eigenschaften möglich wäre
-(@lst-ttl2). So wäre dann auch die zweite Beispielabfrage in RDF möglich
-(@lst-sparql2). Abgesehen von der noch fehlenden Unterstützung in mehreren
-RDF-Werkzeugen werden die Daten mit dieser Erweiterung allerdings leicht noch
-unübersichtlicher.
+Mit der kommenden Version RDF 1.2 (auch *RDF-star*) können RDF-Triple mit
+weiteren Tripeln angereichtert werden, so dass ine direkte Entsprechung zu
+Kanten-Eigenschaften möglich wäre (siehe @lst-ttl2 und @lst-sparql2). Abgesehen
+von der begrenzten Software-Unterstützung werden Daten mit dieser Erweiterung
+allerdings nicht unbedingt übersichtlicher.
 
 ```{#lst-ttl2 .ttlr lst-cap="Kanten des Beispiel-Graph in RDF/Turtle 1.2"}
 <Padmé>  <owns> <R2D2>   {| <episode> 1 |} .
@@ -246,47 +235,37 @@ SELECT ?p {
 ```
 
 Die wesentlichen Unterschiede von RDF und Property-Graphen sind in @tbl-rdf-pg
-zusammengefasst. Grundsätzlich lässt sich feststellen, dass RDF vor allem für
-die Zusammenführung von Daten aus unterschiedlichen Quellen sinnvoll ist.
-RDF-Modelle werden daher tendenziell eher projektübergreifend und nachnutzbar
-angelegt werden. Dieser Vorteil birgt in der Praxis allerdings die auch die
-Gefahr von langwierigen Prozessen und theoretischen, komplexeren Lösungen, die
-möglichwerweise an der Praxis vorbeigehen.
+zusammengefasst. Grundsätzlich ist RDF vor allem für die Zusammenführung von
+Daten aus unterschiedlichen Quellen sinnvoll. RDF-Daten werden daher
+tendenziell eher projektübergreifend und nachnutzbar angelegt. Dieser Vorteil
+birgt in der Praxis allerdings auch die Gefahr von langwierigen Prozessen und
+theoretischen, komplexeren Lösungen.
 
  RDF            | Property Graphen 
 ----------------|------------------
 Graph aus Knoten und Kanten   | Graph aus Knoten, Kanten und Eigenschaften
 Etabliert durch das W3C       | Standardisierung noch nicht abgeschlossen
 Identifier sind globale URIs  | Interne oder lokale Knoten-Identifier
-Globale Ontologien mit Regeln | Interne oder lokale Datenbank-Schemas
+Globale Ontologien und Regeln | Lokale Datenbank-Schemas
 Abfragesprache SPARQL         | Abfragesprache Cypher
 
 : RDF und Property-Graphen im Vergleich {#tbl-rdf-pg}
 
 
 ## Property Graphen an der VZG
 
-An der VZG werden Property-Graphen vor allem im Projekt NFDI4Objects
-eingesetzt. Darüber hinaus sollen auch Sacherschließungsdaten des K10plus für
-Analysen in einer Graphdatenbank indexiert werden. In beiden Fällen ist das
-Ergebnis ein so genannter Knowledge Graph. Für die Integration mit anderen
-Datenquellen sollen beide Knowledge Graphen auch nach RDF konvertiert werden
-und bestehende RDF-Daten durch Konvertierung in das PG-Format in Teilen in die
-Property-Graphen integriert werden.
+An der VZG werden Property-Graphen vor allem im Projekt
+[NFDI4Objects](https://www.nfdi4objects.net/) eingesetzt. Darüber hinaus sollen
+Sacherschließungsdaten des K10plus für Analysen in einer Graphdatenbank
+indexiert werden. In beiden Fällen ist das Ergebnis ein so genannter *Knowledge
+Graph*. Für die Integration mit anderen Datenquellen sollen beide Knowledge
+Graphen auch in RDF bereitgestellt und RDF-Daten durch Konvertierung in das
+PG-Format mit Property-Graphen zusammengeführt werden.
 
 ## Zusammenfassung
 
-*muss noch ausformuliert werden*
-
-- Property-Graphen: flexibel aber dennoch nicht zu kompliziertes
-  Werkzeug zur Strukturierung und Speicherung von Daten
-
-- Standardisierung noch nicht abgeschlossen aber ausreichend
-
-- Im Gegensatz zu RDF nicht aus Austauschformat gedacht
-
-- PG und RDF lassen sich zumindest einfacher aufeinander abbilden als Formate
-  in hierarchischen oder feldbasierten Formaten wie MARC, PICA, XML.
-
-- Bei Interesse bitte mich ansprechen!
-
+Property-Graphen bilden ein flexibles und nicht zu kompliziertes Werkzeug zur
+Strukturierung, Speicherung und Auswertung vernetzter Daten. Im Gegensatz zu
+RDF sind Property Graphen allerdings nicht als allgemeines Austauschformat
+gedacht. Die VZG setzt Property-Graphen ein und ist an der laufenden
+Standardisierung beteiligt.