Has anyone written about what it’s like to create controlled vocabularies (CVs) in the context of actual project work? I can’t think of any. Below are some spurious notes of my recent experience, probably not understandable to anyone else ’cause I don’t have time to instruct. We’re racing to deadlines and I’m driving as fast as I can…
The exercise and deliverables can be rather abstract for some folks, especially if they view the world through a technology lens. It helps to create illustrations and screen shots to show what is meant and how terms are used.
CVs become a very helpful as a way of recording the tacit knowledge of an organization, helping everyone communicate and use their information. The process of creating the terms helped clarify their use for the team in understanding the business. (It’s tempting at this point to ramble on about language being symbols for meaning, so we’re actually controlling meaning, and those who control meaning have the power to define reality (the power to name – Jansen)).
If the CV is just informing other artifacts and not something that will be maintained or otherwise carried forward, state that so there is no confusion (e.g. do users of a CMS have to look at a thesaurus to discern meaning, or some other more user-friendly artifact?).
Illustrating the CV within the process: Business’s understanding of reality -> CV -> CMS Manual and CMS user interface -> data and metadata -> UI (e.g. web pages). The CV helps build a bridge between the organization and the user interface.
In all the talk of technology, IA, etc., ultimately people are coming for content. If the content sucks, the site sucks. (Content is king). Given that content creation and migration is also expensive, to properly honor the content developer’s work we need to put considerable thought into how content is created. A CV helps ensure the builders understand the subject domain and can communicate it to future content authors.
There’s never a perfectly controlled vocabulary; the number of terms is finite and language can only be clarified to a certain extent. It may be necessary to state this fact to set expectations. It involves judgment calls regarding which terms to control, how to control them (e.g. supplying the definition vs. restricting use via the user interface), and how to define them.
As with any design exercise, you need a scope, users and user intentions to guide the work. When defining the scope of the CV, determining the number of terms may seem arbitrary, but may be necessary given the other factors like time, money, and user response to the system.
CVs for CMS may be used in various ways: to populate menus in the UI (“hard” control), to offer examples, to define terms for a manual (“soft” control), to determine metadata relationships, etc. Specify what you’re using it for explicitly to show its value.
Not creating a CV before building a system can lead to expensive design and technology changes later if the designer’s conception of reality don’t match the users.