As it stands tags/keywords are just a multi valued string fields. The intend of this post is discuss converting tags to first class objects. The idea is that we have a Tag content type subclassing Annotation, to assign a tag to an item we have three options:  1) Let the tag point at all tagged items, by having a field with a list of item urls. This is bad for deletions. If you delete a file we have to check and update all tags accordingly which can very expensive.  2) Let the items point at the tags that they have assigned by having a field with a list of tag urls. Deletions is no problem here (deletions of tags are of course expensive, but is an uncommon operation). The tricky thing here is to get the display titles for the tags since you only have the urls of the assigned tags available. Solutions to this problem could be    2.1) Accept that apps must query for the xesam:title field of each of the found tags and manually do the tag->tag_name mapping for each item    2.2) Encode the tag name in the URL in a predefined manner. URLs are not indexed/searchable as it stands which means that we have to introduce an "indexed URL" field data type to make it possible to search by tag names.   2.3) Having a duplicate field listing the names of the assigned tags. This is problematic since we do not have ordered lists thus we cannot map it canonically to the urls listed in the field containing the tag urls.  3) Bidirectional links. Ie tags point at the tagged items, and items point the assigned tags. This gives all the above benefits and problems, except that it becomes cheap to delete if you do reverse lookups. It incurs a synchronization overhead and the possibility for the tags to become inconsistent if there is the slightest glitch in the server. Some use cases that we want to keep in mind (in random order):  U1) Show all files with a given tag  U2) Show all files without a tag  U3) List all files (matching a query) with the tag names next to each file  U4) Deletions/modifications/renaming of tags and files should be light (mostly del/mod of files)  U5) It should be possible to have a tag without any files associated (not possible with the current tag-as-a-field model) I think I would go for solution 2.1. This solves all use cases but U2 (maybe it does solve U2, but I just haven't figured out how). Cheers, Mikkel