Schon länger habe ich Diigo gesehen - und vor einigen Tagen habe ich mich dann angemeldet (ja, eine richtige Registrierung ist dank OpenID nicht nötig) und gleich meine Bookmarks von Del.icio.us importiert. Sehr schön ist, dass man mit Hilfe des Firefox-Plugins für Diigo gleichzeitig bei Del.icio.us (sowie weiteren Services) und Diigo seine Bookmarks speichern kann, so hat man für den Fall eines Falles ein Backup und kann außerdem jederzeit wieder zurückwechseln.

Wer schon einen Socialbookmarking-Service nutzt, wird sich fragen: Warum Diigo? Und wieso gleich Socialbookmarking 2.0? Diigo hat einige meiner Meinung nach sehr interessante Features, die andere Services eher nicht haben. Es gibt Benutzergruppen, Benutzergruppen von Websites und Tags, man kann Freunde definieren, Benutzer auf Grund von Tag- und Bookmark-Überschneidungen finden und last but not least kann man auf jeder Website Text markieren und Kommentare zu dieser Markierung allgemein hinterlassen, die auf Wunsch auch öffentlich sichtbar sind - vorausgesetzt, man hat die Erweiterung für Firefox installiert. Eine weitere Möglichkeit, Bookmarks zu verwalten und zu präsentieren sind Listen. Aus mehreren Bookmarks kann man eine Liste erstellen, man kann die Bookmarks auch sortieren und dann kann man die Liste als eine Art Präsentation ansehen. Innerhalb der Präsentation funktionieren die Markierungen und Kommentare auch ohne extra Plugin, von daher ist dieses Feature ideal, wenn man eine Tour durch seine Website oder seine Referenzen generieren möchte oder für ein Thema jemandem interessante Webseiten zeigen möchte. Auf Wunsch kann solch eine Präsentation sogar mit Musik unterlegt werden.

Um diesen Artikel nicht nur Werbung sein zu lassen möchte ich nun noch auf einige Schwächen/Probleme eingehen, die mir bis jetzt aufgefallen sind. Benutzt man die Erweiterung für Firefox, so sollte einem bewusst sein, dass Diigo jede URL, die man besucht, zu Gesicht bekommt, allerdings laut der Privacy Policy nicht speichert. Das gleichzeitige Speichern bei Del.icio.us bzw. anderen Services erfordert, dass man sein Passwort von diesem Service an Diigo weitergibt. Insgesamt sollte man Diigo also eine gute Portion Vertrauen entgegenbringen.

Auch die Tags sind meiner Meinung nach nicht so ausgereift, es gibt keine Möglichkeit, bei Tags eine kleine Beschreibung einzutragen wie bei Del.icio.us und auch das Gruppieren von Tags ist bislang nicht möglich.

Dennoch möchte ich auf Diigo nicht mehr verzichten, wie Werner Trotter schreibt ist es das Schweizer Messer für Wissensarbeiter und bei Recherchen ein unschätzbarer Helfer.

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.

Ich schrieb bereits öfters über meinen Plan, ein WikiBlog zu programmieren. Vielleicht auch zu oft, denn Tatsache ist, dass ich von einer Idee in die nächste kam und am Ende alles derartig kompliziert wurde, dass ich bis jetzt nur einen kleinen Teil unfertig umgesetzt habe. Und dies wird eventuell auch so bleiben.

Eher zufällig lernte ich in letzter Zeit DokuWiki kennen. Ich muss zugeben, als ich die ersten Websites mit DokuWiki sah, war ich nicht sehr begeistert, sie schienen mir immer gleich auszusehen und im allgemeinen nicht viel zu können. Diese Ansicht hat sich aber radikal geändert, als ich mich mehr mit DokuWiki beschäftigt habe. Nicht nur, dass man DokuWiki so gestalten kann, dass man auf den ersten Blick gar kein DokuWiki mehr erkennt, man kann es vielmehr auch so erweitern, dass es nicht nur ein Wiki sondern auch ein Blog mit allen Funktionen, die man sich nur denken kann, wird. Möglich wird dies durch ein Pluginsystem, das das Hinzufügen neuer Funktionalitäten ermöglicht.

Diese Website basiert jetzt auf DokuWiki und ist ein WikiBlog bzw. Bliki. D.h. es gibt hier Bereiche, die eher an ein Blog erinnern, während andere eher einem Wiki gleichen. Dazu gibt es Kommentare, Trackbacks und Tags. Es funktioniert noch nicht ganz alles so, wie es soll, die Tag-Übersicht geht in dem Sinne nicht, dass die Links nicht funktionieren. Ein eigenes Design fehlt ebenfalls noch und inhaltlich möchte ich auch noch einige Dinge ändern. Ich habe die mir wesentlich erscheinenden Inhalte aus meinem alten Blog kopiert, einige Inhalte, die ich in größerem Umfang ändern möchte, fehlen aber noch. Auch “richtige” RSS-Feeds muss ich noch einrichten, es wird in Zukunft aber auf jeden Fall Feeds mit den neusten Einträgen und den neuesten Kommentaren geben.

Ein Captcha ist dazu da, automatisch eingetragenen Spam zu verhindern, indem durch die Lösung von Aufgaben (meist dem Entziffern einiger Buchstaben und Zahlen aus einem Bild) sicher gestellt wird, dass der Benutzer ein Mensch ist (da die Aufgaben so konzipiert sind, dass sie von Computern nicht gelöst werden können oder es zumindest einen nicht wirtschaftlichen Aufwand benötigen würde).

Laut diesem Wikipedia - Artikel verbringen die Internetnutzer täglich zusammengerechnet rund 150.000 Stunden damit, solche Captchas zu lösen. Eigentlich eine Zeitverschwendung!

Das haben sich die Erfinder von reCAPTCHA wohl auch gedacht und deshalb kann man dort nun kostenlos Captchas bekommen zum Einbetten in die eigene Seite, die helfen, alte Bücher, die für das gemeinnützige Archiv Archive.org digitalisiert werden, zu entziffern.

Wie das ganze funktioniert? Eigentlich genial und zugleich sehr einfach. Diejenigen Wörter, die der Computer nicht eindeutig erkennen kann (das merkt er zum Glück), werden dem Benutzer in einem Bildchen präsentiert. Und zwar gleich zwei davon, wobei die Software bei einem davon bereits weiß, was das Wort heißen soll. Somit kann die Software zumindest bei dem einen kontrollieren, ob der Benutzer das richtige Wort erraten hat. Das andere Wort wird auch noch weiteren Benutzern vorgezeigt um sicherzustellen, dass das eingegebene Wort wirklich stimmt.

Damit das ganze nicht zu einfach wird für Computer, werden die Wörter zusätzlich noch mit einem variablen Strich durchgestrichen und außerdem etwas verzerrt. Damit auch blinde Benutzer nicht ausgeschlossen werden, gibt es auch noch eine Sprachvariante.

Um reCAPTCHA zu nutzen, gibt es nun mehrere Möglichkeiten: Man kann selber Funktionen programmieren, um auf reCAPTCHA zuzugreifen. Man kann aber auch Plugins für gängige Scriptsprachen verwenden. Und um es ganz einfach zu machen, gibt es für gängige Content Management Systeme und Blogs auch fertige Plugins, so dass man sich nur noch registrieren muss und einen Key (Schlüssel) für die Nutzung generieren muss. Falls für das eigene CMS auf der Seite nichts aufgeführt ist, einfach mal suchen, bei Drupal habe ich z.B. auch ein passendes Plugin gefunden (nein, das hier ist nicht Drupal, aber ich habe andere Seiten mit Drupal wo Spam durchaus ein Thema ist).

Eine super Sache also, ich denke ich werde das noch des öfteren einsetzen.

Via: reCAPTCHA: Buchstabenrätsel in nützlich | Gadgets Blog

Wie Jonathan Uhmann in der Waldorf-Googlegroup angekündigt hat, gibt es unter Waldorfportal.net eine neue Community für Menschen, die etwas mit der Waldorfschule zu tun haben - und zwar nicht nur für Schüler, sondern für alle - Schüler, Ehemalige, Eltern, Lehrer und auch nicht nur auf Deutschland zentriert, sondern gleich international.

Ganze 6 Benutzer sind schon angemeldet, darunter Jonathan selbst und ich. Wirklich viel zu sehen gibt es noch nicht, es ist im Moment eher ein Erkunden der Plattform. Denn so ganz reibungslos funktioniert noch nicht alles und wirklich intuitiv ist es auch nicht.

Es ist z.B. kein Hinweis zu finden, dass man in den Kommentaren HTML-Code verwenden muss und nicht einmal Zeilenumbrüche übernommen werden.

Aber man kann sich natürlich schon anmelden, Blog-Posts schreiben und Bilder, Audio-Dateien und Videos hochladen sowie Veranstaltungen ankündigen. Auch Benutzergruppen innerhalb dieses Waldorfnetzwerkes lassen sich anlegen und in Foren kann man diskutieren.

Jonathan hat viel vor, darunter ein neues Design sowie die Übersetzung der Seite und dann die Mehrsprachigkeit.

Wenn die schon angesprochenen “Kinderkrankheiten” verschwinden und die Seite aktiv genutzt wird, sicher eine super Sache. Man könnte für jede Schule eine Gruppe anlegen und dann innerhalb der Gruppe z.B. Veranstaltungen der Schule ankündigen wodurch auch die Vernetzung der Waldorfschüler untereinander besser würde und man könnte dadurch z.B. von den Klassenspielen und Jahresarbeiten benachbarter Schulen erfahren und sie besuchen.

[Edit 2008]Die Seite hat sich seit Mai 2007 nicht weiterentwickelt, mehr Benutzer/Aktivität gibt es auch nicht, ich würde das Projekt als gescheitert einstufen.[/EDIT]

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.

Wie an der Waldorfschule üblich, gab es auch bei mir in der 12. Klasse eine Jahresarbeit (mittlerweile wurde diese an meiner Schule in die 11. Klasse verschoben), eine ungefähr ein Jahr umfassende Arbeit (meist allerdings kürzer), in der sich der Schüler intensiv mit einem selbst gewählten Thema intensiv beschäftigt. Neben der obligatorischen theoretischen Arbeit und einer Präsentation ist dabei auch eine praktische Arbeit erwünscht. Ich habe mich für das Thema Webdesign entschieden.

Mit Webdesign habe ich mich zwar schon länger beschäftigt, vor der Jahresarbeit waren allerdings eher technische Probleme der Umsetzung das, womit ich mich beschäftigt habe. Doch Webdesign ist noch viel mehr als nur die Technik, bei Webdesign geht es ganz entscheidend um Design und Themen wie Gebrauchstauglichkeit und Barrierefreiheit. U.a. diese Themen machte ich zum Thema meiner Jahresarbeit, deshalb wählte ich auch den Untertitel “Wie gestalte ich eine Website so, dass sie optimal benutzbar ist?”. Ich habe im Rahmen meiner Jahresarbeit neben der theoretischen Ausarbeitung und einer Präsentation von 20 Minuten auch praktisch gearbeitet, indem ich u.a. die Website der Waldorf SV, der bundesweiten Waldorfschülervertretung, komplett neu gestaltet habe.

Die theoretische Ausarbeitung umfasst 70 Seiten und kann als 6,2 MB großes PDF heruntergeladen werden: webdesign.pdf.

Frau Professor Barbara Liskov hat eine interessante Idee: ein globales Speichersystem. Jede Datei liegt auf verschiedenen Servern, am besten verschlüsselt. Die Vorteile liegen auf der Hand: Die Datei ist von überall aus zugänglich und ist zudem vor Datenverlust geschützt, da sie nicht nur auf einem Server ist und die Server außerdem auf keinen Fall im gleichen Rechenzentrum stehen dürfen.

Doch es gibt natürlich auch Probleme: Die Daten dürfen z.B. nicht einfach plötzlich weg sein, weil die Firma, die dahinter steckt Pleite gemacht hat. Frau Liskov schlägt deshalb vor, die Daten von einem Konsortium verwalten zu lassen. Ein weiteres Problem stellt die Sicherheit vor Hacker-Angriffen und “bösen” Servern dar, die versuchen, in dem System Schaden anzurichten. Hierzu werden komplizierte Fehlervermeidungssysteme benötigt.

Insgesamt finde ich das ganze sehr interessant. Wenn die Internetanschlüsse wesentlich schneller wären (v.a. der Upload), fände ich solch ein System auf OpenSource-Basis gut. Ich stelle mir das ganze dann eher als P2P-System vor, d.h. statt Unternehmen Privatpersonen. Natürlich müssen alle vertraulichen Daten verschlüsselt werden. Die könnte z.B. mit einem Key funktionieren, den man auf Speicherstick dabei haben könnte, so dass das ganze portabel ist. Ein weiteres Problem ist natürlich, dass die Daten nicht manipuliert werden, ein Problem, dass auch Frau Liskov anspricht.

Geht man von einem P2P-System, so sollte dieses ein Geben und Nehmen sein, z.B. stellt man 10 GB zur Verfügung und bekommt dafür 2 GB Speicher zur Verfügung (alle Daten müssen ja mehrmals gespeichert werden, deshalb so viel weniger).

Ein derartiges System gibt es bereits, Freenet, wenn auch mit leicht anderer Zielsetzung. Die anonyme und zensurfreihe Verteilung von Informationen ist das Ziel von Freenet, doch die Verbreitung von Kinderpornografie ist die Folge. Somit ist es fragwürdig, ob der hier von mir skizzierte Gedanke wirklich umsetzbar ist oder ob hier nicht zu viel Missbrauch entsteht. Sicherlich ist es ein Unterschied, ob man nur selbst Zugriff auf seine Daten hat, oder auch andere, doch ich denke, das Problem wird bleiben.

Seit 2005 gibt es ein “Internetradio”, bzw. besser gesagt einen Flashplayer der neuen Art: Pandora - Aus ca 400 000 Musikstücken werden automatisch Musikstücke ausgewählt, die einem gefallen. Am Anfang gibt man ein Stück bzw. einen Künstler an, dies kann man später wiederholen um neue Richtungen mit in die Musik zu bringen. Ob einem ein Stück gefällt, teilt man der Software einfach mit. Jedes Stück ist mit vielfältigsten Attributen versehen und anhand dieser findet die Software andere Stücke, die einem ebenfalls gefallen könnten.

Das ganze ist kostenlos, nach einigen Songs muss man sich allerdings registrieren. Kostenlos bekommt man eine Version, die durch Werbung finanziert wird, gegen einen geringen Preis kann man die Werbung abschalten.

Aufgrund der Lizens kann man nicht unbedingt ein spezielles Lied einfach so abspielen, ein zurückspringen in der Playliste ist aus diesem Grund ebenfalls nicht möglich.

Seit Mai 2007 werden sämtliche Benutzer, die nicht aus den USA kommen, ausgeschlossen, ein Umgehen dieser Beschränkung ist allerdings mit Hilfe von einem Proxyserver möglich.

Eine auch in Deutschland verfügbare Alternative ist Last.fm, dort gibt es aber keine derartig umfangreiche Kategorisierung.

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.