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.
so könnten die tags mit ihren Zugangsrechten verknüpft und nur für autorisierte Zugriffe verfügbar werden. Man könnte mit dieser Methode jegliche Information benutzergruppenspezifisch darstellen, also an ihr Realitätsbild angepasst + Könnte man eventuell ein automatisches Tagging System einrichten dass es dem Benutzer vereinfacht die Unmenge an Informationen mit für ihn sinnvollen Tags zu versehen. Wenn ja, wäre die Sicherheitsfrage in diesem System besonders wichtig, da diese Software praktisch wissen muss wie der Benutzer lebt und die Welt sieht. Ein Spielraum für Gedanken zu diesem Thema bietet auch die Bionik, im Sinne der Programmierung von Softwarekomponenten die wie organische Zellen funktionieren. So könnte man ein Systemmodell des Lebens des Benutzers als Vorlage für das automatische Taggingsystem erstellen und als DNA in einem Software Zellkern schützen. Dieser gibt nur die aktuell benötigten Informationen als RNA frei die von der geschlossenen Software zur Erstellung von benutzerspezifischen Tag-Netzwerken im Sinne der Tätigkeit von Ribosomen benutzt werden. Puh, ich hoffe das war jetzt nicht zu abstrakt ;) Wissensgebiete zu Vernetzen wird denke ich für solch eine komplexe Idee wie Tagging Systeme unerlässlich sein.
nur falls noch nicht bekannt: http://de.wikipedia.org/wiki/Assoziative_Dateiverwaltung . Zur Dateiverwaltung würde ich ein virtuelles Neuronales Netzwerk vorschlagen, dass durch Relationsgewichtung angeforderte Information sucht und darstellt.
Erst einmal vielen Dank für die Anregungen, nein, den Begriff "Assoziative Dateiverwaltung" kannte ich noch nicht. Das Problem, wenn man Tags mehrdimensional macht, ist, dass es recht schwierig wird, das in einem Dateisystem darzustellen. Okay, natürlich kann man z.B. in jedem Ordner eine Datei _meta haben, in der in einem Format wie [[wpde>YAML]] diese Meta-Informationen abgelegt sind. Doch was, wenn eine Datei _meta heißt? Ich bin mittlerweile sehr am Zweifeln, ob ein Dateisystem wirklich geeignet ist, um alle Tagging-Informationen und -Aktionen abzubilden. Alleine die Tatsache, dass tausende Ordner und Dateien existieren werden in jedem Verzeichnis bereitet vielen Programmen Probleme bzw. führt zu Wartezeiten, da Programme davon ausgehen, dass alle Dateien dargestellt werden können. Manche lesen sogar alle Dateien erst einmal (oder zumindest einige Header-Informationen dieser Dateien). Ich denke, mit einem herkömmlichen Dateimanager lässt sich ein Tagging-Dateisystem schwer bedienen. Dennoch bin ich überzeugt, dass die Basisfunktionalität auch in einem Dateisystem dargestellt sein sollte, um kompatibel zu bleiben. Eine andere Frage ist das automatische Tagging. Natürlich kann man den Inhalt analysieren und dass ID3-Tags oder EXIF-Header ausgelesen werden ist klar. Doch das ganze muss immer unter der Kontrolle des Benutzers bleiben. Und wie das möglich ist, ist mir noch ein Rätsel. Ich denke bei allem, das über sehr einfache Tags hinaus geht benötigt man eine spezielle Tagging-Software, die einem z.B. Tags vorschlägt oder Vorschläge für existierende Dateien unterbreitet und zum Akzeptieren vorlegt. Zur Realisierung: In KDE 4 kann man mit dem Dateimanager [[wp>Dolphin_(software)|Dolphin]] Dateien taggen. Das System basiert auf Nepomuk (Networked Environment for Personalized, Ontology-based Management of Unified Knowledge). Die Tags, die Dolphin unterstützt, entsprechen allerdings bei weitem nicht dem, was ich mir vorstelle. Doch Nepomuk kann noch viel mehr, wie auch [[http://www.kdedevelopers.org/node/3382|dieses Projekt]] zeigt. Schaut man sich im Wiki von Nepomuk um, merkt man dass dort schon sehr viel existiert, z.B. [[http://dev.nepomuk.semanticdesktop.org/wiki/LocalDataAlignment|Local Data Alignment]], d.h. das Vorschlagen von Verknüpfungen von Informationen oder [[http://dev.nepomuk.semanticdesktop.org/wiki/UserWorkContext|User Work Context]], d.h. das Analysieren dessen, was der Benutzer gerade macht. Mir fehlt aber noch sehr der Überblick, was Nepomuk genau ist und wie man es nutzen kann. Es gibt eine Java- und C++-API und viele hoch spannend klingende Features, aber ob es damit möglich wäre, solch ein "Dateisystem" zu bauen ist mir nicht klar. Eine andere Frage die bei dieser ganzen Diskussion um einen semantischen Desktop bei mir auch immer wieder aufkommt, ist die, ob solch ein semantischer Desktop überhaupt wünschenswert ist. Ich denke wenn, nur in einer sehr automatisierten Version. Im Prinzip müsste solch ein Desktop ja jedes Programm umfassen. D.h. eine eingehende Mail müsste automatisch getaggt werden, der Absender erfasst werden, sofern noch nicht geschehen, usw. Denn von Hand will so etwas, glaube ich, niemand erfassen. Ich schwanke im Moment zwischen einer Minimallösung, wie sie Stratus (siehe oben) implementiert und einer Lösung eines komplexen semantischen Desktops. Auch die Ansätze von [[wpde>Plan_9_(Betriebssystem)|Plan 9]] finde ich diesem Zusammenhang sehr interessant, wenn man z.B. E-Mails oder Kontakte als Dateien/Verzeichnisse repräsentiert werden, könnte man da auch mit einem Tagging-Dateisystem sehr viel leichter ansetzen.
Ich bin vor kurzen auch auf die Idee zur umsetzung eines "assoziativen Dateisystems" gekommen. Meine Idee war jedoch das ganze mit einer Online-Datenbank zu verknüpfen (wiki-ähnlich) in der die Tags zu Dateien eingetragen werden. Außerdem können Dateien zu Packeten zusammengefasst werden, die ein hirarchisches Dateisystem simmulieren. So umgeht man einige Probleme und verhindert, dass unwichtige Dateien angezeigt werden. Ich möcht jetzt nicht alle Dateils erläutern, da die bisherige Planung 20 Seiten umfasst. Wenn du interresse hast ein solches Programm umzusetzen, melde dich doch einfach bei mir. Ansonsten werde ich mir vielleicht ein paar deiner Ansätze noch klauen
Hallo Michael, Ich beschäftige mich schon seit längerem mit diesem "Thema" und greife es auch immer wieder selber auf. Leider fehlt mir aktuell selber die zeit dazu etwas vernünftiges umzusetzen. Meine hoffnung liegt daher im moment immer noch darin dass ich auf etwas existierendes finde (für linux) Eine schöne, gelungene und funktionierende Implementierung findet man in DESKWORK -> http://www.deskwork.de/INFOS/LCARS.HTM . Mein ansatz war bislang auf FUSE basis ein equvalent zu deskworks lcars zu schaffen. (ja alle trekis schreien nun auf ;), aber es ist wirklich gut und funktioniert auch so) Naja das ist jedenfals mein kommend dazu, ich hoffe es kann dir weiterhelfen oder dich zumindest noch zu problemlösungen Inspirieren. MfG Sascha
Danke für die Anregungen, ich bin zwar nach wie vor am Thema interessiert, verfolge das ganze aber momentan nicht mehr so intensiv. Interessant in letzter Zeit war auch noch http://the-gay-bar.com/index.php?/archives/283-Konzeption-und-Entwicklung-einer-semantikbasierten-Managementschicht-fuer-Dateisysteme/ - das scheint mir eigentlich genau das richtige zu sein, wenn der Code dann mal fertig wird.
[...] Ideen für ein Tag-Dateisystem [...]
Hallo, ich habe auch schon oft ueber ein "tagged file system" nachgedacht. M.E. sollte die Implementierung recht simpel sein: a) Eine flache Dateistrucktur, also keine Dateiverzeichnisse mehr. Systemdateien koennten trotzdem noch in anderen Verzeichnissen liegen. Jede Datei bekommte eine UID vor den Namen. Das Rechtesystem (Benutzer und Gruppen) bleibt bestehen. b) Eine Datenbankschicht zur Indexierung und Suche. Hier werden auch UID, Metadaten und Tags fuer jede Datei gespeichert. Eine API bildet die Schnittstelle zum Betriebssystem. c) Eine Praesentationsschicht, sozusagen der Dateibrowser. Zur Navigation wuerde ich persoenlich Tag-Clouds favorisieren, die dann mit den Metadaten kombiniert werden koennen. Aehnlich der aktuellen Suchmechanismen bei eBay und Amazon. Diese Implementierung koennte sogar auf einem bestehenden Dateisystem aufsetzt. Oder habe ich etwas uebersehen?! Bitte gebt mir bescheid, wenn jmnd. ein Implementierungsprojekt startet :) Viele Gruesse, Felix
Hallo, ich habe noch etwas vergessen zu sagen: Ich denke, dass man bei diesem Ansatz nicht versuchen darf die Tags an die Datei zu speichern, sondern nur die Metadaten, da nur diese fuer jeden zutreffen und allgemein uebersetzt werden koennen. Metadaten sind objektive Angaben zur Datei und Tags sind subjektive, persoenliche Assoziierungen mit der Datei. Gruss, Felix
Hallo, bin gerade durch Zufall auf diesen sehr interessanten Beitrag gestossen. Wir beschäftigen ins im Zuge unserer Betriebssystem-Vorlesung (Wirtschaftsinformatik Studium) intensiv mit Dateisystemen und sollen im Rahmen einer Belegearbeit auch etwas in die Richtung Dateisysteme entwickeln. Wohin unsere Richtung genau geht, ist noch offen, aber deinen Tag-Dateisystem Ansatz finde ich interessant, eventuell realisierne wir was in dieser Richtung. Aber unter "Probleme" hast du ja schon Sachen angesprochen, die m. E. eine große Hürde darstellen, vorallem wenn es um den Austausch von (getaggten) Dateien mit anderen geht. Gruß, Fabian
Hi! Ich arbeite hier in Graz an meiner Dissertation, die sich exakt mit dem Problem hier beschäftigt. Im Rahmen dessen entwickle ich mit Studenten eine Forschungsplattform, mit der man prototypenhaft Aspekte rund um das Thema Assoziative Datenhaltung erforschen kann. Diese Implementierung nennt sich tagstore und wird unter der GPL freigegeben werden. Die erste brauchbare Version wird es ab Herbst 2010 geben. Gleich mal vorweg: unsere Implementierung von tagstore ist *nicht* als "Produkt" oder entgültige Lösung gedacht! Unserer Meinung nach ist es zwingend erforderlich, dass die Funktionalität in das Betriebssystem *und* das Dateisystem einfliesst. Die Grundzüge von tagstore kann man unter https://intra.ist.tugraz.at/trac/tagstore/wiki/AboutTagstore und https://intra.ist.tugraz.at/trac/tagstore/wiki/ProjectConstraints durchlesen. Nur kurz: ich beschäftige mich damit, dem Benutzer beim Navigieren (im Gegensatz oder besser als Ergänzung zur Desktopsuche) eine Methode in die Hand zu geben, damit er/sie an die Dateien kommt, ohne wissen zu müssen, wo sie liegen. Das bedeutet im ersten Schritt: single user, single system. Als Folge unseres Leitsatzes der Transparenz werden wir keine Datenbank einsetzen. Wir wollen das Ziel erreichen, dass man Otto Normaluser das Tool (zum Testen) in die Hand geben kann. Unter Linux, OS X und Windows (ab Vista). Vorhandene Desktopsuchmaschinen, Backupmechanismen, vorhandenes Wissen des Benutzers (Kopieren auf USB-Stick) kann weiterhin und unverändert benutzt werden. Dinge wie FUSE usw. kann ich zum Beispiel meinen Eltern auch nicht zumuten. Ein User kann potentiell mehrere tagstores parallel einsetzen. Denkbar sind Gebiete, die sich nicht oder nur kaum überlagern wie "Beruf" und "Privat". Es werden nur Benutzer-generierte Items (können Dateien als auch Verzeichnisse sein) in einem tagstore abgelegt. Es handelt sich also um Sub-Hierarchien in seinem HOME. In der ersten Basisversion: In einem bestimmten Verzeichnis (eines pro tagstore) werden mit beliebigen Programmen neue Dateien abgelegt. Der Benutzer erspart sich also das Suchen eines Zielverzeichnisses. Danach kommt automatisch ein Fenster, wo der Benutzer Schlagwörter vergeben kann. Aufgrund unserer technischen Realisierung ist hier die Anzahl auf <=5 beschränkt. Usability-Dinge wie automatische Vervollständigung bekannter Tags gehören ebenso dazu wie (in Zukunft) ein Recommender-System für Tags. Ab diesem Zeitpunkt wird von tagstore ein automatisch verwaltetes Verzeichnissystem aus Symlinks bereitgestellt, wo der Benutzer auf vielen Wegen zu ein und desselben Item hinnavigieren kann. Egal, welchen Dateibrowser er/sie bevorzugt. Wenn ein item "Ideen.txt" mit den Tags "Uni, Diss, 2read" verschlagwortet werden, kommt der Benutzer über die Verzeichnisse Uni, Diss oder 2read direkt zur Datei. Aber auch über alle möglichen Kombinationen davon: Diss/2read Uni/Diss Diss/Uni/2read ... Doppelte Dateinamen sind bei uns nicht zugelassen: pro tagstore kann ein Dateiname nur ein einziges Mal vorkommen. Da es sich um 100% User-Content handelt, wird das hoffentlich ein untergeordnetes Problem darstellen: es gibt also keine fünf Dateien Namens "Readme". Mehrere Dateisysteme: ausserhalb eines tagstores ändert sich nichts. Wenn der Benutzer eine Datei aus einem tagstore kopiert, "verliert" die Datei ausserhalb die Infos über die Tags. Spezielle Tags: die Benutzer können sich eigene Reminder-Tags ausdenken wie zum Beispiel das "2read" von oben. Tags haben im Kopf vom Benutzer verschiedene Funktionen: reminder-tags, descriptor-tags, categorizer-tags, ... Synonyme muss der Benutzer auch selbst aufdecken. Wir hoffen, mit Tagvervollständigung und Recommendersystemen Synonyme weitgehend zu verhindern. Wir werden hier Forschungsarbeit investieren. Speichern in ein bestimmtes Verzeichnis innerhalb der Tag-Hierarchie soll in späterer Folge zu einem automatischen Ablegen unter diesen Schlagworten führen. Aber das ist eine erweiterte Version und so wie es aussieht, können wir das unter Windows technisch nicht ordentlich realisieren. Sicherheit ist für tagstore (vorerst) kein Thema. Single user/single system sollte dieses Thema aber auf die üblichen Betriebssystemmechanismen abschieben können. Implementierung: da wir mit exzessiven Verlinken arbeiten, haben wir (wenige) technische Limits für unsere Forschungsplattform. Wie gesagt: wir erforschen Benutzerverhalten und Benutzerwünsche mit tagstore, damit in Zukunft die Funktionalität ordentlich in Betriebssysteme und Dateisysteme Einzug hält. Fürs Erste schaut unsere technische Realisierung aber durchaus praxistauglich aus, wenn man die Tags pro Item und die Gesamtanzahl der Items pro tagstore beschränkt (einige tausend sollten kein Problem sein). Wir beschäftigen uns nicht mit Semantik. Ich denke, das ist ein völlig anderer Ansatz, der langfristig erstrebenswert ist. Die Ergebnisse bislang haben mich aber ernüchtert. Sinnvoll einsetzen kann man Semantik in der Dateiablage nicht. Hier müsste man alle Datei öffnen/speichern-Dialoge ändern, alle Dateibrowser neu implementieren usw. Bei tagstore kann man alle seine Applikationen weiterhin verwenden und bekommt eine neue Möglichkeit der Navigation in die Hand gedrückt, die als Ergänzung zur Desktopsuche assiziatives Wiederfinden in Abhängigkeit des *momentanen* geistigen Kontextes ermöglicht. Wer mit uns diskutieren möchte, als Testuser für tagstore sich bereitstellen will, Ideen in unser Projekt einfliessen will, ... der möge sich unter tagstore@IST.TUGraz.at melden! Ich bin auch (ab sofort) im IRC (freenode) unter novoid im #tagstore erreichbar und schaue immer wieder rein.
@karl voit wow, ich bin gespannt. ich denke so eine dateiverwaltung stösst sicher auf grossen anklang. hoffentlich kommts bald raus ;)
[…] Ideen für ein Tag-Dateisystem […]
Konnte mir das jetzt nicht alles durchlesen... Was ist mit NTFS und Streams? F3 sagt, die wurden hier nicht genannt. Bin da eben über pcwDescribe von PC Welt drauf gekommen: http://www.pcwelt.de/ratgeber/Schlagwortsuche-ueber-NTFS-Streams-1215746.html
Ich grüble auch seit längerem über Tagging-Systeme und finde deinen Ansatz sehr gut. Meine Programmier/OS Kenntnisse sind zwar äußerst begrenzt, aber die Möglichkeiten die solche Systeme bieten könnten sind einfach überwältigend. Zwei kleine Anregungen meinerseits: + wie wäre es tags mit metainformation zu versehen; also tags von tags in n-Dimensionen.