<div>On 11/12/2007, Marko Anastasov <<a href="mailto:marko.anastasov@gmail.com">marko.anastasov@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Dec 10, 2007 8:42 AM, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> 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?</blockquote><div> 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. </div> [1]: <a href="http://xesam.org/main/XesamOntology90#xesam:userKeyword">http://xesam.org/main/XesamOntology90#xesam:userKeyword</a> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > >  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.</blockquote><div> Good. Agreed. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> [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?</blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > > 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)</blockquote><div> Yes, you are right. Apps can easily work around this. </div> Cheers, Mikkel </div>