Most Semantics Live in Metadata

The evolution of formal means to describe metadata is only half the story. The other half is how people have evolved their applications designs to make better use of metadata.

Application Metadata Design Is Subtle

The shift to using more metadata in application design occurred in parallel with the evolution of the metadata expression. However, the shift in application design has been much more subtle, for two reasons:

1. It requires no new languages, acronyms, or conferences; designers just do it.

2. Many good designers do this without being aware that they are doing it. The longer they are in the field, the more likely they will see a "nonmeta" design as less appropriate, without necessarily knowing why.

Metadata in Packaged Applications

Several studies have indicated that building a packaged software application takes between 5 and 10 times as much effort as building the same functionality once on a custom basis for a single site. Much of the reason for this difference is that package vendors realize that they are going to have to tailor their system to most of the customers for whom it is installed.

Many techniques are used to aid in this process, including metadata-based design. At one level, many packaged application vendors use the active repository approach for such things as screen labels and report headings. With this approach, a single change to the metadata repository can change the system's appearance. For example, if one company wants to call parts "items," a single change to the metadata repository changes all the screens and all the reports.

More flexible, but not as widely implemented, are metadata designs in which the implementers (and by extension, theoretically, the end users) can extend the data model, rather than just create aliases for things already in the model. The most simplistic implementation occurs when vendors leave the last dozen fields on any given master record as "user1," "user2," "user3," and so on. This allows the users (i.e., the company) to redefine these fields for their own use. So if they decide that they need to store shoe size and favorite wine on their contact lists, they simply redefine "user1" to be "shoe size" and "user2" to be "favorite wine." The screens prompt and the reports display these new labels. However, these are miscellaneous fields. They are not recognized by any of the rest of the application programs. Some designs contain custom validation rules that allow you to validate shoe sizes or pick favorite wines from a list, but that is about it. In other words, there are ways for one user to communicate some semantics to another user, without the application becoming aware.