We've been talking about using "supertags" for tagging things with
purposes other than using the tags as key words. They could be used for
display purposes, for example. Using a taxonomy would codify this
process rather than hacking on a kludgy solution like using tags that
looked like "display:sidebar" or something.
Moving to a taxonomy would also allow us the opportunity to augment the
system to provide (optional) hierarchical tags/categories.
Obviously, this is a large-ish structural change. Fortunately, it'll be
before our 1.0 release, so we shouldn't have big migration problems.
I'd like opinions on the transition, and volunteers for design and
implementation.
Owen
Chris
For starters, there need not be any differences. Applying a taxonomy
would allow the existing tag system to work just as it does. As far as
the API to access it, I suggest we keep what we have working, but make
it work with the database structures for the taxonomy instead of the
current tag2post system.
What a taxonomy would allow us to do in addition to that is have
additional characteristics that we could apply to posts or other objects.
Consider that we have a site that reviews software. Tags remain
keywords that are associated to posts. We might use "image" and
"editing" to tag a post about Photoshop. Tags are just one vertical of
categorization for posts. We could have another one, say "OS", that
would be used to describe specifically which operating systems the
post's software is relevant to.
A question you might ask is, "Why not just tag the post with 'Windows'
when it's Windows software instead of having a new tag type?" Because
you may talk about Windows in a post, but the post itself might not be
about Windows software. In that case, you could tag the post "Windows"
but use the OS "OSX.
This is a very simple example that I'm sure someone could imagine an
improvement for, but that is one potential use.
Additionally, if the taxonomy was coded to support it, the terms could
have relationships. A taxonomy term could be a parent or child of
another term, and API access would allow you to retrieve results based
on that relationship.
Also, because you could create multiple sets of these things, you could
associate them to any object in the system. You could have a set of
terms that relate to comments, for example. Your "comment" set of terms
could include terms like "insightful", "interesting", "informative", and
"funny", which you could use to tag your own comments.
There are many places that the taxonomy could be applied. I expect
plugins to fill that role using a well-implemented taxonomy API and
documentation.
Owen
A change to a taxonomy system shouldn't affect the current tag
interface. Plugins could implement other taxonomies, and their UIs,
and that's likely where interesting things will happen.
I wouldn't mind a tag suggest plugin to help me avoid similar but
different tags but that's got nothing to do with changing to a
taxonomy.
I am against adding any further tagging UI overhead to core.
> What do you think of entering tags in the way I described previously?
>
> Ultimately it would be possible to tag a post... os:linux:"debian
> etch" or "operating system":"mac os x":leopard
Personally, I would not use this. Hierarchical categories just get
confusing and broken and hurt my little brain.
cheers, Michael
The existing tag functionality would (hopefully) not be affected from
either the API or UI perspectives. Additional functionality would be
available for plugins to take advantage of for providing the UI you
described.
I think that people's preferences are going to be so varied on how this
works from that point of view that the only way to address it is to
allow plugins to evolve and choose the fittest for inclusion as
optionally-available core plugins.
Owen