[Link for English translation]
Das FactGrid ist eine Graphdatenbank. Das heißt, dass man sich die Datenlage in einer solchen Ressource besser nicht in Form von fünf oder zehn großen, aufeinander verweisenden Tabellen (zu Personen, Orten, Organisationen und Dokumenten etwa) vorstellt.
Das Wissen besteht in einer solchen Datenbank aus Wissensgegenständen – in Wikibase-Instanzen heißen sie „Items“ – und den Beziehungen zwischen ihnen, den „Properties“, sprich Eigenschaften, die diese Gegenstände an andere (oder auch an historische Daten, Links, Bild-Dateien oder Geokoordinaten binden).
Eine solche räumlich vernetzte Beziehung zwischen zwei Gegenständen kann man mit jedem Molekülbaukasten basteln. Hier ein Objekt mit Beziehungen zu zwei anderen. Das kann eine Person (die rote Kugel) sein mit Verbindung zu ihren Eltern (den beiden blauen Kugeln). Strukturell sieht das Gefüge aber nicht anders aus, wenn zu einer Person deren zwei Kindern erfasst sind, oder zwei Universitäten, an denen sie studierte.
Das Molekülmodell trägt nicht besonders gut. In einer Datenbank wie dem FactGrid sind alle Objekte vollkommen gleichartig. Sie alle sind monotone „Items“, die unter Q-Nummern hochgezählt werden. Erst die Aussagen zu ihnen bringen Unterschiede ins Spiel. Ein Vater ist jemand im FactGrid, wenn auf ihn von wo anders eine P141 „Vater“-Property verweist, auf „Mütter“ verweisen dagegen P142-Verbindungen.
In einer Tripel basierten Datenbank (die alles Wissen in dreigliedrige Aussagen zergliedert) genügen zwei Sorten von Bausteinen, etwa Kugeln für die Wissensgegenstände und, weil hier eben Bezugsrichtungen wichtig werden, Pfeile für die Verbindungen zwischen ihnen.
Alle Personen, die an der Universität Jena studierten, findet man, wenn man danach fragt, von welchen Items aus eine Aussage zur „ausbildenden Institution“ (P160) – auf das Item der „Universität Jena“ (Q21880) verweist. So (ausführbares Link) sieht die SPARQL-Suchanfrage aus, und die kann nun niemand so einfach „skripten“:
SELECT ?item ?itemLabel WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language “[AUTO_LANGUAGE],en”. }
?item wdt:P160 wd:Q21880.}
Wieso dies alles genau so zu schreiben ist, kann man ohne Handbuch nicht wissen, und man kann ohne Kenntnis der Datenbank auch nicht wissen, welche Q-Nummer man für die Jenaer Universität und welche P-Nummer man für die Aussage „hat hier studiert“ braucht.
Der Wikimedia Abfragehelfer (ist da bereits ein massiver Gewinn. Wenn einem klar ist, was man erreichen kann, wenn man zuerst „filtert“ und dann bestimmt, was einen an einzelnen Aussagen zu den herausgefilterten Objekten interessiert, kommt man mit dem Abfragehelfer erheblich viel weiter. In das Filterfeld kann man etwa „Uni Jena“ eingeben, ohne die Q-Nummer zu kennen. Der Autocomplete lenkt einen beim Eintippen komfortabel. Der Abfragehelfer ahnt bereits, dass einem interessiert, wer hier studierte – das ist die Property, die am häufigsten auf die Uni Jena verweist, sie kommt als erster Property-Vorschlag.
Wenn man nun mehr zu den herausgefilterten Studenten wissen will, kann man von deren jeweiligen Items Aussagen beziehen – etwa die Geburtsdaten, die Geburtsorte, die Sterbedaten und Sterbeorte, Väter und Mütter:
Es ist dies aber auch schon der Punkt, an der Abfragehelfer die Waffen streckt. Wenn man wissen will, wo die Orte liegen (um sie auf eine Landkarte zu spiegeln), muss man durch die Orte hindurch fragen, denn auf deren Items liegen die Geokoordinaten und hier hilft einem der Abfragehelfer nicht mehr weiter.
Es ist ebenso wenig möglich, im Abfragehelfer einen Qualifier hinzuzusetzen, um etwa den Studienbeginn mit abzufragen. Auch die einfache Umkehr der Fragen ist nicht vorgesehen: Ich kenne eine bestimmte Person und will wissen, wo sie von wann bis wann studierte.
Eigentlich sollte zur Graphdatenbank ein Visual Editor gehören…
Man müsste Graphdatenbank mit Skizzen der Beziehungen zwischen den Objekten befragen können. Hier die banalste Frage nach Allen, die überhaupt irgendeine Ausbildungseinrichtung besuchten. Wer waren sie, und welche Einrichtungen waren das?
Wenn uns nur Studenten der Uni Jena interessieren, sollten wir das für die zweite Kugel notieren können. Man tippt in den Kreis oder stellt es mit dem Werkzeugkasten klar: der zweite Gegenstand in diesem Spiel soll die Uni Jena sein:
Man kann jede solche Anfrage nun beliebig erweitern etwa, indem man von den Studenten aus die Frage nach deren Vätern (P141) stellt, sie sollen hier in Tabellenspalte 3 gelistet werden:
Und man könnte nun sehr einfach den Schritt tun, der mit dem aktuellen Abfragehelfer so leicht nicht mehr zu machen ist: die nächste Frage an die Väter ansetzen. Von welchen (wieder P160) Institutionen wurden diese Väter eigentlich ausgebildet?
Man könnte die Frage auch kurzschließen, um zu erfassen, welche Studenten genau wie ihre Väter in Jena studierten:
Ich gab den Dreiecken verschiedene Farben, um sichtbar zu machen, wenn im Gefüge dieselben Fragen an verschiedenen Stellen gestellt werden (und damit strukturell ähnliche Gegenstände anspielen).
Optional / Verpflichtend
Vielleicht würde man in den Property-Dreiecken mit einem Ausrufezeichen notieren, wenn eine Aussage nicht optional, sondern verpflichtend für alle Funde gelten soll.
Qualifier
Qualifier müssten in der Visualisierung gar nicht viel komplexer sein. Hier wird jeweils ein einzelnes Statement zum Gegenstand neuer Statements. Wenn wir das graphische Repertoire schlank halten wollen, könnten wir die hinzukommenden Aussagen einfach an die vermittelnde Property binden – etwa, um bei den Studenten in zwei eigenen Spalten zu notieren, was die Qualifier P49 und P50 zu deren jeweiligem Studienbeginn und -Ende an dieser Uni notieren:
Filter und gezielte Darstellungen
Ich ließ in den letzten Suchen bereits den aufgeklappten Werkzeugkasten mitlaufen. Der nun sehr viel schlanker Befunde weiterverarbeiten. Eine Suche könnte etwa bei den Mitgliedern (P91) des Illuminatenordens (Q10677) erfassen, welchen religiösen Hintergründen (P172) sie entstammten. Bei einer Statistik, etwa einer Bubble Chart, würden wir die Zahl der einzelnen Treffer wissen wollen:
Denkbar nicht minder, dass man bei Zeitangaben Zeitfenster notieren kann, Werte die größer oder kleiner als angegeben sein müssen, um Befunde ins zeitspezifische Bild zu bringen. Spätestens bei solchen Suchen wird allen, die da schon einmal mit SPARQL hantierten und Aussagen verschachtelten klarer, dass der visuelle Query Editor sehr viel intuitiver und auch sehr viel viel schlanker erfassen würde, was einen bei einer Suche interessiert. Man würde damit spielen können, sich an Befunde herantasten können. Man würde es lernen, in den Datenstrukturen zu denken.
Mal so zum Nachdenken…
PS. Rechte und linke Maustaste – wie man im Visual Editor arbeitet
Wie würde man im Visual Editor seine Suchanfragen schreiben? Vielleicht ganz einfach: Mit der linken Maustaste setzt man einen Kreis mit Fragezeichen darinnen.
Klicke ich mit der linken Maustaste in diesen Kreis, kann ich dort etwas hineinschreiben und das Fragezeichen durch Text ersetzen.
Klicke ich mit der rechten Maustaste in den Kreis, scheinen grau vier Erweiterungsoptionen auf: Zwei Pfeile gehen von meinem Kreis weg, zwei Pfeile führen zu ihm hin. Jedes Mal gibt es zwei offene Angebote mit lediglich einem Fragezeichen darin, und zwei Angebote (zur Erklärung, was hier geschieht), bei denen Muster-Text gegeben ist:
Mit der linken Maustaste kann ich die Richtung meiner Wahl anklicken, diese erscheint jetzt farbig, die anderen drei bislang grauen Pfeile werden damit unsichtbar. Ich kann nun fortfahren und Fragezeichen (von Properties oder Items) durch Text ersetzen, oder auf einen Pfeil oder Kreis klicken und mir mögliche Erweiterungen von hier aus anzeigen lassen.
Wie im aktuellen Abfragehelfer erhalte ich immer eine Vorschau von 20 Zeilen Tabelle, mit der ich sehe, was ich hier soeben getan habe.
