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

Ann Apps ann.apps@man.ac.uk
Wed, 6 Aug 2003 14:27:40 +0000

My opinion on DC within OAI-PMH is that it should be retained as 
either mandatory or very-strongly-recommended. Because it 
provides basic interoperability at a simple resouce 
description/discovery level. Most resouces will have a title and 

But as others have pointed out, there should be encouragement to 
provide other richer metadata formats appropriate to the particular 

I'm answering this particular email really to put the record straight 
on DC types. It may not be very widely known yet. At the most 
recent meeting of the DC Usage Board it was agreed to include two 
new types in the DCMI Type Vocabulary: Moving Image and Still 
Image. (The existing Image type will be retained because it is 
already in use.) Definitions of these new types will become 
available when the DC Terms documentation is next updated.

However, the DCMI Type Vocabulary is not really part of simple 
DC. In simple DC the value of a property is just a text string. In 
order to indicate that a value of dc:type is using the DCMI Type 
Vocabulary you need to say 'xsi:type="DCMIType"' which is 
qualified DC.

Of course you can choose to include tems like 'Text', 'Image' as 
the value of the dc:type property in simple DC, but simple DC itself 
doesn't require it. It is perfectly valid in simple DC to have:

Some of the discussion I've seen over the last day or so incline me 
to think that the use of simple DC in oai_dc is already being used 
with an assumption of qualified DC restrictions for some elements. 
Which inclines me to wonder if OAI-PMH should include some 
recommendation for oai_qdc as well.


From:           	Bob Donahue <bob_donahue@wgbh.org>
To:             	<oai-implementers@oaisrv.nsdl.cornell.edu>
Send reply to:  	Bob Donahue <bob_donahue@wgbh.org>
Subject:        	[OAI-implementers] Re: Reconsidering mandatory DC in OAI-PMH
Date sent:      	06 Aug 2003 08:32:33 -0400

> Our problem is that the requirement of unqualified Dublin Core causes
> the metadata to be EXTREMELY INACCURATE to the point of it almost
> rendering our reporting useless.  My frustration is that I feel
> "stuck" in a schema that wasn't built to be extendable and that
> doesn't (apparently) have a way to self-correct to handle situations
> where items don't fit the limited preconceived notion of what items
> were expected to be in a particular repository without resorting to a
> "bash the square peg into the round hole anyway" approach.
> In our repository, many of the digital assets are video.  However due
> to extreme short-sightedness on some group's part, video isn't
> included in the list of media formats and is deprecated to "image". 
> So, anyone finding our collection through (for example) the NSDL gets
> the first impression that we're a collection of still images and a few
> documents.   This hinders our efforts considerably.  I don't think
> anyone would say this isn't a fundamental problem.
> Furthermore, the list of elements in *unqualified* DC is insufficient
> to adequately describe digital assets, particularly multimedla.  My
> intent has been to "just" support oai_dc because I had to, then find a
> metadata format that actually works.  Dumping oai_dc for either a "new
> and improved" version (i.e., one that permits higher accuracy in
> descriptions) or another default metadata system is preferable to
> clinging to an outmoded system that's already obsolete and a poor fit
> to the contents of many repositories.   Along with the addage "if it
> ain't broke, don't fix it" should be inscribed "if it doesn't work,
> I guess the way to placate both camps (or leave them equally
> frustrated) would be to create an "extended" oai_dc replacement within
> which "classic" oai_dc will work without alteration.  The extensions
> would provide the means to extend the metadata to encompass new media
> types (and several older ones), and more freedom to make changes in
> the future.  I can't see a standards using DC working without
> qualifications, myself.
> Bob Donahue
> WGBH Interactive
> Teachers' Domain:  http://www.teachersdomain.org/
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers

Ann Apps. Senior Analyst - Research & Development, MIMAS,
     University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039    Fax: +44 (0) 0161 275 6040
Email: ann.apps@man.ac.uk  WWW: http://epub.mimas.ac.uk/ann.html
NISO's OpenURL: the standard that puts thinking back in linking