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

Matthew Cockerill matt@biomedcentral.com
Tue, 5 Aug 2003 13:10:15 +0100


I'm surprised that all contributors to this discussion have favoured
removing the obligation for implementers of the OAI-PMH protocol to support
a baseline Dublin Core metadata format.

BioMed Central makes available not just Dublin Core, but also its own richer
XML formats, including the fulltext XML of our research articles. So I can
certainly see that there is an argument that the OAI community needs to
encourage and foster the use of OAI in ways that go beyond the basic
provision of DC metadata. 

But it still seems to be that having a baseline metadata standard that *all*
OAI providers must implement is an *extremely* useful aspect of the
protocol. 

e.g. It is currently possible to build tools which will browse an arbitrary
repository, and list the titles of the new items which were added to the
repository that day. If you remove the support for Dublin Core metadata,
then even such a simple task would become impossible (right ?).

Does it really follow that removing the requirement for Dublin Core support
would increase the support for other, richer formats? Surely the two things
are independent,

Matt

==
Matthew Cockerill Ph.D.
Technical Director
BioMed Central Limited (http://www.biomedcentral.com)
34-42, Cleveland Street
London W1T 4LB

Tel. +44 20 7631 9127
Fax. +44 20 7580 1938
Email. matt@biomedcentral.com


> -----Original Message-----
> From: Martin Sevigny [mailto:sevigny@ajlsm.com]
> Sent: 05 August 2003 12:25
> To: oai-implementers@oaisrv.nsdl.cornell.edu
> Subject: RE : [OAI-implementers] Reconsidering mandatory DC in OAI-PMH
> 
> 
> > Carl Lagoze wrote
> 
> > 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.
> 
> I do strongly agree with this statement. Many times, I had to 
> go back at
> the basics and try to convince people tha OAI-PMH could 
> transport other
> XML data structures then DC.
> 
> This strong association has been of great importance in the early and
> rapid adoption of OAI, because it (may) remove the burden of 
> agreeing on
> data structure for exchange. But I think that since this first step in
> the adoption of OAI is now done, it would not cause too much harm to
> remove this constraint.
> 
> > 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.
> 
> This is the main drawback of it. I personnaly believe that in a real
> distributed, multilingual, multivocabulary environment (very realistic
> today), the benefits of having a common model as limited as 
> Dublin Core
> are not that important.
> 
> > 1. Change the Dublin Core requirement to a recommendation.
> 
> Agreed.
> 
> > 2. Leave oai_dc as a reserved metadataPrefix
> 
> Yes, it should.
> 
> > 3. Move the oai_dc part of protocol document to Implementation
> > Guidelines
> 
> OK.
> 
> Martin Sévigny
> AJLSM
> sevigny@ajlsm.com
> 
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> 

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________