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

[Young,Jeff]

If we're going to have a registry of OAI providers as Tim suggests, I would
be nice if this registry was itself OAI compliant. This would satisfy Tim's
concern about it being flat and centrally located. Naturally, though, we
would want to use oai_dc to describe the registered repositories. ;-) 

Including XSLT references in the OAI responses could give the registry a
human-readable view as was done with the OpenURL registry. Such a registry
could be updated as part of the validation/registration process currently
available on the Open Archives home page. ListSets could be used to identify
which registered repositories support which metadataFormats. Etc.

Jeff

> -----Original Message-----
> From: Tim Cole [mailto:t-cole3@uiuc.edu]
> Sent: Tuesday, August 05, 2003 4:56 PM
> To: oai-implementers@oaisrv.nsdl.cornell.edu
> Subject: Re: [OAI-implementers] Reconsidering mandatory DC in OAI-PMH
> 
> 
> 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
> 
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>