[Tagdb] Over tagging fields?

[Michal Migurski]

> Some of this depends on your application - tagging authors seems to  
> be a different
> application concept than tagging books although in the database  
> they are just entities.

Tagging entities may be a good way to think about it, though. Type of  
entity (author, book, publisher) might be a way to narrow the search,  
but it's not an important detail when the tagging action is taking  
place. Rashmi Sinha wrote a nice piece a few months ago about the  
cognitive cost of tagging (http://www.rashmisinha.com/archives/05_09/ 
tagging-cognitive.html) which argued that the benefits over  
traditional classification stemmed from the rapid-fire activation of  
mental concepts that are immediately recorded as tags. If this is the  
real benefit to tags, then it makes sense to let users tag  
everything, and have the database sort it out. "Iain M. Banks"?  
"Scottish", "SciFi", "Culture". "Excession"? "SciFi", "Culture",  
"GSV". And so on. The tags DB only gets better as more free  
associations are dumped into it.

Personally, I've found that using separate tag pools makes sense when  
there's some behavioral or social reason to do so. For example,  
Reblog (dot org, a feed-reading app that supports fast republishing  
of interesting stuff) has two kinds of tags, for feeds and entries.  
We don't merge them, because the the feed tags are typically used as  
input filters while the entry tags are used to annotate republished  
entries. Feed tags: "A-List", "Favorites", "Provisional". This is not  
stuff you may want your readership to see. Item tags: "Funny",  
"Python", "Politics". These are used just like tags in Del.icio.us,  
and aid everyone's search rather than just your own.

So... yeah. It depends on how conceptually distinct authors and books  
are, the way your app defines them. =)

-mike.

----------------------------------------------------------------
michal migurski- contact info and pgp key:
sf/ca            http://mike.teczno.com/contact.html