Out of the box WordPress comes with a fairly small set of hard-baked object types which don’t necessarily map particularly well to the semantic web:

• pages
• posts
• comments
• links
• users
• tags, categories and link categories.

The options for relating things have been pretty limited:

• posts can be related to tags and categories
• links can be related to link categories
• users and posts can have metadata but no out of the box display for this.

Taxonomies

As of WordPress 2.3 the database schema changed to introduce “taxonomies”. This involved a rejigging of the way categories and tags were stored and related. This allowed for the creation of custom realtionships to be made. ie. it is possible to create custom relationship types such as “is a”, “studied”, “likes”, etc. This allows for much richer metadata to be produced. Out of the box taxonomies are not available to WordPress users but plugin developers are able to use the new data structures to come up with something better than what is available with tags and categories.

Check out these two posts explaining the changes

• Tip #5 : Taxonomy in WordPress 2.3
• WordPress 2.3 Taxonomy Schema

This all looks promising. However, I was a bit disappointed with the way things had been implemented in the backend. To me it seems that some less than optimal decision were made.

The thoughts that follow are a result of looking at the DB schema only. I have not peered into the code or am aware of the background for making the decisions that were made.

The old WordPress had the following tables:

• categories
• post2cat
• link2cat

The new WordPress has factored these replaced them with three new tables:

wp_terms
term_id
name
slug

wp_term_taxonomy
term_taxonomy_id
term_id
taxonomy
description
parent
count

wp_term_relationships
object_id
term_taxonomy_id

Please read WordPress 2.3 Taxonomy Schema for a better understanding of how the above three tables work together. I will make a few points at this stage.

• the terms table handles names and slugs for category, link_category and post_tag. The slug provides the unique index. This design seems very strange to me as we have three namespaces (category, link_category and post_tag) which are being constrained by a single slug namespace. It therefore seems impossible to have the same slug represent different concepts (or names) across namespaces. eg /category/max (the “max” size) and /tag/Max (the “Max” person). The schema just smooshes the namespaces together, limiting expressiveness. This might be acceptable if there were only one namespace but there isn’t. This makes me a bit concerned about renaming things. If one term is forming double duty for a tag and a category, then the rename of one will knock onto the other.
• naming duties are split between wp_terms and wp_term_taxanomy. Why does wp_terms get name and slug, and
  wp_term_taxonomy get description? Weird. I can’t see the benefit of the wp_terms table. One argument for it might be that wp_terms is there to handle duplication of names and to save space. I don’t buy this. Names and slugs are short, clashes are relatively rare and we have the namespace slug problem above. I can’t see the point of wp_terms. Further, any query would need to join across to wp_terms to get the name – a pointless exercise.
• according to the documentation the object_id property type in wp_term_relationships can take a link_id or a post_id. What? This breaks the relational model. We don’t know what the ID represents in this table. Is it a link or a post? The only way I can see this working is to join across to wp_taxonomy and restrict on the taxonomy value! ie. you need to do a join to restrict the object ID. I haven’t checked the code so I can’t be sure. I must be missing something here but that is the only way I can see it working. This must lead to less than efficient querying on big datasets.

So that’s me being a bit critical of the design of taxonomies as it stands technically. However, I have bigger problems with what can be achieved sematically with it. The main limitation lies with the content of the wp_term_relationships table. You are limited into what can go into object_id (links and posts) and what can go into term_taxonomy_id (category, link_category, tag, custom). There is a divide between the resources would and the subjects world. This means that it is impossible to:

• relate posts with posts, links, users, comments or pages
• relate links with posts, links, users, comments or pages
• relate users, commentsor pages with anything

This really is a massive lost opportunity. Why the limitation?

The main problem for me is not being able to relate posts with posts. It is very common to want to encode a “see also” or a “is friends with” or “works for”. If you have this content in your WordPress as a post rather than a tag/category/custom then you are out of luck. For users who are using WordPress as a CMS with most of the content is posts (in order to get the benefits of tags and categories) this is a frustrating situation.

Another obvious loss is the inability for tags and categories to apply to pages. This kind of functionality is often bolted on by plugins. It would be nice if it could be supported natively.

Suggested alternative

OK. What would be a better design? If I were to take a stab at it I would solve it in two tables, rather than three.

mw_term
term_id
subtype (“tag”|”category”|”custom”|”predicate”)
title
slug
description
parent
unique index: subtype + slug

1 = _category (subtype:predicate)
2 = _link_category (subtype:predicate)
3 = _post_tag (subtype:predicate)

This design solves the term problem by making a single mw_term table which handles all of the naming: title, slug and description. It also handles the namespacing problem because uniqueness is solved with slug + subtype index. The subtype handles the old “taxonomy” values but also includes another: predicate.

Predicates join subjects and objects. They could have their own table for naming but why double up? Lets just put them into the mw_term table. You can see that the first three rows in mw_term are for the category, link_category and post_tag terms.

mw_triple
subject_type (post, link, term, user, comment, page)
subject_id
predictate_id
object_type (post, link, term, user, comment, page)
object_id

And here we have a standard relationship table which relates subjects with objects. This is very much like an RDF triple. You can see that this allows us to relate anything to anything resulting in the most freedom of expression. It is now possible to do some very helpful stuff without plugins:

• relate posts to posts
• relate pages to categories and tags
• relate tags/custom to tags/custom

If we wanted to represent “joe (post_id=1) worksfor acme (post_id=2)” we would have the following:

mw_term.term_id = x
mw_term.subtype = custom
mw_term.title = “Works for”
mw_term.slug = “works-for”

mw_triple.subject_type = “post”
mw_triple.Subject_id = 1
mw_triple.predictate_id = x
mw_triple.object_type = “post”
mw_triple.Object_id = 2

This is simple and straight forward.

What can be done in the current framework?

The most obvious thing is not to worry and just work with post-custom taxonomies. These are quite powerful and should get you a long way. This approach should gain a quick takeup once the taxonomy plugins become more widely deployed and used. For example, the Simple Taxonomies plugin is very simple to use and quite intuitive. If only I could get the target links to work

But what is we want to do more within the wp_term_taxonomy paradigm. What can we do? It would be possible to hack some “proxy” term_taxonomies to make statements about posts. This allows us to make statements about a post as an object (in the triples sense of the word).

We will reuse the “joe worksfor acme” example above. The posts get some auto created terms which we can use to relate them. The hack here is to have a shadow term for each post.

wp_terms.term_id = x
wp_terms.name = “mw.post_id.1″
wp_terms.slug = “mw.post_id.1″

wp_terms.term_id = y
wp_terms.name = “mw.post_id.2″
wp_terms.slug = “mw.post_id.2″

wp_term_taxonomy.wp_term_taxonomy_id = t
wp_term_taxonomy.taxonomy = “Works for”
wp_term_taxonomy.term_id = y

wp_term_relationships.object_id = 1
wp_term_relationships.term_taxonomy_id = t

We have just expressed “joe worksfor acme”. This is obviously a lot more complex than the example because we are forcing it to do something it doesn’t want to do.

This is problematic mainly because of duplication of data in wp_terms, making data integrity harder. If “joe” is deleted we will need to delete wp_terms.1. The row wp_term_taxonomy.t might also need to be deleted since it is an orphan. It also doesn’t solve the case where we want to relate tags with tags or custom with custom. So this is a sub-optimal solution.

Conclusion

The best way to look at taxonomies is to consider them as tags on steroids. To be honest this will solve a lot of problems and I am looking forward to using them to improve my tag structure. This will get me most of the way there.

I did have the dream of being able to import RDF and dump it into the two metadata centers in WordPress: Custom Fields for literals and Taxonomy for relationships. Or failing that, at the very least I wanted an easy way to relate my posts. However, it now appears that the taxonomy structure is a halfway house which isn’t capable of supporting structures as flexible as those found in RDF. It also seems to fall short for simpler things as well.  If you wanted to go down this path then the best bet seems to support a data structure outside of the WordPress tables which is a shame. How easy would it be to plug in an open source Topic Maps or RDF engine to support these relationships?

The Sydney Institute publishes the Sydney Papers, a quarterly publication of the various speeches given at weekly events. The Sydney Institute required a CMS which would allow them to maintain a subscription list where paying members have access to protected content. This was implemented as a WordPress site with a subscription manager.

Requirement: Content Management, Publishing, Subscription
Technology: WordPress, PayPal, Theme customisation

Update

Yep. I have worked through my various scribblings and have now uploaded some blog posts. Yipee.

At the time of inspiration I genuinely felt that there was something innovative in each of the ideas. In many (most) cases a little research demonstrated that the idea wasn’t that new and in fact someone had managed to implement it to a certain degree. Oh well. I’ve still included the ideas though for historical purposes. The joke is that many of the AdSense ads actually are for the idea

There are of course a few ideas that I have held back on. I’m hoping to make something of them before releasing them to the world.

Update: I moved the blog to WordPress in May 2009 and am happy for it.