[Xesam] RFC: Tags as first class objects
marko.anastasov at gmail.com
Tue Dec 11 01:46:47 PST 2007
On Dec 10, 2007 8:42 AM, Mikkel Kamstrup Erlandsen
<mikkel.kamstrup at gmail.com> wrote:
> 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:
It seems that I don't quite understand the specification . I thought that
tags are already defined as a content type, a subclass of Annotation.
Could you explain?
> 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.
This already works (in the web development world) and would be best I think,
while the rest would be complications without substantial benefits.
> 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
Again, this is perfectly fine IMO. In any case, as soon as something becomes
an object, you need to query for some property.
> 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 disagree about tags that do not apply to any files. I think that as soon
as a tag's assign count becomes zero, it should be removed from the
metadata store. The user does not see it any more, and probably does
not need it, and should re-enter it again if necessary. It would seem like
metadata junk that grows without user's knowledge - when would you
say that a store should delete them?
> 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).
I'm not totally sure what you mean whose task this should be (server's?),
but anyway U2 is easily solvable by a little bit of application logic (get all
files by content type, sort by tags)
More information about the Xesam