[OAI-implementers] Reconsidering mandatory DC in OAI-PMH

[Tim Cole]

At the risk of becoming embroiled in a religious battle:

----- Original Message ----- 
From: "Alan Kent" <ajk@mds.rmit.edu.au>
To: <oai-implementers@oaisrv.nsdl.cornell.edu>
Sent: Monday, August 04, 2003 11:50 PM
Subject: Re: [OAI-implementers] Reconsidering mandatory DC in OAI-PMH


> On Mon, Aug 04, 2003 at 03:49:17PM -0400, Carl Lagoze wrote:
> > 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
> > Guidelines
>
> No comments about 3, but I agree with 1 and 2.
>
> If two parties want to talk to each other, they need to agree on how
> they are going to talk. Supporting oai_dc is a good thing to do, but
> there is nothing in the protocol that will break if DC is not
supported.
> If two parties want to use OAI to exchange data in a closed
environment,
> they will probably not bother supporting oai_dc anyway.

This is the crux of the issue. Does a harvesting service need to talk to
a metadata provider before beginning to harvest that provider's
metadata?

Currently with OAI-PMH the answer is no, and many of us (both providers
and harvesters) are glad of that since it simplifies our lives.
Currently, once a harvesting service learns of a new provider from the
OAI registration list, from the Repository Explorer list, or by other
means, that harvesting service can start harvesting the provider knowing
nothing more than oai_dc and the provider's baseURL. Certainly the
harvesting service administrator can contact the provider administrator
directly, but he or she doesn't have to. For their part, OAI providers
don't have to be bothered by everybody who wants to harvest their
metadata. (I have comments from metadata providers who say this is a
very good thing. They don't want to have to talk to everyone who might
want to harvest their metadata. That's an aspect of OAI-PMH they like,
and one reason they're willing to tolerate requirement for oai_dc.)

So, while the requirement for oai_dc is not of interest in a closed
environment (or other settings) where negotiations about exchange
metadata schema are expected to take place, having a reliable lowest
common denominator is of critical importance if you're trying to
establish and maintain a large network of open, widely accessible,
widely distributed metadata providers, such as many of us using OAI-PMH
are trying to develop. There is great value for many of us in preserving
a strongly preferred lowest common denominator for OAI-PMH, and I'm
afraid, if Z39.50 is anything to go by, a simple recommendation in the
protocol or in the Implementation Guidelines won't be sufficient
encouragement for some providers who really should be using oai_dc as
one of their formats.

But, perhaps at this stage in the evolution of OAI-PMH there are other
ways short of the current strict requirement for oai_dc as embedded in
current version of the Protocol. We should pursue this possibility
before making a definitive decision.

For instance, an open, widely accessible network of metadata providers
also requires a good registration/provider discovery service. Currently
registration of (i.e., a means to discover) OAI providers needs more
work, as we're all well aware. A single, flat centralized list isn't
going to scale well. It's not clear what's going to happen here,
long-term, but the question is will some mechanism be maintained that
will continue to vet provider services before registering them, and in
particular vet their use of oai_dc? If yes, then perhaps the requirement
to use oai_dc as such can be dropped in the Protocol itself with the
replacement recommendation elaborated to explain that oai_dc is required
if you want to register your OAI-PMH service with the formal OAI
provider registration service. This would be a carrot for providers that
really want to be visible and widely used, the ones for which oai_dc
probably does make sense. Other providers operating in closed
environments could ignore oai_dc since they would have no interest in
public registration of their services. Those few providers that want
visibility but don't want oai_dc would have to develop alternative means
of making their services known, but arguably if they're dealing with
metadata that doesn't lend itself to oai_dc, they wouldn't want to be in
a registry full of mostly oai_dc providers anyway.

Of course this alternative approach to strongly encouraging the use of
oai_dc hinges on maintaining a registration system of some kind that
requires provider services to pass certain functional tests, including
the ones for oai_dc. If instead we're going to a less formal way of
discovering OAI providers (e.g., a friends mechanism), then there would
be no carrot to encourage use of oai_dc in cases where it was most
appropriate and anarchy would prevail as has been noted by several
others in earlier responses.

So I guess I'd like to see further consideration of a relaxation of
oai_dc requirement discussed in the context of the future of OAI
provider discovery services. Will there be a way to help providers using
oai_dc get enhanced visibility for doing so?

Tim Cole
University of Illinois at UC