[OAI-implementers] Reconsidering mandatory DC in OAI-PMH
Tue, 05 Aug 2003 13:00:38 +0200
i should add my strong support for this proposal from the perspective of
building componentised digital libraries.
my experiences in recent years have shown that the OAI-PMH can be very
useful for transferring data among completely separable internal
components of a digital library. while experimenting with the
OAI-PMHv1.1, i had to work around a few issues, almost all of which were
subsequently resolved in OAI-PMHv2.0 (granularity, list sizes, etc.).
currently, the biggest remaining stumbling block is the requirement for
DC versions of records, which makes no sense in the closed environment
of a local but componentised dl.
i believe that removing this as a requirement will enable internal (in
addition to external) data transfers to use OAI-PMH, and will encourage
the building of finer-grained service provision components that can be
interconnected instead of service providers being themselves monolithic
also, let me add that i think Jose Borbinha's ideas are great. we really
should have some kind of registry of formats/transformations and i am
sure these ideas have been mentioned before. there is only the issue of
who will do it :)
philosophically, if this is done well, it could lead us closer to a "one
item, one format" scenario and that has positive ramifications for
mirroring, data consistency and standardisation of mappings. on the
whole, changing the status of dc to a recommendation is going to make
the PMH more viable for community-based systems rather than global OAI
search engines like the ones we have seen thus far. personally, i think
this is the right direction in which to aim the PMH.
lastly, before you release any new versions, do note that SOAPification
is coming sooner or later and you need to put more thought into
separating the essence of the protocol from the binding so we dont end
up with protocol version soup (where soup = v2.0, v2.1, v2.0/SOAP,
Carl Lagoze wrote:
> 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.
>  http://www.dlib.org/dlib/july03/young/07young.html
> Carl Lagoze
> Michael Nelson
> Herbert Van de Sompel
> Simeon Warner
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
hussein suleman ~ email@example.com ~ http://www.husseinsspace.com