[Xesam] RFC: Tags as first class objects

[Mikkel Kamstrup Erlandsen]

On 11/12/2007, Marko Anastasov <marko.anastasov at gmail.com> wrote:
>
> 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 [1]. I thought
> that
> tags are already defined as a content type, a subclass of Annotation.
> Could you explain?


Yeah, I can see the confusion :-) We also have a field xesam:userKeyword[1]
which is also described as a tag. I think the current state is ambiguous. It
would be a bit odd if apps both had to use Tag objects and userKeyword
fields to handle tags.

[1]: http://xesam.org/main/XesamOntology90#xesam:userKeyword

>
> >  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.


Good. Agreed.

[snip]
> > 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?


Hmm, I don't think that should up to the metadata store to decide (when tags
should be pruned).

Pruning empty tags also makes it impossible to map some metadata systems
like GMail, which perfectly fine handles empty tags.

>
> > 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)


Yes, you are right. Apps can easily work around this.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20071211/113de27a/attachment.html