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

[Jose Borbinha]

Sounds good! It is simple, practical, and can fit well in the model!!!

Tim's analysis is correct!
I just would like to add a new element for his final conclusions, which
is the fact that even for metadata providers that create and use
internally rich metadata, the ability to publish it in DC stills
attractive, since it is a way to keep the full contents for themselves
on the same time that they make it possible to discover their resources.
I mean, if I have a complex MARC21 or UNIMARC catalogue, it doesn't mean
that I'll make the records available in those schemas just because
OAI-PMH makes it possible, since I might be giving away too much. I
might still prefer to publish the metadata in simple DC...
Thus, I don't think this possible move of the OAI-PMH to a more generic
model will be a threat to the popularity of DC!


Regards
Jose borbinha

-----Mensagem original-----
De: oai-implementers-admin@oaisrv.nsdl.cornell.edu
[mailto:oai-implementers-admin@oaisrv.nsdl.cornell.edu] Em nome de
Young,Jeff
Enviada: terça-feira, 5 de Agosto de 2003 22:18
Para: 'Tim Cole'; oai-implementers@oaisrv.nsdl.cornell.edu
Assunto: RE: [OAI-implementers] Reconsidering mandatory DC in OAI-PMH


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
> 
_______________________________________________
OAI-implementers mailing list
List information, archives, preferences and to unsubscribe:
http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers