Statement completion in interactive development environments -- what Microsoft calls IntelliSense -- is one example. Interaction with controls at design time is another.
These scenarios don't strictly require that metadata be embedded in generated code, but it's administratively convenient to do so. Objects that contain their own metadata descriptions are well adapted to an increasingly decentralized world. At the same time, though, there are countervailing reasons to prefer looser coupling between data and its metadata. In the Java and .Net environments, for example, embedded configuration metadata is handy for programmers but not as convenient for system administrators. So, administrators can override the hard-coded settings with alternates they declare in separate XML configuration files maintained under their control.
The tension between these two world views -- the programmer's and the system administrator's -- shows why there often isn't one right way to manage metadata. Even in a single domain, using a single controlled vocabulary, the people who manage metadata can occupy different organizational roles and expect to use different sets of tools.
Document and message metadata
Documents and messages carry richer intrinsic metadata than the basic facts -- owner, creation and modification date, size, permissions -- that file systems maintain. A Word document has built-in properties; a Web server includes metadata in HTTP response headers; e-mail messages also transmit metadata in headers.
In all these cases, it's possible to include extra items of metadata. Word documents can have custom properties; Web pages can use metatags; e-mail messages can carry custom header fields. We've long hoped that optional user-assigned metadata would help us relate our documents and messages to the activities they represent and embody. But assigning extra information requires extra effort, which is always a stumbling block. And when this optional metadata isn't limited to controlled vocabularies, it's hard to build reliable processes around it.
New social tagging services, such as del.icio.us and Flickr, have brought a fresh approach to this ancient dilemma. When data is open to public inspection -- such as the set of all Web resources, or just the subset of online photos -- these tagging services have proved to be surprisingly effective ways to gather and exploit voluntarily contributed free-form metadata.
If you tag personal documents and messages stored on your own hard drive or in your own partition of an online service, the only person who benefits from that effort is you. And you, in turn, gain nothing from the effort that others invest in tagging their personal data. Without feedback and positive reinforcement, rigorous use of metadata requires a level of discipline verging on the neurotic.
When metadata refers to shared data, however, and when lots of people can interact with that shared data, the dynamics shift. In this scenario, the metadata produced by a few people -- for selfish reasons -- can also benefit many others. Enlightened self-interest is one key motivator, but peer pressure is another. Although nothing compels me to tag my bookmarks or photos according to group conventions, doing so means the items I tag will receive more attention from the group. That's a powerful incentive to contribute, and it creates a tight feedback loop that helps metadata vocabularies converge.