In seiner Funktionalität auf die Lehre in gestalterischen Studiengängen zugeschnitten... Schnittstelle für die moderne Lehre
In seiner Funktionalität auf die Lehre in gestalterischen Studiengängen zugeschnitten... Schnittstelle für die moderne Lehre
KnowEdge ist eine interaktive & explorative DBpedia-Visualisierung. Das Projekt ist im Rahmen des Kurses „Immersive Datenvisualisierung“ entstanden, indem wir das Planetarium Potsdam als Präsentationsmedium verwenden sollten.
Zu Beginn des Kurses galt es einen geeigneten Datensatz als Basis für die Visualisierung zu finden. Wir entschieden uns zu Beginn, dass wir keinen thematischen Datensatz im herkömmlichen Sinne verwenden wollten. Daher machten wir uns auf die Suche nach offenen Datenbanken die mehrere Themenbereiche gleichzeitig abdecken und somit die Möglichkeit eröffnen sollten Beziehungen zwischen den unterschiedlichen Datensätzen herzustellen. Dabei stellten sich freebase.com und dbpedia.org als am geeignetsten heraus.
Aufgrund der flexibleren und simpleren API entschieden wir uns für die Datenbank [DBpedia](http://dbpedia.org/About „DBPedia“).
Die DBpedia ist eine freie Datenbank welche mit anderen freien Datensammlungen verbunden ist. Dies sind unter anderem Freebase, Open Cyc, UMBEL, GeoNames, MusicBrainz, CIA World Factbook, das Linked Open Data-Projekt der New York Times, Digital Bibliography & Library Project, Project Gutenberg, Jamendo, Eurostat und die US-Volkszählung.
Die Verknüpfung mit anderen Datenbanken wird durch den verwendeten RDF-Standard ermöglicht ([Resource Description Framework](http://de.wikipedia.org/wiki/Resource_Description_Framework „Resource Description Framework“)).
Das RDF-Modell speichert Aussagen über Ressourcen. Die kleinste Einheit in diesem Datenmodell ist das sogenannte Triplet, welches die semantische Beziehungen zwischen zwei Resourcen in die folgenden Bestandteile aufschlüsselt:
SUBJEKT : PRÄDIKAT : OBJEKT
Subjekt und Objekt stellen dabei die Resourcen dar. Die semantische Beziehung zwischen Objekt und Subjekt wird über das Prädiakt definiert. Ein solches typisches Triplet könnte wie folgend aussehen:
DEUTSCHLANDS : HAUPTSTADT_IST : BERLIN
Beispiel eines echten Tripels: Subjekt: http://dbpedia.org/resource/Tom_Cruise Prädikat: http://dbpedia.org/property/spouse Objekt: http://dbpedia.org/resource/Katie_Holmes„
Wir wollten die Kuppel in einem dreidimensionalen Datenraum verwandeln, in dem der User sich mit Hilfe einer 3D-Maus bewegen könnte. Die Subjekte&Objekte die innerhalb der DBpedia definiert waren, sollten dabei als Informations-Knotenpunkte visualisiert werden und die Beziehungen zwischen ihnen als Verbindungslinien. Also eine klassische (jedoch im Raum navigierbare) Netzwerkvisualisierung.
Bevor wir anfingen unsere Idee in Processing umzusetzen machten wir ein paar Designskizzen und recherchierten über schon vorhanden „Netzwerk-Visualisierungen“.
Um schnell einen funktionsfähigen Prototypen zu entwickeln und trotzdem die große Datenmenge von DBPedia im Griff zu behalten, beschränkten wir uns nach dem Ladevorgang darauf nur Städte, Länder und Personen die in ihnen geboren oder gestorben sind zu verarbeiten.
Der erste Schritt war es die Resourcen, welche mit der ausgewählten Resource verknüpft waren kreisförmig um diese anzuordnen. Dieser Ansatz wurde den jedoch den nichtrelationen Beziehungen zwischen den Knotenpunkten nicht gerecht. Daraufhin entschieden wir uns die Knotenpunkte über einen sogenannten [Force-Directed Graph](http://en.wikipedia.org/wiki/Force-directed_graph_drawing „Force-directed Graph“) im Raum zu verteilen.
Dieses Darstellungsystem simuliert jeden Knotenpunktmit einer abstoßenden Kraft und erzeugt zwischen Knotenpunkten die in Beziehung zueinander stehen eine Anziehungskraft. Durch diese Simulation und die in Anziehungskräften simulierten Beziehungen bilden sich automatisch Gruppierungen, welche die Tatsächlichen Verknüpfungen darstellen.
Wir testeten dieses System zuerst in 2D. Als wir schließlich wirklich Anfragen an DBPedia stellen konnten und sich so unserer Visualisierung „füllte“, stellten wir fest das sich durch die Anziehungskräfte Kreise bildeten. Daraufhin entschlossen wir uns dazu, die gesamte Simulation in die Dritte Dimsion zu tragen. Dieser Schritt sollte es uns ermöglichen spannende „Datenräume“ zu erzeugen.
Wir stießen während des Projektes des öfteren auf große Hindernisse — eigentlich fing es schon mit der enorm großen Datenmenge der DBPedia an.
Schnell wurde klar, dass wir unter den gegebenen Umständen keine Visualisierung der kompletten DBPedia umsetzen würden. Das Laden und Verarbeiten einer Resource brauchte je nach Größe bis zu 10 Sekunden, was die Anwendung stockend wirkend lies. Also musste innerhalb der Anwendung ein zweiter Thread gestartet werden, welcher sich im Hintergrund um das Resourcenladen kümmerte. Dieser wiederum erschuf Speicherzugriffsprobleme und mehr (Threadsafe … Queue-Interface …olé).
Aber auch die Darstellung des dreidimensionalen Raumes stellte uns vor Fragen, die wir uns vorher noch nie gestellt hatten. Hinzu kam die Steuerungsimplementierung des Spacenavigators (3D-Maus), welche uns viel Kopfzerbrechen bereitete: Eine First-Person-Camera ist ein nicht zu unterschätzender Programmieraufwand („Quaternions“ … „Gymbal-Lock“ … olé). Auch Begriffe wie „Billboarding“, wobei es darum geht zweidimensionale Fläche (zum Beispiel Text) immer in Richtung der Camera auszurichten, waren für uns neu.
Trotz und vielleicht auch gerade wegen der vielen „Steine“ auf dem Entwicklungsweg zu dieser dynamischen Netzwerk-Visualisierung haben wir viel gelernt.
Der resultierende Protoyp ermöglichte es dem Benutzer eine rudimentäre Steuerung innerhalb des 3D-Raumes und das dynamische nachladen von Resourcen aus dem Internet.