Levels and Types of Metadata

There is a certain subspecies of the population of computer scientists who, once they solve a problem, "go meta." Exactly what this means varies from situation to situation, but it generally involves looking for a more generalized or more abstract way to solve the same problem.

When successful, this leads to a solution that covers a broader domain or solves the same problem more flexibly. Often these solutions involve rethinking the way the problem has been expressed, and this is usually at the level of the metadata. The expression "going meta" is sometimes used derisively to describe those who become too abstract, but if the practitioner can abstract and then reassemble the problem at hand (unfortunately, the second step sometimes gets dropped), useful designs often emerge.

To give some idea of the richness of metadata, Figure 6.9 shows one piece of primitive data (the number 42) and more than a dozen individual bits of data about that data. Most of this data is kept in most systems. It is not always easily accessible, and it is not all repeated for each instance of primitive data. But all of this, and more, is potentially at the disposal of the metadata designer.

Figure 6.9: Types of metadata.

"Going meta" means taking any one of those pieces of data on the periphery and putting it in the center. For example, if we put "alpha time" in the middle, what is the metadata that is the "name" of "alpha time"? It is probably "attribute." What is its type? It may be "entity." In one sense, the metadata for a database is the database schema. To go "up" a level, the metadata for the schema (often called the "meta-metadata") is a model in which you can store the schema (imagine a database whose tables were called things such as "table" and "column," and you'll be close). This is what the MOF described previously has done for software architectures.

It is sometimes thought that "going up" a level adds semantics. Initially, it does just the opposite; abstracting actually removes semantics. The benefit is that at this more abstract level, you now have a location in which to define semantics. Whether or not, and how well, this occurs is completely up to the implementation, but it is the opening that we have to step into to explore how semantics will be expressed in applications.