I’ve been meaning to write about my presentation at the Semantic Technology Conference last month. It was called Representing Taxonomy: What Am I Looking At Here? The idea I was trying to convey is that, as semantic technologies become more widely adopted, we’re (sometimes) going to have to come up with data to drive our semantic applications. We’re also going to need processes for documenting that data and communicating about it to our clients and stakeholders.

Here’s a diagram I created to show how taxonomy building tasks should be integrated with the phases of a web development process. Communication with the stakeholders should be taking place throughout the project lifecycle. What’s the goal? Getting the following things from the stakeholders:

• Approval for data
• Expert input
• Partnership in the effort
• Distributed communication to other contributors

The approach I recommend, as indicated in the diagram, includes:

1. Groundwork – Gather background information that your stakeholders will need to make good taxonomy decisions. This may include some basic education about the concepts involved.
2. High Level – Start thinking about the general ways in which you will need to organize the data of the site. These may emerge naturally, based on the concept behind the site.
3. Dimensions & Relationships – Use diagrams, lists, tables, or spreadsheets to further express how the content will be organized. Use real data to inform the Information Architecture of the site.
4. Detailed Taxonomy – Apply the concepts in the taxonomy to all of the content, products, etc. on the site. Consider prototyping your data to make it come to life.
5. Usage Guidelines – Communicate to the content creators how to apply the taxonomy to the content once the site is live.
6. Taxonomy Maintenance – Document the things that your stakeholders need to consider in order to keep the taxonomy up-to-date.

It’s pretty straightforward, and may not seem all that earth-shattering compared to all the excitement around semantic technologies these days. But sometimes the simplest things are the hardest to put into words.

After the presentation, one person told me that he’s an engineer and he has always had trouble communicating about these things with the domain experts, and this helped him see how he could approach it more systematically. That’s exactly the effect I was trying to achieve.

Have a look at a low-res version of my complete presentation (B&W, PDF, 2-up)