Konzeption und Entwicklung einer semantikbasierten Managementschicht für Dateisysteme

Diplomarbeit Universität Oldenburg

Jürgen Geuter

22. Januar 2009

Lizenz

Commons Deed

Es ist Ihnen gestattet:

• das Werk vervielfältigen, verbreiten und öffentlich zugänglich machen • Abwandlungen bzw. Bearbeitungen des Inhaltes anfertigen

Zu den folgenden Bedingungen:

Namensnennung. Sie müssen den Namen des Autors/Rechteinha- • bers in der von ihm festgelegten Weise nennen.

Weitergabe unter gleichen Bedingungen. Wenn Sie den lizenzierten Inhalt bearbeiten oder in anderer Weise umgestalten, verändern oder als Grundlage für einen anderen Inhalt verwenden, dürfen Sie • den neu entstandenen Inhalt nur unter Verwendung von Lizenz- bedingungen weitergeben, die mit denen dieses Lizenzvertrages identisch oder vergleichbar sind.

• Im Falle einer Verbreitung müssen Sie anderen die Lizenzbedingungen, unter welche dieses Werk fällt, mitteilen. • Jede der vorgenannten Bedingungen kann aufgehoben werden, sofern Sie die Einwilligung des Rechteinhabers dazu erhalten. • Diese Lizenz lässt die Urheberpersönlichkeitsrechte unberührt.

http://creativecommons.org/licenses/by-sa/3.0/de/

Erklärung der Selbstständigkeit

Hiermit versichere ich, die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie die Zitate deutlich kenntlich gemacht zu haben.

Oldenburg, den 22. Januar 2009 Jürgen Geuter

Inhaltsverzeichnis

1 Einleitung 1 1.1 Problemstellung ...... 1 1.2 Ziele der Arbeit ...... 3 1.3 Ablauf dieser Arbeit ...... 4 1.4 Motivation ...... 5 1.5 Bestehende Lösungen ...... 6 1.6 Zielgruppe ...... 7

2 Theoretische Grundlagen9 2.1 Die Beschaffenheit physischer Objekte und ihrer Organisationssysteme . . . .9 2.2 Die Beschaffenheit mentaler Objekte ...... 12 2.3 Der Begriff des „Tags“ der Unterschied zum Begriff der Kategorie ...... 16 2.4 Die Entsprechung von Verzeichnis und Kategorie und die Probleme dieser Entsprechung ...... 23 2.5 Dateisysteme ...... 23 2.6 Metadaten in Dateien ...... 27 2.7 Dateien und ihre semantische Einordnung ...... 28

3 Evaluation verschiedener Lösungsansätze 29 3.1 Diskussion des verwandten Konzeptes der „Desktop Search Engine“ . . . . . 29 3.2 Diskussion verschiedener Metadatenstandarts ...... 31 3.3 RDF als Format zur Beschreibung von Relationen ...... 36 3.4 Evaluation unterschiedlicher Technologien bezüglich ihrer Eignung für diese Arbeit ...... 38

4 Entwurf 47 4.1 Architektur ...... 47 4.2 Entwurf der Datenstrukturen ...... 50 4.3 Entwurf der Client-API ...... 65 4.4 Definition einer Abfrage-Sprache ...... 70 4.5 Entwurf des Metadatenscanners ...... 78 4.6 Entwurf einer prototypischen grafischen Oberfläche ...... 79

5 Implementierung 85 5.1 Die Entwicklungsplatform ...... 85 ii Inhaltsverzeichnis

6 Zusammenfassung und Ausblick 91 6.1 Reflexion der Ergebnisse ...... 91 6.2 Erweiterungen für das Wittgenstein System ...... 92 6.3 Abschluss ...... 94

Literaturverzeichnis 95 KAPITEL 1

Einleitung

Seit langer Zeit sind Menschen konfrontiert mit dem Problem, Objekte, die einen irgendwie gearteten Wert für sie haben, zu archivieren und zu organisieren. Das Spektrum der Objekte ist weit und reicht von persönlichen Briefen über Fotos bis hin zu den für die Ausbildung benötigten Schulungsunterlagen: Die Objekte sind neben ihren unterschiedlichen inhaltlichen Bedeutungen für den jeweiligen Besitzer auch von sehr unterschiedlicher physischer Beschaffenheit.

1.1 Problemstellung

Die Unterschiede in der materiellen Struktur der Objekte führten in der Folge zu spezialisier- ten Organisierungswerkzeugen, welche häufig auf einen sehr eingeschränkten Objektbereich zugeschnitten sind. Fotoalben beispielsweise sind sehr genau auf die Bedürfnisse bei der Organisation von Lichtbildern optimiert, sie erlauben es, die Fotos ohne Beschädigung im Album zu fixieren und bieten Platz für kurze Notizen zum Foto; ein Besteckeinsatz in der Küchenschublade hingegen bietet üblicherweise eine Anzahl von voneinander abgetrennten Fächern, in denen die jeweiligen Besteckteile je nach ihrer Art einsortiert werden können. Der Besteckeinsatz ist aber völlig ungeeignet um Fotos in ihm aufzubewahren, sie würden unter Umständen beschädigt und blieben unorganisiert.

Die Organisation von Menschen hat nicht nur rein ästhetische Bedeutung, es geht nicht nur Organi- sations- darum, dass Dinge in einer „schönen“ Struktur sind; die Organisation von Dingen erlaubt es systeme uns, überhaupt erst mit der Menge von Dingen in unserem persönlichen Umfeld umzugehen. Wie der Psychologe George A. Miller 1956 in seinem Artikel The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information[Mil56]1 postuliert, können Menschen nicht beliebig große Mengen von Objekten bearbeiten. Das so genannte Arbeitsgedächtnis (vgl. [Bad99], Kapitel 3), das heißt der Bereich des menschlichen Gehirns, welcher die Informationen, die zur Bearbeitung des gerade für den Menschen relevanten

1 Der vollständige Artikel steht unter http://www.musanim.com/miller1956/ zur Verfügung 2 1 Einleitung

Vorgangs notwendig sind, enthält, kann laut Miller 7 (+/-2)1 so genannte „chunks“ enthalten2. Der Inhalt eines solchen „Chunks“ ist dabei variabel und kann durchaus ein sehr komplexes mentales Objekt sein, je nach gerade vorliegendem Prozess kann ein „Chunk“ eine einfache Zahl sein, eine Person oder ein komplexer Begriff wie „zu Hause“. Diese Begrenztheit des menschlichen Denkapparates macht Organisation zentral für die Möglichkeit des Menschen die wachsende Anzahl der Objekte in seinem Umfeld handhabbar zu machen.

Aufräumen Das Aufräumen, also das Einordnen von Objekten in Organisationssysteme wie Regale, Schränke &ct, ist etwas, was viele Kinder schon früh von ihren Eltern erlernen: Kleidung ist zu unterscheiden von Büchern und Spielzeug, Zahnputzbecher und Trinkgefäß gehören, trotz ihrer scheinbaren Ähnlichkeit, an ganz unterschiedliche Orte.

Suchen Sucht der Mensch nun nach einem Objekt, kann er eine Hierarchie von Ordnungssystemen durchlaufen: Er sucht beispielsweise das Buch Dive into Python. Er betrachtet die höchsten Ordnungssysteme, die er in seiner Wohnung hat, die Räume und entscheidet, dass, weil das Buch ein technisches Fachbuch ist, es im Arbeitszimmer zu finden sein muss. Im Arbeitszimmer finden sich nun eine neue Menge von Ordnungssystemen, beispielsweise ein Bücherregal, ein Schrank &ct., die es dem Suchenden erlauben, die Möglichkeiten so weit einzuschränken, bis er das Buch gefunden hat. Organisationssysteme sind, was dieses zielgerichtete Suchmodell erfolgreich sein lässt.

1.1.1 Der Einzug der virtuellen Inhalte

virtuelle Neben den Dingen des alltäglichen Lebens und dem persönlichen psysischen Besitz, trat, Inhalte nach dem flächendeckenden Einzug des Personal Computers in viele Privathaushalte, eine neue Klasse von Entitäten, die zu organisieren waren, auf: Die rein „virtuellen“ Inhalte „innerhalb“des Computersystems. Texte, Bilder, Videos, Musik und diverse weitere Arten von Informationen fanden, oft über spezialisierte Werkzeuge ihre Repräsentanz auf den Computersystemen der Anwender, ein Datenstrom, der durch den Durchbruch des Internets in großen Teilen der Privathaushalte3 und der wachsenden Verbreitung von digitalen Foto- und Videokameras4, welche das einfache Erstellen digitaler Inhalte in großer Menge ermöglichen, noch weiter anschwoll. Der Nutzer sieht sich damit konfrontiert, die wachsende Menge der für sie oder ihn relevanten Inhalte in Dateien und Verzeichnissen zu verwalten, Inhalte ganz unterschiedlicher Art, für deren Nutzung sogar teilweise spezielle Software notwendig ist, Inhalte, die möglicherweise sogar zu ganz unterschiedlichen Aspekten des Lebens des Nutzers gehören: Persönliche Inhalte oder Inhalte mit Bezug zur Ausbildung bzw. dem Beruf.

1 nach Millers Theorie ist die genaue Anzahl genetisch bedingt 2 Neuere Artikel wie [Cha95] vertreten die These, dass die exakte Anzahl der „Chunks“ reizabhängig ist, d.h. dass die Anzahl beispielsweise für Wörter größer ist als für Nichtwörter; die genaue Zahl ist aber in diesem Kontext nicht relevant, die starke Beschränktheit selbst ist heute wissenschaftlich unbestritten 3 vgl. [For08]: Im II. Quartal 2008 gaben 64% der befragten Deutschen über 18 an, das Internet zu nutzen, bei den Männern über 18 waren es sogar 72%. Losgelöst davon gaben 72% der Befragten an, in ihrem Hause existiere ein Internetzugang, unabhängig davon, ob sie ihn persönlich nutzen oder nicht. 4 vgl. [Chr08]: Nach einer Studie des Branchenverbandes BITKOM aus dem Juni 2008 besitzen 53,7% aller deutschen Haushalte eine Digitalkamera 1.2 Ziele der Arbeit 3

Ein heuter durchaus gängiger Weg, die Lösung dieses Problems für den Nutzer einfacher zu Vorstruk- machen, ist es, dem Nutzer innerhalb seines Betriebssystemes einen Satz von Verzeichnissen als turierung Struktur vorzugeben. Microsoft®gibt beispielsweise bei seinem aktuellen Vista Betriebssystem jedem Nutzer in seinem persönlichen Verzeichnis mehrere Verzeichnisse vor wie „Bilder“, „Do- kumente“, „Musik“ und „Videos“, auch viele Linux Distributionen wie Ubuntu1 oder Fedora2 haben sich auf ähnliche Vorgaben festgelegt. Die vorgegebenen Verzeichnisse kategorisieren die dem Nutzer vorliegenden Daten anhand ihres Medientyps, wobei eine sehr grobe, generelle, dafür sehr einfach durchschaubare Trennung vorgenommen wird: Die Inhalte des Nutzers werden eingeteilt in einen generellen Bereich „Dokumente“, der alles, was der Nutzer selbst an Texten erarbeitet und die Texte, die er beispielsweise aus dem Internet herunterläd, an einer Stelle sammelt. Die anderen Ordner sind jeweils Spezialisierungen: Bilder, Videos und Musikdateien unterscheiden sich vor allem durch ihre unterschiedliche Rezeption und ihre unterschiedliche Handhabung. Moderne Computersysteme sind in der Lage, den Typ von Dateien bzw. deren Inhalten zu erkennen und dem Nutzer dementsprechend eine unterschiedliche Repräsentation anzubieten: Bilder werden in einer Art „Albumansicht“ dargestellt, in der jede Datei als kleines Vorschau- bild3 repräsentiert wird, auch für Videodateien werden Vorschaubilder generiert und als Liste ausgegeben und eine Menge von Musikdateien wird als Tabelle angezeigt, in deren Spalten bestimmte Metadaten über die jeweiligen Stücke4 zu finden sind. Diese Form der Vorstrukturierung ist ein Weg, den Limitationen von Dateisystemen, die in Abschnitt 2.5 genauer analysiert werden, aus dem Wege zu gehen. Dateisysteme bieten dem Betriebssystem und damit dem Nutzer oft nur sehr wenige Möglichkeiten, Metadaten über seine Dokumente und Dateien zu verwalten sowie Beziehungen zwischen Dateien zu definieren: Um Dateien zusammenzufassen steht nur das Mittel des Verzeichnisses zur Verfügung, ein Mittel, dessen diverse Limitationen ausführlich in 2.5 ausgearbeitet werden.

1.2 Ziele der Arbeit

Das erste Ziel dieser Arbeit soll es sein, die Limitationen, die auf den Schwächen gängiger neues Datei- Dateisysteme basieren, zu analysieren und einen Lösungsweg zu entwerfen und zu implementie- system ren, der es dem Nutzer erlaubt, die für ihn relevanten Daten, losgelöst von den Möglichkeiten für die Speicherung von Metadaten, die spezielle Dateiformate (vgl. 2.6) anbieten, zu speichern, zu durchsuchen und anhand der Metadaten auf Dateien zuzugreifen. Hierbei sollen einerseits ein gemeinsamer Stamm von Metadaten, der auf alle unterschiedlichen Arten von Dateien bzw. Dateitypen sinnvoll anwendbar ist, gefunden und definiert werden sowie eine Möglichkeit geschaffen werden, typspezifische Erweiterungen der Stammdaten vorzunehmen: Bei einer Musikaufnahme sind zum Beispiel Metadaten wie „Komponist“ relevant, die sich auf viele andere Dateitypen nicht anwenden lassen. Des weiteren soll eine Verschlagwortung (vgl. 2.3)

1 http://ubuntu.com 2 http://fedoraproject.org 3 einem so genannten „Thumbnail“ 4 wie Interpret, Albumtitel oder der Titel des Stückes 4 1 Einleitung

der Dateien ermöglichen, Dateien ganz unterschiedlichen Types und Inhalts zusammenzustellen und so die Menge der Dateien des Nutzers immer wieder aus neuen Sichten zu betrachten.

Abbildung Das zweite Ziel dieser Arbeit ist, die semantischen Relationen (vgl. 2.7) zwischen Dateien von Relationen und anderen Entitäten abzubilden, Entitäten, die außerhalb der Dateien selbst existieren. Diese Entitäten gilt es zu ermitteln und sinnvoll zu definieren. Beispiele für solche Entitäten sind Personen, die zu Dateien in diversen Relationen stehen können: Als Autor, als Bearbeiter, als Besitzer. Während die Relation Besitzer zu Datei für jede Datei möglich ist, gibt es eine große Menge spezieller Relationen, die nur für Bestimmte Medientypen und Entitäten Sinn ergibt: Eine Relation wie „Person, die auf dem Bild abgebildet ist“ ist offensichtlich nur zwischen einer Person und einer Bilddatei sinnhaft. Es sind Möglichkeiten zu schaffen, solcherlei Relationen zu definieren und sie auf Dateien anzuwenden.

Schnitt- Schliesslich sind für das entworfene System Schnittstellen zu schaffen, die es einerseits stellen anderen Anwendungen erlauben, auf die Daten des Systems zuzugreifen, das heißt die es erlauben, die durch den Nutzer ins System eingegebenen Daten und Relationen sinnvoll zum finden von Inhalten oder anderen Entitäten zu nutzen, und die andererseits es dem System ermöglichen, auf Daten, die in anderen Systemen zur Verfügung stehen, zuzugreifen. Dieser Zugriff auf Fremdsysteme soll es ermöglichen, Daten in das System zu importieren, um dem Nutzer den Aufbau des für ihn persönlich relevanten Datenstammes zu vereinfachen. Des weiteren ist ein Weg zu finden, der es auch nicht speziell an das zu entwickelnde System angepassten Anwendungen erlaubt, auf die innerhalb des Systems definierten Verbindungen und Strukturen zuzugreifen, um eine so genannte „Insellösung“1 zu vermeiden.

1.3 Ablauf dieser Arbeit

Nach der Beschreibung der bearbeiteten Problemstellung, der Definition der in dieser Arbeit zu erreichenden Ziele und einer kurzen Beschreibung der Motivation für die Auswahl des Themas im einleitenden Kapitel, wendet sich die Arbeit den theoretischen Grundlagen der Arbeit zu. Es werden unterschiedliche mentale und physische Objekte bezüglich ihrer Eigenschaften untersucht und einige Methoden beleuchtet, die zur Ordnung eben dieser Objekte verwendet werden. Die besprochenen Ordnungsmethoden werden dann in Bezug gesetzt zu den für die Arbeit direkt relevanten Begriffen „Datei“ und Dateisystem.

Analyse Im Folgenden werden verschiedene Technologien und Lösungsansätze, die sich im Theme- relevanter Techno- numfeld der Arbeit verorten, auf ihre Eignung für die Bearbeitung der Problemstellung hin logien untersucht und gegeneinander abgegrenzt. Der Evaluation der vorhandenen Technologien folgt, auf besagter Evaluation aufsetzend, der Entwurf einer Software zur Umsetzung der zuvor formulierten Ziele sowie eine Beschreibung der Programmier- bzw. Laufzeitumgebung, auf der die implementierte Lösung aufsetzt.

1 Unter einer Insellösung versteht man ein technisches System, welches nicht mit verwandten oder ähnli- chen Fremdsystemen zusammenarbeiten kann, vgl auch http://de.wikipedia.org/w/index.php?oldid= 50366645 1.4 Motivation 5

Abschliessend soll die entwickelte Software bezüglich ihrer Leistungsfähigkeit betrachtet werden: Entspricht ihr Leistungsumfang den Zielen der Arbeit? Wo bestehen Möglichkeiten, die Software sinnvoll zu erweitern? Der Blick auf zukünftige Erweiterungsmöglichkeiten soll hierbei auch einen direkten Bezug auf die Architektur und den Entwurf der Software behalten und deutlich machen, wie die Erweiterung sinnvoll umsetzbar ist.

1.4 Motivation

Die Zukunft des Internets liegt, nach dem „Erfinder“ des WWW, Tim Berners-Lee, im Semantic semantic Web. Wie er in seinem Aufsatz The Semantic Web - A new form of Web content that Web is meaningful to computers will unleash a revolution of new possibilities[BLHL01] schreibt, wird eine Anreicherung der Daten, die Online verfügbar sind, erst fortgeschrittene Agentensysteme ermöglichen:

The Semantic Web will bring structure to the meaningful content of Web pages, creating an environment where software agents roaming from page to page can readily carry out sophisticated tasks for users. Such an agent coming to the clinic’s Web page will know not just that the page has keywords such as „treatment, medicine, physical, therapy“ (as might be encoded today) but also that Dr. Hartman works at this clinic on Mondays, Wednesdays and Fridays and that the script takes a date range in yyyy-mm-dd format and returns appointment times. And it will „know“ all this without needing artificial intelligence on the scale of 2001’s Hal or Star Wars’s C-3PO. Instead these semantics were encoded into the Web page when the clinic’s office manager (who never took Comp Sci 101) massaged it into shape using off-the-shelf software for writing Semantic Web pages along with resources listed on the Physical Therapy Association’s site.

Die Übertragung desselben Gedanken auf den so genannten „Desktop“, das heisst auf den Semantic lokalen Arbeitsrechner einer Person und die Art wie er sich ihr darstellt, ist bekannt unter Desktop dem Namen semantic Desktop. Im Gegensatz zum semantic Web, welches langsam aber sicher seinen Einzug in den „Mainstream“ findet, ist der semantic Desktop in seiner Entwicklung allerdings noch weit zurück, sicherlich auch, weil der Desktop und seine Software, im Gegensatz zum Web, nicht von einem Standartisierungsgremium wie dem W3C kontrolliert wird. Die grundlegenden Ideen sind allerdings ähnlich: Es soll, durch das Hinzufügen von Me- tadaten zu den vorhandenen Daten, ermöglicht werden, intelligente Software zu entwickeln, Software, die es einerseits dem Nutzer ermöglicht, seine Daten besser zu organisieren und zu finden, und andererseits anderen Programmen erlaubt, auf die strukturierten Daten des Nutzers zuzugreifen und sie im korrekten Kontext zu verwenden.

Der konventionelle Desktop hat sich konzeptionell seit einigen Jahren nicht weiterentwickelt: der konventi- Es stehen dem Nutzer Dateien zur Verfügung, die er in Verzeichnissen einordnen kann. onelle Einige spezielle Dateitypen bieten ihm auch die Möglichkeit, Metadaten zu pflegen, allerdings Desktop immer in speziellen Anwendungen. Die Übertragung der sich im World Wide Web bewährt habenden Technologien und Strategien auf den Desktop kann diesem neue Impulse geben, sich weiterzuentwickeln. Die Dichotomie zwischen dem oft zitierten „Web 2.0“ und dem Desktop, welche oft als evolutionärer Schritt auf dem Weg weg vom Desktop, hin zu Web-Applikationen 6 1 Einleitung

interpretiert wird, lässt sich auch auf anderem Wege auflösen - ohne die Vorteile von lokal laufenden Anwendungen (wie zum Beispiel die hohe Flexibilität bei der Gestaltung von Benutzungsoberflächen) aufzugeben.

Entwick- Die Vorteile und (Neu-)Entwicklungen des WWW auf den Desktop zu bringen ist nicht nur lungen des WWW als Technologietransfusion, die das „Leben“ des Desktops verlängert, zu sehen, sondern vor allem die Schaffung einer Basis, auf der „der Desktop“ und „das Web“ produktiv und intelligent zusammenarbeiten können um dem Nutzer ein besseres Umgehen mit dem Computer zu bieten. In dieses Programm gliedern sich die Ziele dieser Arbeit ein, als ein Versuch, den semantic Desktop ein Stück weiter zu entwerfen und zu implementieren.

1.5 Bestehende Lösungen

Die Recherche im World Wide Web zeigt, dass im Themenkomplex semantic Desktop die Anzahl der ernstzunehmenden Lösungen nicht groß ist: So existieren diverse Einzelanwendungen, die einen kleinen Teil des Spektrums in gewisser Weise „semantisch hochwertiger“ abdecken, als das noch vor einigen Jahren der Fall war (zum Beispiel Audioplayer wie die bekannte Software iTunes1 von Apple oder Fotoverwaltungssoftware wie Googles Picasa2) aber Lösungen, die das Problem grundlegend angehen sind selten.

1.5.1 Das NEPOMUK Projekt

Das NEPOMUK Projekt3 ist ein von der EU mit 11.500.000 Euro gefördertes Projekt, welches am 01. Januar 2006 startete und noch bis zum 31. Dezember 2008 weiter läuft. Nach seiner eigenen Definition zielt das Nepomuk Projekt auf das folgende ab[NEP08]:

To build the Semantic Desktop, NEPOMUK’s objectives are to develop the methods, data structures and services necessary • to annotate and link arbitrary information on the local desktop, across different media types, file formats, and applications. Semantic web data structures and techniques will be applied and adapted to achieve this goal. • to articulate and visualize the user’s ideas and transform them into semantic information. We will extend easy-to-use wiki technology and integrate it with annotation mechanisms. • to integrate content creation and processing with the users’ way of structuring their work. Key approach will be the integration of agile process modelling concepts with the information generation and structuring.

1 http://www.apple.com/itunes/ 2 http://picasa.google.com/ 3 http://nepomuk.semanticdesktop.org 1.6 Zielgruppe 7

Die umrissenen Metadatenkonstrukte werden bei NEPOMUK aber vor allem als Grund- lage für ein vernetztes System gesehen1: Die Metadaten des einen Rechners sollen mit den Metadaten anderer Rechner, vor allem auch in großen Firmen wie SAP2 zusammengebracht werden um eine Art Gesamtwissen des Netzes zu repräsentieren. Damit richtet sich NEPO- MUK eher als ein betriebliches Wissensmanagement aus, mit starkem Fokus auf betriebliche Organisationseinheiten.

Hier unterscheidet sich das Ziel dieser Arbeit doch merklich von denen des NEPOMUK NEPOMUK als Basis Projektes: Wo NEPOMUK das Wissen von Organisationseinheiten zu sammeln sucht, liegt eines ver- netzten der Fokus dieser Arbeit auf der Entwicklung eines Systemes für den Einzelnutzer, welches, Systems eben weil es nicht dazu gedacht ist, eine Art „Konsenzwissen“ in der Abteilung zu sammeln, vom Nutzer mit einem ganz anderen Fokus angegangen wird3 Auch legt diese Arbeit einen deutlicheren Schwerpunkt auf den Begriff der Relation, die als ganz zentrales Ordnungs- und Strukturelement dem Nutzer helfen soll, seine Sicht und sein Verständnis seiner Welt und Umgebung im System zu modellieren.

1.6 Zielgruppe

Die Zielgruppe des zu entwickelnden Systems ist leicht zu umreissen: Jeder Computernutzer, welcher mit nicht-trivialen Mengen von Dateien und Daten zu tun hat. Das erstreckt sich vom Sachbearbeiter in einer Versicherung über Wissenschaftler, Studenten, Schüler und Lehrer bis hin zum Heimuser, der seine digitalen Fotos verwalten will.

Das System will gerade eben auch die Nutzer ansprechen, die nicht auf ein großes innerbe- der einzelne triebliches Wissensmanagementsystem zugreifen können, denen nicht von einer IT-Abteilung Nutzer Platformen bereit gestellt werden, um ihr Wissen strukturiert abzulegen. Jeder, der schon einmal vor dem Problem stand, eine bestimmte Datei schnell wiederfinden zu wollen, jeder, der Probleme hat, die große Menge aus Dokumenten, die er noch lesen und durcharbeiten wollte, zu organisieren und zu überblicken, ist Teil der Zielgruppe. Die Zielgruppe ist der einzelne Nutzer und seine Dateien, die er nach seinen ganz persönli- chen Vorstellungen und Denkmodellen organisieren will.

1.6.1 Welche Aufgaben erleichtert das zu entwickelnde System?

Das zu entwickelnde System wird den Zugriff auf die eigenen Dateien und Daten vereinfachen, Entwicklung eines persön- indem diese durch den Nutzer in ein System gebracht werden, welches seinen persönlichen lichen Denk- und Arbeitsprozessen entspricht. Dabei geht es nicht nur um eine simple „Suche“ im Modells Inhalt der Dateien oder ihren Metadaten, sondern darum, dem Nutzer die Gelegenheit zu geben, aus seinen Daten ein angemessenes Modell seiner Sicht auf die Welt zu konstruieren.

1 weshalb das NEPOMUK Projekt auch vom Social Semantic Desktop spricht 2 die „Project Objectives“ Seite[NEP08] gibt genau Installationen von Systemen bei SAP, PRC und dam Institut Pasteur als Main Results an 3 In der Beschreibung einiger Einsatzszenarien in 1.6.2 wird diese Betonung des Einzelnen am Beispiel deutlicher erörtert. 8 1 Einleitung

Im Idealfall ergeben sich dadurch für den Nutzer neue Einsichten über die Beziehungen, die seine Daten untereinander und zu wichtigen Entitäten seines Lebens haben.

1.6.2 Einsatzszenarien

Im folgenden sollen einige simple Szenarien entworfen werden, die illustrieren, auf welche Weise das zu entwickelnde System Vorgänge vereinfachen kann.

1.6.2.1 Szenario 1

Ein Privatanwender besitzt ein große Menge unterschiedlichster Dateien: Bilder, Musik, Fotos &ct. Bisher sortiert er seine Dateien einfach anhand ihres Inhaltstypes in Verzeichnisse ein, allerdings hilft ihm das nicht bei den für ihn relevanten Fragen: Er will im System seine Frau auswählen und dann nicht nur ihre Daten sehen, sondern auch die Fotos, auf denen sie abgebildet ist. Im Wittgenstein System hat er einfach beim Hinzufügen der Fotos solcherlei Relationen mit angegeben. So sieht er nicht nur die Fotos, auf denen seine Frau abgebildet ist, sondern auch die, die seine Frau als Photograph gemacht hat. Da er von Zeit zu Zeit seine digitalen Photos als „reale“ Fotos drucken lässt, um sie seiner Famile zu schicken, hat er des weiteren ein Metadatenfeld für Fotos erzegt, in dem er markiert, ob er das Foto gedruckt hat. Auch eine neue Relation hat er erzeugt, um für ein Foto einfach markieren zu können, wem er einen Abzug des Fotos hat zukommen lassen. Betrachtet er also ein Foto im Detail so kann er nicht nur sehr schnell auf den Namen des Photographen oder der Personen auf seinem Bild zugreifen, sondern er kann direkt sehen, wem er das Bild hat zukommen lassen.

1.6.2.2 Szenario 2

Ein Freiberufler nutzt seinen Rechner nicht nur privat sondern auch beruflich. Selbstverständ- lich haben sich auch für ihn diverse Dateien und Daten unterschiedlichen Typs angesammelt. Um seine Daten auf einfache Weise getrennt betrachten zu können, hängt er an alles private den Tag „privat“ und an alle Dateien, die für seinen Beruf relevant sind den Tag „job“. Auf einem Treffen mit Kunden war auch seine Familie zugegen und es wurden einige Fotos gemacht. In Wittgenstein stellt sich für ihn nicht die Frage, ob die Fotos in den Ordner „job“ oder den Ordner „privat“ gehören: Sie sind mit beidem getaggt und werden so in beiden Kontexten gefunden. Kommt nun der Fall, dass der Kunde nach dem einen Foto fragt, auf dem der Sohn des Kunden und der Sohn des Freiberuflers miteinander spielten, ist das Auffinden innerhalb von Wittgenstein trivial: Der Freiberufler lässt sich alle Dateien vom Typ „Foto“, die mit dem Tag „job“ markiert sind und auf denen sein Sohn abgebildet ist1 auflisten und hat so schnell und einfach das richtige Bild gefunden.

1 eine Relation wie sie zuvor im Szenario 1 beschrieben wurde KAPITEL 2

Theoretische Grundlagen

Nachdem im vorigen Kapitel das Problem, dem sich diese Arbeit widmet, umrissen wurde, stellt das folgende Kapitel die Grundlagen, auf denen diese Arbeit fusst zusammen. Hierbei werden sowohl die Definition, Eigenschaften und Historie einiger relevanter Begriffe auf- gearbeitet als auch im speziellen nochmal detailliert die Probleme, die die Grundlage der Gesamtproblemstellung dieser Arbeit bilden, analysiert.

2.1 Die Beschaffenheit physischer Objekte und ihrer Organisationssysteme

Als „physische Objekte“ bezeichnen wir die Entitäten, die wir mittels unseres Wahrneh- physische mungsapparates, unserer Sinne, wahrnehmen können. Im Rahmen dieser Arbeit wird eine Objekte Position vertreten, die man in der Philosophie als Realismus [San99] bezeichnet. Realismus ist die Denkschule, nach der Phänomene ausserhalb des menschlichen Geistes existieren und der Mensch diese Phänomene wahrnehmen kann; im Realismus wird also die Existenz einer realen Welt angenommen (im Gegensatz beispielsweise zu Positionen wie dem Solipsismus, der annimmt, dass nur das eigene Selbst wirklich ist, während alle anderen „Ichs“ und die „reale Welt“ nur Bewusstseinsinhalte des denkenden Selbsts sind), oder wie es die Enzyklopedia Philosophie sagt: »Realismus bezeichnet als ontologischer und erkenntnistheoretischer Begriff im weitesten Sinne zwei Annahmen: (a) Es gibt Dinge ausser mir; (b) im Prinzip ist die Aussenwelt meiner Erkenntnis zugänglich.«[San99][Seite 1346] Nur auf der Basis dieser Annahme ist die vorgenommene Trennung zwischen den physischen Objekten, den Dingen, und den mentalen Objekten überhaupt denkbar. Im alltäglichen Leben ist die Realismusfrage in dieser Deutlichkeit kaum von Bedeutung - die Existenz der Aussenwelt wird schon alleine aus Proktikabilitätsgründen als gegeben betrachtet - doch wird an dieser Stelle in der gegebenen Deutlichkeit darauf verwiesen, um die Trennung der physischen von den mentalen Objekten überhaupt denkbar zu machen. Physische Objekte haben, trotz ihrer großen Diversität, einige Gemeinsamkeiten, alleine aufgrund der Tatsache, dass sie physisch sind, das heisst alleine, weil sie innerhalb des Raumes existieren. 10 2 Theoretische Grundlagen

So kann sich ein physisches Objekt jederzeit nur an genau einem Ort in der Raumzeit befinden1. Umgekehrt kann an einem Ort immer nur genau ein physisches Objekt sein. Diese Eigenart macht es vollständig unmöglich, ein physisches Objekt in mehreren unterschiedlichen Organisationsystemen gleicher Ebene unterzubringen. Was bedeutet in diesem Kontext der Begriff „Ebene“? verschachtelte Es ist problemlos möglich, mehrere Organisationssysteme ineinander zu verschachteln: In Organisations- systeme einen Schrank können mehrere Kisten gestellt werden. Ein Objekt in einer der Kisten (nennen wir sie KisteX) ist so gleichzeitig innerhalb des Organisationssystems „Schrank“ wie auch innerhalb des Organisationssystems „KisteX“. KisteX ist ebenfalls, als physisches Objekt, ins System „Schrank“ eingeordnet (und mit ihm alle Objekte innerhalb der Kiste). „Schrank“ ist also in diesem Falle auf einer höheren Ebene angesiedelt als „KisteX“. Der Zwang eines physischen Objektes, immer an genau einer Stelle in der Raumzeit zu sein, beschränkt die Möglichkeiten, das Objekt in auf physischen Objekten basierenden Systemen zu organisieren: ObjektY ist organisiert in KisteX, welche sich in Schrank1 befindet; ObjektY ist also in das System Schrank1 eingeordnet und dort wiederum in KisteX. Das ObjektY kann sich nun keinesfalls auch innerhalb von Schrank2 befinden, selbst wenn es auch dort sinnvoll einsortiert werden könnte. Nicht jedes Organisationssystem ist allerdings selber ein physisches Objekt: Dinge lassen sich beispielsweise eben so gut rein räumlich organisieren, indem man Zusammengehörigkeit nicht durch einen physischen Container sondern durch räumliche Nähe ausdrückt. Räumliche Nähe ist selbst kein physisches Objekt sondern eine Relation, die man nur auf physische Objekte anwenden kann. Sie selbst ist nicht physisch, ist aber nur innerhalb eines Raumes auf Objekte innerhalb dieses Raumes anwend- und denkbar.

Identität Ein weiteres Merkmal aller physischen Objekte ist, dass die Identität zweier Objekte sehr von Objekten leicht eindeutig festzustellen ist: Das logische Identitätsprinzip besagt, dass zwei Objekte X und Y genau dann identisch sind, wenn alle ihre Eigenschaften identisch sind. Da aber jedes Objekt zu jedem Zeitpunkt nur an genau einem Ort und an jedem Ort nur genau ein Objekt sein kann, folgt, dass der Vergleich der räumlichen Position der beiden Objekte X und Y zu einem bestimmten Zeitpunkt reicht, um die Identität festzustellen: Wenn X und Y zu Zeitpunkt Z am selben Ort sind, sind sie identisch.

2.1.1 Mentale Organisationssysteme

Neben den auf physischen Relationen basierenden Organisationssystemen gibt es des weiteren noch rein mentale Organisationssysteme, die sich nur über ein intellektuelles Konstrukt des organisierenden menschlichen Geistes konstituieren: Die Menge aller Gegenstände, die der Ordnende „schön“findet, ist beispielsweise ein rein mentales Ordnungssystem. Die Zugehö- rigkeit oder die Nicht-Zugehörigkeit zu diesem System lässt sich nur vom Ordnenden selbst2

1 Das Erörtern der philosophische Frage, ob Universalien wie „die Röte“ oder die Naturgesetze Objekte der physischen Welt sind, sei an dieser Stelle anderen überlassen, für diese Arbeit schlagen wir sie der Einfachheit halber den mentalen Objekten (vgl. 2.2) zu, da es für den betrachteten Problembereich nicht relevant ist 2 bzw. anderen Menschen, denen der Ordnende seine Kriterien kommuniziert hat 2.1 Die Beschaffenheit physischer Objekte und ihrer Organisationssysteme 11 vornehmen, im Gegensatz beispielsweise zum Ordungssystem „räumliche Nähe“, dessen definie- rende Qualität (Distanz im Raum) für jeden Beobachter mit intaktem Wahrnehmunsapparat evident ist.

Mentale Ordnungssysteme unterliegen nicht den Beschränkungen, die für auf physischen Unterschiede zu physischen Objekten basierende Ordnungssysteme gelten: Ein physisches Objekt kann beispielsweise in Ordungs- beliebig viele mentales Ordnungssysteme gleichzeitig einsortiert werden, es kann gleichzeitig systemen im System „alle schönen Gegenstände“und im System „alle roten Gegenstände“sein, obwohl beide Systeme keineswegs ineinander verschachtelte Ordnungssysteme darstellen. Würde man diese mentalen Systeme nun aber durch physische Container darstellen, so könnte ein Objekt nicht gleichzeitig in beiden Containern sein. Auch innerhalb von mentalen Systemen lassen sich Systeme verschachteln: Die Einteilung der Erde in Staaten beispielsweise ist ein Organisationssystem, welches räumliche Nähe, eine mentales Ordungssystem, verwendet, um einen bestimmten Punkt auf der Erde einem Staat zuzuordnen1. Innerhalb dieses Staatenorganisationsschemas jedoch sind die einzelnen Staaten wiederum in kleinere, ebenfalls räumlich basierte, Systeme gegliedert: Die Bundesrepublik Deutschland beispielsweise in ihre Bundesländer.

Eine weitere Eigenschaft aller physischen Objekte ist, dass sie einen gewissen Raum einneh- Begrenztheit physischer men und auch diese Eigenart hat Konsequenzen für die Organisationssysteme innerhalb derer Objekte bestimmte Objekte organisiert werden können: Jeder Container, egal wie groß er sein mag, kann nur eine sehr beschränkte Anzahl von Objekten aufnehmen.

Abbildung 2.1: Ebenen von Ordungssystemen

Dieses Problem findet seinen Niederschlag an vielen Stellen im Alltag: Beim Anlegen eines neuen Ordnungssystems ist die zu erwartende Anzahl bzw. der zu erwartende räumliche

1 Eine Ausnahme stellen hier die Bereiche der so genannten „hohen See“dar, die keinem Staate zugeordnet sind und somit für das beschriebene Organisationssystem so zu sagen einen weiteren Staat bilden namens „unzugeordnet“[F.A89] 12 2 Theoretische Grundlagen

Umfang der Objekte, die es aufnehmen soll, von großer Relevanz; eine Schublade, die zu klein ist für meine Löffel, Gabeln und Messer ist nicht geeignet als Besteckschublade. Gerade bei Ordungssystemen, deren Inhalt sich häufig vergrößert, wie beispielsweise das Bücherregal eines Wissenschaftlers, ist das Maximumum des Fassungsvermögens schnell erreicht. In einem solchen Falle bleiben als Optionen entweder das Ersetzen des alten Containers durch einen neuen, mit größerem Fassungsvermögen, oder das „Erweitern“des Systems durch hinzufügen weiterer Container. Solche Mehr-Container-Ordnungssysteme heben das erweiterte Ordnungssystem auf eine höhere Ebene, indem sie eine neue Zwischenebene konstruieren. Ein Beispiel für eine solchen solchen Fall zeigt Abbildung 2.1: Da im ersten Fall das gesamte Ordnungssystem nur einen physischen Repräsentanten hat, sind beide Entitäten nahezu identisch, die physische Repräsentation umfasst das gesamte Organisationssystem, was die physische Repräsentation und das Organisationssystem scheinbar auf einer Ebene zusammenbringt1. Im Falle, dass sich das Organisationssystem jedoch über mehrere physi- sche Repräsentanten spannt, ist die Trennung zwischen dem Organisationsschema und den physischen Repräsentanten allerdings offensichtlich und notwendig, wie Abbildung 2.1 zeigt.

2.2 Die Beschaffenheit mentaler Objekte

Wie schon in 2.1.1 beschrieben, gibt es mentale Organisationssysteme, die sich nicht über einen physischen Gegenstand wie ein Regal, einen Zaun oder eine Schachtel konstituieren, sondern deren Repräsentanz wiederum nur ein Objekt innerhalb eines menschlichen Geistes ist.

mentale Solcherlei Organisationssysteme gibt es, wie schon beschrieben, diverse, doch sind nicht alle Organisations- systeme mentalen Objekte auch Organisationssysteme. Betrachten wir als Beispiel das, offensichtlich mentale, Organisationssystem, mithilfe dessen der Mensch die ihm angenehmen Geschmäcker von den unangenehmen trennt. Die unterschiedlichen Geschmacksrichtungen sind das, was Bertrand Russel in Our Knowledge of the External World[Rus93] „Sinnesdaten“ nennt: Unsere Sinne nehmen Signale aus der realen Welt2 auf und sind in der Lage, diese unserem Geiste zur Verfügung zu stellen. Die Sinnesdaten, auf denen der Geist dann operiert, auf denen er seine Entscheidungen trifft, sind rein mental und haben selber keine direkte Verbindung mehr mit der realen Welt. Des weiteren sind die Gedanken einer Person selbstverständlich rein mentale Objekte. Denkt eine Person nach über Gegenstände der realen Welt, so können diese Denkprozesse offensichtlich nur auf mentalen Objekten stattfinden: Aus den interpretierten Sinnesdaten werden also mentale Objekte, die Objekte der realen Welt repräsentieren. Diese mentalen Objekte basieren aber zumeist nicht nur auf einem Satz aus Sinnesdaten, sondern werden, den Mechanismen des Wahrnehmungs- und Denkapparates entsprechend, mit jedem weiteren Kontakt zum entsprechenden Objekt der realen Welt angereichert und erweitert. Ein Beispiel: Ein Mensch A ist in der Lage eine andere Person B alleine aufgrund eines Passbildes zu

1 Streng genommen sind beide Entitäten auf unterschiedlichen Ebenen, doch diese Unterscheidung ist in diesem Falle für den betrachteten Fall irrelevant 2 vgl. 2.1 2.2 Die Beschaffenheit mentaler Objekte 13 identifizieren1. Wenn A nun B im realen Leben trifft, bekommt er deutlich mehr Sinnesdaten über B geliefert wie Statur, Geruch und eine Ansicht von der Seite. Alle diese neuen Sinnes- eindrücke werden dem mentalen Objekt, welches Person B repräsentiert, zugeschlagen, die mentale Repräsentation von B wird vollständiger. Mentale Objekte haben keine räumliche Ausdehnung und logischerweise auch keinen Ort, an dem sie existieren. Sie sind im Verstand des Denkenden und stehen auch nur ihm direkt zur Verfügung. Wenn zwei Personen über ein reales Objekt sprechen wollen, dann können sie das betreffende Objekt teilen: Beide können Sinnesdaten desselben Objektes sammeln und sich dann über das Objekt austauschen. So ist sicher zu stellen, dass die Grundlage der mentalen Repräsentation des Objektes bei beiden Sprechern identisch ist. Bei mentalen Objekten ist der Transfer zwischen Menschen nur über das Vehikel der Sprache möglich, ein Medium, welches keineswegs so eindeutig ähnliche Ergebnisse liefert wie der Austausch physischer Objekte.

Weil mentale Objekte keine räumliche Ausdehnung haben, sind Ordnungssysteme auf ihnen unbegrenzte offensichtlich nicht durch räumliche Begrenzungen eingeschränkt: Das Ordungssystem, in dem Kapazität eine Person alle angenehmen Gerüche einsortiert kann immer noch weitere Objekte enthalten2, es ist nicht irgendwann „voll“; diese Eigenschaft ist einer der markantesten Unterschiede zwischen mentalen Objekten und physischen. Aus ähnlichen Gründen kann ein mentales Objekt problemlos in mehreren mentalen Orga- nisationssystemen gleicher Ebene einsortiert sein, da die mentalen Objekte nicht an genau einen Punkt im Raum gebunden sind.

2.2.1 Transfer von mentalen Objekten in die reale Welt

Wie schon gesehen stammen einige mentale Objekte mittelbar aus der realen Welt: Sie stellen mentale Repräsentationen realer Gegenstände dar, die aus Sinnesdaten abstrahiert wurden. Auch der entgegengesetzte Weg steht zur Verfügung: Mentalen Objekte werden vom Menschen in der realen Welt Repräsentationen geschaffen; das bekannteste Beispiel dafür ist sicherlich die Schrift. Wie Abbildung 2.2 zeigt, sind aber die erzeugten Repräsentationen kein Zirkel: Die physische Repräsentation der mentalen Repräsentation eines physischen Objektes und das Objekt selber sind keineswegs identisch - sie sind sich für den Außenstehenden nicht einmal zwingenderweise ähnlich. Betrachten wir den in Abbildung 2.2 dargestellten Vorgang genauer: PersonB erhält Sinnes- daten, die auf ein Objekt PersonA zurückgehen und konstruiert eine geistige Repräsentation. Auf Basis dieser geistigen Repräsentation erzeugt PersonB nun eine physische Repräsentation, beispielsweise malt PersonB ein Bild von PersonA oder beschreibt sie in einem Text. PersonA und das gemalte Bild von PersonA sind offensichtlich keineswegs identisch, in vielen Fällen (zum Beispiel, wenn PersonB ein sehr junges Kind oder Pablo Picasso innerhalb seiner kubis-

1 so denn die gesuchte Person B nicht zufällig ein eineiiger Zwilling ist, dessen Geschwister ein sehr ähnliches Gesicht haben 2 die Einzige Beschränkung der mentalen Organisationssysteme ist offensichtlich die geistige Kapazität und Merkfähigkeit des Menschen, welche aber in gewisser Weise eine physisch beschränkte ist: Das Gehirn des Menschen ist physisch und damit auch gewissen Limitationen unterworfen 14 2 Theoretische Grundlagen

Abbildung 2.2: Bildung von Repräsentationen

tischen Periode ist) sind die beiden Objekte sind nicht mal ansatzweise ähnlich. Für einen dritten mögen die beiden Objekte sogar so unterschiedlich sein, dass eine Identifikation des einen als Repräsentation des anderen völlig absurd erscheint. Doch, auch wenn die Identität oder Entsprechung der Repräsentationen nicht immer ganz einfach zu kommunizieren ist, so hat der Transfer von mentalen Objekten in physische Repräsentationen einen ganz zentralen Vorteil, der alle Schwierigkeiten aufwiegt: Er ermöglicht es, die Vorgehensweisen, die sonst nur auf physische Objekte anwendbar sind, indirekt auf mentale Objekte anzuwenden. Nehmen wir die schon erwähnte Gruppierung von physischen Objekten über räumliche Nähe. Sobald wir unsere mentalen Objekte in Repräsentationen auf ein Blatt Papier bringen können wir mentale Objekte anhand von Nähe gruppieren und ordnen. Es gelten für die physischen Repräsentationen natürlich alle Beschränkungen, die allen physischen Objekten gemein sind, doch gibt es viele Fälle in denen die Beschränkungen weniger störend als die Möglichkeiten der physischen Repräsentanz hilfreich sind, beispielsweise in Kommunikationskontexten in denen die physische Repräsentation Missverständnisse vermeidet und eine gemeinsame Begriffsbasis bieten kann.

2.2.2 Vergleich von virtuellen Inhalten mit physischen und mentalen Objekten

Wie schon in 1.1.1 angedeutet, sind die „virtuellen Inhalte“ seit dem Advent des Computers im allgemeinen und des Internets im speziellen eine noch verhältnismäßig neue Klasse von Objekten, die einen gewissen Sonderstatus besitzen. Einerseits haben virtuelle Inhalte (meist in Form von Dateien vorliegend) eine physische Qualität: Dateien werden auf den unterschiedlichesten Datenträgern gespeichert, deren zu- 2.2 Die Beschaffenheit mentaler Objekte 15

grundeliegende Technologien zwar oft kaum Schnittmengen besitzen, die aber doch immer alle Qualitäten physischer Objekte haben, vor allem ihre Begrenztheit. Die Größe der Kapazi- tät moderner Datenträger, im speziellen sind hier Festplatten zu nennen, ist in den letzten Jahren immens gewachsen: Wo IBMs Deskstar 16GP Festplatte 1997 noch mit 16,8 Gigabyte Kapazität aufwarten konnte, stellte Hitatchi 2007 die erste Festplatte mit einem Terabyte Kapazität vor. Innerhalb von 10 Jahren war die Kapazität fast um den Faktor 60 gewachsen. Dateien bzw. die in ihnen gespeicherten Daten liegen als Bitmuster auf den Datenträgern vor. Je nach Interpretation, wobei Interpretation in diesem Falle das öffnen der Datei mit einem speziellen Anwendungsprogramm bedeutet, kann dasselbe Bitmuster sogar ganz unter- schiedliche Bedeutungen haben. Betrachten wir die folgende Datei und ihren Inhalt zuerst einmal als reine Textdatei:

1 2 3 4 5 6 Seiteninhalt 7 8 Listing 2.1: uninterpretierter Dateiinhalt

Dasselbe Bitmuster geöffnet mit einem Programm, welches die Auszeichnussprache HTML erkennen kann, ergibt etwas wie das folgende:

1 2 3 Seitentitel 4 5 Seiteninhalt 6 7 Listing 2.2: interpretierter Dateiinhalt

Der Inhalt der Datei ist in beiden Fällen völlig identisch und doch ist ihre Bedeutung keineswegs diesselbe. Öffnen wir diesselbe Datei mit einem Webbrowser so werden einige Textelemente plötzlich als ganz spezielle Formatierungselemente interpretiert und die Titelleiste des Webbrowsers zeigt „Seitentitel“ an (vgl. Abbildung 2.3). Derselbe Datenstrom bekommt durch eine andere Interpretation völlig andere Bedeutungen. Wenn eine Person über eine MP31 Datei spricht, so meint er im seltensten Fall die Bitmuster auf seiner Festplatte oder seinem tragbaren Abspielgerät, er meint „das Lied“ welches zu hören ist, wenn die MP3 Datei von einer geeigneten Software dekodiert und abgespielt wird.

Hier zeigt sich die besondere Qualität virtueller Inhalte: Für den Besitzer einer Datei ist besondere Qualität nicht ihre physische Wirklichkeit relevant, für ihn ist die Datei das, was sie bedeutet, ihr virtueller interpretierter Inhalt. Der Unterschied ist immens, denn das, was die Datei bedeutet ist keine Inhalte

1 MP3 ist die Abkürzung für das MPEG Layer III, ein Dateiformat zum verlustbehafteten Komprimieren von Audiodaten 16 2 Theoretische Grundlagen

Abbildung 2.3: Datei interpretiert vom Browser

physisches Objekt sondern ein mentales. Die physische Realität der Datei als Bitmuster auf einem Datenträger ist der archivierbare, der speicherbare, der transferbare, der kopierbare Repräsentant des Inhaltes, den die Datei für den Nutzer enthält. Dateien haben also einen gewissen Janus-Charakter, einerseits als physisches Objekt „Bit- muster auf Datenträgern“ und andererseits als Repräsentant eines mentalen Objektes „Inhalt der Datei“. Dieser Doppelcharakter wird sehr relevant werden, wenn wir uns später mit Konzepten zur Organisation von Dateien beschäftigen.

2.3 Der Begriff des „Tags“ der Unterschied zum Begriff der Kategorie

Die beiden Begriffe der Kategorie und des Tags1 sind von maßgeblicher Bedeutung für die vorliegende Aufgabe. Um die beiden Konzepte, die auf den ersten Blick recht ähnlich sein mögen, es auf den zweiten Blick aber keineswegs sind, voneinander abzugrenzen, sollen beide Begriffe im folgendenkurz umrissen werden.

2.3.1 Der Begriff der Kategorie

Aristoteles Die moderne Kategorienlehre findet ihren Ursprung in der Arbeit des griechischen Philosophen

1 „Tag“ ist der englische Begiff für „Etikett“ oder „Anhänger“, welchen ich in dieser Arbeit aufgrund seiner größeren Verbreitung in technischen Systemen anstatt des in diesem Kontext weniger gebräuchlichen Begriffes „Schlagwort“ verwende 2.3 Der Begriff des „Tags“ der Unterschied zum Begriff der Kategorie 17

Aristoteles1. Ähnlich wie sein Lehrmeister Plato vertrat Aristoteles die These, die Welt lasse sich in eine ganz bestimmte Ordnung bringen. In den „Kategorien“ [Ari98] erarbeitet Aristoteles die Begriffe, die zur Bestimmung der „richtigen“ Kategorien zu verwenden sind: Die Ordnung der Welt in Kategorien ist seiner Meinung nach keineswegs zufällig oder beliebig, die Einteilung der Welt und ihrer Dinge in Kategorien basiert auf dem „Wesen“, der „Essenz“ der Dinge2. Das Wesen eines Dinges ist seine definierende Eigenschaft, das, was übrig bleibt, wenn man alles zufällige oder beliebige subtrahiert: Die Haarfarbe beispielsweise ist nicht wesentlich für einen Menschen, es gibt Menschen nahezu jeder Haarfarbe und auch Menschen vollständig ohne Haare, wesentlich für den Menschen ist hingegen seine Vernunftbegabtheit, ohne die ein Mensch nicht denkbar ist.

Abbildung 2.4: Der Kategorienbaum, welcher die Dinge der Welt repräsentiert (simplifiziert)

Nach Aristoteles lässt sich so die Welt, nur über Wesensbestimmungen in einem hierarchi- schen, geordneten Baum aus Kategorien abbilden, welcher in seinen Blättern dann alle Dinge, physisch und nicht-physisch, enthält; Diagramm 2.4 zeigt ein stark verkürztes Beispiel. In Diagramm 2.4 können wir sehen wie Aristoteles die Welt einteilen würde: Sokrates ist ein Mensch, ein Mensch ist ein vernunftbegabtes Lebewesen, jedes vernunftbegabte Lebewesen ist ein Lebewesen, jedes Lebewesen ist ein physisches Objekt. Die Tatsache, dass wir wissen, das Sokrates ein Mensch ist, fasst für uns so den gesamten Weg durch den Baum zusammen: Wir müssen nicht extra dazu sagen, dass Sokrates ein Lebewesen ist, weil das in seiner Wesenheit als Mensch eingeschlossen ist. Genauso wissen wir, dass Sokrates kein Tier ist, denn die

1 384 v.Chr - 322 v.Chr, bekannt als Schüler Platos und Erzieher Alexanders des Großen 2 Aristoteles verwendet den griechischen Begriff „ousía“ 18 2 Theoretische Grundlagen

Kategorie „Tier“ liegt nicht auf dem Weg von der Wurzel des Baumes hinunter zum Blatt „Sokrates“.

Das „Wesen“ Dabei ist der Begriff des „Wesens“ die unanfechtbare Grundlage: Das wesentliche an Sokrates eines Dinges ist sein Menschsein. Er kann seinen Bart abschneiden, er kann in einem Unfall sein Bein verlieren, er kann seinen Namen ändern: All das ist unwesentlich. Aber sein Menschsein kann er nicht ablegen ohne sich im Wesen selbst zu verändern. Damit ist auch sofort offensichtlich, dass die Unterteilungen auf einer Ebene (in Diagramm 2.4 beispielsweise „physische Objekte“ und „nicht-physische Objekte“ trennscharf sind: Eine Kategorie oder ein Objekt kann nur in genau einer Kategorie sein. Wäre ein Objekt in zwei Kategorien, hätte das Objekt zwei „Wesen“, was ausgeschlossen ist. Und da Kategorien Wesensdefinitionendarstellen, können sie sich offensichtlich nicht überschneiden.

Taxonomien Auf diese Art und Weise erlauben Kategorienhierarchien, Wissen zusammenzufassen und zu strukturieren: In der Biologie ist es beispielsweise üblich, Arten von Lebenwesen zu taxono- mieren, das heisst in einen hierarchischen System zu erfassen, welches die verwandschaftlichen Beziehungen von Arten zueinander erfasst. Das noch heute verwendete System geht zurück auf den schwedischen Wissenschaftler Carl von Linné, welcher diese Form der Ordnung 1735 in seinem Werk Systema Naturae1 das erste mal beschrieb. Auf im Softwaredesign finden sich solche Bäume: In Vererbungshierarchien simpler objekt-orientierter Programmiersprachen2, in denen die Klassen auf diese Art und Weise strukturiert werden. Aufgrund der Wesenshaftigkeit der Kategorisierung werden solche Hierarchien üblicherweise von Experten erzeugt: Um eine neue Art in die biologische Taxonomie korrekt einzuordnen bedarf es eines großen Vorwissens, welches eine große Einstiegshürde darstellt. Der „Finder“ einer neuen Art mag beispielsweise nicht qualifiziert sein, um eine Einordnung vorzunehmen. Das Hinzufügen neuer Kategorien ist aus denselben Gründen nicht einfach: Die neue Kategorie muss definiert sein, um ihr eigenes Wesen festgestellt zu haben; denn nur ein definiertes Wesen gibt eine Existenzberechtigung als Kategorie. Eine aristotelische Kategorisierungshierarchie stellt also, nach ihrer Selbstauffassung, ein „korrektes“, das heisst dem Wesen der Welt und allen Dingen in ihr entsprechend, System dar, welches die Wirklichkeit abbildet: Die Anordung der Dinge kann nur auf eine korrekte Art vorgenommen werden, denn mehrere unterschiedliche Wesen hat kein Objekt.

Dewey Diese Auffassung von Kategorisierung bildete über viele Jahrhunderte die Grundlage aller Wissenschaft: Man suchte neue Kategorien, verfeinerte alte Kategorien und glaubte so, das Wesen der Welt über kurz oder lang vollständig erfassen zu können. Die Wissenschaft selber definierte sich aus in viele einzelne Spezialwissenschaften, die sich immer feiner und feiner in Spezialgebiete unterteilten. Kategorisierung fand aber nicht nur in der Wissenschaft selber statt, sondern auch in der ausserwissenschaftlichen Kultur: Die Teilung von Musik in unter- schiedliche Genres beispielsweise schlägt sich noch heute in der Einrichtung von Plattenläden nieder. Auch das von Melvil Dewey3 entwickelte DDC System zur Erfassung und inhaltlichen

1 Die 12. Auflage von 1766 kann digitalisiert unter http://gallica.bnf.fr/Catalogue/noticesInd/ FRBNF37273248.htm eingesehen werden 2 wie beispielsweise JAVA, eine Sprache, welche nur Einfachvererbung unterstützt 3 gebohren am 10. Dezember 1851 als Melville Louis Kossuth Dewey in Adams Center, New York, gestorben am 26. Dezember 1931 in Lake Placid, New York 2.3 Der Begriff des „Tags“ der Unterschied zum Begriff der Kategorie 19

Erschließung von Bibliotheksbeständen basiert auf denselben Prämissen: Die Themenbereiche sind hierarchisch, ihrem Wesen entsprechend, angeordnet und jedes Buch hat einen genau definierten Platz innerhalb der Ordung.

2.3.1.1 Kritik am Begriff der Kategorie

1 Erst mit Ludwig Wittgensteins Werk Philosophische Untersuchungen[Wit06], welches 1953, Wittgenstein zwei Jahre nach dem Tod Wittgensteins, veröffentlicht wurde, wurde die fixe Kategorienlehre in ihren Grundfesten erschüttert. Wittgenstein arbeitete am Beispiel des Wortes „Spiel“ heraus, dass es Kategorien gibt, die jedem Menschen offensichtlich sind, die man aber keineswegs klar definieren kann:

»Betrachte z.B. einmal die Vorgänge, die wir „Spiele“ nennen. Ich meine Brett- spiele, Kartenspiele, Ballspiel, Kampfspiele, usw. Was ist allen diesen gemeinsam? - Sag nicht: „Es muß ihnen etwas gemeinsam sein, sonst hießen sie nicht ’Spie- le’“ - sondern schau, ob ihnen allen etwas gemeinsam ist. - Denn wenn du sie anschaust, wirst du zwar nicht etwas sehen, was allen gemeinsam wäre, aber du wirst Ähnlichkeiten, Verwandtschaften, sehen, und zwar eine ganze Reihe. Wie gesagt: denk nicht, sondern schau! - Schau z.B. die Brettspiele an, mit ihren mannigfachen Verwandtschaften. Nun geh zu den Kartenspielen über: hier findest du viele Entsprechungen mit jener ersten Klasse, aber viele gemeinsame Züge verschwinden, andere treten auf. Wenn wir nun zu den Ballspielen übergehen, so bleibt manches Gemeinsame erhalten, aber vieles geht verloren. - Sind sie alle ’unterhaltend’. Vergleiche Schach mit dem Mühlfahren. Oder gibt es überall ein Gewinnen und Verlieren, oder eine Konkurrenz der Spielenden? Denk an die Patiencen. In den Ballspielen gibt es Gewinnen und Verlieren; aber wenn ein Kind den Ball an die Wand wirft und wieder auffängt, so ist dieser Zug verschwunden. Schau, welche Rolle Geschick und Glück spielen. Und wie verschieden ist Geschick im Schachspiel und Geschick im Tennisspiel. Denk nun an die Reigenspiele: Hier ist das Element der Unterhaltung, aber wie viele der anderen Charakterzüge sind verschwunden! Und so können wir durch die vielen, vielen anderen Gruppen von Spielen gehen. Ähnlichkeiten auftauchen und verschwinden sehen. Und das Ergebnis dieser Betrachtung lautet nun: Wir sehen ein kompliziertes Netz von Ähnlichkeiten, die einander übergreifen und kreuzen. Ähnlichkeiten im Großen und Kleinen.«[Wit06, §66]

Jedem Menschen2 ist klar, was ein Spiel ist, und das obwohl es kaum möglich ist, eine Wesensdefinition des Begriffes „Spiel“ zu bilden, welche klar alle Spiele umfasst und nichts sonst. So zeigt uns Wittgenstein auf, dass die aristotelische Sicht auf Kategorien nicht haltbar ist: Die klare Definition vom „Wesen“ eines Objektes ist oft nicht möglich und, wie er im o.g. Zitat schreibt, ist auch die Idee der klaren Oberkategorie hinfällig: »Wir sehen ein kompliziertes

1 geboren als Ludwig Josef Johann Wittgenstein am 26. April 1889 in Wien; gestorben am 29. April 1951 in Cambridge 2 welcher der verwendeten Sprache, in diesem Falle Deutsch, mächtig ist 20 2 Theoretische Grundlagen

Netz von Ähnlichkeiten, die einander übergreifen und kreuzen. Ähnlichkeiten im Großen und Kleinen.«

Verbindungen Das „kreuzen“ ist an dieser Stelle der relevante Begriff: Kategorien sind verbunden zu vielen anderen Kategorien, auch wenn sie nicht als Unterkategorie auffassbar sind. Das aristotelische Bild des hierarchischen Kategorienbaums wird abgelöst durch ein Netz aus Begriffen, die, wie Wittgenstein sie nennt, „Ähnlichkeiten“ aufweisen. Diese Kritik an der aristotelischen Sicht auf Kategorisierung ist nun keineswegs als Aufruf zu verstehen, jegliche Kategorisierung abzuschaffen: Kategorienbildung hilft uns zu Abstra- hieren und Information zu kapseln, sie macht den Umgang mit der Welt einfacher und kann Informationen strukturieren und einfacher verständlich machen. Was Wittgenstein zeigt, ist die Tatsache, dass das „Wesen“ keineswegs die Grundlage der Kategorisierung ist, sondern, dass Kategorien sinnvoll definierbar sind, sie aber etwas aussagen darüber, wie der Ordnende seine Begriffe ordnen möchte, und nicht, wie die Welt selbst ist. Somit gibt es, laut Wittgenstein, keine „richtige“ Kategorisierung: Eine Kategorienhierarchie kann für ein spezielles Problem gut funktionieren (wie zum Beispiel die Einteilung der Arten nach ihrer Abstammung in der biologischen Taxonomie), es sind aber jederzeit viele andere Kategoriensystem denkbar, die für andere Probleme besser funktionieren.

Kategorien- Kategorienbäume sind also oft auf speziel- bäume und Vollständigkeit le Probleme und deren Lösungen zugeschnit- ten. Bei solchen Kategorienbäumen ist es typisch, dass sie bezüglich des betrachteten Problems eine gewisse Vollständigkeit an- streben. Abbildung 2.5 illustriert ein dabei häufig anzutreffendes Muster, die Kategorie „sonstige“. Im Beispiel werden geometrische Formen in Kategorien sortiert: Kreise, Drei- Abbildung 2.5: Formenkategorien cke und Quadrate haben ihre sauber defi- nierten Kategorien, doch gibt es offensichtlich noch viel mehr unterschiedliche geometrische Figuren. Um diese mit erfassen zu können, wird die besondere Kategorie „sonstige“ einge- führt, in der alle geometrischen Figuren gesammelt werden, die nicht in eine der speziellen Unterkategorien passen. Sicherlich könnte man im Beispiel eine Menge von neuen Kategorien schaffen für alle Möglichkeiten, doch würde die Übersichtlichkeit verloren gehen. So deckt man gängigerweise nur die Hauptkategorien ab und sortiert den Rest unter „sonstige“ ein, damit es auch einen Platz im Kategorienschema findet. Die Sonderkategorie „sonstige“ ist an dieser Stelle der Trick, der es ermöglicht, die große Vielzahl und Unterschiedlichkeit der Dinge der realen Welt in einfache Kategoriensysteme zu abstrahieren: Die Hauptfälle sind explizit, der als unwichtiger betrachtete, oft undefinierte, Rest findet sich als „sonstige“ wieder.

2.3.2 „Tags“

Der Begriff des „Tags“ findet sich heute vor allem im Kontext des modernen WorldWideWeb: „Tagging“ erlaubt es Menschen, an bestimmte Objekte (Fotos, Personen, Nachrichten &ct) Worte zu hängen, die so genannten Tags, die als Schlagworte fungieren. Der Nutzer ist so in der Lage, die Objekte in Kontext zu anderen Objekten zu setzen: Wenn ein Foto mit dem Tag 2.3 Der Begriff des „Tags“ der Unterschied zum Begriff der Kategorie 21

„Katze“ versehen wurde, entsteht so automatisch eine gewissen Verbindung zu allen anderen Fotos, die auch mit dem Begriff „Katze“ „getaggt“ wurden. Dabei ist die Verbindung sehr lose: Tags sind weder als Wesensaussagen im aristotelischen Sinne zu verstehen, noch als objektive Beschreibung des getaggten Gegenstandes. Tags können sehr freie Assoziationen sein, die der Nutzer gerade zum betreffenden Objekt hat. Dabei existieren für Tags keinerlei Beschränkungen bezüglich ihrer eigenen Qualität: Es ist möglich (und sogar gewollt) ein Objekt mit Substantiven, Adjektiven und selbst Halbsätzen zu taggen. Auch sind Tags in hohen Masse persönlich: Die Tags, die ein Nutzer an ein bestimmtes Objekt hängt, müssen nicht zwangsläufig für irgendjemand anderen Sinn ergeben oder nachvollziehbar oder gar hilfreich sein. Die Häufigkeit der Verwen- dung von Tags bildet automa- tisch gewisse „Haufen“ oder englisch Cluster von getagg- ten Objekten innerhalb eines definierten Rahmens: Betrach- ten wir einen Dienst wie de- licious.com1, der es Nutzern erlaubt, die Lesezeichen ihres Browsers online zu speichern und mit Tags zu versehen, so kann man alleine anhand ver- Abbildung 2.6: Eine beispielhafte „Tagcloud“ wendeten Tags und der Häu- figkeit ihres Auftretens einiges über den speziellen Nutzer und seine Interessen ablesen. Diese Cluster hat der Nutzer dabei keineswegs immer bewusst erzeugt, wie es mit Kategorien der Fall wäre, sondern es ist gerade eine Eigenschaft von Tags, dass sich die Cluster automatisch, bei ihrer Verwendung bilden.

Zur Darstellung von Tags und ihren Clustern haben sich so genannte „Tagclouds“ etabliert, Tagclouds wie man sie in Abbildung 2.6 sehen kann. Dabei ordnet man die verwendeten Tags alphabetisch an und repräsentiert die Häufigkeit des Auftretens eines Tags durch seine Schriftgröße: Sehr groß dargestellte Tags sind häufig, sehr klein geschriebene Tag sind selten angewandt worden. Im Gegensatz zu Kategorien sind Tags, wie schon oben angedeutet, nahezu völlig kontext- los. In seinem Buch Everything is Miscellaneous[Wei08] beschreibt David Weinberger die Eigenarten von Tags folgendermassen: »A jar of strawberry jam you will find at a roadside stand in Vermont has a label that says “Strawberry” and perhaps the year in which it was made. The photo of that same jar posted at Flickr2 might have tags that say “strawberry”, “jam”, “preserves”, “cooking” [. . .] and “gift”.[.. .] Tags capture only a few bits [. . .] because tags by themselves have no context. Until we look at the picture, we don’t even know if the tag “jam” refers to preserves, jazz or traffic.«[Wei08, Seite 167]

1 http://www.delicious.com 2 Flickr.com ist ein Web Dienst der es Nutzern erlaubt, Fotos zu veröffentlichen und mit Tags zu versehen 22 2 Theoretische Grundlagen

Tags lassen jeglichen Kontext aussen vor: Wenn ich ein Tier mit dem Begriff „Schwalbe“ tagge, dann ist das zusätzliche Wissen, was mir die Kategorie Schwalbe (nämlich, dass das Tier ein Vogel ist, ein Lebewesen &ct) geboten hätte, verloren. Die Einordnung, die eine Kategorisierung hätte bieten können, kann von Tags nicht geleistet werden. Im Gegenzug bieten Tags etwas an, was Wittgenstein bei seiner Betrachtung von Kategorien auch schon angedeutet hatte: »Wir sehen ein kompliziertes Netz von Ähnlichkeiten, die einander übergreifen und kreuzen. Ähnlichkeiten im Großen und Kleinen.«1 Die Cluster von Tags, die sich nach und nach bilden, gruppie- ren Objekte zusammen, formu- lieren eine Art von Relation bzw. Ähnlichkeit. Betrachten wir beispielsweise alle Künst- ler, welche bei Last.fm2, die mit dem Begriff „trip-hop“ getaggt sind: Neben dem Tag „trip- Abbildung 2.7: Der Tag „trip-hop“ beim Onlinedienst Last.fm hop“, der die betrachtete Men- ge aus Künstlern konstituiert, sind alle diese Künstler mit noch vielen weiteren Begriffen getaggt worden. Die häufigsten dieser Tags kann man als „ähnlich“ interpretieren, je häufiger zwei Tags gemeinsam auftreten, desto ähnlicher sind sie. Dabei ist Ähnlichkeit keine binäre Relation: Etwas ist nicht ähnlich oder eben nicht, sondern etwas ist „zu 75% ähnlich“, die Verbindungen der Objekte über Tags sind „fuzzy“. expertenlose Tags verlangen keine Experten und keine Wesensbestimmungen, sie sind persönlich und teil- Tags weise für den Aussenstehenden kaum nachvollziehbar und doch beschreiben sie Verbindungen in der Welt, die zwischen Dingen bestehen. Bestimmte Verbindungen werden häufig gesehen und formuliert, andere seltener, doch es kann niemals „falsche“ oder „unsinnige“ Tags geben.

2.3.3 Der Unterschied von Tags und Kategorien

Kategorien teilen einen Objektbereich auf: Man definiert die relevanten Kategorien und ordnet dann die betreffenden Objekte in die Kategorien ein, als würde man Briefe in Briefkästen einsortieren. Jedes Objekt findet genau einen Platz, genau den Platz, an den es gehört. Nach der fertigen Kategorisierung ist eine klare Ordnung entstanden, in der die Dinge zueinander stehen. Tags hingegen erzeugen keine solch klare Ordnung: Jedes der Objekte des Objektbereichs kann beliebig viele Tags haben, es kann sogar so weit führen, dass es am Ende mehr Tags gibt, als Objekte. Anstatt eines Baumes, in dem die Verbindungen der Kategorien die Äste sind an deren Ende sich die Objekte in den Blättern finden, leben Tags im Laubhaufen: Anstatt zu ordnen, zu teilen und zu sortieren, erlauben es Tags, einen scheinbar ungeordneten Haufen auf immer neue Weise zu betrachten. Anstatt einer klaren Ordnung entstehen alle interessanten

1 vgl. 2.3.1.1 2 http://last.fm ist ein Onlinedienst, der es Nutzern erlaubt, ihre musikalischen Vorlieben zu veröffentlichen und Künstler, Alben und Stücke mit Tags zu versehen 2.4 Die Entsprechung von Verzeichnis und Kategorie und die Probleme dieser Entsprechung23

Ordnungen: Ich weiß anhand des Tags „Schwalbe“ nicht mehr, wo in die Taxonomy der Arten sich Schwalben einsortieren, aber ich kann anhand des Tags alle Objekte, die irgendwie zum Begriff „Schwalbe“ in Bezug stehen, betrachten. Oder alle Objekte, die mit „Schwalbe“ und „Motorrad“ getaggt sind: Die Verbindung des Motorrads mit dem Namen „Schwalbe“ zum Vogel gleichen Namens ist eine, die nur Tags darstellen können, Kategorien scheitern hier.

2.4 Die Entsprechung von Verzeichnis und Kategorie und die Probleme dieser Entsprechung

Ein Beispiel, welches schon in 1.1.1 auftauchte, soll an dieser Stelle das Problem illustrieren. Viele Betriebssysteme strukturieren den persönlichen Ordner eines neuen Nutzer vor, indem sie Verzeichnisse vordefinieren wie „Dokumente“, „Bilder“ oder „Musik“. Diese Vorstrukturierung soll es dem Nutzer erleichtern, seine Dateien in Ordnung zu halten. Wie man sieht, ist diese Teilung keine willkürliche, sondern eine Form der Kategorisierung der Inhalte anhand ihres Typs: Bilder, Musik und „Dokumente“ haben ihre vordefinierten Kategorien, in die sie einzuordnen sind. Und genau wie in der aristotelischen Betrachtung von Kategorien ist eine Datei genau in einem Ordner1. Was auf den ersten Blick nach einem logischen Konzept klingt, scheitert sehr schnell am Detail: Der Ordner „Bilder“, der auch Fotos enthalten soll, wird weiter aufgegliedert in „Freunde“ und „Familie“. In welchen der Ordner ist das Foto einzusortieren, auf dem der eigene Bruder und der beste Freund abgebildet sind? In einem weiteren Ordner namens „sonstige“? Wir haben in 2.3.1.1 schon die Kritik am aristotelischen Kategorisierungsbegriff erörtert: Verzeichnisse als Kategorien können aber nur genau diesem Modell entsprechen. Die Kategori- sierung von Dateien über Verzeichnishierarchien scheitert im Alltag an ihrer Unflexibilität. Dateien sind, im Verständnis der Nutzers, nicht so sehr ein geordneter Baum, wie eher ein großer Haufen aus Dingen, die irgendwie zusammenhängen, weshalb die Verwendung von Tags der Verwendung von Verzeichnishierarchien überlegen ist.

2.5 Dateisysteme

Moderne Computersysteme sind nicht nur starke Rechenmaschinen, die komplexeste Berech- nungen in kürzester Zeit ausführen können, sie sind auch üblicherweise gleichzeitig Datenspei- cherungssysteme, welche es den Nutzern erlauben, Daten persistent, das heisst über Neustarts des Systems hinweg, dauerhaft für einen späteren Zugriff abzulegen. Wie genau die Daten allerdings auf dem Datenträger landen ist keineswegs immer identisch: Unterschiedliche Datei-

1 Es ist zwar in vielen Dateisystemen möglich, so genannte „Links“ zu setzen, die es ermöglichen, eine Datei in mehreren Ordnern erscheinen zu lassen, die Ursprungsdatei, auf die alle die Links zeigen, muss sich allerdings trotzdem an genau einem Ort finden. Auch ist die Pflege einer solchen Struktur in Dateisystemen sehr unbequem, da man der Datei nicht direkt ansehen kann, wohin sie überall gelinkt wurde, der Fall ist also alleine aufgrund seiner mangelnden Handhabbarkeit auszuschliessen. 24 2 Theoretische Grundlagen

systeme mit unterschiedlichen Eigenschaften stehen zur Realisierung der Datenspeicherung zur Verfügung.

2.5.1 Definition eines Dateisystems

Definition 2.1. Ein Dateisystem stellt eine Methode dar, Dateien, und damit deren Inhalt, zu speichern und zu organisieren.

Abstrakter gesagt ist ein Dateisystem eine spezielle Datenbank für das Speichern, die hierarchische Organisation, die Manipulation und den Zugriff auf Daten[CS93]. Viele Dateisysteme nutzen ein Speichermedium wie eine Festplatte, eine Speicherkarte oder eine CD-ROM um die Daten abzulegen; diese Dateisysteme verwalten intern den physikalischen Ort auf dem Datenträger, an dem der Inhalt einer speziellen Datei abgelegt ist. Nicht jedes Dateisystem legt seine Daten in derselben Art und Weise auf Datenträgern ab, um auf die Dateien, welche mit einem bestimmten Dateisystem auf einen Datenträger geschrieben wurde, zugreifen zu können, braucht das laufende Betriebssystem einen so ge- nannten „Treiber“, das heisst, eine Komponente, die den Zugriff auf das Dateisystem kapselt. Der Treiber implementiert eine vom Betriebsystem definierte Schnittstelle, über die dann das Betriebssystem die Daten abruft. Die meisten heute gängigen Betriebssystem bringen in ihrer Standardinstallation die Un- terstützung für mehrere unterschiedliche Dateisysteme mit: So wird das Dateisystem FAT, welches 1977 von Bill Gates und Marc McDonald entwickelt wurde[Dun89], heute immer noch1 von jedem der drei verbreitetsten Betriebssysteme2 unterstützt. Die Entwicklung blieb aber nicht beim, nach technologischen Maßstäben heute nahezu antiken, FAT Dateisystem stehen, mit sich ändernden Festplattencharakteristika und dem Vordringen der Computer in immer neue Bereiche menschlichen Lebens und Arbeitens wurden neue Dateisysteme notwendig.

FAT FAT war, mit seiner sehr simplen Struktur[Ecm95], den Anforderungen an Datenintegrität, Sicherheit und Leistungsfähigkeit nicht gewachsen: Es wurden noch nicht einmal grundlegende Funktionalitäten wie Nutzerberechtigungen, wie sie in Multi-Nutzersystemen notwendig sind, unterstützt. Microsoft®ersetzte in seiner Windows NT Linie3 FAT als Standarddateisystem durch NTFS, welches bessere Leistung und Datenintegrität sowie Nutzerrechte unterstützte und auch in der unixoiden Welt traten moderne Dateisysteme auf den Plan wie SGIs XFS, IBMs JFS oder das von SUN entwickelte ZFS, welche hohen Datendurchsatz, große Datenrobustheit und diverse andere Features mit sich brachten. Konventionelle Festplatten, deren Vertreter seit Jahren durch die Nutzung neuer Techno- logien mit immer größeren Kapazitäten aufwarten können, die sich aber konzeptionell seit ihrer Einführung kaum verändert haben, sind in gewissen Anforderungsbereichen als Daten-

1 allerdings selbstverständlich in einer modernisierten Version 2 Microsoft®Windows®, Apple OSX und Linux in unterschiedlichen Distributionen 3 welche sich von Windows NT®über Windows 2000®und Windows XP®bis hin zum aktuellen Windows Vista®erstreckt 2.5 Dateisysteme 25 speichermedium anderen Speichermedien deutlich unterlegen: Die herkömmliche Festplatte setzt auf die Magnetisierung von Bereichen auf mechanisch drehenden Scheiben. Mechanische Bauteile sind nicht nur anfälliger für Erschütterungen, sondern brauchen, um die mechanische Bewegung aufrechtzuerhalten, eine verhältnismässig große Menge Energie. Dies ist gerade im Marktsegment der mobilen Endgeräte wie tragbaren Audioplayern, Digitalkameras, Mobilte- lefonen und Notebooks ein Problem, so dass sich in diesen Bereichen neue Speichermedien durchgesetzt haben. So genannte Flash-Speicher oder Festkörperkaufwerke1 setzen nicht mehr auf mechanische Teile und sind deshalb für den mobilen Betrieb besser geeignet. Diese neuen Datenträger haben allerdings nicht immer nur Vorteile, so ist die Anzahl der möglichen Löschvorgänge auf einem Flash-Speicher begrenzt ist, was beispielsweise zur Entwicklung von JFFS und später dessen Nachfolger JFFS22 führte, Dateisystemen, die ganz speziell mit dem Fokus entwickelt wurden, die Probleme von Flash-Speicher im Einsatz abzumildern. Neben den Mehrzweckdateisystemen und den auf spezielle Hardwareumstände ausgelegten Dateisystemen gibt es allerdings noch weitere Klassen von Dateissystemen, die sich von den bisher beschriebenen grundlegend unterscheiden.

2.5.2 Netzwerk- und virtuelle Dateisysteme

Die bisher beschriebenen Dateisysteme hatten alle gemein, dass sie mit einem physischen Speichermedium interagierten und Daten in irgendeiner Form auf dieses Speichermedium schrieben, doch existieren auch andere Typen von Dateisystemen.

2.5.2.1 Netzwerkdateisysteme

Netzwerkdateisysteme erlauben es, auf Daten über ein Netzwerk wie das Internet zuzugreifen. Dabei übersetzen sie Dateizugriffe transparent für den Nutzer, das heisst, der Nutzer ist nicht gezwungen, die Datei auf seinen Rechner herüberzukopieren, um sie dann zu öffnen, sondern öffnet sie als sei sie lokal; das Netzwerkdateisystem kümmert sich dann um den Transfer der Daten zum entfernten Rechner. Das Netzwerkdateisystem selber schreibt üblicherweise auf dem entfernten Rechner nicht selber auf irgendwelche Datenträger sondern nutzt dort wiederum traditionelle Dateisysteme. Netzwerkdateisysteme abstrahieren also wirklich nur den Zugriff auf Daten fremder Systeme. Bekannte Beispiele für Netzwerkdateisysteme sind das ursprünglich von SUN entwickelte NFS oder CIFS, welches typischerweise von Windows Clients zur Kommunikation verwendet wird.

1 engl. „solid state drive“ 2 http://sourceware.org/jffs2/jffs2-html/ 26 2 Theoretische Grundlagen

2.5.2.2 Virtuelle Dateisysteme

Virtuelle Dateisysteme bieten, ähnlich wie Netzwerkdateisysteme2.5.2.1, eine Abstraktion. Dabei wird nicht der Zugriff von Daten über ein Netzwerk abstrahiert, sondern beispielsweise der Zugriff auf einen laufenden Kernel (wie im „proc“ Dateisystem in einem Linux System). Der Nutzen von virtuellen Dateisystemen liegt darin, den Zugriff auf ein irgendwie geartetes System über die wohldefinierten und verbreiteten Schnittstellen zum Zugriff auf Dateien2.5.3 abzuwickeln. 1 flickrfs Betrachten wir flickrfs als Beispiel für ein virtuelles Dateisystem: Flickrfs erlaubt es dem Nutzer, seinen Flickr Account wie ein Verzeichnis in einem Linux System einzuhängen. Die Bilder, die der Nutzer in seinem Flickr Account hochgeladen hat, finden sich als Dateien in diesem Verzeichnis wieder, so dass sie mit einem herkömmlichen Dateimanager verwaltet werden können: Kopiert man ein Bild in das Verzeichnis, wird es dem eigenen Flickr Account hinzugefügt, löscht man ein Bild, wird es von der Flickr Seite entfernt. Dabei ist flickrfs keineswegs nur ein Netzwerkdateisystem, es abstrahiert die gesamte öffentliche API, welche Flickr anbietet. Die Abstraktion eines komplexen Systems in Form von einem virtuellen Dateisystem hat den Vorteil, dass vielen Nutzern die typischen Operationen auf Dateien (kopieren, löschen, umbenennen &ct) vertraut sind und sie deshalb zur Interaktion mit dem abstrahierten System keine neuen Vorgänge erlernen müssen.

2.5.3 Zugriff auf Dateien

Um innerhalb eines Betriebssystems auf Dateien zuzugreifen, die über ein unterstütztes Datei- system bereitgestellt werden, stellen Betriebsysteme APIs zur Ferfügung, die zu verwenden sind. Ein von der IEEE etablierter Standart, dem viele Betriebssysteme folgen ist der so genannte POSIX Standard[Por04]. Viele moderne Betriebssysteme, vor allem die in der Unix-Tradition stehen, unterstützen POSIX, doch auch für Windows Betriebssysteme werden POSIX Erweiterungen angeboten. Der POSIX Standard definiert, unter anderem, welche Operationen ein Betriebssystem auf Dateien und Verzeichnissen anbieten muss: Diese reichen von Methoden zum Feststellen, welche Art von Objekt unter einem bestimmten Namen zur Verfügung steht, zum Auslesen bestimmter Bereiche einer Datei oder zum Schreiben in die Datei. Diese Methoden stehen für jede Datei zur Verfügung, egal welches Dateisystem verwendet wird, um die Datei zu speichern und ist der Grund, aus dem Dateimanager in der Lage sind, auf beliebigen Dateisystemen zu arbeiten und Zugriff auf Inhalte anzubieten.

2.5.4 Wittgenstein, das Dateisystem

Wie der Titel dieser Arbeit andeutet, ist es das Ziel ein Dateisystem zu entwickeln. Dabei ordnet sich dieses wie folgt in die oben genannten Typen ein: Wittgenstein wird ein virtuelles

1 http://manishrjain.googlepages.com/flickrfs 2.6 Metadaten in Dateien 27

Dateisystem sein, welches sich im Hintergrund auf andere, traditionelle Dateisysteme zum physischen Speichern von Daten verläßt. Dies kombiniert die Stabilität und Leistungsfähigkeit moderner Dateisysteme mit der Flexibilität, die ein eigenes Dateisystem beim Zugriff auf Daten bietet.

2.6 Metadaten in Dateien

Die Menge der bekannten Dateiformate ist immens1: Dateiformate werden von fortschritt- licheren Formaten abgelöst, Dateiformate für neue Anwendungen und Datentypen werden definiert.

Dabei bieten viele Dateiformate Datenfelder an, in denen Metainformationen gespeichert EXIF werden können. Dabei orientieren sich die Art der Metadaten üblicherweise am Typ der jeweiligen Datei: Für JPEG Dateien, welche häufig von digitalen Fotokameras verwendet werden, existiert beispielsweise die EXIF Erweiterung[Sta02], welche es erlaubt, diverse Daten über die Aufnahme direkt im Bild zu speichern: Die Art der Kamera, die Belichtungszeit, teilweise sogar die Koordinaten an welchem Platz das Bild aufgenommen wurde. Für Musikdaten existieren ebenfalls Metadatenstandards, welche es erlauben, den Interpreten eines Stückes, seinen Titel und beispielsweise das Album, auf dem das Stück veröffentlicht wurde, Textverarbeitungen erlauben es, in ihren Dateiformaten den Autor eines Dokumentes zu speichern. Was alle diese Metadatenstandards gemeinsam haben ist ihre Uneinheitlichkeit: EXIF wird von JPEG, TIFF und RAW Dateien unterstützt, PNG, GIF und das recht moderne JPEG2000 im Gegenzug können EXIF Daten nicht einbinden. Die Struktur der Metadaten der unterschiedlichen Musikdatenformate setzt zwar auf einem gemeinsamen Grundstock auf (den Interpreten eines Stückes können die meisten Dateitypen abspeichern), doch spezielle Dateiformate fügen jeweils wieder neue Daten hinzu. Der bei MP3-Dateien verwendete ID3 Standard existiert in zwei Versionen, die beide parallel in einer Datei auftreten können (und komplett unterschiedliche Werte haben können): Unterstützt eine Anwendung nur eine der beiden ID3 Versionen, sieht die vorliegende Musikdatei so aus, als habe sie keinerlei Metainformationen. Für den Nutzer bedeutet das, dass er, so er sich nicht intensiv mit den Stadards und Dateitypen auseinandersetzt, nicht genau weiß, welche Datei welche Art von Metadaten unterstützt. So scheint es nicht logisch, dass ein Musikstück beispielsweise nur auf einem Album erschienen sein kann: Was ist, wenn dasselbe Stück auf zwei Alben vorhanden ist? Warum sollte der Nutzer deshalb zweimal dieselbe Datei nur mit unterschiedlichen Metadaten speichern?

Diese mangelnde Einheitlichkeit von Metadaten in Dateien verdeutlicht, dass Möglichkeiten Uneinheitlichkeit zu schaffen sind, Metadaten zu Dateien ausserhalb der Dateien zu speichern. Doch sind von Metadaten Metadaten nur vonnutzen, wenn sie auf einem wohldefinierten und flexiblen Wege abrufbar

1 http://en.wikipedia.org/wiki/List_of_file_formats bietet eine lange und trotzdem unvollständige Liste an 28 2 Theoretische Grundlagen

sind: Diese zu definieren und zu schaffen ist Teil der Aufgabe dieser Arbeit. Anstatt sich auf die Metadaten, die in Dateien direkt gespeichert sind, zu verlassen, werden die Metadaten in einer flexiblen Art und Weise ausserhalb der Datei gespeichert und der Zugriff darauf dann über eine Schnittstelle dem gesamten Computersystem und allen laufenden Programmen bereitgestellt.

2.7 Dateien und ihre semantische Einordnung

Wie schon in 2.2.2 gezeigt, betrachten Nutzer Dateien nicht als Bitmuster auf einem Daten- träger, sondern als das, was sie als Interpretation des Dateiinhaltes erwarten: Eine MP3-Datei ist das Lied, welches sie enthält. Daraus resultierend sind Dateien für den Nutzer direkt mit Objekten der realen Welt verbunden: So kann eine Person in vielen Rollen zur Datei assoziiert sein, als Autor (des in der Datei enthaltenen Inhalts), als Inhalt selbst (beispielsweise als eines der Objekte auf einem Bild) oder als Kommentator (die Person hat über die Datei eine Aussage gemacht). Dabei wird klar, dass die Verbindungen zwischen Dateien und realen Objekten keineswegs immer einfach sein müssen: Die Verbindung „X ist Autor von Y“ ist sehr einfach, aber die Verbindung „X hat einen Kommentar über Y gemacht“ braucht entweder noch ein drittes Objekt (den Kommentar selbst) oder die Verbindung selbst muss den Kommentar enthalten. Auch sind Verbindungen keineswegs immer auf alle Objekte anwendbar: „X ist Autor von Y“ ist anwendbar auf X, welche Personen sind, keineswegs aber auf X, welche Orte sind oder Zeitangaben. Des weiteren können Dateien offensichtlich auch zueinander in Beziehung stehen. So kann eine Datei beispielsweise eine Quelle für eine andere Datei sein. Am Beispiel dieser Arbeit kann man solcherlei Beziehungen leicht festmachen: Die Datei „bibliography.bib“ enthält das Literaturverzeichnis des Dokumentes, welches den Text der Arbeit enthält. Und die LaTeX Datei, in der dieser Text hier verfasst wird, ist die Quelldatei für das PDF, welches später daraus generiert wird. Dateien stehen in komplexen Relationen zu anderen Dateien und zu Dingen, was bedeutet, dass das zu entwickelnde System eben diese Dinge auch modellieren muss. Der Nutzer muss in der Lage sein, die Objekte der realen Welt, die er mit seinen Dateien in Zusammenhang bringen will ins Systen zu bringen. Die Beziehungen zwischen den Objekten und Dateien sind komplex: Sie sind nicht nur eine Menge aus Zeigern, die einige Objekte und Dateien zusammenhängen, sondern sie haben unter Umständen selbst noch Eigenschaften. Die Relation „Person X mag Datei Y“ kann einfach modelliert werden: Wenn die Realtion besteht, mag X die Datei Y. Doch ist „mögen“ ein sehr schwieriges Gefühl: Menschen mögen manche Dinge lieber als andere. Sie mögen beide Dinge, aber eben nicht gleich stark. Die „mögen“-Relation muss also eigentlich quantifizierbar sein. KAPITEL 3

Evaluation verschiedener Lösungsansätze

Im folgenden Kapitel sollen einige bestehende Technologien betrachtet und beschrieben werden, die im Problemumfeld des zu entwickelnden Systems oder sehr ähnlichen Problemfeldern an- gesiedelt sind. Diese Konzepte oder Technologien werden dann bezüglich ihrer Verwendbarkeit für das vorliegende Projekt evaluiert.

3.1 Diskussion des verwandten Konzeptes der „Desktop Search Engine“

Das Suchen von Dateien auf dem eigenen Computer ist eine Funktionalität, welche schon sehr früh ihren Einzug in die Betriebssysteme fand: Mit wachsender Zahl von Dateien war es immer schwieriger geworden, eine bestimmte Datei schnell aufzufinden. Zu Beginn war die Suche simpel: Man konnte Teile des Dateinamens eingeben und das System lieferte dann, nachdem alle Dateien des betreffenden Teils des Dateisystembaums bezüglich des Kriteriums evaluiert wurden, die Liste der Treffer zurück. Dieses Vorgehen war langsam und oft nicht sehr effizient, da das Durchsuchen der einzelnen Dateien bzw. ihrer Namen sehr schnell an die Hardware-bedingten Grenzen der Leistungs- fähigkeit der zugrundeliegenden Datenträger stieß und da der Name einer Datei oft nicht genug Informationen trug, um die wirklich klar zu identifizieren: Betrachten wir die Bilder, die eine Digitalkamera liefert, so werden sie zumeist einfach aufsteigend nummeriert, eine Namensgebung, die für Menschen nicht besonders gut handhabbar ist.

Dieses Problem wurde durch so genannte „Desktop Search Engines“ gelöst: Eine Desktop Indizieren von Search Engine nutzt die oft brach liegenden Ressourcen moderner Computersysteme1 um den Inhalten Inhalt des Systems zu indizieren. Das bedeutet, dass eine Desktop Search Engine ähnlich arbeitet wie eine Suchmaschine im Internet. In Zeiten, in denen viele Systemressourcen ungenutzt sind, durchsucht die Desktop Search Engine den Inhalt der Dateien, deren Formate sie unterstützt. Aus diesen Inhalten wird ein lokaler Index aufgebaut, der es dann dem Nutzer erlaubt, Dateien anhand ihres Inhalts zu

1 moderne Rechner haben immense Leistungsreserven, die bei vielen Anwendungsbereichen wie zum Beispiel Textverarbeitung oder dem Hören von Musik kaum ausgeschöpft werden 30 3 Evaluation verschiedener Lösungsansätze

finden. Weil der Index zu diesem Zeitpunkt aber schon existiert, ist die Suche um einige Größenordnungen schneller, als wenn die Daten erst dann durchsucht würden, wenn der Nutzer eine Anfrage stellt. Desktop Search Engines sind auf breiter Basis installiert, schon Microsoft™s Windows 2000™und Windows XP™installierten einen Indizierungsdienst, jedoch erst bei Windows Vista™wurde dieser Dienst standardmässig aktiviert. Google, Betreiber der meistgenutzen Internet Suchmaschine der Welt, bietet mit seinem „Google Desktop“1 eine Desktop Search Engine an, welche sich sogar in die Web-Oberfläche der Internetsuchmaschine integriert. Auch im Bereich der freien Software existieren einige kon- kurrierende Systeme wie unter anderem Beagle2 und Tracker3, welche ebenfalls das Durchsu- chen der Daten eines Nutzers er- lauben. Diese unterschiedlichen Projekte führten zur Entwick- lung eines gemeinsamen Stan- dards namens XESAM4 zur Ermöglichung einer nahtlosen Integration besagter Desktop Search Engines wie sie in Ab- bildung 3.1 gezeigt wird.

3.1.1 Leistungsgrenzen von Abbildung 3.1: Integrierte Desktop Search Engine im Datei- Desktop Search Engines auswähldialog

Desktop Search Engines schei- nen auf den ersten Blick eine sehr ähnliche Problemstellung zu lösen, wie diese Arbeit: Die Ermöglichung des schnellen Auffindens von Daten, eine Aufgabe, die die meisten Produkte auch hervorragend erfüllen. Es existieren allerdings gravierende Einschränkungen bei der Nutzung von Desktop Search Engines: Dateiformate, die das jeweilige Produkt nicht kennt, kann es auch nicht sinnvoll indizieren. Die weitverbreitetsten Dateitypen werden üblicherweise unterstützt, doch speziellere, nicht so stark verbreitete oder proprietäre Dateiformate werden oft nicht unterstützt, was es dem Nutzer gegebenenfalls unmöglich macht, innerhalb der Daten, die seine Homebanking Software verwaltet, zu suchen. Metadaten können von vielen Desktop Search Engines ausgewertet werden, allerdings nur solange diese in klar definierten, verbreiteten Formaten vorliegen: Die ID3-formatierten Metadaten, die beispielsweise in MP3 Audiodaten zu finden sind, werden von den meisten

1 http://desktop.google.com/ 2 http://beagle-project.org/Main_Page 3 http://www.gnome.org/projects/tracker/ 4 eXtEnsible Search And Metadata specification, http://xesam.org/main 3.2 Diskussion verschiedener Metadatenstandarts 31

Desktop Search Engines unterstützt, und auch EXIF Daten in Digitalfotos werden von den meisten Produkten im Desktop Search Markt erfasst. Desktop Search Enginges können, genau wie Suchmaschinen im Internet, anhand gewisser Schlagworte Inhalte finden, was sie hingegen nicht leisten können ist das Definieren völlig beliebiger Relationen zwischen Dateien (und gegebenenfalls anderen Typen von Objekten): Solcherlei Relationen kann nur der Mensch selbst definieren, sie lassen sich nicht automatisiert aus einem Dokument ermitteln.

Desktop Search Engines durchsuchen Inhalte für den Menschen, helfen ihrem Nutzer aber Durchsuchen vs. nicht seine Inhalte zu organisieren: Die Dateien bleiben weiterhin verstreute Inhalte ohne Organisieren Bezug zueinander, ohne Bezug zu ihren für den Nutzer relevanten Metadaten. Die Struktur, die sie dem Nutzer für seine Inhalte anbieten ist nicht die des Nutzers, sondern die technische Sicht, die der Nutzer erlernen muss: Er muss trainieren, welche Suchbegriffe für ihn zum Ziel führen (ähnlich wie Menschen das Suchen in Internet Suchmaschinen trainieren müssen, bis sie für sie persönlich „gute“ Ergebnisse erzielen). Der Fokus dieser Arbeit hingegen ist die Erstellung einer Organisation von Inhalten, die dem mentalen Modell des Nutzers entspricht, seiner Art Inhalte zu organisieren, zu verknüpfen und anzuordnen. Die Zielsetzung von Desktop Search Engines und dieser Arbeit sind somit nahezu gegensätzlich, auch wenn sie auf den ersten Blick sehr ähnlich schienen. Es existieren offensichtlich durchaus Schnittstellen zwischen beiden Ansätzen: Eine Desktop Search Engine könnte beispielsweise die Schnittstelle, die das in dieser Arbeit zu entwickelnde System anbietet, nutzen, um ihren eigenen Index mit unterschiedlichsten Metadaten anzurei- chern, die es im Gegenzug dem Nutzer einfacher machen, Inhalte über die Desktop Search Engine zu finden.

3.2 Diskussion verschiedener Metadatenstandarts

Wie schon in 2.6 beschrieben wurde, existieren für diverse Dateiformate Metadatenstandards wie beispielsweise EXIF für digitale Fotos. Um diese zu harmonisieren, wurden diverse Projekte ins Leben gerufen, um generischere Metadatenstandards zu definieren, welche es erlauben, Metadaten ähnlicher Art auf unterschiedlichen Medientypen zu definieren. Im folgenden sollen zwei dieser Standards genauer untersucht werden, der schon in 3.1 angesprochene XESAM Standard und der von der Dublin Core Metadata Initiative herausgegebene Dublin Core Standard. Beide Standards sind frei zugänglich und frei von jeglicher Patentbelastung, somit ist es möglich, sie ohne Nutzungseinschränkungen oder Kosten innerhalb der zu entwickelnden Software zu nutzen. Proprietäre und unfreie Lösungen werden, um schon im Vorfeld rechtlichen Problemen aus dem Weg zu gehen, an dieser Stelle nicht betrachtet.

3.2.1 Der XESAM Standard

Wie schon in 3.1 erwähnt, hat sich der XESAM Standard [Xes08b] aus den Anforderungen bei der Entwicklung und Einbindung von Desktop Search Engines entwickelt, ist aber nicht ausschliesslich in diesem Bereich relevant: Auch das schon erwähnte Nepomuk Projekt (vgl. 1.5.1) ist involviert in der Erarbeitung und Diskussion um Xesam. 32 3 Evaluation verschiedener Lösungsansätze

Der Xesam Standard spaltet sich dafür auf in vier große Bereiche: Die Xesam Search API, also die Schnittstelle, über die Software auf die Desktop Search Engine zugreifen kann um im Datenbestand zu suchen, die Xesam Query Language, welche die formale, XML-basierte Abfragesprache, in der die Anfragen an Suchmaschinen zu formulieren sind, definiert, die Xesam End User Search Language, eine einfache und für Endnutzer verwendbare Sprache um spezielle Suchanfragen zu formulieren, und die Xesam Ontology, die Definition der Daten und ihrer Zusammenhänge, die die Desktop Search Engine vorhält. An dieser Stelle soll die Xesam Ontology[Xes08a] betrachtet werden, welche den Teil des Standards darstellt, der sich mit der Speicherung von Metadaten beschäftigt.

3.2.1.1 Xesam Ontology

Die Xesam Ontology stellt eine streng hierarchische Beschreibung der Struktur von Dateien und ihrer Metadaten dar. Dabei trennt sich die Xesam Ontology in zwei Stränge: die Xesam Core Ontology, welche den Grundstock von Metadaten bildet und die Xesam Convenience Ontology, welche Erweiterungen zur Core Ontology enthält, welche aus für den Nutzer lesbaren Namen, Erweiterungen für proprietäre Standards, und Mappings1 auf externe Standards enthält. Innerhalb einer Xesam Implementierung ist jedes Objekt definiert über zwei Hauptei- genschaften: Source und Content. Source ist dabei eine Klassifikation der physikalischen Datei, Content eine des abstrakten Inhalts. Beiderlei Klassifikationen sind dabei, wie schon angedeutet, streng hierarchisch, wie Abbildung 3.2 zeigt: Das Photo ist auf der Source-Seite ein xesam:File und damit au- tomatisch auch ein xesam:FileLike, aber kein xesam:BlockDevice. Wie schon aus anderen aristotelischen Kategorisationshier- archien bekannt, ordnet sich die Content- Seite ebenfalls in eine strenge Hierarchie ein, das xesam:Photo ist ein xesam:Image, welches wiederum ein xesam:Visual ist. Für jede dieser Klassifikationen in der Hierarchie definiert Xesam einen Satz aus Attributen, die jedem Objekt, welches in Abbildung 3.2: Ein digitales Foto in der Xesam Ontology dieser Kategorie einsortiert wurde, zukom- men, wobei einige der Attribute optional sind. Für den in Abbildung 3.2 dargestell- ten Fall, erhält das Objekt, alleine aus der Content-Seite über 80 definierte Attribute, davon alleine 15 nur um die EXIF Daten zu repräsentieren.

1 Ein Mapping ist eine Übersetzungstabelle zwischen unterschiedlichen Begriffswelten. Ein einfaches Beispiel für ein Mapping wäre ein Vokabelheft, welches deutsche Worte auf ihr englisches Äquivalent abbildet 3.2 Diskussion verschiedener Metadatenstandarts 33

Xesam ist ein Beispiel für einen statischen Standard: Es wurden, seitens der beteiligten Projekte, aus den geläufigen Dateien Kategorien abstrahiert, in die die von der Desktop Search Engine gefundenen Daten einsortiert werden, dabei hat jedes Objekt genau eine Source und genau einen Content. Auch Personen werden innerhalb dieses Systems model- liert (xesam:Person) sowie feste Beziehungen von Personen zu Dateien. Die Eigenschaft xesam:author beispielsweise kommt jedem Objekt der xesam:Content Kategorie zu und erlaubt es, den Autor eines solchen Objektes festzulegen.

3.2.1.2 Ist Xesam als Standard für diese Arbeit geeignet?

Aufgrund seiner Entstehung und des Fokuses des Xesam Standards beschränkt er sich auf Attribute und Klassifikationen, die man möglichst einfach und eindeutig automatisiert aus Dateien extrahieren kann: Den Typ einer Datei kann man recht einfach feststellen und wenn es ein Bild ist und zusätzlich noch mit EXIF Daten versehen ist, dann muss es ein Foto sein. Relationen in Xesam sind vergleichbar zu Referenzen in Instanzen in objekt-orientierten Programmiersprachen: Ein xesam:Content Objekt besitzt eine Variable author, welche eine Referenz auf ein xesam:Person Objekt enthalten kann. Dieser Ansatz ist aus technischer Sicht leicht umzusetzen und für den Bereich Desktop Search Engine völlig ausreichend, für die Ziele dieser Arbeit ist dieser Ansatz allerdings zu simpel: xesam:Content Objekte können zwar beispielsweise einen Autor haben, aber mehrere Einzelpersonen als Autor zuzuweisen ist nicht möglich. Auch nichtdefinierte Relationen sind nur schwer innerhalb von Xesam zu realisieren, bzw. nur als Erweiterungen des Standards, also de facto ausserhalb des Standards. In Hinblick auf Relationen zwischen Dateien und anderen Entitäten reichen die Möglichkeiten Xesams also nicht aus. Die von Xesam vorgenommene Kategorisierung im Bereich Content kann für die zu ent- wickelnde Software nützlich sein, um gewisse „Standardbeziehungen“ zu ermitteln und zu definieren: Neben der Beziehung von Personen zu Dateien als Autor finden sich noch diverse weitere und auch die Eigenschaften von Dateien in Xesam können durchaus als Menge von möglicherweise relevanten Beziehungen und Eigenschaften von Objekten im zu entwickelnden System genutzt werden. Eine Kompatibilität zum Xesam Standard auf einem gewissen Niveau scheint sinnvoll zu sein.

3.2.2 Dublin Core

Der Name „Dublin Core“ leitet sich ab einerseits aus dem Ort, an dem der Standard 1995 innerhalb eines Workshops erarbeitet wurde, nämlich Dublin, Ohio, und dem englischen Begriff „Core“, welcher verdeutlichen soll, dass der Standard eine einfache, aber grundlegende Liste aus Eigenschaften von Inhalten definieren will. Heute wird Dublin Core von der Dublin Core Metadata Initiative verwaltet und weiterentwickelt. Dublin Core bildet beispielsweise die Basis 34 3 Evaluation verschiedener Lösungsansätze für das Open Source Metadata Framework1, welches die Grundlage für die die Hilfefunktionen der beiden großen freien Desktop Umgebungen GNOME2 und KDE3 bildet. Dublin Core enthält wiederum zwei Substandards: Simple Dublin Core, welches 15 Meta- datenelemente definiert, und Qualified Dublin Core, welches drei weitere Elemente und so genannte „Element Refinements“ definiert. Die von Simple Dublin Core definierten Elemente sind wie folgt:

• „Title“, der Name der Ressource, beispielsweise der Titel eines Buches. • „Creator“, eine Entität verantwortlich für das Erzeugen der Ressource, beispielsweise der Autor eines Buches. • „Subject“, das Thema der Ressource; dieses wird häufig in Schlagworten formuliert. • „Description“, eine Beschreibung des Inhaltes der Ressource, beispielsweise eine Zusam- menfassung oder ein Inhaltsverzeichnis. • „Publisher“, eine Entität, welche für die Veröffentlichung der Ressource Verantwor- tung trägt, beispielsweise die Organisation, die einen Standard veröffentlicht, oder der Herausgeber eines Buches. • „Contributor“, eine Entität, die einen Beitrag zum Inhalt der Ressource geleistet hat. • „Date“, ein Datum, welches mit einem Ereignis im Lebenszyklus der Ressource verbunden ist, beispielsweise das Veröffentlichungsdatum. • „Type“, der Typ des Inhalts einer Ressource. Die Dublin Core Metadata Initiative empfiehlt hier, Begriffe eines festgelegten Vokabulars zu verwenden, wie beispielsweise einen Genrebegriff aus einer Liste von möglichen Genres für ein Buch. • „Format“, die physikalische oder digitale Gestalt der Ressource. So kann eine Datei beispielsweise über ihren Dateityp beschrieben werden oder ein Buch als Hardcover beschrieben werden. • „Identifier“, ein eindeutiger Bezeichner der Ressource innerhalb eines gegebenen Kontexts. Bücher können beispielsweise über ihre ISBN eindeutig gekennzeichnet werden, eine Datei zum Beispiel über eine URL. • „Source“, eine Referenz auf eine weitere Ressource, welche als Quelle für diese Ressource gedient hat. • „Language“, die Sprache des Inhalts der Ressource. • „Relation“, eine Referenz auf eine weitere Ressource. Diese ist nicht weiter qualifiziert. • „Coverage“, der Gültigkeitsbereich der Ressource. Dieser kann beispielsweise ein Zeitraum sein oder ein geographischer Bereich.

1 http://www.ibiblio.org/osrt/omf/ 2 http://www.gnome.org 3 http://www.kde.org 3.2 Diskussion verschiedener Metadatenstandarts 35

• „Rights“, Informationen über die Rechte, welche an der betreffenden Ressource bestehen. Typischerweise finden sich in diesem Element Urheberrechte und Nutzungsrechte wieder.

Dublin Core definiert, dass jedes dieser Elemente beliebig oft innerhalb einer Ressource auftauchen kann und optional ist. So ist es innerhalb von Dublin Core trivial eine Ressource unter beliebig vielen Titeln zu verwalten, oder eine beliebige lange Liste unterschiedlicher Autoren einer Ressource zuzuordnen. So umgeht Dublin Core viele Probleme, die Systeme, die auf festen Datenfeldern beruhen: Hätte eine Ressource nur ein einfaches Datenfeld „Autor“ so müsste man bei einem Text, der von mehreren Personen geschrieben wurde, alle Autorennamen in diesem einen Feld eintragen. Hierbei würden die Information über die einzelnen Autoren verloren gehen.

Die oben schon angesprochenen „Element Refinements“ sind hierbei Attribute der oben Element beschriebenen Elemente: Refinements für das „Date“ Element sind beispielsweise „Crea- Refinements ted“, „Modified“ oder „Valid“1. So können die sehr generischen Elemente Dublin Cores über Refinements klarer ausdefiniert werden. Die von der Dublin Core Metadata Initiative her- ausgegebenen Refinements sind aber keineswegs als Beschränkung zu verstehen, sondern als Grundstock: Parser sind angehalten Refinements, die sie nicht kennen, als Text zu begreifen, den Menschen lesen können: Definiert also eine Software ein Refinement für Date namens „deleted“, so wird dieser Text einfach direkt weitergeleitet. Auf diese Weise bleiben unter- schiedliche Dublin Core Dialekte kompatibel ohne die Flexibilität und Anpassbarkeit des Standards unnötig einzuschränken.

3.2.2.1 Ist Dublin Core als Standard für diese Arbeit geeignet?

Die Flexibilität, die Einfachheit und die Erweiterbarkeit des Dublin Core Standards machen ihn zu einem sehr attraktiven Kandidaten als Metadatenstandard für diese Arbeit. Im Gegensatz zu Xesam2 versucht Dublin Core keineswegs alle Eigenschaften von Ressourcen eindeutig zu erfassen sondern beschränkt sich auf eine klare Menge von grundlegenden Attributen, die einfach und kompatibel erweitert werden können. Problematisch ist, ähnlich wie bei Xesam, die Auffassung der Relationen zwischen Entitäten: Relationen sind sehr simpel definiert, was ihre Implementierung sehr einfach macht. Doch für die in 2.7 aufgezeigten Probleme für diese Arbeit kann auch Dublin Core nicht lösen: Die Modellierung komplexer Relationen, die mehr sind, als simple Referenzen von Entitäten aufeinander. Als Basis für die verwendeten Metadaten allerdings ist Dublin Core hervorragend geeignet und aufgrund der schon im Standard vorgesehenen Erweiterbarkeit ist auch eine Kompatibilität des zu entwickelnden Systems zu Dublin Core nicht nur möglich, sondern aufgrund der Verbreitung Dublin Cores auch wünschenswert.

1 http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/ 2 siehe 3.2.1 36 3 Evaluation verschiedener Lösungsansätze

3.3 RDF als Format zur Beschreibung von Relationen

Die in 3.2.1.2 und 3.2.2.1 angesprochenen Probleme stammen aus dem beiden gemeinsamen Fokus auf RDF als Repräsentationssprache. RDF , das „Resource Description Framework“, ist eine vom World Wide Web Consortium herausgegebene Familie von Spezifikationen, welche ihren Ursprung als Sprache zur Bereitstellung von Metadaten hat. RDF bildet den Grundstein des von Tim Berners-Lee beschriebenen Semantic Web[BLHL01]. RDF soll an dieser Stelle nicht vollständig aufgerollt, sondern vor allem auf seine Schwächen im Bezug auf die Aufgabenstellung Untersucht werden. RDF stellt die Beziehungen von Objekten in so genannten „triples“ dar[Wor04b]: Ein „triple“ setzt sich dabei zusammen aus einem Subjekt einem Prädikat und einem Objekt. Die Aussage „StudentX hat die Matrikelnummer 123456“ wird für ein RDF-Triple in die folgenden Bestandteile zerlegt: • Das Subjekt „StudentX“ • Das Prädikat „eine Matrikelnummer haben“ • Das Objekt „123456“ In der für RDF typischen XML Notation stellt sich das gerade beschriebene Triple folgen- dermassen dar:

1 4 5 123456 6 7 Listing 3.1: Die Relation „StudentX hat die Matrikelnummer 123456“ in RDF/XML

Das RDF/XML Beispiel verwendet zur Modellierung des Prädikates „eine Matrikelnummer haben“ das Element „Identifier“ aus dem Dublin Core Standard1. Die XML Repräsentation ist für diesen Falle völlig ausreichend und formuliert die Beziehung klar.

Simple Probleme treten mit komplexeren Beziehungen auf, weil, wie man im Listing sehen kann, die Beziehungen Art der Beziehung das einzige ist, was das formulierbar ist: Die Beziehung „identifiziert“, die wir im Listing verwenden, hat keine weiteren Eigenschaften. So schränkt RDF die Möglichkeiten für das definieren von Relationen stark ein2: Relationen müssen sich auf Triple herunterbrechen lassen. Nehmen wir beispielsweise die Beziehung „ein Dreick sein“. Diese Beziehung besteht nicht zwingend zwischen zwei Entitäten sondern zwischen genau dreien: Drei Punkten in einer Ebene, die nicht auf einer Geraden liegen. Die Beziehung „ein Dreieck sein“ umfasst allen 3 Punkte gleichzeitig. Man kann diese Relation nicht ohne weiteres auf Triple übersetzen: Sicherlich kann man eine Entität „Dreieck“ definieren und allen 3 Punkten die Relation „Eckpunkt

1 eine Matrikelnummer ist der Identifikator des Studenten innerhalb der Universität 2 eine Schwäche die Dublin Core und Xesam erben 3.3 RDF als Format zur Beschreibung von Relationen 37 des Dreiecks sein“ zuweisen, doch zeigt sich hier ein klarer semantischer Unterschied beider Aussagen: Die Relation „ein Dreick sein“ zwischen 3 Punkten hat als eindeutigen Inhalt, dass sich das Dreick über seine drei Eckpunkte konstituiert. Die Triple-Version läßt das Dreieck losgelöst von seinen Eckpunkten existieren, und bekommt seine Eckpunkte erst nach der Feststellung seiner Existenz zugewiesen. Was an dieser Stelle ähnlich klingen mag, zeigt seine Unterschiede im Detail: Verschieben wir einen der Eckpunkte, so ist offensichtlich, dass die Relation, die sich über die drei Eckpunkte definiert, sich geändert hat (weil sich einer der Bezugspunkte der relation geändert hat). Darauf folgt automatisch das neue Dreieck. Die Triple-Notation würde einfach eine andere Punkt-Entität zur Entität Dreick verbinden, die Dreiecks-Entität selber bleibt aber unverändert.

Es lassen sich in RDF des weiteren auch Aussagen über Listen (so genannte bags oder Listen collections[Wor04a]) von Objekten machen, so dass man, um das vorherige Beispiel wieder aufzugreifen, die drei Eckpunkte des Dreiecks als Liste aus Punkten darstellt, über die man die Aussage macht, sie bildeten das Dreieck. RDF Listentypen können allerdings die komplexen Eigenschaften, die Zusammenstellungen von Dingen in der realen Welt oft haben, nicht abbilden: Ein RDF Liste ist beispielsweise nicht beschränkt, so könnte man in korrekter RDF Notation Dreiecke mit mehr als drei Eckpunkten konstruieren. Die Triple-Notation kann Relationen zwischen mehr als zwei Entitäten zwar nachbilden, verändert dabei aber die Semantik der Relation: Weil die Relationen eben nur noch binär sind, können Entitäten, die sich nur als Relation konstituieren nicht nachgebildet werden ohne externe Regeln, die auf das RDF Konstrukt angewendet werden. Eine weitere Kritik am Triple-Modell von RDF formuliert David Weinberger in Everything is Miscellaneous: »MetaCarta’s software analyzes the language in documents looking for references to geographic places. It tells the user that there is a certain probability that the word “London” in a document refers to London, England, another probability that it refers to London, Ontario, and a thrid probability that it refers to London broil. But RDF triples were not designed with probabilities in mind. They assume relationships are as simple as “is the daughter of”. Yet even being the daughter of someone is more complex that those few words express. Just ask any daughter.[. . .] RDF would have made Aristotile happy.«[Wei08, Seite 194]

RDF Triples sind nicht in der Lage, Relationen, die selber Eigenschaften haben, sauber Relationen mit abzubilden; nehmen wir Weinbergers Beispiel und nehmen an, das die Wahrscheinlichkeit 75% Eigenschaften ist, dass das „London im Text“ sich auf die britische hauptstadt bezieht: Wir nehmen als Subjekt das Wort „London in einem bestimmten Text“, als Prädikat das einfache „ist“ und als Objekt die Stadt London in England. Nun wollen wir der Beziehung eine Wahrscheinlichkeit als Eigenschaft zuweisen und wie schon zuvor sind wir gezwungen, die Relation selbst, als komplett eigenständige Entität zu definieren: Neben den relevanten Entitäten „London in einem Text“ und der Stadt London in England ergeben sich die Entitäten „Objekt1 ist Objekt2“ und „Wahrscheinlichkeit 75%“. Die Entität „Objekt1 ist Objekt2“ ist dabei nur notwendig, um in ihr die diversen Eigenschaften der Relation über weitere simple Verbindungen nachzubilden 38 3 Evaluation verschiedener Lösungsansätze

und wie schon im Beispiel „Dreieck“ entsteht eine Entität losgelöst von den sie eigentlich konstituierenden Entitäten.

Reification RDF lässt Aussagen über Aussagen, so genannte Reifikation[Wor04a], zu: RDF-Tripel, deren Subjekt wiederum ein RDF-Tripel ist. So lassen sich Eigenschaften von Relationen nachbilden, doch, wie schon oben am Beispiel des Dreiecks gezeigt, erzwingt diese Form der Modellierung von Eigenschaften oft externe Logik, die sicherstellt, dass die behaupteten Eigenschaften konsistent sind. Betrachten wir das Dreick ein weiteres mal und modellieren die einzelnen Innenwinkel über Reifikationen, so müssten wir bei jeder Änderung eines Eckpunkts sichstellen, dass die Innenwinkel weiterhin korrekt sind und sie gegebenenfalls neu berechnen. Reifikationen erlauben es also auch nicht, die komplexen Eigenschaften der von uns betrachteten Relationen angemessen zu modellieren. Diese in den vorigen Abschnitten herausgearbeiteten Schwächen in der Definition von RDF, die auf ein aristotelisches Denkmuster, nämlich, dass sich die Welt sauber und klar in definierten, hierarchischen Strukturen abbilden lässt, zurückgeht, sind, wie durch Wittgenstein gezeigt wurde1 sehr problematisch im Umgang mit Objekten des realen Lebens: Die Dinge der realen Welt sind durch komplexe Relationen, die weit über das vpn RDF unterstütze, binäre Modell hinausgehen, wie hier schon an simplen Beispielen gezeigt wurde. Aus diesem Grunde wird sich die hier entwickelte Software nicht auf die eingeschränkten Möglichkeiten RDFs beschränken, sondern darüber hinaus gehen. Wie an Beispielen gezeigt, kann im Zweifelsfall auch in RDF eine komplexe Relation unter Verlust einiger Information und Struktur nachgebildet werden, so dass die Reduktion auf das simple RDF-Modell unangemessen erscheint.

3.4 Evaluation unterschiedlicher Technologien bezüglich ihrer Eignung für diese Arbeit

Der Begriff der Platformunabhängigkeit ist, spätestens seit dem er als eines der Hauptargu- mente in der Marketingstrategie für die JAVA Platform der Firma SUN angeführt wurde, aus der modernen Softwareentwicklung nicht mehr wegzudenken: „Write once, run anywhe- re“2; doch beschränkt sich diese Möglichkeit keineswegs nur auf die JAVA Platform: Diverse moderne dynamische Sprachen wie Python3 oder Ruby4 erlauben es, Software zu schrei- ben, die auf diversen Betriebssystemen und Computerarchitekturen lauffähig ist, und auch Microsoft™s .NET-Platform hat im Mono Projekt5 eine Laufzeitumgebung gefunden, die es erlaubt, .NET-Anwendungen auf Linux, Solaris, Mac OS X oder anderen Unices laufen zu lassen. Die in dieser Arbeit zu entwickelnde Software soll ebenfalls so platformunabhängig sein, wie es möglich ist, trotzdem sollen an dieser Stelle einige grundlegende technische Probleme und

1 vgl. 2.3.1.1 2 http://en.wikipedia.org/wiki/Write_once,_run_anywhere 3 http://www.python.org 4 http://www.ruby-lang.org 5 http://www.mono-project.com 3.4 Evaluation unterschiedlicher Technologien bezüglich ihrer Eignung für diese Arbeit 39 ihre möglichen Lösungen erörtert werden, um am Ende eine fundierte Entscheidung treffen zu können, welche Platform und welche Technologien eingesetzt werden sollen.

3.4.1 Generelle Anforderungen

Generelle Anforderungen an einzusetzende Technologien sind zuerst einmal ihre frei zugängliche Dokumentation: Da keinerlei proprietäre Fremdsysteme direkt einzubinden sind, ergibt es Sinn, auf Technologien zu setzen, deren Dokumentation vollständig und qualitativ hochwertig ist. Technologien mit inkorrekter, mangelhafter oder nur unter Einschränkungen zugängiger Dokumentation sind folglich auszuschliessen. Des weiteren sind Technologien, die das Integrieren in den Desktop des jeweiligen Nutzers ermöglichen, zu bevorzugen. Platformunabhängigkeit bezieht sich unter diesem Gesichtspunkt nicht nur darauf, als Software überhaupt auf diversen Platformen lauffähig zu sein, sondern sich auch möglichst nahtlos in diverse Platformen zu integrieren.

3.4.2 Interprozesskommunikation

Unter Interprozesskommunikation versteht man Verfahren, die es Software erlauben, mit anderer Software zu interagieren, Daten auszutauschen und Befehle aufzurufen. Das Problem, unterschiedliche Programme auf einem Rechner miteinander kommunizieren zu lassen ist schon alt, weshalb es dafür eine große Menge von fertigen und erprobten Lösungen gibt. Im folgenden werden die beiden Begriffe Server und Client wie folgt benutzt: Der Server ist der Prozess, welcher auf eingehende Verbindungen wartet, der Client ist der Prozess, welcher dann zu einem Server die Verbindung aufnimmt. Jeder Prozess kann in unterschiedlichen Kontexten selbstverständlich mal Server und mal Client sein.

3.4.2.1 POSIX Local IPC Sockets

Eine der, vor allem für typischerweise über Netzwerke kommunizierende Dienste verwendeten, Lösungen ist die Kommunikation über so genannte Unix Domain Sockets, oder wie der POSIX Standard[Por04] sie nennt POSIX Local IPC Sockets. Diese sind auf jedem POSIX kompatiblen System verhanden und stellen sich als spezielle Dateien dar: Die Socket-Datei ist mit einem laufenden Programm verbunden und wenn Daten in die Socket-Datei geschrieben werden, so kommen diese im verbundenen Programm, dem Server, an. Zur Kommunikation über POSIX Local IPC Sockets muss der Server eine klare Schnittstelle, ein Protokoll definieren, welches auch dem Client bekannt sein muss, dieses Protokoll enthält alle Regeln, die für eine erfolgreiche Kommunikation eingehalten werden müssen. Der Nachteil dieser Lösung ist, dass ein spezielles Protokoll zu definieren, zu implementieren und zu testen ist. Diverse Dienste, setzen aus Leistungsgründen auf eigens definierte Protokolle, die es ihnen erlauben ihre Aufgabe möglichst effizient zu erfüllen: Viele Datenbankmanage- 40 3 Evaluation verschiedener Lösungsansätze

mentsysteme wie MySQL1 oder PostgreSQL2 bieten solche eigens spezifizierten Protokolle und fertige Client-Bibliotheken an, die es Drittanbietern erlauben, das spezifische Protokoll mit wenig Aufwand zu unterstützen.

3.4.2.2 Kommunikation über TCP

Ähnlich wie POSIX Local IPC Sockets erlaubt das TCP Protokoll eine einfache Möglichkeit, zwischen einem Server und einem Client Daten auszutauschen. Dabei wird in diesem Falle allerdings keine spezielle Datei zum Datenaustausch genutzt, sondern die Daten werden über das Netzwerksubsystem des Betriebssystems versendet und empfangen. Dabei können selbstverständlich sowohl der Sender als auch der Empfänger auf demselbem Rechner laufen. Weil die Kommunikation über TCP-Sockets3 so ähnlich zu den POSIX Local IPC Sockets ist, bringt sie dieselben Schwierigkeiten mit sich: Ein Protokoll muss entwickelt und getestet werden. Hinzu kommt bei einem offenen Netzwerkdienst noch das Problem der Authentifikation, um unberechtige Zugriffe abwehren zu können, ein Problem welches bei POSIX Local IPC Sockets die Sicherheitsmechanismen des Betriebssystems lösen.

3.4.2.3 XMLRPC und Web Services

Moderner als die simple Kommunikation über TCP-Sockets sind die auf dem im Internet sehr verbreiteten HyperText Transfer Protocol (HTTP) aufsetzenden Mechanismen des XMLRPC und des Web Service. Beide erlauben es, Daten und Befehle mit entfernten Systemen auszutauschen, ohne dass komplexe Protokolle selbst zu definieren sind. Das Protokoll zum physikalischen Versenden der Daten ist in beiden Fällen, wie schon gesagt, HTTP und die Daten sind in beiden Fällen in klar spezifizierte und von diversen Bibliotheken unterstützten XML-Formate zu kodieren. Beide Mechanismen setzen also auf sehr verbreiteten und gut getesteten Technologien auf, die vollständig plattformunabhängig sind und selbst die Kommunikation zwischen vollständig unterschiedlichen Platformen erlauben. Der Vorteil der beiden Protokolle ist auch ihr Nachteil: Das ihnen zugrunde liegende HTTP ist mit einem großen Overhead verbunden, der, gerade bei Web Services, noch durch die komplexen XML Strukturen in der die Daten transportiert werden, erhöht wird. Für die Anforderungen von Anwendungen auf dem Desktop kann dieser Overhead schnell sehr problematisch werden.

1 http://www.mysql.com 2 http://www.postgresql.org 3 nicht zu verwechseln mit POSIX Local IPC Sockets! 3.4 Evaluation unterschiedlicher Technologien bezüglich ihrer Eignung für diese Arbeit 41

3.4.2.4 D-BUS

D-BUS ist ein ursprünglich von der Firma Red Hat entwickeltes und mittlerweile unter dem Dach von Freedesktop.org1 weiterentwickeltes Nachrichtenbussystem. Der Fokus bei der Entwicklung von D-BUS lag hierbei darin, einen einfachen und portablen Standard zu schaffen, um Kommunikation zwischen unterschiedlichen Prozessen und Diensten zu vereinfachen:

»D-Bus is a system for low-latency, low-overhead, easy to use interprocess communication (IPC). In more detail: • D-Bus is low-latency because it is designed to avoid round trips and allow asynchronous operation, much like the X protocol. • D-Bus is low-overhead because it uses a binary protocol, and does not have to convert to and from a text format such as XML. Because D-Bus is intended for potentially high-resolution same-machine IPC, not primarily for Internet IPC, this is an interesting optimization. • D-Bus is easy to use because it works in terms of messages rather than byte streams, and automatically handles a lot of the hard IPC issues. Also, the D-Bus library is designed to be wrapped in a way that lets developers use their framework’s existing object/type system, rather than learning a new one specifically for IPC. «[Hav]

Dabei laufen auf einem System üblicherweise mehrere parellele D-BUS Instanzen: Der so genannte System-Bus, über den Systemdienste miteinander kommunizieren, und gegebenenfalls mehrere Session-Busse, von denen jeweils einer an der Sitzung eines eingeloggten Nutzers hängt. Die Busse sind vollständig voneinander getrennt und unterstützen Berechtigungen zum Zugrif auf bestimmte Objekte auf dem Bus. D-BUS wird eingesetzt als IPC Mechanismus in den GNOME und KDE Projekten und diversen mobilen Entwicklungsplattformen wie Nokias Maemo Platform und ist verfügbar für Linux, Unix, Mac OS X und Microsoft™Windows™Betriebssysteme. Für D-BUS existieren Client-Bibliotheken für eine große Menge von Programmiersprachen wie beispielsweise C, C++, .NET/Mono, JAVA, Python, PHP und Perl.

3.4.2.5 Fazit nach Betrachtung der vorliegenden IPC Mechanismen

Während XMLRPC und Web Services unter Umständen bekannter und verbreiteter sind als D-BUS, so scheiden sie doch, aufgrund des mit ihnen verbundenen Overheads, aus als IPC Mechanismus für eine Desktop-Anwendung. Mittels POSIX Local IPC Sockets und TCP-Sockets könnten sicherlich performante Protokolle entworfen und implementiert werden, doch bietet D-BUS eine gut dokumentierte und getestete Lösung, die genau die für eine Desktop Anwendung relevanten Kriterien erfüllt.

1 eines Dachprojektes zur Kooperation zwischen Desktop Umgebungen wie GNOME und KDE 42 3 Evaluation verschiedener Lösungsansätze

Weil für D-BUS des weiteren fertige Bibliotheken für die meisten relevanten Program- miersprachen existieren und D-BUS auf den verbreitetsten Betriebssystemen läuft, ist es die beste Wahl für einen flexiblen und platformunabhängigen IPC-Mechanismus. Aufgrund seiner Wurzeln im Ökosystem der freien Software stehen des weiteren eine große Menge getesteter Codebeispiele zur Verfügung, die eine Implementierung eines D-BUS Interfaces einfach machen.

3.4.3 Weitere Schnittstellen

Wie schon in der Formulierung der Ziele dieser Arbeit1 angeschnitten, ist das Entwickeln einer Insellösung zu vermeiden. Doch selbst bei Rückgriff auf D-BUS als verbreitete und offene Schnittstelle existiert eine kaum zählbare Menge an Software, die selbst in Zukunft aus unterschiedlichen Gründen niemals die noch zu spezifizierende Schnittstelle implementieren werden. Um diesen fremden Systeme trotzdem in einer Form Zugriff auf die Daten unseres Systems anzubieten existieren einige Möglichkeiten, die im Folgenden kurz evaluiert werden sollen.

3.4.3.1 Netzwerkdateisystem

Die meisten modernen Betriebssysteme unterstützen eines oder sogar mehrere Netzwerkbe- triebssysteme wie CIFS oder NFS. Eine Möglichkeit, fremden Systemen Zugriff auf die Daten unserer Software zu bieten, auf die Tags, die Relationen und die Entitäten, die der Nutzer definiert hat, wäre es, einen Server für eines der oben genannten Netzwerkdateisysteme zu implementieren, der Pfadzugriffe auf Anfragen an das System übersetzt. Diese Lösung wäre platformagnostisch, da nur die Unterstützung eines Netzwerkdateisystems zum Zugriff auf Daten notwendig ist, hätte allerdings den Nachteil, dass die Implementierung eines korrekten Servers für ein solches Dateisystems keine triviale Aufgabe darstellt. Des wei- teren stellt sich für eine netzwerkbasierte Lösung wiederum das Problem der Authentifikation, um unerwünschte Fremdzugriffe auf das System zu vermeiden.

3.4.3.2 FUSE

FUSE steht für „Filesystem in Userspace“ und wurde ursprünglich als Modul für den Linux Kernel entwickelt. FUSE erlaubt es, Dateisysteme auf simple Art und Weise im so genannten Userspace, also dem unpriviligierten Segment des virtuellen Speichers des Betriebssystems, zu implementieren. Eines der Hauptprobleme, die dadurch gelöst wurden, war, dass ein Absturz innerhalb des Dateisystemcodes nicht das gesamte Betriebssystem mit sich reissen konnte: Nur der Prozess im Userspace, der das Dateisystem implementiert musste geschlossen werden.

virtuelle Doch auch für virtuelle Dateisysteme hat sich FUSE als ausgesprochen nützlich erwiesen: Dateisysteme Anstatt komplexen Code in der Kernel Schicht des Betriebssystems, meist in C, schreiben zu müssen, bietet FUSE eine einfache API, welche in diverse Sprachen wie C++, Java, Python,

1 vgl. 1.2 3.4 Evaluation unterschiedlicher Technologien bezüglich ihrer Eignung für diese Arbeit 43

C#, Erlang und noch viele mehr1 portiert wurde. Das Entwickeln von virtuellen Dateisystemen wurde auf diese Art und Weise schneller und auch einer größeren Menge von Entwicklern möglich, was in der Folge diverse virtuelle Dateisysteme wie beispielsweise das schon erwähnte Flickrfs2 ermöglichte. FUSE ist heute nicht mehr auf den Linux Kernel beschränkt sondern wurde auch auf Mac OS X und Windows™sowie diverse Unices portiert. Ähnlich wie schon bei der Idee der Netzwerkdateisysteme angerissen, könnte man FUSE einsetzen, um ein virtuelles Betriebssystem zu entwickeln, welches Pfadaufrufe in Anfragen an das System übersetzt.

3.4.3.3 Fazit Weitere Schnittstellen

Die Idee, Pfadaufrufe in Anfragen an unser System zu übersetzen, kann sowohl von FUSE als auch von einem Netzwerkdateisystem umgesetzt werden, doch ist die Implementierung eines FUSE Dateisystems aufgrund der guten Dokumentation, der klaren und einfachen API sowie der großen Anzahl freier Codebeispiele um Größenordnungen einfacher einzuschätzen. Der Rückgriff auf Pfadaufrufe als Formulierung von Anfragen an unser System erlaubt es jeder Anwendung über die herkömmlichen Schnittstellen, die das jeweilige Betriebssystem anbietet zum Zugriff auf Dateien3, auf die vom Nutzer definierten Strukturen zuzugreifen. Dies ermöglicht es dem Nutzer, auch mit nicht auf unsere Anwendung angepassten Anwendungen, auf die innerhalb unserer Software geschaffene Struktur und alle die Möglichkeiten, die sie ihm bietet zur Strukturierung seiner Dateien und zum schnellen Auffinden, zu nutzen.

3.4.4 Datenhaltung

Zur Datenhaltung des Systems stehen einige Möglichkeiten zur Verfügung, die teils schon Ange- rissen wurden. In den nächsten Absätzen sollen die relevanten Möglichkeiten zur Datenhaltung kurz evaluiert werden.

3.4.4.1 XML/RDF

Wie schon in 3.3 beschrieben, hat die Kombination aus XML und RDF einige Schwachpunkte, SPARQL die das modellieren komplexer Relationen in XML/RDF schwierig, bzw. nur über Umwege möglich machen. Doch ist RDF ein etablierter und anerkannter Standard zur Speicherung von Metadaten, der sogar 2006 mit der ersten Veröffentlichung des SPARQL[Wor08] Standards eine Abfragesprache bekommen hat, welche das Durchsuchen von RDF-formatierten Daten bzw. die Extraktion von Informationen aus einer RDF-Struktur erlaubt. Die SPARQL Syntax orientiert sich dabei an SQL, der Abfragesprache für relationale Datenbanken.

1 siehe hierzu http://fuse.sourceforge.net/wiki/index.php/LanguageBindings 2 http://manishrjain.googlepages.com/flickrfs 3 wie Beispielsweise POSIX 44 3 Evaluation verschiedener Lösungsansätze

XML/RDF und SPARQL sind noch verhältnismässig jung, weshalb gerade bei SPARQL Aussagen über die Leistungsfähigkeit, die Stabilität und die Korrektheit der unterschiedlichen Implementationen schwer zu machen sind. Es existieren zwar Benchmarks wie der Berlin SPARQL Benchmark1, doch fehlt noch eine breite Untersuchung der Leistungsfähigkeit der unterschiedlichen Implementierungen. Des weiteren sind RDF-Speicher mit einem gewissen Installationsaufwand für den Nutzer verbunden, bzw. mit einer großen Zahl von Abhängigkeiten für die zu entwickelnde Software.

3.4.4.2 Relationale Datenbank

Relationale Datenbanken bilden heute das Rückrad vieler Anwendungen, gerade auch vieler Anwendungen im Internet, die mit einer Vielzahl von parallelen Nutzern umzugehen haben. Dabei existieren neben den bekannten großen Datenbanken wie MySQL, PostgreSQL oder den kommerziellen Oracle und DB2 noch kleine relationale Datenbankmanagementsysteme wie SQLite2, die sich leicht und ohne viel Aufwand in Anwendungen integrieren lassen, weshalb sie auf gewisse Funktionalitäten ihrer großen Brüder verzichten. Relationale Datenbankmanagementsysteme werden seit Jahrzehnten eingesetzt und opti- miert, sie sind sehr verbreitet, und die standartisierte Abfragesprache SQL ist einfach und vielen Softwareentwicklern vertraut.

Objekt- Seit einigen Jahren finden auch so genannte objekt-relationale Mapper (ORMs) einen relationale Mapper großen Zuspruch, die es erlauben, die Klassen einer objekt-orientierten Programmiersprache transparent auf relationale Datenbankmanagementsysteme zu übersetzen. So erspart sich der Programmierer die händische Entwicklung einer direkten Datenbankanbindung, allerdings zum Preis einer gewissen Leistungseinbusse. Als weiteren Bonus bringen ORMs häufig die Möglichkeit mit sich, diverse unterschiedliche Datenbanken und ihre subtilen Unterschiede ab- strahieren zu können, so dass dem Entwickler der Wechsel der verwendeten Datenbanksoftware verhältnismäßig leicht fällt. Relationale Datenbanken sind allerdings nicht auf die speziellen Probleme dieser Arbeit zugeschnitten wie RDF-basierte Lösungen.

3.4.4.3 Fazit Datenhaltung

Auch wenn RDF-basierte Datenspeicher genauer auf das Problem, welches in dieser Arbeit angegangen werden soll, zugeschnitten sind, so sind die Nachteile, die einerseits in den oben schon beschriebenen grundlegenden Schwächen von RDF und andererseits in der mangelnden Erprobung und der aufwendigen Installation der RDF-Datenspeicher liegen, doch gravierend. Relationale Datenbanken sind aus diesem Grunde für das vorliegende Projekt die bessere Wahl, weil ihre Leistungsfähigkeit sich schon seit langen Jahren bewiesen hat.

1 http://www4.wiwiss.fu-berlin.de/bizer/BerlinSPARQLBenchmark/ 2 http://www.sqlite.org 3.4 Evaluation unterschiedlicher Technologien bezüglich ihrer Eignung für diese Arbeit 45

Allerdings scheint die Nutzung eines ORMs sinnvoll um gegebenenfalls einen späteren Wechsel auf eine RDF-basierte Speicherlösung zu ermöglichen.

3.4.5 Zusammenfassung

Aus der Untersuchung der unterschiedlichen Technologien haben sich für viele Problemfelder gute Lösungen herauskristalisiert:

• Für die Interprozesskommunikation ist die Wahl auf D-BUS gefallen, welcher auf allen relevanten Platformen läuft und von einer großen Menge von Programmiersprachen unterstützt wird. • Als weitere Schnittstelle neben D-BUS hat sich FUSE als die beste Alternative zum Anbinden von unmodifizierter Software herausgestellt. Auch FUSE erlaubt es, eine große Menge unterschiedlicher Programmiersprachen einzusetzen, und ist sehr portabel. • Für die Datenhaltung wurde sich für eine relationale Datenbank und gegen einen RDF- basierten Speicher entschieden, vor allem aufgrund der Verlässlichkeit und Erprobtheit von relationalen Datenbanken. Um eine spätere Migration möglich zu machen, soll ein ORM eingesetzt werden, der die Zugriffe auf die relationale Datenbank so weit wie möglich abstrahiert.

All diese gewählten Technologien lassen eine weite Auswahl an möglichen Programmier- sprachen zu, von denen eine große Teilmenge das Schreiben platformunabhängiger Software ermöglicht und sogar vereinfacht: JAVA, C# und Python sind sicherlich die drei bekanntesten Vertreter. An dieser Stelle wurde sich für eine Implementierung in Python entschieden: Python erlaubt es, sowohl nach dem objekt-orientierten, dem funktionalen oder dem prozeduralen Programmierparadigma[Flo79] zu programmieren, liefert eine relationale Datenbank und ihre Treiber in der Standardinstallation mit1. Python wird von vielen Betriebssystemen wie Mac OS X und der überwiegenden Mehrheit aller Linux-Distributionen und Unix-Derivate in der Standardinstallation mitgeliefert und läuft auch unter Windows™Platformen hervorragend. Die Python Dokumentation ist, wie die Sprache selbst auch, unter freien Lizenzen verfügbar und von sehr hoher Qualität. Somit ist Python eine ideale Wahl als Programmiersprache für die Umsetzung der gesetzten Ziele.

1 SQLite 46 3 Evaluation verschiedener Lösungsansätze KAPITEL 4

Entwurf

Im folgenden Kapitel soll das zu entwickelnde System im Detail entworfen werden. Hierbei wird, soweit es möglich ist, UML-Notation verwendet, um die Beziehungen von Klassen zu modellieren. UML unterstützt allerdings nur eine sehr reduzierte Menge von Konstrukten, weshalb an einigen Stellen die UML-Notation durch eigene Notationen erweitert werden wird; die Erweiterungen werden bei ihrem ersten Auftreten beschrieben werden. Die zu entwickelnde Software, die ein virtuelles Dateisystem bereitstellen wird, firmiert unter dem Namen „Wittgenstein“ zu Ehren des Philosophen, der die theoretische Grundlagen zur Modellierung geliefert hat 1, im Folgenden wird „Wittgenstein“ also, wenn keine weitere Eingrenzung vorgenommen wird, als Name der entwickelten Software verwendet werden, um genau zu sein als Name des Servers, der das virtuelle Dateisystem bereitstellt.

4.1 Architektur

Das hier entworfene System stellt ein typisches Beispiel einer Client-Server Architektur dar: Das virtuelle Dateisystem wird von einem Server implementiert, zu dem sich beliebig viele Clients über die angebotenen Schnittstellen verbinden, um Daten aus dem System auszulesen oder dem System neue Daten hinzuzufügen. Dabei sind die Schnittstellen dergestalt entworfen, dass an die Clients selbst kaum Anforde- rungen gestellt werden: Wie diese den Zugriff auf die Schnittstellen selbst realisieren oder auf welcher Technologie sie aufsetzen ist für den Server irrelevant. Diese Form der Architektur bringt mit sich einige Anforderungen an das Design der Schnittstelle für die Clients mit sich, welche in Abschnitt 4.3.1 genauer ausgearbeitet werden.

Der Server, welcher die gespeicherten Daten verwaltet und die Schnittstelle zum Zugriff Server- auf die Daten anbietet, ist in klar getrennte Komponenten strukturiert, zwischen denen nur struktur geringe Abhängigkeiten untereinander bestehen. So ist das Austauschen einer Komponente, beispielsweise das Ersetzen der auf einer relationalen Datenbank basierenden Datenhaltung2,

1 vgl. 2.3.1.1 2 wie in 3.4.5 angedeutet 48 4 Entwurf

mit verhältnismässig geringem Aufwand möglich. Des weiteren erleichtert dieses Vorgehen die Integration von fertigen Bibliotheken zur Lösung bestimmter Teilprobleme, was nicht nur die Entwicklungszeit verringert sondern auch in vielen Fällen die Qualitätssicherung erleichtert, schlicht weil weit verbreitete Bibliotheken von einer großen Anzahl von Nutzern und Entwicklern im täglichen Einsatz getestet und verbessert werden. So erlaubt die Kompo- nentenbasierung uns, den Fokus des Projektes auf die Aufgabe selbst zu legen und weniger auf die „Infrastruktur“ drumherum. Der Wittgenstein-Server organisiert sich intern wie in Diagramm 4.1 dargestellt:

Abbildung 4.1: Architektur des Wittgenstein Servers

Model- Dem klassischen Model-View-Controller Design Pattern entsprechend, trennt diese Struktur, View- Controller das „Model“, das heisst die Komponente, die sich mit der direkten Verwaltung der Daten beschäftigt, vom „Controller“, welcher den „Umgang“ mit den Daten kontrolliert und welcher in diesem Falle von der Komponente „Öffentliche API“ realisiert wird. Der „View“ Teil der Gleichung ist völlig entkoppelt von den anderen Teilen: Die, mit dem Server über seine Schnitt- stelle kommunizierenden, Clientanwendungen, graphische Benutzungsoberflächen, realisieren die „View“, die Ansicht auf die Daten. 4.1 Architektur 49

Der Server kommuniziert allerdings nicht nur mit seinen Clients, sondern, über die „Helfer zur Datenextraktion“ unter Umständen auch mit Fremdsystemen: Nehmen wir als Beispiel den Fall, dass eine Person ins System aufgenommen werden soll, so ergibt es Sinn, dass ein Datenextraktionshelfer die Kontaktdatenbank, die der Nutzer in seinem Instant Messenger oder seinem EMail-Programm pflegt, kontaktiert, um bestimmte Daten der Person zu übernehmen. Doch können solche Datenextraktionshelfer auch einfach die Funktionaliät bereitstellen, die festen Metadaten eines speziellen Dateiformates auszulesen. Die Datenextraktionshelfer bzw. die Schnittstelle, über die sie angebunden werden, wird im Abschnitt 4.5 im Detail spezifiziert. Die „Öffentliche API“ stellt hierbei Funktionen zur Verfügung, die den Zugriff auf die Daten des Models, sowie das Hinzufügen neuer Daten auf eine einfache Art und Weise erlauben. Die Funktionalität der „öffentlichen API“ wird des weiteren vollständig von der D-BUS Schnittstelle in eine Form übersetzt, die es, völlig losgelöst von der Implementierungssprache, auf den vollständigen Funktionsumfang des Servers zuzugreifen. Weiter Schnittstellen können leicht geschaffen werden, indem man entweder auf der D-BUS Schnittstelle aufsetzt, oder selbst eine Abstraktion der „öffentliche API“ schafft, welche dann beispielsweise den Zugriff innerhalb eines anderen IPC Mechanismus ermöglicht.

Zusammenfassend bietet die Modularität beim Design der Serverarchitektur zwar die Modularität Möglichkeit, nahezu jede Komponente durch eine andere zu ersetzen, doch liegt der Fokus dabei nicht auf dem Selbstzweck sondern der Erweiterbarkeit bezüglich weiteren Clientschnittstellen nach aussen sowie der Implementierung von weiteren Datenhaltungen.

4.1.1 Aufteilung der Gesamtsoftware in Teilanwendungen

Wie die Abbildung 4.1 zeigt, trennt sich unser System in einige lose gekoppelte Kompo- nenten auf: Abstrahiert man von den Details der Architektur, teilt sich die Software in 3 Teilanwendungen auf.

1. Der Wittgenstein Server, welcher über D-BUS angesprochen werden kann, und welcher letzten Endes vor allem eine sehr spezialisierte Datenbank für Metadaten darstellt 2. Der Helfer zur Datenextraktion, welcher ein spezieller Client ist, der dem Server zusätz- liche Daten über neu hinzugefügte Objekte liefert 3. Die Clients, welche die angebotenen Schnittstellen nutzen

Dabei ist der Helfer zur Datenextraktion letzten Endes auch nur ein weiterer Client, der vom Aufteilung in mehrere Server bei Bedarf gestartet wird: Die Datenextraktion findet nicht innerhalb des Serverprozesses Anwendungen statt, sondern in einem extrenen Prozess. Dem Datenextraktor wird die Referenz auf die neue Datenstruktur übergeben und nachdem dieser neue Daten über das Betreffende Objekt ermittelt hat, schreibt dieser sie über die D-BUS Schnittstelle zurück. Dieser Ansatz hat den Vorteil, dass neue Objekte direkt nach dem Eintragen zur Verfügung stehen, selbst wenn der Datenextraktor auf entfernte Fremdsysteme mit hoher Latenz zugreifen muss. Trägt der Nutzer eine neue Person ein, so ist diese auf der Stelle benutzbar, auch wenn der Datenextraktor im Hintergrund versucht, die vollständige Addresse der Person aus dem Addressbuch zu ermitteln. Die Extraktion von Metadaten aus Dateien kann des weiteren, gerade bei beschädigten oder nicht vollständig dem Standard entsprechenden Dateien, von 50 4 Entwurf

Stabilitätsproblemen betroffen sein: Ein abstürzender Datenextraktor kann aber in unserem Design niemals den Server zum Absturz bringen. Auch können eventuelle Fehler in den vom Datenextraktor genutzen Bibliotheken abgefangen werden, da jede Information immer durch die öffentliche D-BUS Schnittstelle gefiltert wird: Selbst defekte Dateien, deren Metadaten defekt sind oder falsch ausgelesen wurden, können keine defekten Eintragungen erzeugen. Das Heraustrennen der Datenextraktion macht den Server selbst einfacher und damit einfacher zu warten, zu implementieren und zu testen: Der Server selbst wird reduziert auf das Bereitstellen einer speziellen Datenbank und einer Schnittstelle zum Zugriff auf diese. Der Server bietet so dem Nutzer eine möglichst kurze Latenz beim Zugriff auf seine Daten, ein wichtiges Akzeptanzkriterium für Datenbanken und andere Anwendungen zur Datenhaltung.

4.2 Entwurf der Datenstrukturen

Unser System setzt auf einigen Konstrukten auf, die wir im folgenden Abschnitt detail- lierter modellieren werden. Diese Konstrukte ergeben sich nach einiger Reflexion über die Beschaffenheit physischer Objekte und der Sicht von Menschen auf eben jede.

4.2.1 Übersicht

Abbildung 4.2: Übersicht der Klassen, die die Datenhaltung modellieren 4.2 Entwurf der Datenstrukturen 51

Das Model, die Datenhaltung, modelliert ihre Inhalte innerhalb einer objekt-orientierten Struktur aus Klassen. Die einzelnen Klassen werden im Verlauf dieses Kapitels noch genauer beschrieben, doch an dieser Stelle soll ein Überblick geschaffen werden, darüber, wie die einzelnen Klassen zusammenhängen. Wie Diagramm 4.3 zeigt, zergliedern sich die verwalteten Objekte in drei Basistypen: Resource, Relation und Entity. Das Modul Relation modelliert Beziehungen zwischen Instanzen von Resource und Entity. Der Einfachheit halber wird relation an dieser Stelle nur als einfache Klasse modelliert, wie später im Abschnitt 4.2.6 noch genauer ausgearbeitet wird, ist die Struktur von Relationen etwas komplexer, um eine große Flexibilität zu gewährleisten. Die abstrakte Klasse Entity repräsentiert die Unterschiedlichen Objekte der Welt, die der Nutzer zu seinen Ressourcen in Beziehung setzen möchte, die einzelnen Unterklassen von Entity modellieren hierbei jeweils einen speziellen Typ von Objekten der Welt. Eine gemeinsame Oberklasse abstrahiert gemeinsame Eigenschaften aller im System verwalteten Objekte.

4.2.2 Die Klasse Object

Alle im System verwalteten Typen von Objekten setzen auf einer gemeinsamen Basisklasse auf, dem Object1. Die gemeinsame Basis Object bringt mit sich einige Eigenschaften, die für alle Objekte im System relevant sind: Zuerst einmal besitzt jedes Objekt eine eindeutige Identifikation. Statt einer eigenen Notation oder einem eigenen Algorithmus zur Generierung dieser ID wird auf den UUID-Standard[PMR05] zurückgegriffen, welcher die folgenden Eigenschaften umsetzt: »A UUID is 128 bits long, and can guarantee uniqueness across space and time.« 16 Da UUIDs 128bit Zahlen sind, ist die Anzahl aller möglichen UUIDs folglich 256 oder in UUIDs etwa 3.4 × 1038. Das bedeutet, dass man, um alle UUIDs zu generieren, für 10 Milliarden Jahre in jeder Nanosekunde eine Billion UUIDs generieren müsste: UUIDs sind also hinreichend eindeutig, um jedes Objekt, welches der Nutzer ins System aufnehmen möchte, klar genug zu identifizieren, dass sogar ein späterer Abgleich mit weiteren Systemen theoretisch möglich sein wird. Sicherlich sind theoretische Kollisionen bei UUIDs denkbar, doch ausreichend unwahrscheinlich. UUIDs werden üblicherweise als 32 hexadezimale Zeichen dargestellt, in 5 Gruppen zerlegt und durch Bindestriche („-“) getrennt; die Verteilung der Zeichen ist 8-4-4-4-12, ein Beispiel für eine UUID wäre also ba7ae523-dd5c-4f4c-859a-99e1567272a3.

Als zweite Eigenschaft, die die Oberklasse Object an alle Unterklasse weitergibt ist die, kommentierbar kommentierbar zu sein, das heisst, das man an Instanzen dieser Klasse (oder ihrer Unterklassen) beliebig viele Kommentare anhängen kann, dabei ist Comment selbst allerdings auch noch eine Unterklasse von Object; so kann auch jeder Kommentar eindeutig referenziert werden.

1 Nicht zu verwechseln mit dem object, welches üblicherweise die Basisklasse einer jeden Python Klasse darstellt, oder dem Object aus dem JAVA Kontext: Das hier genannte Object ist unsere eigene Klasse 52 4 Entwurf

Bewertungen Schlussendlich fügt Object noch das Attribut rating hinzu, welches es dem Nutzer erlaubt, ähnlich wie aus Mediaplayern bekannt, seine Objekte im System zu bewerten: Wo im Musik- player das Rating ausdrückt, wie sehr der Nutzer ein bestimmtes Stück mag, so kann es in unserem Kontext die Qualität einer jeden Ressource oder einer jeden Entität modellieren.

Tabelle 4.1: Beschreibung der Eingenschaften von Instanzen der Klasse Object, welche an ihre Unterklassen vererbt werden

Eigenschaft Bedeutung uuid Die UUID des Objektes rating Die Bewertung des Objektes, formuliert als Ganzzahl zwischen 0 und 5

Object Die gemeinsame Oberklasse Object, in ihren Eigenschaften beschrieben in Tabelle 4.1, ist als Basisklasse vor allem auf zukünftige Erweiterungen ausgelegt: Jedem Objekt innerhalb des Systems eine eindeutige ID zuzuordnen erlaubt beispielsweise den Austausch bestimmter Objekte zwischen zwei Instanzen, ohne dabei Objekte, die für die Nutzer identisch sind, als zwei unterschiedliche Objekte in den unterschiedlichen Wittgenstein Installationen erscheinen zu lassen: Übernimmt Person A von Person B einen Datensatz zum Beispiel über ein bestimmtes Buch, so kann man selbst nach einigen Monaten immer noch die beiden Datensätze auf den unterschiedlichen Systemen miteinander abgleichen. Diese Anwendung geht zwar noch über den Rahmen dieser Arbeit hinaus, die Grundlagen für solcherlei Funktionalität ist hingegen schon implementiert.

4.2.3 Die Klasse Comment

Die Klasse Comment modelliert einen Kommentar zu einem beliebigen Objekt innerhalb des Systems. Sie erlaubt es dem Nutzer, an jede Relation, an jede Ressource und an jede Entity1 mehrere Kommentare zu hängen. Jeder dieser Kommentare enthält dabei, neben seinem Inhalt, seinem Text, auch noch den Zeitpunkt seiner Erstellung und den Namen des Nutzers, der ihn erstellt hat2.

Tabelle 4.2: Beschreibung der Eingenschaften von Instanzen der Klasse Comment

Eigenschaft Bedeutung text Der Inhalt des Kommentares author Der Name des Autors des Kommentars date Das Datum der Erzeugung des Kommentars

1 sogar an jeden Kommentar selbst! 2 Eine Funktion die zur Zeit bei Ein-Benutzer-Nutzung nicht relevant ist, die aber später beim Austausch von Kommentaren relevant werden kann 4.2 Entwurf der Datenstrukturen 53

4.2.4 Die Klasse Resource

Die Klasse Resource modelliert die Dinge, um deren Verwaltung sich diese Arbeit schlussendlich dreht, Ressourcen. Unter Ressourcen verstehen wir in diesem Falle die folgenden Objekte: • File: Eine Datei irgendwelchen Inhalts • Directory: Ein Verzeichnis, welches Dateien oder andere Verzeichnisse enthalten kann • URL: Eine URL fungiert als Name einer Ressource, die beispielsweise im Web Wide Web liegen kann. URLs werden in diesem Kontext behandelt wie der Inhalt auf den sie zeigen, das bedeutet, dass es nicht um die URL selber geht, sondern die Daten, die über die URL bezogen werden können.

Die Eigenschaften von Ressourcen werden, wie in 3.2.2.1 festgehalten, in einem zum Dublin Dublin Core Core Standard kompatiblen Format gespeichert. Somit haben alle Ressourcen die folgenden Eigenschaften gemein1:

Tabelle 4.3: Auflistung der Typen von Resourceneigenschaften

Eigenschaft title subject description type format identifier language coverage rights

Jede Resource besitzt als mögliche Eigenschaf- ten des weiteren Orte: Den Ort oder die Orte, an dem die Resource auffindbar ist. Für Dateien und Verzeichnisse sind diese Orte Pfadangaben im lokalen Dateisystem, für URLs sind es Ad- dressen innerhalb eines Netzwerkes. Ein solcher Ort ist allerdings eindeutig: Zu einem Zeitpunkt kann beispielsweise an einem Ort im Dateisystem Abbildung 4.3: Die Beziehung von Resour- nur genau eine Datei bzw. ein Verzeichnis liegen. ce und Property Deshalb interpretieren wir Orte als „Refinement“ der Eigenschaft identifier. Jede dieser Eigenschaften kann in mehreren Ausprägungen vorkommen: So hat jede Resource als Unterklasse von Object eine UUID, welche offensichtlich ein besonderer identifier ist, doch

1 zur genauen Beschreibung der Begriffe siehe 3.2.2 54 4 Entwurf

sind für viele Ressourcen auch noch weitere identifier denkbar, welche hinzugefügt werden können, wie beispielsweise ISBNs für elektronisch vorliegende Bücher. Wie beim Dublin Core Standard vorgesehen, ist jedes der Felder optional. Die Dublin Core Felder relation, source, date, contributor, publisher und creator werden in diesem System als vordefinierte Relationen abgebildet: Als Autor, also creator, einer Ressource können eine oder mehrere im System definierte Personen ausgewählt werden. Diese werden dann mit der Ressource verknüpft, wie in den folgenden Abschnitten noch genauer ausgearbeitet werden wird. Um diese Multiplizität zu gewährleisten, wird eine weitere Klasse hinzugefügt, welche die oben genannten Eigenschaften Modellieren können: Die Klasse Property. Property Instanzen erlauben es uns, jedes Attribut beliebig oft in unsere Resource-Instanzen einzubinden und somit dem Dublic Core Standard konform zu sein. Die Klasse Property besitzt dabei die folgenden Eigenschaften: Die Resource zu der sie verbunden ist, ihren Typ (zum Beispiel „subject“, „description“ &ct), ein optionales „Refinement“1 und den zugewiesenen Wert. Die Relationen, die für die Erfüllung der Kompatibilität mit dem Dublin Core Standard notwendig sind, werden vom System mitgeliefert und können nicht vom Nutzer geändert werden. Im Folgenden sollen einige weitere Eigenschaften untersucht werden, die die unterschiedlichen Arten von Ressourcen besitzen, und beschrieben werden, wie diese Eigenschaften innerhalb des Modells umgesetzt werden.

4.2.4.1 Weitere Eigenschaften von Resourcen

Daten über Eine Datei im Dateisystem, die in unser System aufgenommen wird, wird nicht bewegt oder Ressourcen selbst verändert, die neuen Metadaten liegen ausserhalb ihrer selbst. Trotzdem ergibt es Sinn, einige Metadaten, die Datei- und Betriebssystem selbst über die Datei anbieten, mit in unser System aufzunehmen. Den Dateityp, welchen wir über die Dublin Core „type“ Eigenschaft abbilden, sowie das Datum der letzten Änderung, welches der Dublin Core Eigenschaft „Date“ entspricht, sind dabei trivial offensichtlich. Die Repräsentation der Größe einer Datei auf dem Datenträger wird über die im Dublin Core Standard definierte Eigenschaft „format“ realisiert. Wird als Resource ein Verzeichnis hinzugefügt, so modellieren wir dieses ebenfalls über die Eigenschaft „type“. Verzeichnisse werden vom System des weiteren standardmässig über Relationen mit den in ihnen Dateien und Verzeichnissen verbunden, so diese denn im System erfasst sind: Die vom Nutzer über Verzeichnishierarchien definierte Ordnung bleibt so auch im neuen, flexibleren System erhalten und zugreifbar. Auch Webseiten bzw. deren Inhalte lassen sich so einfach in das System integrieren: Sie werden betrachtet wie eine Datei, deren Ort eine URL ist, das heisst eine Netzwerkaddesse inklusive des Protokolls, welches zum Zugriff auf diese Netzwerkaddresse notwendig ist. Ähnlich

1 im Sinne des Begriffes „Refinement“, wie Dublin Core ihn definiert 4.2 Entwurf der Datenstrukturen 55 wie bei Verzeichnissen wird die spezielle Eigenschaft eine Online-Ressource zu sein, über die Dublin Core Eigenschaft „type“ realisiert. Ressourcen haben so eine einheitliche Struktur losgelöst von ihrer physikalischen Erscheinung, so können alle Arten von Ressourcen einfach innerhalb eines einfachen Konstrukts aus relationalen Datenbanktabellen verwaltet werden: Für den ORM sind alle Ressourcen völlig gleich, da sie auf denselben Datenstrukturen basieren.

4.2.5 Die Klasse Entity und ihre Unterklassen

Als Entities betrachten wir in diesem Kontext die Objekte, zu denen wir Ressourcen in Bezug setzen wollen. Diese Objekte sind sowohl physisch als auch Abstrakta: Personen und Gegenstände, genauso wie Datumsangaben und Orte, Schlagworte, abstrakte Konzepte und so genannte Projekte. Entities modellieren die „reale Welt“ des Nutzers in den Ausschnitten, die für ihn und seine Ressourcen relevant sind. Dabei können Entities nicht nur zu Ressourcen, sondern auch zueinander in Beziehung gesetzt werden: Der Geburtstag einer Person ist ein Datum, genau wie der Wohnort üblicherweise durch eine Addresse beschrieben wird. Im Gegensatz zu Ressourcen ist die Struktur von Entities keineswegs ähnlich: Bei Personen betrachtet man andere Eigenschaften als bei Orten oder Daten. Deshalb sollen im Folgenden die Eigenschaften der unterschiedlichen Typen von Entities genauer beschrieben werden.

4.2.5.1 Tag

Tags sind, wie in 2.3.2 beschrieben, Schlagworte, die man wie Etikettenschilder an Objekte „hängt“, ohne Wesensaussage über das „getaggte“. Ein Tag hat deshalb auch nur genau eine Eigenschaft: Seinen Namen. Der Name eines Tags ist seine Bedeutung, sein Inhalt.

Tabelle 4.4: Beschreibung der Eingenschaften von Instanzen der Klasse Tag

Eigenschaft Bedeutung name Der Name des Tags, welcher ihn identifiziert. Dabei werden, um Verwirrungen zu vermeiden, Tagnamen grundsätzlich in Kleinbuchstaben umgewandelt.

4.2.5.2 Date

Ein Date repräsentiert eine Zeitangabe. Zeitangaben können sehr simpel modelliert werden: Die Python Standard Library beispielsweise modelliert ein datetime Objekt als ein Konstrukt aus Jahr, Monat, Tag, Stunde, Minute, Sekunde, Microsekunde und der Information über die Zugrundeliegende Zeitzohne [Pyt]. Auf diese Art und Weise kann ein spezifischer Zeitpunkt genau festgehalten werden.

Um jedoch auch „unscharfe“ Daten zuzulassen wird die Spezifikation an dieser Stelle „unscharfe“ Daten 56 4 Entwurf erweitert. Als „unscharfes Datum“ bezeichnen wir eine Angabe wie „im 17. Jahrhundert“ oder „um den 16. September“, Datenstrukturen, die im Anwendungsbereich unserer Software relevant sein können: Als Lebenszeitraum einer Person, als Beschreibung eines Familienfestes, welches zwar an genau einem Datum stattfand, zu dem aber ein Familienteil schon einen Tag zuvor ankam. Die Liste der Beispiele ist lang und somit erlauben wir für Daten als weitere Eigenschaften ihre „Unschärfe“, sowohl in die Zukunft als auch in die Vergangenheit. Um diese „unscharfen“ Daten auch geeignet anzeigen zu können, kommt als weiteres Feld noch ein Freitextfeld hinzu, in dem der Nutzer eine Formulierung hinterlegen kann, die den „unscharfen Zeitpunkt“ beschreibt. Das System gibt allerdings an dieser Stelle auch einen Sinnvollen Standard vor, wenn der Nutzer keine Angabe macht. Zusammenfassend sieht ein Datum also folgendermassen aus1:

Tabelle 4.5: Beschreibung der Eingenschaften von Instanzen der Klasse Date

Eigenschaft Bedeutung year Das Jahr, in dem der Zeitpunkt gemäss des gregoriani- schen Kalenders liegt month Der Monat des spezifizierten Jahres, in dem der Zeit- punkt liegt day Der Tag des spezifizierten Monats hour Die Stunde des angegebenen Tages in 24 Stunden Schreibweise minute Die Minutenangabe second Die Sekundenangabe timezone Die Zeitzone, auf die sich die vorherigen Angaben be- ziehen timedelta_past Eine Angabe, wie weit sich der Zeitpunkt „unscharf“ in die Vergangenheit ausdehnt timedelta_future Eine Angabe, wie weit sich der Zeitpunkt „unscharf“ in die Zukunft ausdehnt textual_representation Eine Schreibweise, die den Zeitpunkt, und gegebenen- falls seine Unschärfe, angemessen wiedergibt.

4.2.5.3 Place

Die Entity Place repräsentiert einen Ort. Ähnlich wie bei Datumsangaben, kann man Orte auf der Erde (und von denen gehen wir an dieser Stelle aus), über Geokoordinaten genau referenzieren: Eine Längen- und eine Breitenangabe definieren einen Punkt auf der Erde genau. Diese Art, Orte zu spezifizieren stellen wir dem Nutzer selbstverständlich zur Verfügung, doch betrachten Menschen Orte, ähnlich die Zeitpunkte, oft ungenauer: Menschen sehen „London“ als einen Ort, auch wenn die Stadt in Großbritannien sich auf 1.579 km2 ausbreitet.

1 Microsekunde wird an dieser Stelle nicht mehr betrachtet, die Angabe von Microsekunden scheint für den Anwendungsfall zu speziell 4.2 Entwurf der Datenstrukturen 57

Auch liegen Orte oft ineinander: Der Ort „Alexanderplatz“ befindet sich innerhalb des verschachtelte Bereiches, den der als „Berlin“ bezeichnete Ort einnimmt. Hier zeigt sich auch, dass Orte Orte einen Namen haben, der sie bezeichnet1. Um einen Ort menschenlesbar eingrenzen zu können, kann der Nutzer noch eine textuelle Beschreibung zum Ort verfassen, zum Beispiel um zu beschreiben, welches „Paris“ gemeint sein soll. Um auch Orten gerecht zu werden, die sich nicht auf der Erde befinden, bei denen also die übliche Verortung über Stadt und Land oder über Geokoordinaten scheitert, existiert ein Feld namens description _location, in dem der Nutzer eine freitextliche Beschreibung der Lage speichern kann: So ist dann auch der Ort der Mondlandung im System zu verwalten.

Tabelle 4.6: Beschreibung der Eingenschaften von Instanzen der Klasse Place

Eigenschaft Bedeutung name der Name des Ortes length die geographische Länge width die geographische Breite street die Strasse, in der sich der Ort befindet inclusive der Hausnummer zip die Postleitzahl des Ortes city die Stadt, in der sich der Ort befindet country das Land, in dem sich der Ort befindet description eine freitextliche Beschreibung des Ortes description_location eine freitextliche Beschreibung der Lage des Ortes

4.2.5.4 Person

Personen haben zu Ressourcen eine ganz besondere Beziehung, nicht nur als Nutzer unseres Personen und Systems, sondern auch beispielsweise als Erzeuger von Ressourcen. Personen werden des Ressourcen weiteren schon heute in diversen Anwendungsprogrammen verwaltet: Als Kontakte in Instant Messagern oder im EMail-Programm oder als so genannte „Buddies“ in sozialen Netzwerken. Von Standardisierungsgremien festgelegte Standards sind in diesen Bereichen sind zwar kaum vorhanden, doch hat sich in der Anwendung eine gewisser Standard an unterstützten Eigenschaften, um Personen zu beschreiben, herausgebildet, der von den meisten verbreiteten Programmen unterstützt wird, im speziellen wurde hier die Datenstruktur der Software Evolution des GNOME Projektes2 als Grundlage verwendet, da sie über viele Jahre ihre Eignung, sowohl im Kontext von Privatanwendern als auch im professionellen Umfeld, bewiesen hat3. Die Eigenschaften werden in Tabelle 4.7 im Detail aufgelistet. Neben den in Tabelle 4.7 aufgelisteten Attributen kann eine Person des weiteren noch zu URLs zu Webseiten über sie verknüpft sein, welche dann als Relationen zu Resourcen abgebildet werden: Wenn einer Person eine persönliche Homepage zugewiesen wird, dann

1 „identifizieren“ wäre zu viel gesagt, wie die vielen Orte mit dem Namen Paris zeigen 2 http://www.gnome.org/projects/evolution/ 3 Microsofts™Outlook, welches sehr verbreitet ist, baut auf einer sehr ähnlichen Struktur auf 58 4 Entwurf

Abbildung 4.4: Die Datenstruktur zur Modellierung von Personen

erzeugt das automatisch eine Resource, welche dann zur Person assoziiert wird. Ähnlich werden Geburtstage und andere Jubiläen oder Jahrestage über Relationen zu Datumsobjekten abgebildet.

4.2.5.5 Artifact

Ein Artifact stellt einen beliebigen physischen Gegenstand der realen Welt dar: Ein Musikin- strument, ein Kunstwerk, eine Kaffeetasse und ähnliches. Die Aufnahme dieser Gegenstände erlaubt es, beispielsweise die auf einem Bild abgebildeten Gegenstände geordnet zu erfassen oder Gegenstände als Subject einer Resource ausgewählt werden. Artefakte besitzen die in Tabelle 4.8 beschriebenen Eigenschaften.

4.2.5.6 Concept

Im Gegensatz zu Artifact repräsentiert ein Concept einen nicht-physischen oder mentalen Gegenstand der Welt. Concepts können beispielsweise abstrakte Begriffe wie „die Freundschaft“ oder „die Liebe“ sein, genauso wie beispielsweise Wissenschaften („die Mathematik“) oder beliebige andere nicht-physische Gegenstände, die den Nutzer interessieren. Eine detaillierte Liste der Eigenschaften einer Instanz der Klasse Concept findet sich in Tabelle 4.9.

Artifact Die Unterscheidung von Artifact und Concept ist dabei keineswegs immer objektiv: Wo ein vs. Concept Nutzer Einhörner als Artifact modellieren würde, legt ein anderer Nutzer den Fokus auf die Nichtexistenz und modelliert sie deshalb als Concept; beide Modellierungen sind „richtig“, die Sichtweise des Nutzers ist an dieser Stelle das einzige Relevanzkriterium. 4.2 Entwurf der Datenstrukturen 59

Tabelle 4.7: Beschreibung der Eingenschaften von Instanzen der Klasse Person

Eigenschaft Bedeutung name der volle Name der Person nickname der Spitz- oder Rufname der Person emails eine Liste aller Emailadressen der Person, dabei besteht eine Emailadresse aus der Adresse selbst und einem Attribut, welches sie als „privat“,„beruflich“ oder „sons- tige“ markiert phones eine Liste aller Telefonnummern, unter denen die Per- son erreichbar ist. Eine Telefonnummer besteht aus der Nummer selbst sowie einem Attribut, welches die Telefonnummer als „privat“,„beruflich“,„Mobiltelefon- nummer“ oder „sonstiges“ markiert. addresses die Adressen, an denen eine Person erreichbar ist. Da- bei trennen sich Adressen auf in „beruflich“,„privat“ und „sonstige“ und verknüpfen einen Place, der die Adressbestandteile wie Strasse und Postleitzahl lie- fert. Des weiteren erlauben sie noch das hinzufügen eines weiteren Adressbestandteils address_addition in dem Adresszusätze wie „zu Händen“ oder „Abtei- lung“ aufgelistet werden können, die nicht zum Ort selbst sondern zur Person an diesem Ort gehören im eine Liste aller Instant Messaging Adressen, unter de- nen die Person erreichbar ist. Eine solcher Kontakt besteht aus der eindeutigen Kennung des Nutzers so- wie einem Feld, welches den Typ des Instant Messaging Netzes beschreibt.

4.2.5.7 Project

Ein Project modelliert für den Nutzer eine Aufgabe, ein Vorhaben, ein Projekt. Das kann das schreiben einer Arbeit sein, die Mitarbeit an einem verteilten Softwareprojekt oder beispielsweise die Planung einer goldenen Hochzeit. Das Projekt selbst ist in dieser Hinsicht eine recht simple Datenstruktur, die nur Namen und eine Beschreibung bereitstellt, wie im Detail in Tabelle 4.10 beschrieben wird. Interessant wird die Modellierung von Projekten vor allem über die Möglichkeit, Ressourcen und Personen zum Projekt zu assoziieren, Arbeitsprozesse so abzubilden und eine taskorien- tierte Sicht auf die persönlichen Ressourcen einer Person anzubieten. Man könnte eine solche Zuordnung zwar mit Abstrichen über Tags nachbilden, verliert dabei aber alle semantische Klarheit. 60 4 Entwurf

Tabelle 4.8: Beschreibung der Eingenschaften von Instanzen der Klasse Artifact

Eigenschaft Bedeutung name der Name des Gegenstandes description eine freitextliche Beschreibung des Gegenstandes

Tabelle 4.9: Beschreibung der Eingenschaften von Instanzen der Klasse Concept

Eigenschaft Bedeutung name der Name des Konzeptes description eine freitextliche Beschreibung des Konzeptes

Tabelle 4.10: Beschreibung der Eingenschaften von Instanzen der Klasse Project

Eigenschaft Bedeutung name der Name des Projektes description eine freitextliche Beschreibung des Projektes

4.2.6 Das Modul Relation

Relationen sind, was es dem Nutzer erlaubt, Objekte des Systems, ob Resources oder Entities, miteinander zu verbinden, Beziehungen zu formulieren und damit mehrere Objekte zueinander zu gruppieren. Dabei sind Relationen sehr frei in der Art von Typen, die sie verbinden: Es können Ressourcen mit Ressourcen, Entities mit Entities und auch Entities mit Ressourcen verbunden werden. Im Gegensatz zu RDF-basierten Lösungen1 sind Relationen and dieser Stelle auch keineswegs immer auf die Verbindung nur zweier irgendwie gearteter Objekte festgelegt: Es sind auch Relationen denkbar, die beispielsweise eine Person, einen Ort und eine Ressource verbinden2. Zur Spezifikation der Struktur einer Relation werden die Eigenschaften in so genannten EndpointDefinitions festgehalten. Der Nutzer soll dynamisch neue Relationen definieren können, somit muss die Struktur hochgradig flexibel sein: Es ist nicht vorherzusehen, welche Arten von Relationen Nutzer zu formulieren versuchen. Eine Relation teilt sich, wie in Abbildung 4.5 dargestellt, in Instanzen von 4 Klassen auf, welche alle von der Klasse Object erben, also auch UUIDs besitzen und eindeutig zuzuordnen sind. Die Klasse RelationDefinition enthält Namen und Beschreibung der Relation. Instanzen von RelationDefinition stellen also die dem System bekannten Relationen dar. Die genaue

1 vgl. 3.3 2 zum Beispiel im Sinne von „Person hat Ressource an Ort verfasst“ 4.2 Entwurf der Datenstrukturen 61

Abbildung 4.5: Die Datenstruktur zur Formulierung von Relationen

Struktur einer Relation wird über die Definition ihrer Endpunkte über Instanzen der Klasse EndpointDefinition realisiert: Eine EndpointDefinition gehört zu genau einer RelationDefinition. Jede EndpointDefinition hat hierbei einen Namen, um den Endpunkt klarer zu definieren, ein Attribut, welches die möglichen Objekttypen eingrenzt, sowie Minimal- und Maximalwerte für die Anzahl der in diesem Endpunkt verbundenen Objekte. Ein Beispiel soll diese Struktur verdeutlichen: Gegeben sei die Relation „Person verfasst Resource an Ort“. Diese Relation besitzt 3 EndpointDefinitions: „Schreiber“, „Werk“ und „Ort“. „Schreiber“ akzeptiert als Typen nur Instanzen der Klasse Person, „Werk“ Instanzen der Klasse Resource und „Ort“ nur Instanzen der Klasse Place. An einem Werk arbeiten, gerade wenn es beispielsweise ein technischer Standard ist, oft mehrere Personen, also gilt für „Schreiber“, dass die Mindestanzahl 1 und die Maximalanzahl unbeschränkt ist: Es muss mindestens einen Schreiber geben, es können aber theoretisch unendlich viele sein. „Werk“ und „Ort“ hingegen sind beide genau eins, also mindestens eins und maximal eins. Aus diese Art und Weise können vom Nutzer sehr flexible Relationen konstruiert werden, die sogar Instanzen derselben Klasse innerhalb einer Relation unterschiedliche semantische Rollen zuweisen können. Über die Schlüsselbegriffe, die den EndpointDefinitions zugewiesen sind, kann der die RelationDefinition beschreibende Name mit den Informationen aus den EndpointDefinitions angereichert werden: Aus „%(person) verfasst %(resource)“ wird dann in der Anwendung automatisch ein Satz wie „Ludwig Wittgenstein verfasst Tractatus Logico-Philosophicus“. RelationDefinition und EndpointDefinition bilden somit zusammen die Definition der Struk- tur einer Relation. Um mehrere Objekte in eine Relation zu setzen, wird die angemessene RelationDefinition ausgewählt und eine Referent darauf in einer Instanz der Klasse Relation gespeichert: Relation realisiert damit die Repräsentation der Anwendung einer abstrakt definierten Relation auf Objekte des Systems. 62 4 Entwurf

Endpunkte Die Relation Instanz aggregiert nun EndpointLink Instanzen. Ein EndpointLink bildet die Verbindung genau eines Objektes mit genau einer EndpointDefinition ab: Eine Relation kann also durchaus mehrere zugeordnete EndpointLinks besitzen, die dieselbe EndpointDefinition referenzieren. EndpointLinks haben des weiteren die Eigenschaft, „fuzzy“1 zu sein: Ein Objekt kann zu einer EndpointDefinition zu einem bestimmten Prozentsatz gehören. Betrachten wir hierzu das in 3.3 zitierte Beispiel von David Weinberger: Wenn über die Stadt London gesprochen wird, dann meint diese mit gewisser Wahrscheinlichkeit die Hauptstadt Großbritanniens. Diese Form der „unscharfen“ Zuweisung soll in unserem System unterstützt werden. Auch für sehr einfache Relationen wie „ist Mitwirkender an“ kann diese Unschärfe hilfreich sein: Sie erlaubt es, auch kleinste Mitwirkung zu modellieren, ohne dabei alle Mitwirkenden auf eine Stufe zu stellen. Zusammenfassend werden Relationen also in den folgenden 4 Datenstrukturen modelliert: RelationDefinition:

Tabelle 4.11: Beschreibung der Eingenschaften von Instanzen der Klasse RelationDefinition

Eigenschaft Bedeutung name der Name des Relationsdefinition description eine freitextliche Beschreibung der Relationsdefinition

EndpointDefinition:

Tabelle 4.12: Beschreibung der Eingenschaften von Instanzen der Klasse EndpointDefinition

Eigenschaft Bedeutung name der Name des Endpunktes type die für diesen Endpunkt erlaubten Typen von Objekten key ein - innerhalb aller EndpointDefinitions einer Rela- tionDefinition - eindeutiger Bezeichner. Über diesen Bezeichner kann die Anzeige einer Relation sinnvoller gestaltet werden: Die keys können als Platzhalter in der Bezeichnung der RelationDefinition verwendet werden. min_quantity die Mindestanzahl von Objekten, die dieser Endpunkt veraussetzt max_quantity die Maximalzahl von Objekten, die dieser Endpunkt zulässt

Relation:

1 wie in „fuzzy logic“ 4.2 Entwurf der Datenstrukturen 63

Tabelle 4.13: Beschreibung der Eingenschaften von Instanzen der Klasse Relation

Eigenschaft Bedeutung definition Ein Verweis auf die zugehörige Relationsdefinition

EndpointLink:

Tabelle 4.14: Beschreibung der Eingenschaften von Instanzen der Klasse EndpointLink

Eigenschaft Bedeutung definition Ein Verweis auf die zugehörige EndpointDefinition linked_object Ein Verweis auf das Verknüpfte Objekt percentage Der Prozentsatz mit dem das Objekt dem Endpunkt zukommt

4.2.7 Das relationale Datenmodell

Das Datenbankschema der relationalen Datenbank ist im Entity-Relationship-Diagramm 4.6 in seiner Gesamtheit abgebildet.

Das Schema basiert dabei auf dem Konzept der „Joined Table Inheritance“ wie sie Michael Joined Table Bayer in [Bay08] beschreibt. „Joined Table Inheritance“ ist ein Vorgehensmodell, welches es Inheritance erlaubt, die Vererbungshierarchien von durch einen ORM auf relationale Datenbanktabellen gemappten Klassen strukturiert abzubilden. Für Joined Table Inheritance referenziert die die Tabelle, welche eine Klasse repräsentiert, die Tabelle, welche die Oberklasse repräsentiert über einen Foreign Key. Um eine Instanz der Unterklasse aus der Datenbank zu rekonstruieren, verbindet der ORM die Tabelle, welche die Unterklasse repräsentiert, und die Tabelle, welche die Oberklasse repräsentiert, durch einen JOIN. Die Attribute, welche die Unterklasse aus der Oberklasse erbt, werden folglich in der der Oberklasse zugewiesenen Tabelle gespeichert. Dieses Vorgehen bedingt eine recht hohe Anzahl von verhältnismäßig aufwendigen JOIN Operationen, bringt mit sich allerdings den Vorteil, das Datenbankschema deutlich simpler und klarer gestaltbar zu machen. Des weiteren wird die Duplikation von Feldern vermieden: In unserem Entwurf besitzt jedes Objekt eine UUID; anstatt nun jeder Tabelle eine Spalte uuid hinzuzufügen, findet sich dieses Attribut nur in genau der Tabelle objects. So ist die Identität eines Objektes auf einfache Weise nur durch die Informationen in der Datenbank bestimmbar: Zwei Objekte sind identisch, wenn sie dieselbe UUID in der Tabelle objects aufweisen: Komplexe Suchvorgänge in mehreren Tabellen können so vermieden werden. Auf eine tabellarische Auflistung der Tabellen und ihrer Spalten soll an dieser Stelle verzichtet werden, es soll an dieser Stelle auf den Abschnitt 4.2 verwiesen werden, in dem die Attribute 64 4 Entwurf

Abbildung 4.6: Das Datenbankschema als ER-Diagramm der Klassen des Modells beschrieben sind. Details über das Datenbankschema lassen sich des weiteren aus der Abbildung 4.6 ablesen. 4.3 Entwurf der Client-API 65

4.3 Entwurf der Client-API

Die Client-API findet sich in sehr ähnlicher Form an zwei Stellen des Systems: Einmal innerhalb des Servers selbst und ein weiteres mal in ihrer Übersetzung in der D-BUS-API. Dabei sind die Bedeutungen der Funktionen selbstverständlich weitestgehend identisch: Der Aufruf einer Funktion in der D-BUS-API führt, nach dem Übersetzen der Eingabedaten in die Systeminternen Datenstrukturen, zu einem Aufruf der internen API Funktion gleichen Namens. Deren Ergebnis wird dann wiederum in eine über den D-BUS transferierbare Form übersetzt und versendet. Im folgenden werden nicht nur die Funktionen der API vorgestellt, sondern auch die grundsätzlichen Überlegungen auf denen das Design der API basiert dargelegt.

4.3.1 Datenintegrität

Der wichtigste Grundsatz beim Design der API ist ihre Atomarität: Es gibt keinerlei Funk- atomar tionen, die Ergebnisse zurückliefern oder einen Status erzeugen, auf die der Nutzer der API in irgendeiner Form weiter reagiern muss. Der Zugriff auf die API kann den Zugriff des Ge- samtsystems verändern, aber niemals einen ungültigen Zustand erzeugen: Nicht vollständige Einträge beispielsweise unterbindet die API grundsätzlich.

Die API ist des weiteren, ähnlich wie das im World Wide Web verwendete HTTP, zustandslos: zustandlos Eine Anwendung muss sich nicht an der API anmelden oder innderhalb des Servers ihren Zustand hinterlegen, da keine Anfrage Vorbedingungen stellt und jede Anfrage ein vollständiges Ergebnis liefert. Diese Herangehensweise erleichtert nicht nur das Entwerfen und Implementieren von An- wendungen, die die API nutzen, sondern erlaubt es, auf einfache Art und Weise, ein hohes Mass an Datenintegrietät sicherstellen zu können.

4.3.2 Die API Funktionen

Der Zugriff auf die Daten des Systems, das Hinzufügen und das Löschen von Objekten wird Funktionen über eine API abstrahiert, die von der Modelschicht bereitgestellt wird. Die API selbst ist in der API Funktionen und nicht objekt-orientiert realisiert, einerseits, weil die zu implementierende D- BUS Schnittstelle (wie in 4.3.3.1 weiter erläutert) keine Klasseninstanzen unterstützt, sondern nur eine eingeschränkte Menge von Datentypen übertragen kann, und um den Zugriff nicht nur auf objekt-orientierte Sprachen bzw. das objekt-orientierte Programmierparadigma zu beschränken. Für die Clientseite wird allerdings, basierend auf der auf Funktionen aufsetzenden Abstraktion, eine objekt-orientierte Bibliothek mitgeliefert, die aus Python heraus, objekt- orientierten Zugriff auf viele Datenstrukturen bietet. Die API spaltet sich auf in 3 Gruppen von Funktionen: Tabelle 4.15 stellt die Basisfunktionen zusammen, die den Zugriff auf die Daten ermöglichen, Tabelle 4.16 fasst die Metafunktionen zusammen, die Metadaten über den laufenden Server (wie zum Beispiel die Versionsnummer der API) liefern und die Tabelle 4.17 aggregiert die Shortcuts, Funktionen, die auf etwas höherem Abstraktionsgrad häufig benutzte Funktionalität einfacher bereitstellen, als das die 66 4 Entwurf

Basisfunktionen zu leisten im Stande sind. Die Shortcuts fügen allerdings keine Funktionalität hinzu, die nicht auch einfach über Basisfunktionen umzusetzen wäre. Die Notation der Funktionen orientiert sich an den Python Standards, weswegen keine Typen in der Funktionsdeklaration spezifiziert werden. Die Formulierung func(arg1,arg2=1,arg3=None) bezeichnet dabei eine Funktion namens func mit mit dem notwendigen Argument arg1 und den zwei optionalen Argumenten arg2 und arg3 wobei arg2 den Wert 1 annimmt, so der Parameter nicht spezifiziert wurde, und arg3 standardmässig den Wert None1 annimmt.

Funktion Beschreibung get_object(uuid) Liesst das Objekt mit der gegebenen uuid aus und liefert es zurück. get_all_objects(limit=None) Liesst alle Objekte aus und liefert sie zurück. Der optionale Parameter limit erlaubt es, die Anzahl der zurückgelieferten Objekte zu beschränken, vergleichbar zu dem LIMIT Statement aus SQL. get_all_tags(limit=None) Liefert eine Liste aller Tags aus dem System zu- rück. Der optionale Parameter limit erlaubt es, die Anzahl der zurückgelieferten Objekte zu be- schränken, vergleichbar zu dem LIMIT Statement aus SQL. get_tags_for(uuid) Liefert alle Tags zurück, mit denen das Objekt mit der gegebenen uuid getaggt wurde. get_comments_for(uuid) Liefert alle Kommentare für das Objekt mit der gegebenen uuid zurück. delete_object(uuid,cascade=False) Löscht das Objekt mit der gegebenen uuid. Wenn der Optionale Parameter cascade gesetzt ist, werden auch Objekte, die dieses Objekt direkt verknüpfen mitgelöscht, so könnte beim Löschen einer Person jeder Ort, der ihr als Wohnort zu- geweisen ist, mitgelöscht werden. add_object(type,attributes) Fügt ein neues Objekt hinzu. Der Pa- rameter type gibt dabei den Typ des Objektes an, der Parameter attributes enthält ein Dictionary mit den Attribu- ten des Objektes. add_object(’project’, {’name’:’Testprojekt’, ’description’:’Testprojekt’ }) würde beispielsweise ein neues Projekt mit dem Namen ’Testprojekt’ erzeugen.

1 None ist in Python die Bezeichnung für den Nullwert 4.3 Entwurf der Client-API 67

save_object(uuid,attributes) Speichert die im Dictionary attributes gege- benen Werte in das Objekt mit der gegebenen uuid. query(querystring, limit=None) Liefert die Objekte, die der gegebenen Anfra- ge query entsprechen, zurück. query ist dabei formuliert in der in 4.4 definierten Abfragespra- che. Der optionale Parameter limit erlaubt es, die Anzahl der zurückgelieferten Objekte zu be- schränken, vergleichbar zu dem LIMIT Statement aus SQL.

Tabelle 4.15: Beschreibung der Basisfunktionen der Client-API

Die Basisfunktionen stellen innerhalb der API generische Funktionen zum Hinzufügen, Basis- Editieren und Löschen von Objekten im System zur Verfügung. Objekte können einzeln funktionen oder in Listen aus dem System ausgelesen werden, ihre Attribute verändert und Objekte gelöscht werden, die Daten innerhalb des Systems können vollständig über die Basisfunktionen verwaltet werden.

Funktion Beschreibung get_api_version() Liefert die Version der API, also der Schnittstelle zurück. Dies erlaubt es Anwendungen, die die Schnittstelle nutzen, von späteren Erweiterungen oder Verbesserungen der Schnittstelle zu profi- tieren ohne dabei auf jedem System die neueste Wittgenstein Version vorauszusetzen: Anstatt ei- ner neuen, besseren Funktion kann der Client im Falle einer älteren Wittgenstein Version im- mer auf andere, vielleicht weniger elegante oder performante Funktionen zurückgreifen. get_db_version() Liefert die Version der Datenbank zurück. Hier- mit ist an dieser Stelle nicht die Programmver- sion der verwendeten Datenbankengine gemeint, sondern die Version des Datenbankschemas. Spä- tere Wittgensteinversionen können so neue Da- tenfelder hinzufügen, die Clients unterstützen können ohne ältere Clients automatisch auszu- sperren.

Tabelle 4.16: Beschreibung der Metafunktionen der Client-API 68 4 Entwurf

Meta- Die Aufgabe der Metafunktionen ist es vor allem, Clients die Möglichkeit zu geben, mehr funktionen Informationen über den laufenden Wittgenstein Dienst abzurufen, wie die Version des Da- tenbanklayouts oder die unterstützte API Version. Auf diese Art und Weise ist nicht nur eine Erweiterbarkeit von Datenstruktur und API gegeben sondern vor allem auch die Mög- lichkeit für Clients, neue, erweiterte oder verbesserte Funktionalität zu nutzen ohne dabei grundsätzlich inkompatibel zu älteren Versionen von Wittgenstein zu werden.

Funktion Beschreibung add_comment(to, text, Fügt dem System einen neuen Kommentar hinzu, author=Systemuser) der sich auf das durch to spezifizeirte Objekt bezieht und text als Inhalt hat. Wenn der Wert für author nicht übergeben wird, wird der Name des Nutzers im System verwendet. add_tag(name) Fügt einen neuen Tag mit dem gegebenen Namen hinzu. add_date(year=None, month=None, Fügt eine neue Datumsentität hinzu. Hierbei sind day=None, hour=None, alle Parameter optional, sollte allerdings kein minute=None, second=None, Parameter gesetzt sein, schlägt das Hinzufügen textual_representation=None, wegen mangelnder Daten fehl. tz=None,timedelta_past=None, timedelta_future=None) add_place(name, length=None, Fügt einen neuen Ort hinzu, wobei alle Para- width=None, street=None, meter bis auf name, der den Namen des Ortes zip=None, city=None, spezifiziert, optional. country=None, description=None, description_location=None) add_person(name, nickname=None, Fügt dem System eine neue Person hinzu, wobei addresses=None, phones=None, ein name übergeben werden muss. addresses, ims=None) phones und ims sind hierbei Listen von Dictio- naries. add_artifact(name, Fügt ein neues Artifact hinzu mit dem gegebe- description=None) nen Namen und der optionalen Beschreibung description add_concept(name, Fügt ein neues Concept hinzu mit dem gegebe- description=None) nen Namen und der optionalen Beschreibung description add_project(name, Fügt ein neues Project hinzu mit dem gegebe- description=None) nen Namen und der optionalen Beschreibung description define_relation(name, Definiert eine neue Relation mit dem gegebe- description=None, endpoints=None) nen Namen und der optionalen Beschreibung description. endpoints stellt in diesem Kon- text eine Liste aus Dictionaries dar, die jeweils einen Endpoint beschreiben. tag_object(object, tagname=None, Weist dem gegebenen object den über tagname taguuid=None) oder taguuid spezifizierten Tag zu. 4.3 Entwurf der Client-API 69

get_tag_count(tagname=None, Liefert zurück, wie oft der spezifizierte Tag ver- taguuid=None) wendet wurde. get_tags_by_occurrence(limit=None, Liefert eine Liste aus Tags zurück. limit gibt order=’desc’) hierbei die Anzahl der gewünschten Tags an und order, ob die Liste auf- oder absteigend nach der Häufigkeit der Verwendung der Tags sortiert sein soll. Jedes Element der Liste ist dabei ein Tupel aus dem Tag und der Anzahl seiner Verwenung. set_rating(uuid,rating) Setzt das rating für das gegebene Objekt auf den gegebenen Wert.

Tabelle 4.17: Beschreibung der Shortcuts der CLient-API

Die Aufgabe der „Shortcuts“ ist es vor allem, simplere Schnittstellen für häufig verwendete Shortcuts Funktionalitäten bereitzustellen sowie einige Funktionalitäten, die über die Basisfunktionen sehr umständlich realisierbar sind, zu vereinfachen. Die function get_tags_by_occurrence() ist hierfür ein gutes Beispiel, da, um sie nachzubauen, eine große Anzahl von Einzalanfragen an die API gerichtet werden müsste, die durch diesen Shortcut vermieden werden können. Die Liste der Shortcuts ist der Bereich der API, in dem die meisten Erweiterungen zu erwarten sind, Erweiterungen, die durch spezielle Bedürfnisse einzelner Clients erst in ihrer Notwendigkeit deutlich werden.

4.3.3 Die D-BUS-Abstraktion

Die D-BUS Schnittstelle sieht nahezu identisch aus zu der in 4.3.2 dargelegten API, die die Datenhaltungsschicht bereit stellt. Neben einer Übersetzung der API auf die von D-BUS unterstützen Typen1 stellt die D-BUS Schnittstelle aber noch einige weitere Funktionen zur Verfügung, die nichts mit der Datenhaltung sebst zu tun haben. Diese Funktionen, wie in Tabelle 4.18 aufgelistet, bilden vor allem Funktionalität ab, die Clients verwenden können, um zu testen, ob der Wittgenstein Dienst reagiert und läuft, bzw. um Fehlermeldungen aus externen Prozessen2 an den Server zurückliefern zu können.

4.3.3.1 Serialisierung

D-BUS setzt auf einer wohldefinierten Menge von Typen3[Hav] auf, die über den Bus transferiert werden können: Boolsche Wahrheitswerte, Ganz- und Kommazahlen, Unicode- Zeichenketten, Arrays und Dictionaries4.

1 vergleiche hierzu 4.3.3.1 2 vergleiche hierzu 4.5 3 http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures 4 Ein Python Dictionary entspricht einer HashMap in vielen anderen Programmiersprachen, bzw. einem assoziativen Array in PHP 70 4 Entwurf

Tabelle 4.18: Beschreibung der zusätzlichen Funktionen der D-BUS-API

Funktion Beschreibung report_scan_result(uuid, status, Bietet dem Metadatenscanner die Möglichkeit, message=None) das Ergebnis einer Datenextraktion an das Witt- gensteinsystem zurückzumelden. uuid gibt da- bei die uuid des gescannte Objekt an, status ist ’OK’ wenn es keine Fehler gab (alles andere wird als Fehler interpretiert) und der optionale Parameter message enthält gegebenenfalls die Fehlermeldung, die der Scanner an das System liefert. ping() Gibt beim Aufruf den String ’pong’ zurück und kann so verwendet werden, um den Server auf seine Anwesenheit zu testen.

Klasseninstanzen können nicht über den Bus kommuniziert werden, es ist also eine Seria- lisierung notwendig: Die Instanzen auf der Serverseite müssen vor dem Versenden in eine Repräsentation aus D-BUS Typen ersetzt werden. Ein Rückgriff auf eine sprach- oder platt- formspezifische Serialisierung, wie beispielsweise Python’s pickling, ist an dieser Stelle zu vermeiden: Die API würde aufgrund dieses Designs zu eng an die Implementierungssprache gekettet und die Nutzung aus anderen Programmiersprachen aufwendiger.

Serialisierung Es wurde sich also für eine abstraktere Serialisierung der Datenstrukturen entschieden: in Dictionaries Ein Objekt wird in ein Dictionary überführt. Die Attributnamen der Attribute des Objektes werden als Schlüssel für das Dictionary verwendet, die den Zugriff auf die jeweiligen Attribute bereitstellen. Referenzen auf weitere Objekte werden abgebildet, indem die UUID des referen- zierten Objektes anstelle des verknüpften Objektes zurückgeliefert wird: So kann der Client selbst entscheiden, welche Objekte mit ihrem vollständigen Datenumfang abgerufen werden müssen, was die Performance des Gesamtsystems erhöht, da sonst bei großen Mengen von Objekten mit vielen Verknüpfungen große Mengen überflüssiger Daten übertragen werden würden. Der Typ des zurückgegebenen Datensatzes, seine Klasse, findet sich im Attribut discriminator wieder. Bei Objekten, die beliebig lange Listen aus Attributen besitzen, wie beispielsweise die EMailadressen einer Person, werden diese Listen vollständig serialisiert, so dass zu einer Person das Attribut addresses auch als Liste aus Dictionaries zurückgegeben wird. Innerhalb dieser Listen werden Referenzen auf weitere Objekte allerdings wieder nur über ihre UUID abgebildet, eine genauere Auflösung muss der Client selbst vornehmen.

4.4 Definition einer Abfrage-Sprache

komplexe Die Anfragen, die ein Nutzer an das System stellen will, sind oft sehr komplex. Anstatt einfach Anfragen 4.4 Definition einer Abfrage-Sprache 71 nur ein spezielles Objekt aus dem Datenbestand anzufragen, ist der häufigere Fall der, dass eine ganz spezielle Menge von Objekten aus dem System abgefragt werden soll. Diese Arten von Abfragen werden in anderen Systemen wie beispielsweise den meisten bekannteren in Python implementierten ORMs, wie Django1 oder SQLAlchemy2, oft durch die Konstruktion von verschiedenen Objekten, bzw. durch das Verketten von verschiedenen Funktionsaufrufen3: Eine komplexe Anfrage in Django um beispielsweise alle Personen mit dem Namen Peter, braunen Augen und einem Alter von 25 Jahren abzufragen, würde folgendermaßen aussehen: Person.objects.filter(name=’Peter’).filter(age=25).filter(eyecolor=’brown’)

Da D-BUS allerdings eine solche Schnittstelle nicht direkt möglich macht und um eine Beschränkt durch plattform- und Sprachunabhängige Lösung anbieten zu können, wurde die Entscheidung D-BUS getroffen, eine einfach Sprache zum Abfragen von Daten zu entwickeln, die sich an bekannten Abfragesprachen orientiert.

Die heute verbreitetste Abfragesprache ist sicherlich die Structured Query Language SQL, SQL deshalb wurde die Wittgenstein Abfragesprache so entworfen, dass ihr Erlernen, ihr Verstehen und ihr Anwenden einem mit SQL vertrautem Nutzer möglichst leicht gemacht wird. Dabei ist anzumerken, dass die Abfragesprache, wie schon im Namen angedeutet, als Fokus ausschließlich das Auslesen von Informationen aus dem System hat; anders als SQL, welche auch zum Verändern der Informationen verwendet werden kann.

4.4.1 Allgemeine Syntax

4 Eine Abfrage in der Wittgenstein Abfragesprache WQL besitzt die folgende allgemeine Form: grundlegende Form TYPE1,...,TYPEn WITH attr1=Wert, ...attrn =Wert Eine Anfrage trennt sich also auf in 2 Segmente, die durch das Schlüsselwort WITH5 getrennt werden. Im Ersten Segment findet sich eine Auflistung der typen von Objekten, die angefragt werden. Hierbei sind alle definierten Klassennamen gültig zusätzlich zu einigen weiteren Schlüsselworten wie die Tabelle 4.19 zeigt. Bei mehreren angefragten Typen, werden die Typbezeichnungen per , getrennt.

Im zweiten Segment werden die Kriterien deklariert, denen die auszulesenden Objekte ent- Verknüpfungen und sprechen müssen. Hierbei ist es möglich, mehrere Kriterien logisch miteinander zu verknüpfen Modifikatoren durch die in Tabelle 4.20 beschriebenen Schlüsselworte.

Kriterien definieren sich über die Attribute der abzufragenden Objekte, man beschreibt die Anfrage- Menge der Objekte, die man abfragen möchte, also über Anforderungen an ihre Attribute. kriterien Wird eine Anforderung an ein Attribut formuliert, welches in der betreffenden Klasse nicht vorhanden ist, so wird das Kriterium als nicht erfüllt gewertet. Nur grundlegende syntaktische

1 http://djangoproject.org 2 http://sqlalchemy.org 3 dem so genannten „Daisy Chaining“ 4 „Wittgenstein Query Language“ 5 WITH muss nicht zwingen in Großbuchstaben geschrieben werden, es wird allerdings als guter Stil empfohlen um die Anfragen besser lesbar zu machen 72 4 Entwurf

Tabelle 4.19: gültige Schlüsselworte für die Typdeklaration einer Anfrage an Wittgenstein

Schlüsselwort Beschreibung Comment Objekte der Klasse Comment Resource Objekte der Klasse Resource Relation Objekte der Klasse RelationDefinition Tag Objekte der Klasse Tag Date Objekte der Klasse Date Place Objekte der Klasse Place Person Objekte der Klasse Person Artifact Objekte der Klasse Artifact Concept Objekte der Klasse Concept Project Objekte der Klasse Project besondere Schlüsselworte all Objekte beliebiger Klassen Entity Objekte aus einer der Unterklassen von Entity, d.h. Tag, Date, Place, Person, Artifact, Concept und Project

Tabelle 4.20: gültige Schlüsselworte für die Verknüpfung von Anfragekriterien

Schlüsselwort Beschreibung AND ein logisches Und OR das logische Oder XOR das logische XOR, welches auch als „entweder- oder“ bekannt ist , das , ist ein Synonym für das AND

Fehler, wie das Auslassen des WITH Schlüsselwortes, sorgen dafür, dass der Parser die Gegebene Anfrage verwirft. Um Anfragekriterien zu erlauben, die nicht nur auf Gleichheit basieren, werden so genannte Modifikatoren eingeführt, die eine detailliertere Spezifikation der Art des Kriteriums erlauben. Modifikatoren werden dabei als Suffix an das betreffende Attribut angehängt und durch . vom Attribut getrennt. Die .-Syntax erlaubt dabei auch das Traversieren von Beziehungen zwischen Objekten: Ein gegebener Klassenname erlaubt den Zugriff auf alle Objekte der gegebenen Klasse, die zu dem gesuchten Objekt in Beziehung stehen; ein weiterer Punkt erlaubt den Zugriff auf die Attribute der verknüpften Objekte. Nehmen wir als Beispiel an, wir suchten alle Orte, die In Bezug stehen zu der Person mit dem Spitznamen ’foo’. Die betreffende Anfrage würde die folgende Form haben: Place WITH Person.nickname=’foo’ 4.4 Definition einer Abfrage-Sprache 73

Wenn nur der Klassenname gegeben wird, wird das Kriterium auf das name Attribut der spezifizierten Objekte angewendet. So ist die Anfrage all WITH tag=’job’ gültig und liefert alle Objekte zurück, die mit dem Tag mit dem Namen job verbunden sind.

Die Liste aller möglichen Modifikatoren wird in der Tabelle 4.21 spezifiziert. Dabei ist die Auf- Modifikatoren gabe der Modifikatoren, komplexere Suchanfragen zu formulieren. Modifikatoren werden durch . vom betreffenden Attribut abgetrennt. Die Anfrage all WITH name.icontains=’Peter’ liefert beispielsweise alle Objekte zurück, in deren Namen die Zeichenkette ’Peter’ auftaucht. Weitere Beispiele finden sich in der Tabelle 4.21.

Tabelle 4.21: Modifikatoren for Attributspezifikationen

Schlüsselwort Beschreibung gt „größer als“. Neben Zahlwerten ist dieser Mo- difikator auch auf Datumsangaben anwendbar, wobei „A.gt=B“ in dem Falle bedeuten würde, dass B zeitlich vor A liegt. Bei Strings wird die Länge des Strings als Vergleichskriterium ange- nommen. lt analog zu gt bedeutet lt „kleiner als“ not Die Negation. So können negative Kriterien for- muliert werden zum Beispiel „Alle Personen, de- ren Name nicht ’Peter’ ist“ contains Stringsuche. all WITH name.contains=’foo’ liefert alle Objekte zurück, deren name-Attribut die Zeichenkette ’foo’ enthält. Die Suche ist dabei case-sensitive. icontains Stringsuche. all WITH name.icontains=’foo’ liefert alle Objekte zurück, deren name-Attribut die Zeichenkette ’foo’ enthält. Die Suche ist dabei case-insensitive, würde also auch Objekte liefern, die die Zeichenkette ’FOO’ enthalten. exclude Ausschluss. all WITH name.exlude=’foo’ lie- fert alle Objekte zurück, deren name Attribut die Zeichenkette ’foo’ nicht enthält. Die Suche ist dabei case-sensitive. iexclude Ausschluss. all WITH name.iexlude=’foo’ lie- fert alle Objekte zurück, deren name Attribut die Zeichenkette ’foo’ nicht enthält. Die Suche ist dabei case-insensitive, würde also auch alle Ob- jekte ausschliessen, die die Zeichenkette ’FOO’ enthalten. 74 4 Entwurf

4.4.2 Die FUSE-Abstraktion

Grundlegend orientiert sich die FUSE-Abstraktion an den Möglichkeiten, die WQL (siehe 4.4.1) bietet, auch wenn die Abbildung auf Dateien und Verzeichnisse einige Veränderungen mit sich bringt.

Probleme Die erste und gravierendste Änderung ist die des Modifikator-Trennzeichens. Gerade in mit dem „.“ Hinblick auf Plattformen wie Windows-Betriebssysteme, die den Typ einer Datei nicht anhand ihres Inhaltes bestimmen sondern anhand ihrer so genannten „Dateierweiterung“, welche wiederum durch einen „.“ vom Dateinamen getrennt wird, ist der „.“ als Zeichen zu vermeiden, da die Nutzung des Systems, aufgrund der für den Nutzer unverständlichen Zuordnung von Symbolen und Typen, nur noch schwer möglich ist. Des weiteren werden Dateien, deren Dateinamen mit einem „.“ beginnen, in unixoiden Betriebssystemen wie Linux, den Systemen der BSD Familie oder MacOSX als so genannte „versteckte Dateien“ interpretiert, welche dem Nutzer üblicherweise ausgeblendet werden, so er ihre Anzeige nicht explizit erzwingt.

Markierung Da die FUSE-Abstraktion allerdings auf spezielle „Verzeichnisse“ zurückgreift, um Anfragen spezieller Verzeichnisse an den Wittgenstein Dienst zu stellen, ist es sinnvoll, diese Verzeichnisse für den Nutzer klar zu markieren um eine Verwechslung mit den Objekten zu verhindern. Es wurde sich deshalb dafür entschieden der Python-Konvention zu folgen und besondere Verzeichnisse und Dateien dadurch kenntlich zu machen, indem dem Dateinamen __ vorangestellt und hinten angehängt werden. Diese Markierung macht Verzeichnisse, die die Anfrage weiter verändern, leicht sichtbar und sorgt dafür, dass sie bei alphanumerischer Sortierung der Dateien und Verzeichnisse (welche den Standardfall darstellt) als erste Elemente angezeigt werden, was, gerade bei großen Mengen von Objekten, es dem Nutzer deutlich leichter macht, die Objekte zu finden, die er sucht. Die FUSE-Abstraktion wird automatisch beim starten des Wittgenstein Dienstes aktiviert und stellt das durch sie implementierte Dateisystem in einem Ordner namens wittgenstein im Verzeichnis des Nutzers1 zur Verfügung. Der Ordner wittgenstein stellt die in der Tabelle 4.22 dargestellten Unterverzeichnisse als Einstieg für den Nutzer zum Abfragen der Daten des Systems zur Verfügung.

Repräsentation Innerhalb der FUSE-Abstraktion werden Dateien selbstverständlich als Dateien angezeigt der Objekte mit ihren korrekten Eigenschaften, so dass sie genau so geöffnet werden können, als hätte man sie an ihren „echten“ Ort geöffnet. Andere Arten von Objekten werden durch möglichst angemessene Dateiformate repräsentiert, die Tabelle 4.23 gibt hierfür die Entsprechungen wieder.

Reduzierte Die FUSE-Abstraktion ist beschränkt in den Optionen, die sie dem Nutzer zum filtern der Möglichkeiten Objekte anbietet aufgrund ihres Einsatzbereiches: Ein Dateimanager zeigt dem Nutzer nur Objekte an, die existieren. Die Eingabe von Freitext ist in diesem Usecase nicht vorgsehen, was beispielweise die Anfrage „Alle Personen, deren Name ’foo’ enthält“ nicht sinnvoll abbildbar macht. Die FUSE-Abstraktion beschränkt sich deshalb ganz klar auf den Umgang mit den definierten Objekten und erlaubt es, Anfragen zu formulieren, die auf diesen basieren. Sicherlich ist es technisch möglich, auch Anfragen zu ermöglichen, die über Dateien und Verzeichnisse realisiert werden, die ein visueller Dateimanager nicht abbilden kann, doch ist der Nutzen

1 seinem so genannten Homedir 4.4 Definition einer Abfrage-Sprache 75 einer solchen Implementierung sehr eingeschränkt und erscheint gerade für den gegebenen Anwendungsbereich und Einsatzzweck1 nicht sinnvoll.

Die folgenden zwei Beispiele illustrieren, wie die FUSE-Abstraktion Anfragen an das System Beispiele erlaubt: Der Pfad wittgenstein/__tags__/job/__tags__/picture/ beispielsweise stellt ein Verzeichnis dar, welches alle Objekte enthält, die sowohl mit dem Tag „job“ als auch mit dem Tag „picture“ verbunden sind. Würde man den Pfad erweitern auf wittgenstein/__tags__/job/__tags__/picture/__resources__ enthielte das Verzeichnis nur noch Resourcen.

1 nämlich eine Integration der Informationen in 3rd-Party Anwendungen 76 4 Entwurf

Tabelle 4.22: spezielle Verzeichnisse innerhalb der FUSE-Abstraktion

Verzeichnis Beschreibung __tags__ Enthält die alle Tags sowie spezielle Verzeichnisse um die Suche weiter einzugrenzen __people__ Enthält die im System definierten Personen so- wie spezielle Verzeichnisse, um die Suche nach Personen zu verfeinern. __places__ Enthält die im System definierten Orte sowie spezielle Verzeichnisse, um die Suche nach Orten zu verfeinern. __dates__ Enthält die definierten Daten sowie spezielle Ver- zeichnisse, um die Suche nach Daten zu verfei- nern. __concepts__ Enthält die im System existierenden Concept instanzen sowie spezielle Verzeichnisse, um die Suche nach Konzepten zu verfeinern. __artifacts__ Enthält die im System angelegten Artefakte so- wie spezielle Verzeichnisse, um die Suche nach Artefakten zu verfeinern. __projects__ Erlaubt den Zugriff auf die im System angelegten Projekte sowie spezielle Verzeichnisse, um die Suche nach Projekten zu verfeinern. __entities__ Enthält alle Instanzen von Unterklassen der Klas- se Entity sowie spezielle Verzeichnisse, um die Suche nach Entities zu verfeinern. __relation_definitions__ Enthält alle RelationDefinitions sowie spezielle Verzeichnisse, um die Suche nach RelationDefi- nitions zu verfeinern. __relations__ Enthält alle Relations sowie spezielle Verzeich- nisse, um die Suche nach Relations zu verfeinern. __resources__ Enthält alle Resourcen sowie spezielle Verzeich- nisse, um die Suche nach Resourcen zu verfeinern. __comments__ Enthält alle Kommentare sowie spezielle Ver- zeichnisse, um die Suche nach Kommentaren zu verfeinern. 4.4 Definition einer Abfrage-Sprache 77

Tabelle 4.23: Repräsentation der unterschiedlichen Objekttypen innerhalb der FUSE- Repräsentation

Objekttyp Repräsentation Tag Ein Tag ist repräsentiert als ein Verzeichnis, wel- ches alle mit ihm verbundenen Objekte enthält. Tags haben innerhalb des Systems keine weitere Repräsentation. Person Personen werden repräsentiert als vCard Dateien wie sie im vCard Standard Version 2.1 beschrie- ben sind [vca96b]. Date Datumsangaben werden als vCalendar Dateien der Version 1.0 [vca96a] repräsentiert. Place Orte werden als repräsentiert als Textdatei, die die Informationen über den Ort enthält. Artifact Artefakte werden als repräsentiert als Textdatei, die die Informationen über das Artefakt enthält. Concept Konzepte werden als repräsentiert als Textdatei, die die Informationen über das Konzept enthält. Project Projekte werden realisiert als Verzeichnisse, wel- che alle dem Projekt zugeordneten Objekte ent- hält. Um auch auf die Beschreibung des Projek- tes zugreifen zu können, enthält das Projektver- zeichnis eine besondere Datei mit dem Namen __meta__, in welcher sich diese findet. Comment Kommentare werden als Textdateien repräsen- tiert. RelationDefinition Relationsdefinitionen werden repräsentiert als Verzeichnisse, die alle Objekte enthalten, die in einer Relation beteiligt sind, die der gegebenen Relationsdefinition entspricht. Die spezielle Datei __meta__ enthält die Zusatzinformationen über die Relationsdefinition, das spezielle Unterver- zeichnis __relations__ wiederum enthält alle einzelnen Relationen, die von diesem Typ sind. Relation Relationen werden repräsentiert als Verzeichnis- se, die alle in der Relation stehenden Objekte enthalten. Resource Resourcen werden je nach Typ unterschiedlich dargestellt. Dateien werden repräsentiert durch sich selbst genau wie Verzeichnisse. URLs, also Resourcen, die beispielsweise auf Webseiten ver- weisen, werden durch .url Dateien abgebildet, für die es zwar keinen offiziellen Standard gibt, die sich aber trotzdem als Konvention durchgesetzt haben2. 78 4 Entwurf

4.5 Entwurf des Metadatenscanners

Um dem Nutzer den Umgang mit dem System zu erleichtern, versucht das Wittgenstein System selbstständig möglichst viele Informationen über hinzugefügte Objekte zu sammeln. Dazu steht ein Metadatenscanner zur Verfügung, der nach der Erzeugung eines neuen Objektes automatisch versucht, möglichst viele Informationen über das betreffende Objekt zu sammeln, teils aus Fremdsystemen, teils durch direkte Interaktion mit dem entsprechenden Objekt.

Unter- Die im Wittgenstein System vorhandenen Objekte sind von ganz unterschiedlicher Art, wie stützte Objekte schon in Abbildung 4.3 dargestellt wurde, und der Metadatenscanner ist nicht für alle Typen von Objekten geeignet, er wird nur für Resourcen und Entitäten eingesetzt. Anstatt einen monolithischen, generischen Scanner entwickeln zu wollen, der qualitativ hochwertige Informationen über jede Art von Objekt generieren kann1, wurde ein modulares und flexibles Design für den Metadatenscanner gewählt, welches es sowohl erlaubt, generische Funktionalität, die Aussagen über beliebige Arten von Objekten liefern kann, zu implementieren als auch spezifische auf genau einen speziellen Typ von Objekt zugeschnittene Funktionalität zu realisieren.

grund- Die Struktur des Scanners basiert auf einer flexiblen Pluginarchitektur. Ein neuer Scan- legendes Design nerprozess wird grundsätzlich mit einem Objekt als Parameter gestartet, das Objekt, über das der Scanner mehr Informationen ermitteln soll. Der Scanner kennt damit auch den Typ des Objektes. Der Scanner wendet nun alle Plugins, die zum gegebenen Typ von Objekt kompatibel sind, an und aggregiert die von ihnen gelieferten Daten. In einem zweiten Schritt bildet er nun die Vereinigung der ermittelten Daten, wobei ein einfaches Attribut eines Ob- jektes selbstverständlich nur einen Wert annehmen kann. Dieses Problem löst der Scanner, indem er Nullwerte für ein Attribut ignoriert und im Falle weiterhin bestehender Unterschiede den kleinsten gemeinsamen Nenner zu bestimmen versucht. Sollten zwei unvergleichbare Ergebnisse zur Auswahl stehen wird das betreffende Attribut nicht automatisch vom Scanner befüllt sondern es dem Nutzer überlassen, diese Entscheidungen zu treffen (der Scanner sollte autonom und ohne Nutzerinteraktion arbeiten, um den Nutzer nach dem Hinzufügen einer größeren Menge von Objekten nicht über einen längeren Zeitraum bei seiner Arbeit zu stören). Der Scanner kann die unterschiedlichen Ergebnisse in diesem Falle als Kommentar an das Objekt anhängen und den Wittgenstein Server über das aufgetretene Problem informieren (vgl. hierzu die funktion report_scan_result() in der tabelle 4.18). Der Scannerprozess schreibt seine Ergebnisse dann über die D-BUS schnittstelle zurück in das Wittgenstein System.

Plugin- Die Struktur der Plugins ist so entwurfen, dass sie möglichst simpel zu implementieren archi- tektur sind: Jedes Plugin erbt von der vordefinierten Klasse WittgensteinScannerPlugin und über- schreibt deren Klassenmethode run(object); die Klassenmethode run() wird später vom Scanner aufgerufen, um das Plugin zu verwenden. Des weiteren überschreibt jedes Plugin das Klassenattribut supported_types, um anzuzeigen, für welche Typen von Objekten es Daten extrahieren kann. Alle weiteren notwendigen Aktionen, um dem Metadatenscanner Zugriff auf das Plugin zu geben und es für die unterstützten Objekttypen innerhalb des Metadatenscanners zu

1 so ein solches System überhaupt möglich ist 4.6 Entwurf einer prototypischen grafischen Oberfläche 79 registrieren, werden über die Metaklasse WittgensteinPluginMeta. Eine Klasse verhält sich zu ihrer Metaklasse wie eine Klasseninstanz zu einer Klasse: Eine Metaklasse ist so zu sagen der Konstruktor einer Klasse. Wie Abbildung 4.7 zeigt erben alle Plugins von WittgensteinScan- nerPlugin die Metaklasse WittgensteinPluginMeta und können so simpel im Metadatenscanner registriert werden. Die Pluginklasse, die die run() Funktion enthält, wird dabei zu keinem Zeitpunkt instanziiert, sie ist de fakto nur Container für die Metadaten über das Plugin. Die Funktionalität des Plugins selbst kann so streng prozedural innerhalb der run() Funk- tion realisiert werden, oder für komplexere Plugins, unter Zurhilfenahme weiterer Klassen, Klasseninstanzen und Bibliotheken.

Abbildung 4.7: Architektur der Metadatenscannerplugins

4.6 Entwurf einer prototypischen grafischen Oberfläche

Die grafische Nutzungsoberfläche der Wittgenstein Software trennt sich in zwei Bereiche auf: Einmal die Oberfläche, um Objekte hinzuzufügen und zu editieren und andererseits die Oberfläche um Objekte auszulesen.

Diese Trennung ist begründet in dem Ziel, die Anwendung möglichst einfach in weitere Begründung der Aufteilung Software integrierbar zu machen: Indem die grafische Oberfläche zum Hinzufügen neuer der GUI Objekte als eingenständiges Programm verwendbar ist, kann es leicht in weitere Software als Plugin integriert werden. So bietet beispielsweise der Dateimanager des GNOME Projektes an, per Rechtsklick auf ein Dokument bestimmte, typabhängige Aktionen zu starten: Klickt der Nutzer also mit Rechts auf eine .vcf Datei1 so kann der Dateimanager automatisch den Dialog zum hinzufügen einer neuen Person zum Wittgenstein System anbieten. Die für das hinzufügen des Objektes möglichen Felder können dem Programm als Startparameter übergeben werden, so dass der Nutzer eine große Menge von Daten schon vorausgefüllt findet.

1 eine vCard Datei mit Personenbezogenen Daten 80 4 Entwurf

4.6.1 Grundlegende Gedanken zum Entwurf der GUI

Beim Entwurf der GUI wurden als Entscheidungsgrundlage die GNOME Human Interface Guidelines[Cal08] zugrunde gelegt. Ein sehr wichtiger Aspekt, der immer wieder in diesem Dokument angesprochen wird, ist die Reduktion der grafischen Oberfläche auf das für den Nutzer wesentliche sowie der Verzicht auf unnötige Konfigurationsmöglichkeiten: Der Nutzer soll in die Lage versetzt werden auf einfache Art und Weise seine gestellten Aufgaben zu erledigen ohne dabei unnötige Aufgaben, die dem Erreichen seines eigentlichen Ziels nicht dienlich sind, erledigen zu müssen. „The Zen of Python“[Pet04], eine Sammlung von Aphorismen die die grundlegenden De- signprinzipien, auf denen die Sprache Python basiert, formuliert diesen Gedanken mit den Worten

»There should be one– and preferably only one –obvious way to do it.«[Pet04]

Einfachheit und Klarheit anstatt von großer Anpassbarkeit und Konfigurierbarkeit wurde im Entwurf dieser GUI der Vorzug gegeben.

4.6.2 Hinzufügen/Editieren von Objekten

Die Oberfläche zum Hinzufügen von Objekten ist sehr einfach und klar strukturiert: Für jedes Attribut des betreffenden Objektes steht dem Nutzer ein geeignetes Eingabewidget zur Verfügung wie die Abbildung 4.8 am Beispiel der Klasse Place demonstriert.

Abbildung 4.8: Maske zum Hinzufügen von Objekten 4.6 Entwurf einer prototypischen grafischen Oberfläche 81

Offensichtlich unterscheiden sich die Eingabemasken für die Unterschiedlichen Klassen von grundsätzliche Objekten, doch bleibt die Struktur immer analog erhalten, um dem Nutzer eine einfache Gemeinsamkeiten Orientierung zu ermöglichen. Die in Abbildung 4.8 dargestellten Eingabefelder zum Eintragen von Tags, eines initialen Kommentars und zum Festlegen der Bewertung des Objektes sind immer im rechten Fensterbereich an derselben Stelle zu finden. Auf eine Menüleiste wurde bewusst verzichtet, um die Eingabemaske auch visuell vollständig auf ihre einzige Aufgabe zu beschränken.

4.6.3 Auslesen von Objekten

Die Auslesemaske ist dominiert durch das Eingabefeld, in welches der Nutzer seine Anfrage eingeben kann. Nach der Eingabe einer gültigen Anfrage werden die betreffenden Objekte in einer Liste unterhalb des Eingabefeldes angezeigt, wie die Abbildung 4.9 zeigt.

Abbildung 4.9: Maske zum Auslesen von Objekten

Dabei können unterstrichen dargestellte Objekte angeklickt werden, um die Ansicht auf Navigation sie zu beschränken: Klickt man beispielsweise den Tag example so wird automatisch die wie im WWW Anfrage Tag WITH name=’example’ ausgeführt. Genauso lassen sich alle anderen Objekte direkt anklicken, um die Ansicht so neu zu gruppieren. Diese Vorgehensweise entspricht dem Umgang mit dem WWW bzw einem Browser und ist deshalb ein, den meisten Nutzern sehr vertrautes, Paradigma zur Bedienung von Anwendungen. 82 4 Entwurf

Jedes angezeigte Objekt bringt des weiteren einen Knopf mit, welcher das Editieren der über das Objekt gespeicherten Daten erlaubt. Diese Masken verhalten sich dann wiederum analog zu der in Abbildung 4.8 beispielhaft dargestellten Eingabemaske.

Relationen Neben der Ausgabe der direkten Attribute eines Objektes nimmt die Darstellung der Beziehungen des betreffenden Objektes eine zentrale Rolle ein: Die Beziehungen, in denen ein spezielles Objekt beteiligt ist, werden in lesbarer und einfach verständlicher Form direkt unter den Attributen des Objektes in einer Liste dargestellt.

4.6.4 Anwenden von Relationen

In der Bedienung des Systems nimmt die Anwendung von Relationsdefinitionen auf Objekte eine fundamentale Rolle ein; deshalb soll das Anwenden von Relationen möglichst einfach und intuitiv vonstatten gehen. Abbildung 4.10 stellt diese Nutzungsschnittstelle beispielhaft dar.

Abbildung 4.10: Maske zum Anwenden von Relationen auf Objekte

RelationDefinition-Instanzen sind selbst Objekte und werden erzeugt über die in Abbildung 4.8 dargestellte Schnittstelle. Wenn diese RelationDefinition-Instanzen nun also auf andere Objekte angewendet werden, sind ihre Endpunkte also schon klar definiert. Dem Nutzer werden folglich die unterschiedlichen Endpunkte der betreffenden RelationDefinition mit ihren relevanten Informationen wie beispielsweise den akzeptierten Typen von Objekten und der erlaubten bzw. geforderten Maximal- bzw. Minimalanzahl von Objekten präsentiert. In diese 4.6 Entwurf einer prototypischen grafischen Oberfläche 83

Listen können nun aus der in Abbildung 4.9 dargestellten Anfragemaske Objekte mittels Drag-and-Drop eingefügt werden: Der Nutzer „greift“ also beispielsweise in der Anfragemaske ein Personenobjekt und zieht es über den betreffenden Endpunkt. Wenn das betreffende Objekt einen erlaubten Typ hat und noch weitere Objekte mit dem Endpunkt verbunden werden können, wird das Objekt direkt der Relation hinzugefügt. Analog können Objekte auf diese Art und Weise aus der Beziehung entfernt werden, indem sie einfach aus der Liste des Endpunktes, mit dem sie verbunden sind, herausgezogen werden. Das Verwenden von Drag-and-Drop erlaubt es, die Masken schlank und übersichtlich zu halten: Der Nutzer ist einerseits nicht künstlich in seinen Möglichkeiten beschränkt und andererseits nicht erschlagen durch zu komplexe grafische Nutzungsoberflächen mit zu vielen Optionen und Schaltflächen. 84 4 Entwurf KAPITEL 5

Implementierung

Das folgende Kapitel beschreibt die zur Implementierung verwendete Softwareumgebung und die Vorraussetzungen, um Wittgenstein auf dem eigenen System laufen zu lassen. Schliesslich werden noch einige Standards, die das System nach der Installation mitbringt, zusammenge- fasst.

5.1 Die Entwicklungsplatform

Das Wittgenstein wurde unter Verwendnung unterschiedlicher Technologien entwickelt, die das Erstellen plattformunabhängiger Software ermöglichen und vereinfachen. Dabei wurde des weiteren besonderer Wert darauf gelegt, wohlgetestete Standardbibliotheken zu verwenden und möglichst wenig existierende Funktionalität zu duplizieren, um Prof. Dr. Edsger W. Dijkstra zu zitieren:

»My point today is that, if we wish to count lines of code, we should not regard them as „lines produced“ but as „lines spent“: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. «[Dij88]

5.1.1 Python

Python1 ist eine freie Programmiersprache, welche von der Python Software Foundation2 entwickelt und herausgegeben wird. Die Sprache selbst ist dabei nicht auf ein Programmier- paradigma beschränkt sondern unterstützt das prozedurale, das objekt-orientierte und das funktionale Programmierparadigma.

Die Python Software Foundation gibt neben der Spezifikation der Sprache selbst des Runtimes weiteren eine Referenzimplementierung für die Python Laufzeitumgebung heraus, die unter http://www.python.org/download/ zur Verfügung gestellt wird. Diese in C implementierte Platform wird häufig ebenso wie die Sprache als Python bezeichnet, der Klarheit halber

1 http://python.org 2 http://python.org/psf 86 5 Implementierung

bezeichne ich die Laufzeit hier allerdings als CPython. Neben CPython existieren noch weitere Laufzeitumgebungen wie Jython1, welches die Python Sprache innerhalb der Java Virtual Machine implementiert, oder IronPython 2, welches Python Programme innerhalb der von Microsoft entwickelten .NET Platform lauffähig macht.

Python Die Wittgenstein Software setzt eine CPython Version >=2.5 voraus, da einige erst in Version 2.5 eingeführte Konstrukte verwendet werden. Es wäre mit einigem Aufwand möglich, auch ältere Python versionen zu unterstützen,da Python 2.5 allerdings am 19. September 2006 veröffentlich wurde, soll auf die Unterstützung veralteter Versionen an dieser Stelle verzichtet werden. Am 03. Dezember 2008 wurde Python 3.0 veröffentlicht, eine nicht mehr rückwärts- kompatible version der Python Sprache, die die Standardbibliothek umstrukturiert und diverse Interna der Sprache verändert. Zum gegenwärtigen Zeitpunkt ist die Wittgenstein Software nicht kompatibel zu Python 3.0. 3 Modul- Python Module sind nicht zwingend in reinem Python implementiert, aus Performance- kompatibi- lität gründen ist es möglich, Teile des Codes in in C implementierten Extensions auszulagern, um Geschwindigkeitsvorteile zu erlangen. Solcherlei Module sind folglich meist nicht zu den alternativen Python Laufzeitumgebungen kompatibel. Bei der Auswahl der verwendeten Zusatzmodule für die Implementierung wurde nicht auf die Kompatibilität zu 3rd-Party Laufzeitumgebungen wie Jython oder Ironpython Wert gelegt und solcherlei Laufzeitumge- bungen wurden auch nicht getestet. Die Wittgenstein Software selbst ist in reinem Python implementiert und damit theoretisch auf alternativen Laufzeitumgebungen einsetzbar, so denn die benötigten Module lauffähig sind. Alternative Laufzeitumgebungen wurden in diesem Kontext nicht getestet, weil beide großen Implementierungen, Jython und IronPython, zum Zeitpunkt der Implementierung noch nicht alle Features der Python Spezifikation Version 2.5, welche hier vorausgesetzt wird, implementierten.

5.1.2 Python SQLite Bindings

Die Daten des Wittgenstein Systems werden in einer relationalen Datenbank abgelegt. Die offizielle Python Distribution kommt mit eingebauter Unterstützung für die SQLite Datenbank, welche vom Wittgenstein System verwendet wird. Die von Python 2.5 mitgelieferte Version ist ausreichend, muss aber unter Umständen nachinstalliert werden.

5.1.3 SQLAlchemy

4 SQLAlchemy SQLAlchemy ist ein flexibler und erweiterbarer Object Relational Mapper (ORM) und SQL Toolkit. SQLAlchemy ist in reinem Python implementiert und bietet so größtmögliche

1 http://jython.org 2 http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython 3 im Python Sprachgebrauch bezeichnet man ein in sich geschlossenes Stück Software als Modul, etwas, das man in anderen Sprachen teilweise als Package kennt 4 http://www.sqlalchemy.org/ 5.1 Die Entwicklungsplatform 87

Plattformunabhängigkeit und unterstützt eine breite Palette von relationalen Datenbankma- nagementsystemen wie SQLite, MySQL, PostgreSQL, Orcale, DB2, MS-SQL und anderen.

Ein ORM stellt eine Lösung für den so genannten „Object-relational Impedance Mismatch“ Object- relational wie er in Fundamentals of Database Systems[EN06] von Ramez Elmasri und Shamkant B. Nava- Impedance the beschrieben wird: Bei der Kombination von relationalen Datenbankmanagementsystemen Mismatch und objekt-orientierter programmierung treten typische Probleme auf, die auf den unterschied- lichen Sichtweisen auf Daten, die in beiden Welten vorliegen, basieren. ORMs übernehmen die Aufgabe, die relationale Sicht der Datenbankmanagementsysteme in eine objekt-Orientierte Sicht zu übersetzen, so dass der Entwickler eine einheitliche objekt-orientierte Herangehens- weise verfolgen kann. SQLAlchemy ist ein sehr reifes Projekt, welches die Basis einiger Rapid-Development Web Frameworks (wie zum Beispiel Turbogears1) bildet und liegt zum jetzigen Zeitpunkt in zwei Versionen vor, der stabilen 0.4.8 und dem Entwicklungszwei 0.5rc4. In der Entwicklung der Anwendung stellte sich heraus, dass einige der Features im Ent- wicklungszweig 0.5 die Implementierung deutlich vereinfachen würden, und so wurde dieser als Zielversion ausgewählt. Während der Implementierung wurden sogar einige Fehler im Quellcode der 0.5rc3 Version festgestellt, die umgehend von den SQLAlchemy Entwicklern in der version 0.5rc4 verbessert wurden, die Wittgenstein Software setzt also mindestens Version 0.5rc4 der SQLAlchemy Bibliothek voraus.

5.1.4 DBUS-Python

Um mit dem DBUS Dienst zu kommunizieren, liefern die DBUS Entwickler Bindings für DBUS- Python aus2, die unter dem Namen dbus-python verbreitet werden. Die von unserer Applikation Python vorausgesetzte version ist die 0.83.0 bzw. neuer.

5.1.5 FUSE

FUSE, das „Filesystem in Userspace“, findet sich unter Linux seit der Version 2.6.14 direkt FUSE im Kernel wieder, heute aktivieren die meisten Distributionen es standardmässig. Wer seinen Kernel selbst baut, kann das FUSE Modul in der Kernel Konfiguration als CONFIG_FUSE_FS finden und aktivieren. Die FUSE Website listet unter http://apps.sourceforge.net/mediawiki/fuse/index. php?title=OperatingSystems des weiteren die FUSE Implementierungen für nicht-Linux Betriebssysteme auf, es existieren Versionen für diverse BSD Varianten, für Mac OS X, Windows und andere.

Um unter Python mit der FUSE Implementierung zu kommunizieren sind Bindings vonnöten, FUSE- welche vom FUSE Projekt selbst bereitgestellt werden3. Wir setzen an dieser Stelle die Version Python 0.2 voraus.

1 http://turbogears.org/ 2 http://www.freedesktop.org/wiki/Software/DBusBindings 3 http://apps.sourceforge.net/mediawiki/fuse/index.php?title=OperatingSystems 88 5 Implementierung

5.1.6 GTK

1 GTK Für die graphische Oberfläche des Clients wird GTK verwendet. Die PyGTK genannten Python Bindings für GTK2 stehen auf der Webseite des Projektes für Unix, Linux und Windows zur Verfügung. Wir setzen dabei die Version 2.12 oder neuer voraus.

5.1.7 Softwaretests

Unittests Die Software wird mit einem Satz von Unittests ausgeliefert. Python selbst liefert in seiner Standardbibliothek zwei Unittestwerkzeuge mit, das so genannte doctest Modul, welches vor allem für kleine Projekte gedacht ist, und das durch das in der JAVA Welt bekannte JUnit3 inspirierte unittest Modul. Da sich im Umgang das unittest Modul als unhandlich ergeben hat, wurde für diese Arbeit eine nose4 genannte Erweiterung für das unittest Modul der Standardbibliothek eingesetzt, die das Schreiben von Tests deutlich knapper und schlanker gestaltet. Diese Software ist optional und nur für die automatisierten Unittests in der Version 0.10.4 notwendig.

5.1.8 Betriebssysteme

Betriebs- Die Wittgenstein Software wurde auf einem Linux System entwickelt, die verwendeten Biblio- systeme theken sind allerdings keineswegs nur auf Linux beschränkt sondern sind nach Angaben der Entwickler auf allen gängigen Plattformen, d.h. Linux, *BSD, OS X und Windows verfügbar. Getestet wurde die Anwendung allerdings hauptsächlich auf Linux Systemen. Der Code selbst ist allerdings nicht platformabhängig so dass die Software, so sie denn nicht unmodifiziert lauffähig ist, mit geringem Aufwand portiert werden kann.

5.1.9 Zusammenfassung

Es folgt der Übersichtlichkeit halber eine Tabelle mit allen benötigten Softwareversionen und den Adressen, an denen die Software bezogen werden kann:

1 http://www.gtk.org 2 http://www.pygtk.org 3 http://www.junit.org 4 http://somethingaboutorange.com/mrl/projects/nose/ 5.1 Die Entwicklungsplatform 89

Tabelle 5.1: Liste der benötigten Softwarepakete

Software Version Adresse Python/CPython <3.0 und >=2.5 http://python.org SQLAlchemy >=0.5rc4 http://sqlalchemy. org dbus-python >=0.83.0 http://www. freedesktop.org/ wiki/Software/ DBusBindings fuse-python >=0.2 http://www. freedesktop.org/ wiki/Software/ DBusBindings GTK+ >=2.12 http://www.gtk.org PyGTK >=2.12 http://pygtk.org nose >=0.10.4 (optional) http:// somethingaboutorange. com/mrl/projects/ nose/ 90 5 Implementierung KAPITEL 6

Zusammenfassung und Ausblick

Im folgenden Kapitel sollen die Ergebnisse der Arbeit in Hinsicht auf das Erreichen der in Abschnitt 1.2 beschriebenen Ziele reflektiert werden. Abschliessend soll ein Ausblick gegeben werden über zukünftige Erweiterungsmöglichkeiten der entwickelten Lösung.

6.1 Reflexion der Ergebnisse

Die Probleme, die durch die beschränkten Möglichkeiten von Dateisystemen entstehen, sind, Analyse der Limitationen auch durch einen Rückgriff auf die Erkenntnisse der modernen Philosophie und im speziellen von Datei- der Ontologie1, umfassend analysiert worden. Basierend auf diesen Erkenntnissen und den systemen Arbeiten von David Weinberger [Wei08] wurden die grundlegenden Entitäten ermittelt, die das semantische Modellieren von Ressourcen und ihren Eigenschaften ermöglichen. Die Struktur der Eigenschaften wurde dabei so flexibel entworfen, dass eine dynamische Erweiterung der Ressourcen und Entitäten um neue Eigenschaften für den Benutzer einfach realisierbar ist, um alle für ihn persönlich relevanten Daten zu den Entitäten und Ressourcen speichern zu können. Die Möglichkeit, alle Objekte innerhalb des Systems mit Kommentaren versehen zu können, bietet dem Nutzer die Möglichkeit, selbst Informationen, die sich nicht als einfache Eigenschaften eines Objektes modellieren lassen, abzubilden.

Das System liefert dem Nutzer eine breite Palette aus vordefinierten Relationen mit, die er Relationen von Ressourcen auf seine Ressourcen und die von ihm definierten Entitäten anwenden kann. Die vom System und Entitäten mitgelieferten Relationen bilden jedoch nur den Grundstock: Der Nutzer kann sich völlig frei neue Relationen definieren, die es ihm erlauben, sein ganz persönliches mentales Modell der Welt und seiner Ressourcen in der Software abzubilden und diese von ihm geschaffene Struktur zum Auffinden und Navigieren seiner Ressourcen zu nutzen. Der Nutzer wird so in die Lage versetzt, die ihm persönlich optimal erscheinende Organisationsstruktur zu konstruieren.

Das System bietet klar definierte plattform- und programmiersprachenunabhängige Schnitt- Schnittstellen stellen an, die 3rd-Party Software nutzen kann, um auf die gesamten Daten des Systems zuzugreifen. Durch die Implementierung der FUSE-Abstraktion wird es sogar unmodifizierten

1 Ontologie als Fachgebiet der Philosohpie, „Die Lehre vom Sein“ 92 6 Zusammenfassung und Ausblick

Anwendungen der Zugriff auf die Daten und ihre Struktur möglich. Der Nutzer kann so in nahezu jeder Anwendung, die er für seine persönlichen Projekte und Vorhaben nutzt, von seiner persönlich geschaffenen, semantischen Struktur profitieren und seine Arbeitsprozesse so klarer und effizienter ordnen. Das Wittgenstein System ist damit keine Insellösung und unterstützt folglich auch nahezu beliebige zukünftige Programme; so minimiert sich für den Nutzer die Gefahr, seine Daten in einer speziellen Anwendung „gefangen“ zu haben, ohne die Möglichkeit sie angemessen zu nutzen.

weitere Das Wittgenstein System liefert eine so genannten Metadatenscanner mit, der durch seine Informations- quellen einfache aber leistungsfähige Pluginarchitektur die Integration beliebiger Datenquellen erlaubt. Wittgenstein kann so die vom Nutzer schon in anderer Software gesammelten Daten nutzen ohne eine Neueingabe der Information vom Nutzer zu verlangen. Dabei bestehen für die Funktionalität der Metadatenextraktionsplugins nahezu keinerlei Einschränkungen ohne die Sicherheit und Stabilität des Gesamtsystems zu gefährden.

Zusammen- Insgesamt sind die für diese Arbeit gesteckten Ziele umfassend erfüllt worden. Durch eine fassung der Ziel- ausführliche Analyse der Gegebenheiten und gerade auch die Inklusion von „fachfremder“ erreichung Literatur wurde eine sehr solide Basis geschaffen, die einen klaren Entwurf und eine einfach strukturierte Software ermöglichte, die auf Modularität und Erweiterbarkeit ausgelegt ist.

6.2 Erweiterungen für das Wittgenstein System

Im Rahmen dieser Arbeit ist ein System entstanden, welches dem Nutzer neue Möglichkeiten schafft, mit seinen Informationen umzugehen. Die Beschränkungen von Dateisystemen und der konventionellen Möglichkeiten im speziellen Dateien zu organisieren wurden aufgehoben durch eine flexible Managementschicht für Dateien. Auf dieser Basis sind einige Erweiterungen denkbar, die dem Nutzer den Umgang mit dem System und seinen Dateien noch angenehmer und komfortabler gestalten können. Eine solche Liste ist offensichtlich niemals vollständig, doch sollen in den folgenden Abschnitten einige besonders interessante und sinnvolle Erweiterungen des Systems skizziert werden.

6.2.1 Transfer und Abgleich von Datensätzen

Im Moment platziert sich Wittgenstein klar als lokale Anwendung für einen Nutzer, der seine persönlichen Daten und sein persönliches Modell der Welt um diese Daten im System erfasst. Um dem Nutzer Arbeit abzunehmen, wäre es interessant, Mechanismen zu entwickeln, die es erlauben, Daten und Strukturen aus dem Wittgenstein System der einen Person in das System einer anderen Person zu integrieren. Dabei wäre nicht nur der einfache Fall zu bedenken, dass ein Objekt dem fremden System übersendet wird, sondern vor allem der Fall, dass ein bestimmtes Objekt im System S1 unter einer anderen UUID im System S2 geführt wird: Die beiden Objekte sollten verknüpfbar sein, so dass sich die beiden Wittgenstein Systeme bei Änderungen an den Daten gegenseitig synchronisieren können. 6.2 Erweiterungen für das Wittgenstein System 93

Die Verwendung von UUIDs als Identifikator für Objekte schafft bereits eine solide Grundlage, auf der basierend diese Funktion implementiert werden kann.

Gerade in Firmen oder anderen Bereichen, wo Menschen gemeinsam an Projekten arbei- Gruppen- bezogene ten, würde eine solche Funktionalität das effiziente und kooperative Arbeiten stark fördern: Strukturen Neben der schlichten Zeitersparnis, die durch das Teilen von Informationen erreichbar ist, können durch die verknüpften Wittgenstein-Systeme firmen- bzw. gruppenbezogene Struktu- ren konstruiert werden, indem die mentalen Modelle aller Beteiligten zusammen betrachtet werden.

6.2.2 „Repositories“

Als „Repositories“ werden an dieser Stelle eine neue Schicht von Datenstrukturen innerhalb des Wittgenstein Systems bezeichnet. Derzeit bildet Wittgenstein nur eine einfache Manage- mentschicht über allen Dateien, die der Nutzer dem System hinzugefügt hat. Repositories verhalten sich wie Container für Objekte und würden es erlauben, Ressourcen Speichermedien zuzuweisen. Nehmen wir als Beispiel eine Person, die ihre persönlichen Photos auf einem Wechseldaten- träger wie einer portablen Festplatte speichert. Diese Daten lassen sich zwar momentan direkt in Wittgenstein integrieren, doch ist es Wittgenstein nicht direkt möglich, zu entscheiden, ob die im System bekannten Objekte wirklich zur Verfügung stehen: Der Wechseldatenträger könnte beispielsweise nicht mit dem Rechner verbunden sein. Repositories würden es erlauben, Objekte, deren Speichermedium im Moment nicht mit dem Rechner verbunden ist, als „nicht verfügbar“ anzuzeigen, indem das Wittgenstein System das Betriebssystem nach dem Vorhandensein des betreffen Datenträgers befragt. Der Nutzer wäre so nicht nur in der Lage auch Dateien im System zu verwalten und zu finden, die im Moment nicht zur Verfügung stehen1, sondern vor allem auch einfach festzustellen, welche Datenquelle er dem Computer zugänglich machen muss, um auf die Daten zugreifen zu können.

Die Idee weiterführend wäre es weiterhin interessant, Wittgenstein nicht mehr nur als Wittgenstein als reine Managementschicht zu betrachten, sondern auch die Speicherung der Dateien selbst Datenspeicher Wittgenstein zu übergeben. Dabei wären mehrere unterschiedliche Speicherarten für die von Wittgenstein verwalteten Dateien denkbar, so wäre beispielsweise das Speichern der Dateien auf einen entfernten Rechner mittels eines Protokolls wie WebDAV eine Möglichkeit. Der Nutzer wäre so in der Lage, „sein“ Wittgenstein auf beliebige Rechner mitzunehmen: Nach Eingabe der Zugangsdaten würde Wittgenstein den Zugriff auf die Dateien transparent realisieren.

Doch nicht nur der Zugriff auf entfernte Dateien wäre hierbei ein sehr interessanter Anwen- Versionierung und dungsfall sondern auch die transparente Integration von Versionsmanagement oder Verschlüs- Verschlüsselung selung: Vielen Nutzern fehlt das technische Know-How um ihre eigenen Daten verschlüsselt zu speichern oder auf ihnen Versionskontrolle durchzuführen, Wittgenstein könnte an dieser Stelle die Lücke schliessen.

1 wie es das Wittgenstein System bereits erlaubt 94 6 Zusammenfassung und Ausblick

Selbstverständlich sind beide Ideen kombinierbar, so dass am Ende die Möglichkeit geschaffen würde, seine eigenen, wichtigen Dateien nicht nur von jedem Rechner aus zugreifbar zu haben, sondern auch die Sicherheit zu besitzen, dass die Daten verschlüsselt - und damit vor unbefugtem Zugriff sicher - abgelegt werden und durch die Versionierung der Nutzer zu beliebigen früheren Zuständen zurückkehren kann.

6.2.3 Zentrales Archiv von Relationen

Das Wittgenstein System liefert eine Menge von vordefinierten Relationen mit, die der Nutzer zum Modellieren von Beziehungen zwischen Objekten verwenden kann. Des weiteren kann jeder Nutzer beliebige neue Relationen definieren und auf seine Objekte anwenden. Um den Nutzern die Arbeit des Erstellens immer neuer Relationen zu ersparen wäre die Schaffung eines zentralen Archivs von Relationen interessant, durch welches Nutzer die von ihnen Definierten Relationen anderen Nutzern zur Verfügung stellen können. Dieses Archiv müsste sich nahtlos in die Wittgenstein Oberfläche integrieren, so dass der Nutzer, wenn er eine neue Relation braucht, einfach und schnell sehen kann, ob das Archiv ihm eine geeignete Relation zur Verfügung stellen kann oder nicht. Die Analyse der Relationen im Archiv und ihrer Nutzung böte dann eine interessante Menge empirischer Daten über die Nutzung des Wittgenstein Systems und der Bedürfnisse seiner Nutzer. Die Analyse dieser Daten könnte zu einer für die Nutzer weitaus zufriedenstellenderen Fortentwicklung des Wittgenstein Systems führen, da die Menge der Nutzer einfach durch ihre Nutzung relevante Informationen liefert ohne dabei die Privatsphäre des Einzelnen zu beschädigen.

6.3 Abschluss

Wittgenstein will als Ansatz zur semantischen Verwaltung und Organisation von Dateien einen Beitrag liefern zum so genannten „semantic Desktop“, also einer Computernutzung, die auf den semantischen Beziehungen der Dinge, die ein Mensch mit einem Computer erledigen und verwalten möchte, basiert. Sicherlich ist das Management der für die eigenen Projekte und Interessen relevanten Dateien ein zentraler Schritt auf dem Weg zu einer solchen Computernutzung, doch ist auch das Management der Aktivitäten des Nutzers am Computer, das Management seiner parallel laufenden Aufgaben und Tätigkeiten für den „semantic Desktop“ von großer Relevanz. Der „semantic Desktop“ ist ein wichtiges Ziel auf dem Weg die Computernutzung - und damit den Zugang des Menschen zu den digitalen Informationen und Kommunikationskanälen - dem Menschen angemessener zu gestalten, wenn diese Arbeit das Gesamtprojekt „semantic Desktop“ voranbringen konnte, kann sie, aus Sicht des Autors, als Erfolg betrachtet werden.

„Uncritical semantics is the myth of a museum in which the exhibits are meanings and the words are labels. To switch languages is to change the labels.“ Willard Van Orman Quine Literaturverzeichnis

[Ari98] Aristoteles ; Rath, Ingo W. (Hrsg.): Die Kategorien. Ingo W. Rath, Reclam, 1998. – 115 S. – ISBN 978–3150097069

[Bad99] Baddeley, Alan D.: Essentials of Human Memory. Taylor & Francis, 1999. – 356 S. – ISBN 978–0863775451

[Bay08] Bayer, Michael: Mapping Class Inheritance Hierarchies - Joined Ta- ble Inheritance. http://www.sqlalchemy.org/docs/05/mappers.html# joined-table-inheritance. Version: 22.12.2008. – Dokumenatation für Version 5.0

[BLHL01] Berners-Lee, Tim ; Hendler, James ; Lassila, Ora: The Semantic Web - A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities. In: Scientific American Magazine (2001), Mai

[Cal08] Calum Benson, Adam Elman, Seth Nickell, Colin Z. Robertson: GNOME Human Interface Guidelines 2.2. http://library.gnome.org/devel/hig-book/ stable/index.html.en. Version: 2002-2008

[Cha95] Charles Hulme, Steven Roodenrys, Gordon Brown, Robin Mercer: The role of long-term memory mechanisms in memory span. In: British Journal of Psychology 86 (1995), S. 527–536

[Chr08] Christine Faßnacht, Michael Schidlack (beide BITKOM), Hannes Wiese (Roland Berger Strategy Consultants GmbH): Die Zukunft der digitalen Consumer Electronics - 2008. (2008). http://bitkom.org/files/documents/ Studie_CE_2008.pdf

[CS93] Claus, Volker ; Schwill, Andreas: Dateiverwaltung. In: Duden Informatik. 2. Ausgabe. Mannheim : Dudenverlag, 1993. – ISBN 3–411–05232–5, S. 156–157

[Dij88] Dijkstra, Prof. Dr. Edsger W.: On the cruelty of really teaching compu- ting science. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/ EWD1036.html. Version: Dezember 1988

[Dun89] Duncan, Roy: Design goals and implementation of the new High Performance File System. In: Microsoft Systems Journal Sept 1989 4 (1989), September, Nr. 5. http://cd.textfiles.com/megademo2/INFO/OS2_HPFS.TXT 96 Literaturverzeichnis

[Ecm95] Ecma: Volume and File Structure of Disk Cartridges for Information Interchange / Ecma. Version: jun 1995. http://www.ecma-international.org/publications/ files/ECMA-ST/Ecma-107.pdf. 1995. – Forschungsbericht

[EN06] Elmasri, Ramez ; Navathe, Shamkant B.: Fundamentals of Database Systems (5th Edition). 5. Addison Wesley, 2006. – ISBN 0–321–36957–2

[F.A89] F.A. Brockhaus GmbH: Brockhaus - Hoheitsgewässer. Bd. 5. Mannheim : F.A. Brockhaus GmbH, 1989. – 164 S. – ISBN 3–7653–1100–6

[Flo79] Floyd, Robert W.: The paradigms of programming. In: Communications of the ACM 22 (1979), August, Nr. 8, S. 455–460. – ISSN 0001–0782

[For08] Forschungsgruppe Wahlen: Internet-Strukturdaten — Repräsentative Um- frage - II. Quartal 2008. (2008). http://www.forschungsgruppe.de/Studien/ Internet-Strukturdaten/web_II_08.pdf

[Hav] Havoc Pennington (Red Hat, Inc), Anders Carlsson (CodeFactory) and Alexander Larsson (Red Hat, Inc.): D-BUS Specification, http://dbus. freedesktop.org/doc/dbus-specification.html

[Mil56] Miller, George A.: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. In: The Psychological Review 63 (1956), 81–97. http://www.musanim.com/miller1956/

[NEP08] NEPOMUK Projekt: NEPOMUK - Project Objectives. http:// nepomuk.semanticdesktop.org/xwiki/bin/view/Main1/Project+Objectives. Version: 2008

[Pet04] Peters, Tim: The Zen of Python. http://www.python.org/dev/peps/pep-0020/. Version: 2004

[PMR05] P. Leach (Microsoft) ; M. Mealling (Refactored Networks, LLC) ; R. Salz (DataPower Technology, Inc.): RFC4122 - A Universally Unique IDen- tifier (UUID) URN Namespace, Juli 2005. http://www.faqs.org/rfcs/rfc4122. html

[Por04] Portable Applications Standards Committee, IEEE Computer Society, USA: Standard for information technology - portable operating system interface (POSIX). Shell and utilities, 2004. http://ieeexplore.ieee.org/xpls/abs_all. jsp?arnumber=1309816

[Pyt] Python Software Foundation: datetime — Basic date and time ty- pes, http://docs.python.org/library/datetime.html?highlight=datetime# datetime-objects

[Rus93] Russell, Bertrand: Our Knowledge of the External World. Routledge Chapman & Hall, 1993. – 256 S. – ISBN 978–0415096058

[San99] Sandkühler, Hans J. (Hrsg.): Enzyklopedie Philosophie. Felix Meiner Verlag, Hamburg, 1999. – 1346 S. – ISBN 3–7873–1452–0 Literaturverzeichnis 97

[Sta02] Standard of Japan Electronics and Information Technology Industries Association: Exchangeable image file format for digital still cameras: Exif Version 2.2, April 2002

[vca96a] vCalendar - The Electronic Calendaring and Scheduling Exchange Format - Version 1.0. http://www.imc.org/pdi/pdiproddev.html. Version: September 1996

[vca96b] vCard - The Electronic Business Card - Version 2.1. http://www.imc.org/pdi/ pdiproddev.html. Version: September 1996

[Wei08] Weinberger, David: Everything Is Miscellaneous: The Power of the New Digital Disorder. Holt Paperbacks, 2008. – ISBN 978–0805088113

[Wit06] Wittgenstein, Ludwig: Philosophische Untersuchungen. Suhrkamp, 2006. – ISBN 978–3518223727

[Wor04a] World Wide Web Consortium (W3C): RDF Semantics, Februar 2004. http: //www.w3.org/TR/rdf-mt/

[Wor04b] World Wide Web Consortium (W3C): RDF/XML Syntax Spe- cification (Revised), Februar 2004. http://www.w3.org/TR/2004/ REC-rdf-syntax-grammar-20040210/

[Wor08] World Wide Web Consortium (W3C): SPARQL Query Language for RDF, Januar 2008. http://www.w3.org/TR/rdf-sparql-query/

[Xes08a] Xesam Project: XESAM Ontology 0.95, März 2008. http://xesam.org/main/ XesamOntology95

[Xes08b] Xesam Project: XESAM Specification 0.95, März 2008. http://xesam.org/ main/Xesam95 98 Literaturverzeichnis Glossar

Kürzel Beschreibung API Application Programming Interface 26

DDC Dewey Decimal Classification 18

EU Europäische Union6

FAT File Allocation Table 24

JFS Journaled File System 24

NFS Network File system 25

ORM Object Relational Mapper 86

RDF Resource Description Framework 35

SGI Silicon Graphics, Inc. 24 SQL Structured Query Language 71

W3C World Wide Web Consortium5 WQL Wittgenstein Query Languge 71 WWW World Wide Web6 100 Glossar Abbildungsverzeichnis

2.1 Ebenen von Ordungssystemen ...... 11 2.2 Bildung von Repräsentationen ...... 14 2.3 Datei interpretiert vom Browser ...... 16 2.4 Der Kategorienbaum, welcher die Dinge der Welt repräsentiert (simplifiziert) 17 2.5 Formenkategorien ...... 20 2.6 Eine beispielhafte „Tagcloud“ ...... 21 2.7 Der Tag „trip-hop“ beim Onlinedienst Last.fm ...... 22

3.1 Integrierte Desktop Search Engine im Dateiauswähldialog ...... 30 3.2 Ein digitales Foto in der Xesam Ontology ...... 32

4.1 Architektur des Wittgenstein Servers ...... 48 4.2 Übersicht der Klassen, die die Datenhaltung modellieren ...... 50 4.3 Die Beziehung von Resource und Property ...... 53 4.4 Die Datenstruktur zur Modellierung von Personen ...... 58 4.5 Die Datenstruktur zur Formulierung von Relationen ...... 61 4.6 Das Datenbankschema als ER-Diagramm ...... 64 4.7 Architektur der Metadatenscannerplugins ...... 79 4.8 Maske zum Hinzufügen von Objekten ...... 80 4.9 Maske zum Auslesen von Objekten ...... 81 4.10 Maske zum Anwenden von Relationen auf Objekte ...... 82 102 Abbildungsverzeichnis Listings

2.1 uninterpretierter Dateiinhalt ...... 15 2.2 interpretierter Dateiinhalt ...... 15

3.1 Die Relation „StudentX hat die Matrikelnummer 123456“ in RDF/XML . . . 36 104 Listings Tabellenverzeichnis

4.1 Beschreibung der Eingenschaften von Instanzen der Klasse Object, welche an ihre Unterklassen vererbt werden ...... 52 4.2 Beschreibung der Eingenschaften von Instanzen der Klasse Comment ..... 52 4.3 Auflistung der Typen von Resourceneigenschaften ...... 53 4.4 Beschreibung der Eingenschaften von Instanzen der Klasse Tag ...... 55 4.5 Beschreibung der Eingenschaften von Instanzen der Klasse Date ...... 56 4.6 Beschreibung der Eingenschaften von Instanzen der Klasse Place ...... 57 4.7 Beschreibung der Eingenschaften von Instanzen der Klasse Person ...... 59 4.8 Beschreibung der Eingenschaften von Instanzen der Klasse Artifact ..... 60 4.9 Beschreibung der Eingenschaften von Instanzen der Klasse Concept ..... 60 4.10 Beschreibung der Eingenschaften von Instanzen der Klasse Project ..... 60 4.11 Beschreibung der Eingenschaften von Instanzen der Klasse RelationDefinition 62 4.12 Beschreibung der Eingenschaften von Instanzen der Klasse EndpointDefinition 62 4.13 Beschreibung der Eingenschaften von Instanzen der Klasse Relation ..... 63 4.14 Beschreibung der Eingenschaften von Instanzen der Klasse EndpointLink .. 63 4.15 Beschreibung der Basisfunktionen der Client-API ...... 67 4.16 Beschreibung der Metafunktionen der Client-API ...... 67 4.17 Beschreibung der Shortcuts der CLient-API ...... 69 4.18 Beschreibung der zusätzlichen Funktionen der D-BUS-API ...... 70 4.19 gültige Schlüsselworte für die Typdeklaration einer Anfrage an Wittgenstein . 72 4.20 gültige Schlüsselworte für die Verknüpfung von Anfragekriterien ...... 72 4.21 Modifikatoren for Attributspezifikationen ...... 73 4.22 spezielle Verzeichnisse innerhalb der FUSE-Abstraktion ...... 76 4.23 Repräsentation der unterschiedlichen Objekttypen innerhalb der FUSE-Repräsentation 77

5.1 Liste der benötigten Softwarepakete ...... 89