[OAI-implementers] Reconsidering mandatory DC in OAI-PMH
Mon, 4 Aug 2003 15:49:17 -0400
Dublin Core has been the mandated metadata format in OAI-PMH since the
initial release of the protocol. The purpose of this requirement was to
promote interoperability among data providers. It was the subject of
considerable discussion in the formulation of both the 1.0 and 2.0
specifications and we think that it is time to reexamine this
requirement in light of two factors:
1. There is increasing interest in using the protocol for applications
other than sharing metadata to promote resource discovery . Dublin
Core is targeted mainly as metadata for resource discovery and is,
therefore, inappropriate for these other applications. It might make
sense to loosen the Dublin Core requirement to a recommendation, and
thus reduce any barrier to these broader applications.
2. The linkage between Dublin Core and OAI-PMH has been over-emphasized
at the expense of the utility of OAI-PMH for dissemination of richer,
and perhaps more useful, structured data. In some cases data providers
with richer metadata (e.g., MARC, IEEE LOM) have been forced by the
requirement to dumb-down rich metadata to Dublin Core and have then
failed to provide the original metadata. As a result, the community
looses the benefits of rich data and is left with the reduced semantics
of Dublin Core.
We need to choose between the competing goals of protocol stability and
generalization. Although removing the Dublin Core requirement would not
negatively impact existing or future data providers, it may impact
service providers whose applications depend on the existence of a
uniform metadata format.
We would like to open this subject for community discussion. While the
technical aspects of this change are minimal it does have considerable
political impact. Please give your feedback on the following proposal:
1. Change the Dublin Core requirement to a recommendation.
2. Leave oai_dc as a reserved metadataPrefix
3. Move the oai_dc part of protocol document to Implementation
We invite members of this list to contribute their thoughts on this.
Herbert Van de Sompel