I don't get on well with the interfaces supplied with GraphDB, Stardog, RDFox or with TopBraid EDG or Eccenca.
Sure, all these interfaces allow interaction with the triplestores, but none of them come close to the direct representation of relational databases in tables.
The fact is that they are graph databases. And graphs are difficult to visualize. A fundamental advantage of graph databases is precisely the ability to display complex and networked information.
However, this is precisely what is difficult to depict in a standardized UI. In a UI that can display any data from the database and also allows this data to be edited directly. Which perhaps even reflects dynamically changed data from the database.
And I don't find ideas like SHACL-based automatic interfaces very helpful either. Even with that, I don't feel like I'm looking directly at 'the data' from the database.
I'm always one indirection away from the data here, always dependent on correct and up-to-date SHACL descriptions, and often only faced with 'end-user' oriented masks.
These give me no insight into the actual relationships, into the predicates behind individual "fields" and their IRIs, just as little as into the IRIs of the subjects and IRIs or data types of the objects.
Graphs as bags of trees?
I prefer text-based interfaces. They are hard to represent graphs with.
On the other hand, there are many models of how trees can be represented - every outliner represents trees.
And if the trees can reference other trees, we have basically represented graphs.
So how about designing an interface for triplestores that is based on the UX of outliners and represents the graphs as trees? We have already created the reference to other trees in the RDF model: IRIs.
So I can imagine a text-based outliner whose top level is always an RDF subject that "unfolds" to show some or all predicates along with associated data and objects, and allows "unfolding" again for the objects.
First of all, that sounds like a good model to me.
How can the interaction work?
It will be difficult to display the entire content of a triplestore in a gigantic outline :) If I take the tables of a relational representation as a model, then I should be able to scroll through such a text or outline.
However, the structure is just so inconsistent that I don't know exactly what I should scroll through, according to which pattern I should divide the large graph into many trees or top-level entries.
Single subjects - pull mode
I may be influenced here by the graph databases of the Clojure world, above all Datomic, but a model for moving forward in a graph is based on a known subject. In Datomic, the API used to move through the graph from a subject, an ID, is called pull syntax.
So I can also imagine an empty "file" in which I as a user search for a subject. For example, I can start entering letters for the label or the IRI of a subject and - depending on the UX concept - with a key code or after a wait time, the editor can then show me a selection list with possible subjects.
Once I have selected a subject in this way, I can go to "deeper" levels like in an outliner, by tab or return or double-click, whatever the specific UX may look like.
And I can insert another subject under this outline or tree via autocomplete, and another, and another, and complete (or "expand") each as far as is necessary for my work.
And these trees or outlines refer to each other via the IRIs, and thus represent one or more graphs.
A list of subjects - SPARQL mode
On the other hand, I can also write a SPARQL query in the file and have a page-by-page display of the results underneath.
The results could be displayed as a table or as turtle statements, depending on the query type, SELECT or CONSTRUCT.
And the turtle statements could then be expanded by tab as in pull mode - or "collapsed" to create more space.
Writing to the triplestore
To make the interface really useful, it must now be possible to edit these results and write them directly back to the triplestore.
To do this, the UI must store each visible text with the text originally loaded from the triplestore in order to be able to send corresponding DELETE/INSERT statements after a change.
And it needs a UX to create new entries. And to draw attention to existing entries. If, for example, you manually enter an existing IRI as "new", the system should communicate this elegantly.
And how do I delete entries? These must still be displayed in order to be able to save them in the database? Well, something can be found here too, e.g. deleted entries can be displayed as crossed out as long as they have not yet been deleted in the Triplestore.
Nice. I like that. And now?
This looks like a lot of work....
What could the simplest prototype look like?
Clearly a package / mode for Emacs.
Emacs is made for this kind of thing. As nice as an interface in a web browser would be, too much would have to be created first that is already available in Emacs.
The only problem is that I have never written larger packages for Emacs. As far as I know elisp, it's imperative through and through, something I've been moving away from for years.
And how I use text properties or buffers, which are so different from the usual storage locations in programming languages, but which are absolutely central to this, I would still have to learn that too.
MVP
An Emacs mode in which I can find subjects using auto-completion and retrieve further data from the triplestore using the mechanisms of outline mode or org mode.
And I can change this data and write it back again.