[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
identifiers.
But as others have pointed out, there should be encouragement to
provide other richer metadata formats appropriate to the particular
domain.
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:
<dc:type>car</dc:type>.
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.
Ann
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,
> DON'T CLING TO IT ANYWAY". :-)
>
> 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