Zur Realisierung der Visualisierung der gesammelten Ontologienutzungsdaten wurde die Software SONIVIS:Tool erweitert. In SONIVIS wurde eine neue Ansicht mit dem Namen „Analysis View“ implementiert. Diese Ansicht ermöglicht die Betrachtung der gesammelten Daten unter verschiedenen Perspektiven. Der Systementwurf und die verwendete Software wird in Kapitel 3.1 beschrieben. In Abschnitt 3.2 wird die implementierte Ansicht mit all ihren Facetten erläutert, sowie Interpretationen der visualisierten Daten diskutiert.

Abbildung 10: Struktur des System, Quelle: eigen

Die Visualisierung der Ontologienutzungsdaten erfolgt mit Hilfe der Software SONIVIS:Tool. In Kapitel 3.1.1 wird sie näher erläutert. Die Nutzungsdaten selbst liegen in einer Postgres-Datenbank vor, weshalb es notwendig ist, dass ein Postgres-Server auf dem Rechner zur Verfügung steht. In SONIVIS werden diese Daten auf Basis einer Ontologie dargestellt. Diese Ontologie wird von SONIVIS als Graph visualisiert. Weiterhin wird die Ontologie verwendet, um bestimmte Beziehungen zwischen Primitiven, wie beispielsweise Subklassenrelationen, zu überprüfen. Primitive sind sowohl Klassen, als auch Eigenschaften, die in einer Ontologie definiert wurden.

Dazu wird die Java-Bibliothek „Jena“ verwendet. Jena ist ein Open-Source Framework, welches die Entwicklung von Semantic Web Applikationen vereinfacht. Mit Hilfe der Bibliothek können programmatisch RDF, RDFS und OWL Dokumente erzeugt, gelesen, verarbeitet und ausgegeben werden. Desweiteren enthält Jena eine SPARQL-Schnittstelle, mit der Anfragen erzeugt und an einen Service gestellt werden können. Beispielsweise können in OWL geschriebene Ontologien gelesen, verarbeitet und verändert werden. Mehr Informationen zum Jena-Framework können unter [Jena] gefunden werden. Die umittelbare Visualisierung der gesammelten Daten ist aufgrund gewisser Probleme nicht möglich. Daher wurden Preprocessing-Mechanismen implementiert, die diese Probleme lösen. Die Gründe für die Vorverarbeitung und deren Mechanismen werden in Kapitel 3.1.2 erläutert. In Abbildung 10 ist die Systemstruktur schematisch dargestellt (Die genutzen Bilder entsprechen den Logos der Komponenten. Zu finden sind sie auf den genannten Webseiten der Projekte). Wie man erkennen kann, bildet SONIVIS den Mittelpunkt des Systems. Die implementierte Erweiterung der Software ist als Box innerhalb von SONIVIS dargestellt. Sowohl die Preprocessing-, als auch die Metrikkomponente nutzt die Daten aus Postgres und verwendet Jena. Die verarbeiteten Daten werden schließlich zur Visualisierungskomponente weitergegeben, welche die Nutzungsdaten im Graph und in den implementierten Ansichten visualisiert.

Abbildung 11: Schematische Darstellung des Verarbeitungsprozesses, Quelle: eigen

Abbildung 11 stellt den kompletten Verarbeitungsprozess der Daten schematisch dar. Anfangs werden die Log Dateien eines Servers mit Hilfe der in Abschnitt 2.4 beschriebenen Methode analysiert und verarbeitet, sodass die gesammelten Nutzungsdaten strukturiert in einer Datenbank abgelegt werden. Danach erfolgt die in Kapitel 3.1.2 erläuterte Vorverarbeitung der Daten, sodass diese anhand einer Ontologie visualisiert werden können. Anschließend werden diese Daten und eine gewählte Ontologie in SONIVIS verwendet, um die Ontologienutzungsdaten zu visualisieren. Dies geschieht anhand des Graphen, als auch mit Hilfe der implementierten Ansichten. Durch die so erhaltenen Informationen können Nutzer der Software, wie beispielsweise Betreiber von semantischen Datenrepositories, Rückschlüsse auf die Nutzung ihrer Daten und Ontologie ziehen.

Als Grundlage zur Visualisierung der Ontologie und deren Nutzungsdaten wird die Software SONIVIS:Tool verwendet und erweitert. Die Software wird in [MuellerKroeger] beschrieben. SONIVIS ist eine Java-basierte Open-Source Anwendung, die auf der Eclipse (Eclipse ist eine auf Java basierende Entwicklungsumgebung, siehe www.eclipse.org) Rich Client Platform (RPC) basiert. Zur Ausführung benötigt SONIVIS sowohl einen lokalen MySQL-Server (siehe www.mysql), um die nötigen Daten zu speichern, als auch eine Installation von Gnu R. R ist eine Umgebung, mit der effizient statistische und andere Berechnungen durchgeführt werden können. Nähere Informationen zu R sind in [RProject] zu finden. Die Komponenten von SONIVIS werden in Abbildung 10 als Logos innerhalb der SONIVIS-Box dargestellt. Als Hauptaufgaben der Software gelten die Netzwerkgewinnung und -analyse. Entwickelt wurde die Software zur Analyse und Visualisierung von verschiedenen Informationsräumen, wie beispielsweise Wikis oder sozialer Netzwerke. Durch Erweiterungen wurde es unter anderem auch ermöglicht, Ontologien und andere RDF-basierte Dokumente in SONIVIS zu importieren und die von den Dokumenten beschriebenen Graphen visuell darzustellen. Die Darstellung des Graphen kann mit Hilfe verschiedener Layout-Mechanismen berechnet werden. Standardmäßig sind in SONIVIS beispielsweise ein Kreis-Layout und ein Layout basierend auf dem Barnes-Hut Algorithmus (siehe [BarnesHut]) vorhanden, der den Graph mittels Berechnung der Kräfte innerhalb des Netzwerks erzeugt. Visuell generiert wird der Graph mit Hilfe des „Prefuse Visulization Toolkit“ (www.prefuse.org). Desweiteren unterstützt die Software ein Metriksystem, wodurch auf einem gegebenem Netzwerk Metriken berechnet und deren Ergebnisse visualisiert werden können. Beispielsweise können die Größe der Graphknoten und deren Farbe je nach Resultat der Berechnung variiert werden. Die Berechnung der Metriken erfolgen in Java oder mit Hilfe von Gnu R. Eine in Sonivis implementierte Metrik ist beispielsweise „Degree“, welche die Anzahl an direkten Nachbarn eines Knotens berechnet. Dieses Metriksystem kann durch eigene Metriken erweitert werden. Das Graphical User Interface (GUI) von Sonivis basiert auf einem konfigurierbaren Arbeitsbereich. Es sind verschiedene Views implementiert, die zur Analyse, Manipulation und statistischen Untersuchung des Netzwerks genutzt werden können. Im Rahmen dieser Arbeit wurde die Software um eine View erweitert, welche die Visualisierung der gesammelten Ontologienutzungsdaten ermöglicht. Mehr Informationen zu SONIVIS können in [Sonivis] gefunden werden.

3.1.2 Preprocessing

Die direkte Visualisierung der vorhandenen Nutzungsdaten in SONIVIS ist nicht ohne deren Vorverarbeitung möglich. In den folgenden zwei Abschnitten werden sowohl die Gründe dafür, als auch die implementierte Lösung präsentiert. Ein Problem der vorhandenen Nutzungsdaten war, dass die in den Daten vorhandenen SPARQL Abfragen auf konkrete Instanzen, wie „http://dbpedia.org/resource/Berlin“, abzielen. Die Visualisierung erfolgt aber auf Grundlage einer Ontologie, wie zum Beispiel der DBpedia Ontologie. In dieser werden Klassen, wie „http://dbpedia.org/ontology/city“, definiert und miteinander in Beziehung gesetzt. Daher musste eine Zuordnung der vorhandenen Ressourcen zu ihren Klassen vorgenommen werden. Dies wird in 3.1.2.1 genauer erläutert. Ein weiterer Grund für die Vorverarbeitung war, dass durch die hohe Anzahl an Daten, die per SQL abgerufen werden mussten, die Zeit zum Generieren der implementierten View sehr lang wurde. Daher wurden beispielsweise die Daten für die Hosts und deren Zugriffszeiten extrahiert und in eigene, kleinere Tabellen abgelegt. Eine nähere Erklärung dazu findet sich in 3.1.2.2.

Ressourcen - Klassen Mapping

In der zugrundeliegenden Arbeit wurden Serverlogs von DBpedia analysiert und strukturiert gespeichert. Dabei wurden unter anderem auch die SPARQL Anfragen selbst extrahiert und deren Komponenten, wie der Where-Teil oder die Filter, verarbeitet. Im Where-Teil einer SPARQL-Anfrage können mehrere unterschiedliche Anfragetripel, die Basic Graph Patterns, formuliert sein, die den Anfragegraph darstellen. Auch diese Tripel wurden extrahiert, analysiert und in einer Datenbank für eine weitere Verarbeitung hinterlegt. Aus Paltzgründen wird hier dbp als Namensraum für http://dbpedia.org/ verwendet. Ein Beispieltripel ist:

?person dbp:ontology/birthplace dbp:resource/Berlin

Hier wurde angefragt, welche Personen in Berlin geboren wurden. Soll diese Anfrage nun auf Grundlage der DBpedia Ontologie visualisiert werden, ergibt sich ein Problem. In den Anfragetripeln werden fast immer Instanzen verwendet, wie hier „dbp:resource/Berlin“ als Objekt. In einer Ontologie aber werden Konzepte modelliert, welche dann instanziiert werden können. So ist „Berlin“ beispielsweise eine Instanz der Klasse „dbp:ontology/city“. Da in den vorhandenen Nutzungsdaten also hauptsächlich Instanzen vorkommen, muss ein Mapping dieser Ressourcen zu ihren zugehörigen Klassen erzeugt werden. Um dies zu erreichen, wird eine SPARQL Anfrage an die snorql-Schnittstelle des DBpedia Servers gesendet (siehe www.dbpedia.org/snorql). In der Abfrage werden über das Prädikat „rdf:type“ die Klassen einer spezifischen Ressource angefordert. Die SPARQL Anfrage hat folgende Form:

PREFIX rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# 
SELECT ?class
WHERE {resource rdf:type ?class}

Für resource wird die entsprechende Instanz, wie „dbp:resource/Berlin“, eingesetzt. Als Antwort erhält man eine Liste der Klassen der angefragten Instanz. Im Falle von „Berlin“ erhält man beispielsweise einige YAGO-Klassen und unter anderem auch die DBpedia-Klassen „Place“ und „City“. Diese Anfragen wurden mit Hilfe der Jena-Bibliothek realisiert. YAGO ist eine sehr große Ontologie, welche strukturierte Informationen aus Wikipedia enthält, siehe www.mpi-inf.mpg.de/yago-naga/yago/). Mehr Informationen zu Jena sind in 3.1 zu finden. Diese Liste der Klassen wird anschließend in einer Datenbanktabelle gespeichert und mit der entsprechenden Ressource verbunden. Aus Gründen der Performance wurde auch für die angefragten Ressourcen eine neue Tabelle angelegt.

Abbildung 12: Ausschnitt des Datenbankschemas zum Mapping der Instanzen und ihrer Klassen, Quelle: eigen

In Abbildung 12 ist das verwendete Datenbankschema dargestellt. Die Tabelle „queryresultstriplestat“, in der die Tripel-Daten des Preprocessing gespeichert wurden, wurde unter anderem mit den Spalten „subjectresource“,“predicateresource“ und „objectresource“ erweitert, welche auf die Tabelle „analysis_resources“ verweisen. In dieser Tabelle werden die angefragten Ressourcen einmalig gespeichert. Über die Tabelle „analysis_resources_resourceclasses“ werden die Instanzen mit ihren Klassen, die in „analysis_resourceclasses“ abgelegt wurden, verbunden. Durch diese Struktur können jeder Instanz ihre Klassen zugeordnet werden. Ein auftrendes Problem dieser Vorgehensweise ist die Dauer des gesamten Prozesses. Da mehrere 100.000 bis Millionen verschiedene Ressourcen pro Tag angefragt werden, dauert der Vorgang des Anfragens und Speicherns der Klassen für alle in den Daten vorhandenen Ressourcen sehr lange. Das Bottleneck hier ist eindeutig die Netzwerkverbindung, da eine Anfrage über das Internet gestellt werden muss. Je nach Bandbreite kann der gesamte Prozess einige Stunden in Anspruch nehmen. Aus diesem Grund wurde ein Mechanismus zur schrittweisen Anforderung der Daten implementiert. So kann beispielsweise nur ein Teil der Daten verarbeitet und der Rest an einem späteren Zeitpunkt nachgeholt werden. Vorschläge zur Verbesserung des Prozesses finden sich in 5.2. Desweiteren ist anzumerken, dass jede Ressource eine Instanz von mehreren Klassen sein kann, welche auch durch eine Subklassenbeziehung miteinander verbunden sein können. Dies wirkt sich auf die spätere Visualisierung aus. Wenn beispielsweise „Berlin“ angefragt wird, welches unter anderem vom Typ „City“ und „Place“ ist, zählt diese Anfrage für beide Klassen. Verfälscht werden die Ergebisse dadurch nicht, aber man muss sich darüber im Klaren sein, dass wenn beispielsweise „Place“ 1000 mal angefragt wurde, ein Großteil der Anfragen an Unterklassen von „Place“, wie zum Beispiel „City“, gestellt wurden.

Caching der Hosts und Zugriffszeiten

Neben den verwendeten Klassen, werden auch die Ursprünge und Zugriffszeiten der Anfragen visualisiert. Diese wurden aus den Serverlogs extrahiert und in den vorhandenen Datensätzen gespeichert. Aufgrund der Größe der Datenbank war es nicht performant möglich, diese direkt aus der Ursprungstabelle auszulesen und zu verarbeiten. Beispielsweise müssen für der Generierung der Zeitintervalle der Anfragen aus jedem Datensatz der Host und die Zugriffszeit extrahiert und in Zeitintervalle gruppiert werden. Da alle Datensets mehrere 100.000 Anfragen beinhalten und per Stringvergleich die Hosts identifiziert werden müssen, ensteht eine Wartezeit beim Laden dieser Informationen von mehreren Minuten. Zur Lösung dieses Problems muss man sich vor Augen führen, dass die Generierung der Zeitintervalle beispielsweise immer die selben Resultate liefert, da sich die Datensätze nicht verändern können. Daher ist nur die einmalige Generierung dieser Daten notwendig. Anschließend können die zwischengespeicherten Informationen genutzt werden. Aus diesem Gedanken heraus wurden 3 weitere Tabellen eingeführt, die eine effizientere Abfrage der Hosts und Generierung der Zugriffszeiten ermöglichen.

Abbildung 13: Datenbankschema zum Zwischenspeichern der Hosts und Zugriffsintervalle, Quelle: eigen

In Abbildung 13 ist das Datenbankschema zu erkennen. In der Tabelle „analysis_hosts“ wurden alle Hosts einmalig eingetragen. Durch diese Zwischenspeicherung ist es möglich, alle Hosts mit einer einfachen SELECT-Anweisung per SQL zu erhalten. In der ursprünglichen Tabelle mussten die Daten per „SELECT DISTINCT“ bezogen werden, was um ein Vielfaches ineffizienter war. Eine Übersicht über die Verbesserung der Zugriffszeit findet sich in Tabelle 1.

Tabelle 1: Performance Verbesserung durch Caching anhand des Datensets des 4.6.2010, Quelle: eigen

Über die Tabelle „analysis_hostsreferences“ wird eine Verbindung der zwischengespeicherten Daten zu den Originaldaten hergestellt, die in „queryresultsstat“ hinterlegt sind. Damit können beispielsweise die angefragten Tripel oder die Zugriffszeiten eines bestimmten Hosts ermittelt werden. Die Anzahl der Zugriffe eines Hosts pro Zeitintervall wird schließlich in der Tabelle „analysis_hosttimeamount“ zwischengespeichert. Um diese Daten zu erhalten, wird auf Basis der Originaldaten eine Gruppierung nach Host und Zeitintervall realisiert. Dabei werden Zeitintervalle von jeweils einer Stunde, sowie die Anzahl der Zugriffe eines Host während dieser Zeit, generiert. Beispielsweise fragt ein bestimmter Host DBpedia in der Zeit zwischen 10.00 Uhr und 10.59 Uhr 7287 mal an. Diese gruppierten Daten werden in der Caching Tabelle gespeichert. Man könnte noch nach genaueren Zeitintervallen gruppieren, aber für die jetzigen Zwecke der Visualisierung erschien ein Intervall von einer Stunde als vollkommen ausreichend. Um nun die Anzahl der Zugriffe pro Zeitintervall zu erhalten, können mit Hilfe einer einfachen Join-Operation die Hosts und deren Zugriffszeiten kombiniert werden. Eine Übersicht über die zeitliche Verbesserung findet sich in Tabelle 1. Die Gründe für diese starke Verkürzung der Zugriffszeiten sind, dass die nun verwendeten Tabllen um ein Vielfaches kleiner sind als die Ursprungstabellen und dass keine Berechnung der Zeitintervalle mehr erfolgen muss. Desweiteren können die Daten nun mit einfachen Join-Operationen kombiniert werden, wo vorher Stringvergleiche für die Hosts durchgeführt werden mussten.

• Zusammenfassung
• Einführung
• Grundlagen
• Entwurf und Implementierung
• Evulation
• Fazit

• Page:
•  1 
•  2 
•  3 
•  4 
•  5 
•  6