Ich komme weder mit den mitgelieferten Oberflächen von GraphDB, Stardog, RDFox oder mit TopBraid EDG oder Eccenca gut zurecht.
Sicher, all diese Oberflächen erlauben eine Interaktion mit den Triplestores, aber keine kommt an die direkte Darstellung von relationalen Datenbanken in Tabellen heran.
Es sind nun einmal Graphdatenbanken. Und Graphen sind schwer darzustellen. Ein grundlegender Vorteil von Graphdatenbanken ist es gerade, komplexe und vernetzte Informationen darzustellen.
Genau das ist aber schwer in einer einheitlichen UI abzubilden. In einer UI, die beliebige Daten aus der Datenbank darstellen kann, und es auch erlaubt, diese Daten direkt zu editieren. Die vielleicht sogar dynamisch geänderte Daten aus der Db wiederspiegelt.
Und Ideen wie SHACL basierte automatische Oberflächen finde ich auch nicht sehr hilfreich. Auch damit habe ich nicht das Gefühl, direkt auf 'die Daten' aus der Datenbank zu schauen.
Ich bin hier immer um eine Indirektion von den Daten entfernt, immer abhängig von korrekten und aktuellen SHACL-Beschreibungen, und oft nur mit 'Endnutzer'-orientierten Masken konfrontiert.
Dise geben mir keinen Einblick in die tatsächlichen Verhältnisse, in die hinter einzelnen "Feldern" stehenden Prädikate und ihre IRIs, genausowenig wie in die IRIs der Subjekte und IRIs oder Datentypen der Objekte.
Graphen als Bags of Trees?
Ich bevorzuge textbasierte Oberflächen. Mit denen lassen sich Graphen schwerlich darstellen.
Andererseits gibt es viele Vorbilder, wie Bäume dargestellt werden können - jeder Outliner stellt Bäume dar.
Und wenn die Bäume auf andere Bäume verweisen können, haben wir im Grunde Graphen dargestellt.
Wie wäre es also, eine Oberfläche für Triplestores zu entwerfen, die auf der UX von Outlinern beruht und die Graphen als Bäume darstellt? Den Verweis auf andere Bäume haben wir im Modell von RDF ja schon angelegt: IRIs.
So kann ich mir also einen textbasierten Outliner vorstelle, dessen oberste Ebene jeweils ein RDF Subjekt ist, das "aufgeklappt" einige oder alle Prädikate samt zugehörigen Daten und Objekten anzeigt, und für die Objekte wieder ein "aufklappen" ermöglicht.
Das hört sich für mich erst einmal nach einem guten Modell an.
Wie kann die Interaktion funktionieren?
Es wird schwierig, den gesamten Inhalt eines Triplestores in einem gigantischen Outline darzustellen :) Wenn ich die Tabellen einer relationalen Darstellung als Vorbild nehme, dann müsste ich in solch einem Text bzw. Outline blättern können.
Nur ist ja die Struktur gerade so uneinheitlich, dass ich gar nicht genau weiß, worin ich Blättern soll, nach welchem Muster ich den großen Graph in viele Bäume bzw. Top-Level-Einträge zerlegen soll...
Einzelne Subjekte - pull mode
Ich mag hier von den Graphdatenbanken der Clojure-Welt beeinflußt sein, allen voran Datomic, doch ein Modell, sich in einem Graphen voranzuhangeln geht von einem bekannten Subjekt aus. In Datomic heißt die API, mit der man sich von einem Subject, einer ID aus durch den Graphen bewegt, pull syntax.
So kann ich mir auch eine leere "Datei" vorstellen, in dem ich als Nutzer ein Subjekt suche. Ich kann beispielsweise anfangen Buchstaben für den Label oder die IRI eines Subjektes einzugeben und - je nach UX-Konzept - mit einem Tastencode oder nach einer Wartezeit kann der Editor mir dann eine Auswahlliste mit möglichen Subjekten anzeigen.
Wenn ich so ein Subjekt ausgewählt habe, kann ich mich wie in einem Outliner auf "tiefere" Ebenen begeben, per Tab oder Return oder Doppelklick, wie auch immer die konkrete UX aussehen mag.
Und ich kann unter diesem Outline oder Baum ein weiteres Subjekt per Autovervollständigung einfügen, und noch eines, und noch eines, und jedes soweit vervollständigen (oder "aufklappen") wie es für meine Arbeit nötig ist.
Und diese Bäume oder Outlines verweisen über die IRIs aufeinander, und stellen so einen oder mehrere Graphen dar.
Eine Liste von Subjekten - SPARQL mode
Andererseits kann ich auch eine SPARQL-Abfrage in die Datei schreiben, und darunter eine seitenweise Anzeige der Ergebnisse haben.
Dabei könnten die Ergebnisse je nach Abfragetyp, SELECT oder CONSTRUCT als Tabelle oder als Turtle-Statements angezeigt werden.
Und die Turtle-Statements könnten dann wie im Pull-Mode per Tab erweitert werden - oder "zusammengeklappt" um mehr Platz zu schaffen.
Schreiben in den Triplestore
Um die Oberfläche richtig nützlich zu machen, muß man jetzt diese Ergebnisse bearbeiten und direkt wieder in den Triplestore schreiben können.
Dazu muß die UI jeden sichtbaren Text mit dem ursprünglich aus dem Triplestore geladenen hinterlegen, um nach einer Veränderung entsprechende DELETE/INSERT-Statements absetzen zu können.
Und es braucht eine UX, um neue Einträge anzulegen. Und dabei auf vorhandene Einträge aufmerksam zu machen. Falls man z.B. händisch eine vorhandene IRI als "neu" eingibt, sollte das System das elegant kommunizieren.
Und wie lösche ich Einträge? Diese müssen ja weiter angezeigt werden, um sie in die Db speichern zu können? Nun, auch hier läßt sich etwas finden, z.B. können gelöschte Einträge als durchgestrichen angezeigt werden, so lange sie im Triplestore noch nicht gelöscht sind.
Nett. Gefällt mir. Und jetzt?
Das sieht nach einem Haufen Arbeit aus....
Wie könnte der einfachste Prototyp aussehen?
Ganz klar ein Package / Mode für Emacs.
Emacs ist für so etwas gemacht. So schön auch eine Oberfläche in einem Webbrowser wäre, zu viel müsste dafür erst noch geschaffen werden, dass bei Emacs schon vorhanden ist.
Dumm nur, dass ich nie größere Packages für Emacs geschrieben habe. Soweit ich elisp kenne, ist es durch und durch imperativ, etwas von dem ich mich schon seit Jahren wegbewegt habe.
Und wie ich Textproperties verwende oder Buffer, die ja so ganz anders sind als übliche Speicherorte in Programmiersprachen, die aber hierfür absolut zentral sind, das müsste ich auch noch lernen.
MVP
Ein Emacs-Mode, in dem ich Subjekte per Autovervollständigung finden kann und mit den Mechanismen vom Outline-Mode bzw. org-mode weitere Daten aus dem Triplestore holen kann.
Und diese Daten verändern kann und wieder zurückschreiben kann.