[Xesam] RFC: Tags as first class objects

[Mikkel Kamstrup Erlandsen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20071210/a6641913/attachment.htm