[Tagdb] tags in separate table

[toxi]

Zbigniew Lukasiak wrote:
> Hi,
> 
> I have one question - what is the advantage of having a separate table
> for tags.  Lets assume we agree that we have separate tables for users
> and links, and we have a table for the connection users, links and
> tags.  Then why should I have a separate table for the tags instead of
> using them literally in the table (ie. instead of representing them as
> a foreign key put the whole text of the tag into the field).

hi, for the past few months i've been working on a tagging system
using a 3 table schema and i've found it to give me more flexibility
in terms of editing (renaming, deleting) and organizing tags than
using only a column to store tags together with each item:

in my system, i've got:

N tables storing different types of content
1 table storing tags (and their properties)
1 table storing tag<->content<->content type relationships
1 table storing nested tag bundle relationships

storing tags in an individual table allows me to assign them more
properties in future. so far this is only used for identifying "tag
bundles", but in future i'm thinking about adding additional
(internally used) properties to support thesaurus-like functionality
(similar to SKOS: http://www.w3.org/TR/swbp-thesaurus-pubguide/) or
even being able to assign callbacks/controller functions to execute
special transformations for individual tags when doing a tag search...

maybe an example is helpful: the website in question is a curated
online archive of audio-visual art. for various political reasons i
don't want to get into now, we're only using a narrow folksonomy
(like flickr does) - but this is actually besides the point... we've
introduced tags and a RESTful API to enable commissioned artists to
create alternative user interfaces to browse the collection.

one of my ideas was to browse the collection by colour, so when
doing a tag search for "red", i also would like to retrieve items
matching this tag visually, but are not literally tagged "red". the
idea is to assign special properties to the tags "red", "blue",
"green", "orange" and other colours, with the property values
representing HSB colour values. I'd also assign an interceptor
handler to these colour tags in order to dynamically broaden the
"red" search to related colours, based on their HSB distance and so
being able to also find items tagged "rose", "burgundy" or "orange"...

i hope this makes some sense without a more practical example. i
just believe in encapsulating data to stay more flexible for future
demands and keeping tags separate is along the same general idea,
even if it's possibly not the 100% fastest solution.

hth! toxi.
-- 
http://toxi.co.uk/