Als im Februar der Social Bookmark Service Taggle.de von Mister Wong übernommen wurde, habe ich mir einige Gedanken darüber gemacht, was mir Social Bookmarks bringen, was ich da will und was ich mit meinen ca. 600 Bookmarks, die ich dort gesammelt hatte, machen will.

Hm, zuerst einmal, wie ich zu Taggle.de gekommen bin - Martin Mündlein hat mich persönlich auf Grund eines Eintrages hier im Blog angeschrieben. Obwohl mich die Qualität des HTML-Codes von Taggle.de eher abgeschreckt hat, habe ich mich daraufhin entschlossen, mich zu registrieren. Vor allem deshalb, weil ich bei Taggle.de sehr interessante Bookmarks gefunden habe. Auf der Startseite waren sehr oft Links zu Web2.0-bezogenen Themen zu finden, sogar das Wort Web2.0, das ich davor noch gar nicht kann, habe ich auf diese Weiße kennen gelernt. Auch auf Anfragen nach Features wurde schnell reagiert, wenn auch nicht alles Versprochene umgesetzt wurde. Auch dass Taggle.de ein Studentenprojekt und nicht primär von einer Firma war, fand ich gut. Klar, technisch war es nicht der Hit, es gab zwei Mal - so weit ich mich erinnern kann - einen längeren Ausfall, die Tag-Vervollständigung war bei meinen vielen Tags nicht mehr wirklich schneller als das Tippen bzw. das Tippen wurde durch sie sehr erschwert, aber dennoch fand ich einfach sozusagen die Community gut.

Möchte ich überhaupt Social Bookmarks? Also mir ist klar:

• ich möchte auf die Bookmarks von überall aus zugreifen können
• ich möchte meine Bookmarks auch anderen zeigen können
• ich möchte Tags
• der Service sollte einigermaßen gut erreichbar sein (Ausfälle/Geschwindigkeit)

Doch was bringt mir jetzt ein Social Bookmarks-Service gegenüber einer Applikation die auf meinem Webspace läuft (wie z.B. Scuttle)? Hm, ich sehe, wie populär ein Link ist - doch das interessiert mich eigentlich wenig und es hat auch nur bei den großen Seiten wie del.icio.us wirklich ein wenig Relevanz. Aber etwas anderes ist es: ich sehe, welche Tags andere dieser Seite gegeben haben. Und das finde ich echt praktisch, denn es erleichtert einem das Bookmarken ziemlich.

Meine Entscheidung fiel letzten Endes zu Gunsten von del.icio.us und gegen Mister Wong, auch wenn ich mir dort auch erstmal einen Account erstellt und meine Bookmarks importiert habe.

Weshalb del.icio.us? Zum einen ist es dort sehr wahrscheinlich, dass jemand die Seite schon einmal gebookmarkt hat und deshalb bereits schon Tags vorhanden sind. Zum anderen ist ein Ausfall der Seite recht unwahrscheinlich. Außerdem gibt es für del.icio.us für sehr viele Programme (auch Blog-Systeme) Plugins, mit denen man del.icio.us integrieren kann. Scuttle würde diese API, die hier Verwendung findet, auch anbieten, da spielt aber dann die Community die entscheidende Rolle in meiner Entscheidung zu. Was mich letzten Endes überzeugt hat, war der Ruby-wmii Bookmark Manager - ich setzte davor bereits wmii mit der Ruby-Konfiguration ein und hatte das ganze somit schon installiert - und so habe ich nun eine immer (alle 30 Minuten) aktuelle Kopie meiner Bookmarks auf dem PC (d.h. ein aktuelles Backup, ich habe also meine Bookmarks auch zur Verfügung wenn del.icio.us/mein Account mal nicht erreichbar sein sollte) und komme über ein Tastenkürzel sehr schnell an meine sehr schnell und super durchsuchbaren Bookmarks dran - echt klasse! Und zum Hinzufügen klicke ich auf den passenden Button in Firefox und kann die vielen Tags der anderen Benutzer nutzen - auch Klasse! Und ganz am Schluss nun noch ein Link zu meinem Account bei del.icio.us.

Wie u.a. auf TechCrunch zu lesen ist, gibt es mit Moopz nach NoiseRiver und mioNews (und anderen?) jetzt einen weiteren Dienst, der es sich zur Aufgabe gemacht hat, das, was es unter FriendFeed bereits zu sehen gibt, in einer übersichtlicheren Form aufzuarbeiten.

Das besondere an Moopz ist die starke Konzentration auf URLs. Alle Einträge zu einer URL werden bei dieser angezeigt, zusätzlich dazu gibt es einen Auszug aus der verlinkten Seite und automatisch gesetzte Tags. Somit sieht man die selbe URL nicht x Mal, sehr wohl aber trotzdem alle Kommentare zu ihr.

Derzeit gibt es einen Auszug aus den Posts bei FriendFeed, er wird aus den Konversationen einiger Benutzer zusammengesetzt (und meldet man sich an, so werden wohl auch die eigenen hinzugefügt) und ist auf bereits “aktive” Einträge beschränkt, d.h. solche, zu denen es bereits Kommentare gibt. Eine Ansicht, die nur die Einträge der eigenen Freunde zeigt, wie es auf FriendFeed Standard ist, gibt es derzeit noch nicht, ist aber prinzipiell geplant.

Ich denke Moopz geht genau in die richtige Richtung, automatische Tags hatte Oliver Gassner hier ja schon einmal in den Kommentaren erwähnt und ich habe einige Ideen dazu geschrieben - und genau so etwas macht Moopz im Prinzip. Einen Feed, der die URLs und Tags enthält, gibt es sogar auch schon. Jetzt fehlt eigentlich nur noch, dass man den Filter nach Aktivität abschwächen oder ausschalten kann und auf Wunsch ausschließlich oder hauptsächlich die Einträge der eigenen Kontakte angezeigt werden.

Oder: warum ich für URLs lieber Diigo/del.icio.us statt Twitter verwende.

Ohne Zweifel: Twitter mag nett sein, um zu sehen, was andere gerade machen. Und man kann natürlich auch weiter in die Vergangenheit schauen. Und wenn man etwas suchen will, benutzt man die Suche. Doch eines fehlt: systematisches Wiederfinden. Ich muss sagen, ich möchte eine URL, die ich heute finde, morgen wieder finden. Und genau dafür sind Tags wie geschaffen - wenn man sie systematisch benutzt. Ich kann mir nicht ernsthaft vorstellen, dass Twitter-Nachrichten von vor einigen Monaten noch ernsthaft jemanden interessieren (es sei denn, er forscht). Dagegen interessieren mich auch noch Bookmarks von vor einigen Jahren.

Ein weiteres Beispiel: Ich suche eine Software für BibTeX. Egal was, einfach alles, von Import über Verwaltung bis Verwendung. Eine kurze Suche bei del.icio.us nach Bookmarks mit den beiden Tags fördert eigentlich alles zu Tage, was man sich nur wünschen kann. Eine suche bei Google findet potenziell mehr. Aber potenziell auch viel mehr Inhalt, der überhaupt nicht dem entspricht, was ich eigentlich wollte. Generell gilt, je allgemeiner die Suchbegriffe, desto schwieriger wird es. Auch wenn man nach speziellen Kriterien sucht, z.B. eine Software für GNOME, kommen einem Tags sehr zu gute. Allgemein kann man natürlich sagen, dass man über Socialbookmarking-Dienste weniger Seiten findet als über eine herkömmliche Suche. Aber es gilt auch: Was man findet, ist sehr, sehr hochwertig.

Jetzt fehlt eigentlich nur, dass es eine Suchmaschine gibt, die all diese Tags extrahiert und durchsuchbar macht, so dass man nicht nur Tags von del.icio.us hat, sondern von allen möglichen Seiten. Das Mittel der Wahl lautet natürlich: RDF. Wie ich sehe gibt es so etwas schon (wenn auch ohne RDF), in der Form von http://tagcentral.net - allerdings seeehr langsaaam und die Ergebnisse der einzelnen Quellen werden getrennt präsentiert.

Ich habe eine interessante Studie zum Thema Can Social Bookmarking Improve Web Search? gefunden, generelles Fazit ist, wie ich auch schon festgestellt habe, dass es natürlich etwas wenig URLs gibt. Interessant ist auch die Feststellung, dass Tags häufig Stichworten im Inhalt entspricht. Aus meiner Erfahrung heraus muss ich sagen, das stimmt natürlich, aber oft sind derartige Stichworte auch in anderen Inhalten zu finden, die gar nichts mit dem Stichwort als solches zu tun haben. Genau hier sehe ich den Vorteil von Tags. Tags sind allermeist sehr gut auf den Inhalt der verlinkten Seite zugeschnitten und können auf Grund der Vielzahl an Benutzern den Inhalt besser kategorisieren als reine (Inhalts)Stichwörter. Noch einmal zum Beispiel der Software-Suche. Häufig gibt es Seiten mit der Beschreibung einer Software, aber ohne die Information, unter welcher Lizenz diese steht. Ein Benutzer, der ein Bookmark erstellt, könnte aber z.B. das Tag GPL hinzufügen - ein Vorgang, der bei einer herkömmlichen Suchmaschine sehr schwierig wäre.

Um zum Untertitel zurückzukommen: Warum muss ich URLs bei Twitter posten, als Tinyurl, wo man weder sieht, wohin die URL führt noch Popularität oder dergleichen feststellbar ist? Ist das nicht ein riesiger Rückschritt? Warum kann man nicht einfach del.icio.us in der Art wie Twitter verwenden? Oder wie bei Diigo, wo man sogar Kommentare auf der Seite selbst hinterlassen kann, man in der Sidebar direkt sieht, welche Kommentare hinterlassen wurde, wer die Seite noch gespeichert hat und wer alles Seiten dieser Domain gespeichert hat?

FriendFeed scheint da schon besser zu sein, dort kann man Bookmarks (u.a. via del.icio.us) direkt importieren, doch hier fehlen auch bei del.icio.us-Feeds die Tags vollständig. Warum werden Tags derartig wenig beachtet, wo sie doch eine derartig geniale Organisationsmethode darstellen? Irgendwie ist mir das ein echtes Rätsel.

Ich bin ein Fan von Socialbookmarks, u.a. auch wegen der genialen Möglichkeiten, die Tags bieten. Seit einer Weile nutze ich auch Google Reader um RSS-Feeds diverser Websites zu lesen. Google Reader bietet die Möglichkeit, Artikel zu taggen und auch Artikel wieder zu veröffentlichen. Ich finde es allerdings schade, dass ich jetzt zwei verschiedene Orte mit Artikeln habe - den Feedreader und die Socialbookmarks.

Wie ich berichtete nutze ich mittlerweile Diigo.com und als ich heute diesen Artikel über die neuen Share-Features in Google Reader las, fühlte ich mich sehr an Diigo erinnert. Es ist nun möglich, Websites ohne Feeds oder ohne abonnierten Feed via Google Reader wieder zu veröffentlichen oder auch Notizen zu veröffentlichen. Moment mal, hat Google nicht bereits einen Bookmark-Dienst und ein Notebook, in dem man Ausschnitte aus Websites speichern und auch veröffentlichen kann? Irgendwie scheint mir das mal wieder typisch zu sein: Es gibt tausend Services, der eine hat dieses Feature, der andere das andere. Und auch mit Diigo.com kann ich bereits jetzt Ausschnitte aus Websites direkt markieren, speichern und in meinen Bookmarks veröffentlichen. Natürlich mit Kommentar und Posting in Gruppen, Organisation in Listen usw..

Warum hat noch keiner der mir bekannten Socialbookmarking-Dienste RSS-Feeds für sich entdeckt? Ein Feedreader in Diigo wäre meiner Meinung nach die Vollendung eines genialen Recherche-Tools. Wer einen derartigen Dienst erstellt (oder falls es einen solchen bereits gibt) kann mit meiner Mitgliedschaft und Dankbarkeit rechnen (sofern auch die anderen Features stimmen).

Das Semantische Web soll die Zukunft sein - maschinenlesbare Daten sind das Ziel (bzw. sind teilweise schon umgesetzt). RDF ist dabei ein wichtiger Standard, da hiermit praktisch beliebige Daten abgebildet werden können. Was liegt also näher, eine RDF-basierte Speicherlösung als Backend für eine Web-Applikation zu verwenden?

Genau dies macht Semanlink bei Bookmarks. Leider nicht sozial, es geht nur für eine Person. Außerdem ist Semanlink in Java geschrieben und basiert auf Apache Tomcat und das ist leider nicht ganz einfach zu installieren/einzurichten.

Netterweise hat Semanlink die Möglichkeit, Daten von del.icio.us zu importieren, so konnte ich gleich mit meinen über 1000 Bookmarks starten. Begeistert hat mich v.a. die Möglichkeit, Beziehungen zwischen Tags anzulegen. D.h. man kann Beziehungen mit Vater/Kind-Beziehungen oder auch Aliase anlegen und so sehr sinnvoll sowohl Tags als auch dann die dazugehörigen Bookmarks gruppieren.

Weniger positiv überzeugt war ich von der Benutzeroberfläche, zwar gibt es eine schnelle Suche für Tags, doch zum Hinzufügen ist dann ein weitere Klick auf den Link und die Bestätigung eines Dialogfensters nötig, dann wird die Seite neu geladen. Das ist irgendwie nicht ganz das, was man von Ajax erwartet.

Davon abgesehen kann man beliebige RDF-Statements hinzufügen, sowohl bei Tags als auch bei Bookmarks. Doch nur Bookmarks ist eigentlich falsch, denn Semanlink kann auch Notizen verwalten und auch Dateien im Dateisystem. Letzteres habe ich so gut wie gar nicht probiert, es dürfte allerdings, von dem was ich gesehen habe her, ebenfalls nicht viel anders bei den Bookmarks sein, auch wenn Semanlink die Verzeichnisinhalte anzeigt und man die Dateinamen somit nicht von Hand eingeben muss. Eine Integration in den Dateimanager wie bei Dolphin (KDE) wäre hier doch eher wünschenswert oder auch die Umsetzung von Ideen wie ich sie in Ideen für ein Tag-Dateisystem beschreibe.

Gespeichert wird alles in RDF-Dateien, die bei den Dateien sogar direkt im Verzeichnis über den Dateien liegen so dass auch das Verschieben von Verzeichnissen kein größeres Problem darstellen soll.

Man kann sich jetzt natürlich fragen: RDF-Dateien als Datenspeicher für mehrere tausend Bookmarks - funktioniert das? Nunja, natürlich nicht im direkten Zugriff, aber Semanlink liest diese Dateien auch nur beim Start, dann hat es sämtliche (RDF-)Daten im RAM - das wirkt sich natürlich auf dessen Verbrauch aus, führt aber zu einer recht guten Performance.

Ich habe mich mittlerweile wieder von Semanlink verabschiedet, da mir zum einen die soziale Komponente gefehlt hat und ich zum anderen recht negative Erfahrungen gemacht habe, als ich die Zugriffsrechte für das Datenverzeichnis unabsichtlich geändert hatte und Semanlink so keine Daten mehr speichern konnte, dies aber nirgends angezeigt hat. Dank Browser - History ließen sich die Bookmarks zwar wieder auffinden, aber irgendwie war das dann einfach der Anlass, doch wieder zu del.icio.us zurückzukehren - bei dieser Gelegenheit durfte ich übrigens erfahren, dass die Synchronisation von Semanlink zu del.icio.us irgendwie nicht so zuverlässig funktioniert, wie umgekehrt - jedenfalls war am Ende keines meiner neuen Bookmarks bei del.icio.us angekommen.

Ich denke aber auf jeden Fall, dass der Ansatz sehr gut ist und mit einer besseren Benutzeroberfläche und einer sozialen Komponente definitiv zukunftsträchtig ist. Die Daten sind übrigens auch über die Benutzeroberfläche als RDF verfügbar, somit wäre es durchaus möglich an diese mit anderen Applikationen anzuknüpfen.

Schon sehr lange beschäftigt mich die Idee des Taggens von allem, d.h. auch von Dateien in einem Dateisystem. Bereits vor einem Jahr hatte ich eigentlich schon die Ideen dafür. Doch eines Abends habe ich sie zusammen mit rretzbach im IRC diskutiert. Es war sehr interessant und wir haben viele Probleme und teilweise auch ganz gute Lösungen dafür gefunden.

Hinweis: Dieser Artikel ist im Prinzip nicht auf Linux begrenzt, aber sämtliche Beispiele beziehen sich auf Linux oder ein Unix-artiges System.

Verzeichnisse im Dateisystem werden durch Tags ersetzt. Denn Verzeichnisebenen konstruieren um Dateien zu sortieren ist immer sehr schwierig. Und wie es uns die Bookmarks beweisen, geht das mit Tags wesentlich einfacher. Warum also nicht einfach Verzeichnisse durch Tags ersetzen? Dabei bräuchte man natürlich ein neues Dateisystem, dass statt Verzeichnissen Tags unterstützt. Dadurch sollten im Idealfall alle bisherigen Programme weiter funktionieren, ohne dass man auf die neuen Tagging-Funktionen verzichten müsste. Ein paar Beispiele:

ls /foto/2006/urlaub/

listet alle Fotos auf, die man 2006 im Urlaub gemacht hat. Das exakt selbe Ergebnis liefert

ls /urlaub/2006/foto/

. D.h. es wird intern nach Dateien, die mit foto, urlaub und 2006 getagt sind, gesucht. Sucht man Konfigurationsdateien für den Webserver Apache, macht man einfach

ls /apache/config/

. Mit

ls /

bekommt man alle Tags und alle Verzeichnisse aufgelistet. Auch in ein Verzeichnis wechseln sollte gehen, man kommt dann einfach in ein virtuelles Verzeichnis.

Vorhandene Meta-Daten wie bei Photos das Kamera-Modell oder bei Musik die Band oder das Album sollten natürlich ebenfalls gleich in Tags umgewandelt werden.

Die Tags sollten dabei zum eine in einer Zentralen Datenbank im Dateisystem gespeichert werden und zum anderen direkt bei der Datei. Hierfür könnte man z.B. IIM verwenden. Dadurch könnten die Tags auch z.B. bei Bildern, die man von Diensten wie Flickr herunterlädt, dabei sein oder Dateien, die man per Mail erhält oder bei einer Software dabei sind, sind bereits fertig getagt. Dadurch wäre natürlich auch bei einem Crash des Dateisystem nicht alles verloren.

Tags verstehe ich hierbei als freie, beliebige Schlüsselwörter, also kein festes, bereits festgelegtes Kategoriensystem. Welche Probleme das ergibt, darauf komme ich später noch einmal zurück.

Auch sogenannte Action-Tags wären natürlich möglich, d.h. dass man Tags wie action:to_read oder action:to_test vergibt und einsetzt, um seine Arbeit effizienter zu gestalten.

Dann kam natürlich gleich die Frage: Warum gibt es das denn noch nicht? Ist das wirklich so schwierig? Weil bis zu diesem Zeitpunkt hatten wir noch kaum Probleme gefunden, höchstens, dass es vielleicht ein wenig viele Dateien sind, die man im obersten Verzeichnis aufgelistet bekommt, aber naja, das bekommt man mit Caching schon in den Griff. Doch nach und nach vielen uns dann immer mehr Probleme ein.

Und einen Tag später habe ich auch noch einige Implementierungen gefunden! Weiter unten mehr dazu, jetzt erst einmal unsere Gedanken dazu:

Auf einem System wird man verständlicherweise mehrere README-Dateien haben, eben von unterschiedlichen Programmen. Spricht man jetzt solch eine Datei mit dem Tags des Programms davor an, also z.B. bei Apache

cat /apache/README

, ist ja alles kein Problem. Doch was für eine Datei bekomme ich, wenn ich

cat /README

mache? Oder wie reagiert ein Programm, wenn plötzlich in einem Verzeichnis mehrere Dateien mit dem gleichen Namen liegen?

Für dieses Problem kamen uns gleich mehrere Ideen, die mehr oder weniger sinnvoll sind. Also z.B. doppelte Dateien werden in Verzeichnis-listings ausgeblendet oder sie werden zu einem Tag/Verzeichnis, nur was ist dann in dem Tag/Verzeichnis? Okay, also keine mögliche Lösung. Dann könnte man natürlich das Prinzip von P2P-Applikationen aufgreifen und statt Dateinamen zumindest mal intern Hash-Summen verwenden. Dies würde geniale caching-Systeme ermöglichen. Z.B. sagt einem der Web-Server die Hash-Summe der Datei, die er jetzt losschicken will und dann prüft der Browser einfach kurz, ob sie schon lokal existiert und wenn ja, wird die lokale Version verwendet. Doch in dieser Hinsicht waren wir uns einig, dass dies ebenfalls keine Lösung darstellt, da die Menge an Hash-Summen kleiner ist als die Menge der verschiedenen Dateien.

Man könnte natürlich jede Datei gleich einmal mit der Seriennummer des Gerätes taggen, auf dem sie erstellt wird und noch das Datum dazu speichern. Dann könnte man sie schon einmal eindeutig identifizieren. Doch leider kann man darüber auch den Urheber identifizieren, was er dann wohl doch nicht will. Also auch keine Möglichkeit. Und was ist, wenn man 10 Dateien mit dem gleichen Namen per Mail bekommt und sie nicht getagt sind? Okay, dann könnte man sie nach dem Sender taggen. Einziges Problem: das müsste das Mailprogramm können, dann müsste man das ganze Betriebssystem und alle Applikationen verändern.

Und jetzt die Lösung des Problems, die wir gefunden haben: Bekommt das Dateisystem eine Datei zum ersten Mal zu sehen, bekommt sie eine einmalige ID, also z.B. einfach eine fortlaufende Zahl. Kommt bei einer Suchanfrage mehr als eine Datei mit dem gleichen Namen vor, wird einfach die ID hinten dran gehängt. Dabei ist die neueste Datei eines Namens ohne ID und wird als solche dann auch direkt aufgerufen wenn man sie anspricht, also z.B. bei

cat /README

bekommt man die neueste README-Datei. Dies ist sinnvoll, da man meist die neueste möchte, da man die Software z.B. gerade neu heruntergeladen hat.

In einem typischen System hat man leider nicht nur ein Dateisystem, sondern mehrere. Als Lösung sollte jedes Dateisystem, das in einem System eingehängt wird, eine ID bzw. einen Namen bekommen, also z.B. den Gerätenamen. Jede Datei, die dieses spezial-Tag hat, ist auf diesem Gerät. Also nehmen wir mal an, das Tag heißt device:sda1. Wollen wir jetzt alle Bilder mit den Tags Urlaub und 2006 dorthin kopieren, machen wir einfach

cp /urlaub/foto/2006/* /device:sda1

. Die anderen Tags der Dateien werden natürlich ebenfalls übernommen. Beim Speichern sollte dies genauso funktionieren. Gibt man kein Gerät an, sollte es ein default-device geben.

Doch kann man überhaupt so einfach die Dateisysteme zusammenfügen? Ist es überhaupt möglich, die beiden Datenbanken so einfach zu kombinieren und dann bei Suchanfragen beide zu verwenden? Das weiß ich leider nicht. Ein weiteres Problem wäre: Wie weit soll die Software erkennen, dass zwei Dateien auf unterschiedlichen Dateisystemen den gleichen Inhalt haben? Soll sie automatisch einen bit-für-bit-Vergleich machen, wenn Dateiname, Zeitstempel, Tags und Größe übereinstimmen? Oder wertet sie das automatisch als Gleicheit?

Bisher gibt es rekursive Funktionen, die also z.B. alle Dateien in einem Verzeichnis inklusive der Unterverzeichnisse löscht. So etwas würde dann in dem Tag-Dateisystem unweigerlich zu Fehlern führen. Für einen Lösungsvorschlag fehlt mir aber die nötige Kenntnis der genauen Funktionsweise dieser rekursiven Anweisungen.

Es wäre schön, wenn folgendes Funktionieren würde:

ls /image/jpg/width>=1280/

. Die Software müsste dafür Meta-Daten wie die eben benutzte Breite speichern. Dann sollte sie >= etc. in entsprechende Datenbankanfragen umwandeln. Im Prinzip sollte dies möglich sein.

Tags kommen aus Bereichen, in denen es nicht darauf ankommt, ob man einen bestimmten Eintrag findet der eben z.B. mit photo statt foto getagt wurde. Doch in einem Dateisystem sieht das leider anders aus. Hierfür müsste man also eine Alias-Funktion haben. Außerdem verwenden verschiedene Menschen Tags oft vollkommen unterschiedlich, man hat also auch ein Problem, wenn man von anderen Menschen getagte Dateien verwendet.

Auch die Sprache stellt ein Problem dar: Was ist, wenn man englische Tags bekommt, selber aber immer deutsche Tags verwendet? Also z.B. image statt bild. Tags können auch mehrdeutig sein. Apple bezeichnet z.B. sowohl einen Apfel als auch eine Firma. Somit müsste es deutsche Tags mit de: als Prefix geben, englische mit en: (und natürlich alle weiteren Sprachen) und internationale, z.B. mit int: als Prefix. Und jetzt muss man alle Tags mit Prefix benutzen und eine Übersetzungstabelle machen? Vermutlich ja. Man kann ja eine default-Sprache haben, so dass man nicht bei jedem Tag immer den Sprachcode eintippen muss.

Wie kann man eine Datei mit einem Tag ausstatten, das man noch nie benutzt hat? Okay, man kann ein neues Verzeichnis anlegen und die Datei da hinein speichern. Jetzt muss aber das Dateisystem irgendwie mit diesem leeren Tag umgehen können und es darf nicht dazu kommen, dass Müll entsteht. Von daher würde ich vorschlagen, dass ein mkdir, also das anlegen eines neuen Verzeichnisses, dazu führt, dass dieses Tag für 5 Minuten erzeugt wird und in dieser Zeit überall angezeigt wird (also in jedem anderen Tag/Verzeichnis). Sobald eine Datei dem Tag zugewiesen wird, wird es zu einem normalen Tag. Wird keine Datei zugewiesen, verschwindet das Tag nach 5 Minuten wieder.

Mit Tags bekommen wir ein großes Sicherheitsproblem. Was z.B., wenn Dateien absichtlich falsch getagt werden? Wir werden auf jeden Fall Berechtigungen für Tags und für einzelne Dateien brauchen. D.h. wer z.B. eine Datei sehen darf! Denn bisher kann man z.B. nicht einmal sehen, welche Dateien ein anderer Benutzer hat. Dateien, die ein User nicht lesen darf sollten deshalb gar nicht erst in Listings erscheinen. Und selbstverständlich sollten Tags, die ausschließlich solche Dateien enthalten gar nicht erst angezeigt werden. Dies hat natürlich als Folge, dass die Datenbankabfragen wesentlich komplexer werden. Die Gafahr von Sicherheitslücken im Tagging-System sind damit natürlich auch nicht kleiner.

Ein normaler User sollte natürlich auch nicht eine Datei xyz als Config für Apache taggen dürfen, die dieser dann verwendet. Wie man dies lösen kann, ist mir allerdings noch ein Rätsel, denn der User könnte durchaus eine Apache-Config für seinen privaten Webserver haben. Vielleicht sollte man die Dateisysteme für User-Daten und für System-Daten wirklich komplett trennen. Oder man hat ein spezielles system-Tag, das geschützt ist (also nur von root verwendet werden darf und mit dem nur Dateien getagt sein dürfen, die root gehören).

Wie man vielleicht schon gemerkt hat, ist mein Traum, dass das ganze als Dateisystem implementiert wird, das man einfach in den Linux Kernel einfügen kann und keine weiteren Veränderungern benötigt. Da ich von derartiger low-level-Programmierung noch kaum Ahnung habe, kann ich das ganze zumindest im Moment nicht selber bauen. Wenn aber jemand anderes Interesse hätte, die Ideen umzusetzen, wäre ich sehr dankbar und erfreut und diese Ideen, die ich hier geäußert habe, dürfen selbstverständlich gerne verwendet werden.

Hier möchte ich kurz alle mir bekannten Implementierungen vorstellen, weitere dürfen gerne in den Kommentaren ergänzt werden.

• openomy ist ein online-Dateisystem, das Tags statt Ordner verwendet und auch eine API bereitstellt. Wie weit das Projekt ist und was es alles kann weiß ich aber nicht und ich habe es auch noch nicht getestet.

• TagFS - Schwer zu sagen, ich verstehe nicht ganz, was dieses Projekt macht. Einerseits gibt es eine Simulation, andererseits spricht er von einer Integration in das Betriebssystem und bietet Code zum Download an, der auf openomy aufsetzt. Insgesamt sieht das Projekt sehr jung aus.

• tag ist ein Perl-Script, das aber nur Verzeichnisse und Symlinks erstellt, um Tags zu erzeugen. Meiner Meinung ist dieses Konzept zum Scheitern verurteilt bzw. nur in sehr kleinem Rahmen einsetzbar, da man bereits bei 5 Tags 325 Symlinks erhält und diese Zahl bei mehr Tags sehr stark ansteigt. Außerdem funktioniert das Taggen nur mit diesem Script, also nicht mit jedem anderen Programm.

• Von der Uni Koblenz gibt es eine Publikation zu dem Thema, die aber leider nicht als Download verfügbar scheint.

• gnowsis ist eine ganze Desktop-Umgebung vom deutschen Forschungszentrum für Künstliche Intelligenz, die anscheined auch Tagging können soll, mehr ist mir aber nicht bekannt. Es enthält auf jeden Fall ein Framework, dass das lokale Dateisystem (und das Internet?) crawlen kann und Meta-Daten extrahiert.

• Stratus ist meiner Meinung nach das vielversprechendste Projekt. Es setzt auf FUSE und eine Datenbank (SQLite). Das verfügbare Release wurde am 16. August 2006 erstellt. Ich habe mal kurz einen Blick auf den Code geworfen (624 Zeilen inklusive Kommentare, Perl), es sieht recht gut aus und arbeitet wirklich mit mehreren Datenbanktabellen und speichert Tags und Dateien getrennt mit einer Verknüpfungstabelle. Mit dem Problem von doppelten Dateinamen will sich das Projekt in Zukunft befassen.

Die Wikipedia über Folksonomy:

Folksonomy, auch als “Tagging” oder “Social Bookmarking” bekannt, ist ein Neologismus für die Kategorisierung von Informationen durch ihre Benutzer. Umgangssprachlich wird der Begriff auf Gruppen von Personen angewandt, die sich zu diesem Zweck spontan in offenen Gemeinschaften zusammenfinden und ihre Ergebnisse untereinander zugänglich machen.

Meiner Meinung nach ist Folksonomy eine der größten Errungenschaften des Computertechnologie, da so Informationen wirklich effizient verwaltet werden können und man nicht mehr mühseligst eine Ordnerstruktur entwerfen muss, die am Ende doch nichts taugt und man so z.B. Produkte sowohl unter den Firmen als auch unter dem Produkttyp einordnen kann, was vorher nicht möglich war bzw. nur mit “doppelten Listen” möglich war.

Ein wesentlicher Unterschied ist, dass die Daten nicht von Experten oder den Autoren kategorisiert werden, sondern dass die Benutzer es selbst machen und dadurch auch die Wörter verwendet werden, die die User selbst suchen würden wodurch die Suche wesentlich besser wird. Außerdem wird dadurch, dass man nicht erst in einem hochkomplexem Kategorien-System durchsteigen muss, sondern einfach die Tags nehmen kann, die man für sinnvoll hält, die Hemmschwelle zum sich beteiligen wesentlich kleiner.

Auch eine Art Kommunikation kann über Tags stattfinden. Dies kann z.B. so aussehen, dass ein Benutzer ein bestimmtes Tag erstmals benutzt, ein anderer User dies sieht und dieses Tag auch benutzt und es z.B. einer anderen Website oder einem anderen Bild etc. zuordnet. Dadurch sind die Tags auch sehr dynamisch. Es ergibt sich aber auch eine gewisse Stetigkeit, da man meist die häufigsten Tags sieht und sich so an diesen orientieren kann. Interessant ist auch zu sehen, was andere User einem Tag zugeordnet haben, das man gerade verwendet und so zu entscheiden, ob dieses Tag zu dem Inhalt passt, den man gerade kategorisieren will.

So hat Folksonomy einen sehr sozialen Aspekt, aber auch das Individium kommt zum Ausdruck durch die individuelle Wahl der Tags und Tags wie z.B. toread (noch zu lesen).

Allerdings hat Folksonomy auch Nachteile, v.a. dadurch, dass dadurch, dass es keine vorgegebenen Tags gibt, sehr oft entweder zwei Tags das Selbe bedeuten (z.B. Blume und Blumen oder Weblog und Blog) oder ein und das selbe Tag unterschiedliche Bedeutungen haben kann (z.B. Apple - Apfel und die Computerfirma Apple).

Websites mit Tags sind aber auch sehr interessant zum Suchen, da man oft Inhalte findet, die man so nicht unbedingt erwartet hätte, die aber trotzdem sehr interessant sein können.