On Thu, 24 May 2007 at 11:04 PM, Josh Street (of michaeldale.com.au) wrote Can you solve the tagging problem everyone (read:WordPress core team) seems to struggle with? Categories are easy, tagging (in a high-performance, scalable kind of way) seems to be a little harder. I'm a little interested as to why you feel compelled to do this from scratch... learning experience or genuine competitor to existing things? PHP5 rocks socks. 1: Comment Link

On Fri, 25 May 2007 at 9:30 AM, Stuart (of michaeldale.com.au) wrote If you're starting a Bluetrait 2, I want to start redesigning the Admin Panel to make it suit the new Bluetrait.org design that's ready to implement. Talk to me some time. 2: Comment Link

On Fri, 25 May 2007 at 10:09 AM, Michael Dale (of michaeldale.com.au) wrote I haven't yet looked into how I'm going to handle categories. Although the following link should help: Managing Hierarchical Data in MySQL.

I don't really understand the technical difference between tags and categories. They seem pretty similar to me. Tags are kind of like meta data for your post(s) were as categories have a bit more structure to them.

I have a project hopefully coming up that will make use of categories. Although I don't think I needs tags just yet.

I'm writing this from scratch as I've learnt heaps since I started Bluetrait. There is too much old code for me easily upgrade everything.

In terms of competition, I don't think any of the current CMS/blog tools do what I want. I've decided I need something that is closer to a CMS than a blog.

And Stuart I'd love to see the design stuff you've got in mind. 3: Comment Link

On Sun, 27 May 2007 at 3:18 PM, Josh Street (of michaeldale.com.au) wrote Tags are like categories only there are lots more of them. On personal (1-user) sites it's not a big deal (because performance doesn't matter), and on enormous (millions of user) sites it's not a big deal (because it's automatically more efficient from unintentional re-use of tags, plus there are generally more resources to go around). For the in-between sites, it seems... potentially problematic. You either define each tag in a separate record (with potentially more records for metadata than for actual data!), or store them with the record they describe as comma separated keywords (or whatever), in which case your searching *should* become lots less efficient (opening all records to return only a few). Yeah, write operations are more intensive, so option 2 seems better... but for mid-sized usage scenarios the proportion of tags to content could rapidly become absurd -- and, consequently, any tagging metadata will potentially become less useful the more abstractly related they are to one another. Large usage deals with this by volume of tagging and the 'burying' effect (observed with user ranking of feedback on Slashdot, Digg, etc.)... but where less users are contributing (measured in users per item of content), I'm really not as certain about tagging's benefits. It offers an exciting way to traverse related information that conventional 'search' may not, but where there's a low user:contributor ratio it may be self-defeating. Tagging works great because it achieves 'consensus' in keywords in large communities, not by establishing conventions (e.g. I am viewing this website on a: monitor/screen/display/lcd/crt - choose one and one only to tag this article with), but by fulfilling them _all_ in a way that _is never going to happen_ in a smaller environment. And I know you didn't suggest tagging, but I'm still curious about that vs. categories. Cool reasoning re: why from scratch. I'm intrigued by the observation that none can do what you want, but okay! Ever looked at ExpressionEngine? I'm considering it for some future adventures because it's a little heavier. My number-1 blocking feature is Akismet support, but even that's been taken care of... so it'll be getting a workout on the next small-medium sized site I get my teeth into! 4: Comment Link

On Sun, 27 May 2007 at 6:19 PM, Michael Dale (of michaeldale.com.au) wrote I spent a few hours the other day working out how I'm going to cope with categories.

You either define each tag in a separate record....or store them with the record they describe as comma separated keywords....option 2 seems better...

Not sure if I agree with you there. Why? How often do you post a comment verse how often does a user go through categories/tags. Personally I don't think it matters all that much about how long it takes to insert the new tag. Because you're only dealing with a really small amount of data (compared to that in the database). Plus you can easily setup two mysql servers, one for read, one for write. My plan with categories is to have full breadcrumb/search features. The plan being to have heaps of sub categories that you can browse through. Back on to the topic of tags. I think it would be difficult to sort tags based on how popular they are with your second approach. With a tags_to_posts table it is a very simple count query. I do think your second way would be quick for displaying a single post (or the posts on your front page), but I don't think it would be significant enough to justify it. I've decided to use this category library for Bluetrait 2. Although I think I'll need to rewrite most of it. 5: Comment Link