What jumped out at me after reading the first chapter of Steven J. Miller’s text on metadata was the wide applicability and the different typologies of metadata. It is easy to assume that metadata is a bibliographic concept; that only librarians, archivists, and data scientists are interested in metadata. But metadata is important in just about all sectors of private and public employment. Not only that, but metadata is all around us, and we engage with it – sometimes unknowingly – in our daily routines and hobbies. Cultural heritage institutions primarily deal with descriptive metadata in order to describe their resources better for searching, browsing, retrieval, and use. Descriptive metadata, as only one type of metadata in a sea of other metadatas, is laden with complexity and has a rich history.
Metadata, quite simply, is the detailed description of the granular levels or properties of objects, resources, or artistic works. It is commonly defined as “data about data,” but this is far too simplistic a definition. In Setting the Stage, Anne J. Gilliland defines metadata as “the sum total of what one can say about any information object at any level of aggregation.” Almost all metadata is intellectual, allowing users the ability to pinpoint specific items for retrieval in bibliographic databases, or to make informed judgments about the provenance or inherent properties of an item. This explanation is not entirely specific, but neither is the definition for subject analysis, which is determining the “aboutness” of an item; a task that relies heavily on metadata. As Miller writes, “[Metadata] allows users to identify the content, context, and meaning of digital resources, both individually and in relation to one another, and it allows users to retrieve individual resources and sets of related resources based on any number of shared characteristics” (Miller, 10). In other words, without metadata, there would be no order to information. The bibliographic universe would be fraught with entropy. Indeed, without metadata, it would be impossible to find relevant sources of information or even distill meaning from information.
Gilliland, however, shows that the application of a standard metadata schema is not the “Be-all, End-all” of information organization. Gilliland writes: “the distinctiveness of the various professional and object-based approaches (e.g., widely differing notions of provenance and collectivity as well as of structure), different institutional cultures, and divergent cultural approaches (e.g., those exemplified in indigenous protocols for archival and library materials) have left many professionals, and the communities they represent, feeling that their practices and needs have been shoehorned into structures that were developed by another community with quite different epistemologies, practices, and users.” This is a very important point. There can easily be resistance among institutions when adopting metadata standards. Therefore, metadata sharing, harvesting, and aggregating might not be appropriate depending on the cultural context of the institution and the clientele they serve.
Dublin Core (DC) metadata is the most common standard in the cultural heritage domain. I was previously unaware that there were so many more options within DC to qualify data in terms of refinements and encoding schemes. I have used DC before, but I did not really understand its structure, because I was not explicitly dealing with the underlying logic of the standard. My experience with digital content management software is confined to records creation in DSpace. Without taking a class on descriptive metadata before or being required to read any technical manuals on DC metadata as an undergraduate work-study student, using out-of-the-box software can obscure the practice of metadata creation. For instance, simply entering rote data values into input fields on a program with minimal DC support does not really get to the crux of the standard.
DC is designed to be flexible. So flexible, in fact, that application profiles are encouraged for local use. Therefore, there really is no wrong way to create metadata. In terms of interoperability, you can either create metadata that is compatible with the standard (which is encouraged), or you can create metadata that is not compatible, but is still adequate for localized use. In this sense, there is both “good” and “bad” metadata in terms of interoperability, but there really is no such thing as wrong metadata as long as it is operational for information search and retrieval purposes.
On that subject, Miller makes an important point at the end of Chapter 2 in his text. He says that “many implementers have found unqualified Dublin Core too simple for fully effective description of digital cultural heritage resources. Even Qualified Dublin Core does not always have the processing power that some implementers need in order to accomplish the search, browse, navigation, and identification functions they desire to implement for their users” (Miller, 54). In my experience, it seems like most users of information resources rarely see or desire DC elements when searching catalogs. In fact, most users generally have no need for DC metadata. Instead, what they require to find the information objects they are looking for are the local elements. DC elements are essential for machine readability, which in turn is necessary for cross-platform resource discovery. But as far as I can tell, the justification for DC remains the interoperability of linked data and convergent catalogs, which is still very much a “future perfect,” as most catalogs in the cultural heritage domain remain localized. And that may be how they remain indefinitely. For example, as Lynne C. Howarth points out: “[T]here remain legitimate reasons as to why a standards-in-common solution poses its own enduring problems, even within the compelling context of interoperability. Competition for market share, anti-trust laws within commercial applications, the inconvenience (and expense) of implementing a standard that is of primary benefit to others, the need for flexibility in innovation and testing, the inherent dynamism (instability and continuous upgrade) of information technology, and the considerable length of time required for developing, implementing, and evaluating a new standard (the standards development life-cycle), may conspire against full collaboration–and particularly international collaboration–among diverse interests and organization imperatives.”
Clearly, problems remain.