Page 143 - Building Digital Libraries

CHAPTER 6

contextual information about the metadata located within the attribute.
For example, “dc.date.created” indicates to the user when the item was cre-
ated. Moreover, within DSpace, a number of local refinements have been
defined to provide additional context to controlled vocabularies like water
basins or Ohio State University departments. However, since many of these
refinements would have little value outside of the Ohio State University
digital repository, they are removed when metadata is provided for public
consumption through OAI (Open Archives Initiative), allowing users to
harvest metadata in Unqualified Dublin Core.
It’s difficult to overstate the importance of the Dublin Core community
itself. The Dublin Core community is a large international body that is help-
ing to evolve the Dublin Core by worldwide consensus. This has allowed the
Dublin Core schema to tackle areas such as semantic interpretability and mul-
tilingualism on a global scale. Likewise, the community provides strong lead-
ership in the form of the Dublin Core Initiative and promotes Dublin Core
as an extensible standard both within the library community and beyond.
Additionally, the simple but comprehensive nature of Dublin Core has
allowed for quick adoption by a number of digital library providers, as well
as by standards providers from various fields and disciplines. Within the
library community, protocols like OAI, SRU (Search and Retrieval URL),
and Z39.50 all provide standard methods for utilizing Dublin Core as a
metadata capture language—which makes sense, given that a Dublin Core
element will mean the same thing across disciplines. Metadata creation
can also be greatly simplified utilizing Dublin Core, since metadata can be
created at varying levels of granularity and the use of automated metadata
creation methods is encouraged.

Challenges
Ironically, Dublin Core’s simplicity is also its greatest weakness. Unqualified
Dublin Core was purposefully designed as a lowest common denominator
language in order to preserve the highest level of semantic interoperabil-
ity—but this has come at a high cost. Dublin Core simply isn’t as granular as
many other specialty metadata formats, like MARC. This means that a great
deal of data, both real and contextual, is lost when data needs to be moved
between metadata formats. Given the low costs related to the implemen-
tation of Unqualified Dublin Core, many early digital repository systems
did just that—they implemented systems that supported only Unqualified
Dublin Core, causing many to loathe the overly simplistic nature of the
metadata produced.
In this same vein, librarians tend to view Dublin Core’s lack of formal-
ized input standards as a cause for great concern. Given the rigid set of
rules utilized in traditional library metadata creation (RDA), the lack of
such standardization for entering information like controlled names, key-
words, subjects, and so on has been seen as one of the major deficiencies
relating to Dublin Core’s use within the library community. Groups such
as the Greater Western States Metadata Group have sought to fill this void

128