The core problem, which gives rise to the wish for a feature like tags on a modern desktop, is that file systems, the Kernel VFS in particular, are incapable of gluing metadata to files.

The power of tags to bring some kind of order to a set of data in a convenient and intuitive way can be seen in a lot of web applications. The use of tags in GMail, for instance, constitutes an unprecedented break with the limitations of sorting files in folders. The usual way of sorting files in a folder-hierarchy (taxonomy) is time-consuming and still not satisfying, because it is often not clear which single folder e.g. a mail should be assigned to.

This leads to an unsatisfying lack of organization.

While it is obviously an asset to use tags to organize mails one could pose the question why one should not use the same principle to organize files. In fact, the use of tags could be a leap forward for the organization of files at least as big as for the organization of e.g. mails (or bookmarks, photos etc. like in other Web2.0 applications).


On the GNOME Desktop there already exists the concept of emblems. They are either user-defined symbols or live-metadata(read-only, link etc.) which are represented together with the icon of the file or folder in Nautilus.
It is unfortunate that at present the user-assigned emblems are not usable and retrievable by other programs.
It is equally unfortunate that conceptually there is no difference between a user-defined and a live-metadata emblem.

Adding the concept of tagging, which is pretty close to what emblems are today, one can end up in the following scenario:

Emblems will be the visual representation of tags as well as of live-metadata. As one neither wants to represent every tag nor all live-metadata as an emblem it should be kept flexible (perhaps user-defined) which of those actually lead to a graphical representation in the interface.

In this way the meaning of an emblem will not be ambiguous any more. Tags and live-metadata are not the same, whereas before both somehow constituted emblems. An emblem will become the sole representation of those on the UI side.

The storage of tags should be implemented using GIO/GVFS and the project would put its first focus on the implementation of tags on the GVFS side. Secondly, the concept described above, emblems being a visual representation of live-metadata and tags, would be implemented.

Then, depending on the time left, some of the ideas of how to handle tagging and emblems on the user interface side could be implemented. It would be interesting to look at how to design a dialog/tool for connecting tags with an emblem, the integration in the GTK+ File Chooser/Save dialog or the accessibility of tags to desktop retrieval tools.