Hello all,

I'm in the process of evaluating Dublin Core to use as a basis for
developing my institution's own metadata standards for its many and
varied digital library projects that loom on the horizon. An
inter-library initiative of which I am a part has already decided
against using DC, and I've had to write up a justification of that
decision for the benefit of my superiors. In looking for material to
back up--or at the very least better inform--my reasons not to use DC
for this particular project, I'm coming up empty, and it's driving me
crazy. In general, I'm finding very little in the literature that is
critical of DC at all, which bothers me. I'm convinced that my reasoning
is sound, but I can find next to nothing that specifically backs me up.
Although I realize this mailing list is not the hot-bed of discussion
that it used to be, I wanted to bounce my ideas off of you and see what
people think. Please keep in mind that I'm not interested in bashing
DC--I think that DC serves well as a general-purpose,
lowest-common-denominator metadata schema for resources/systems (such as
those on the web) that require nothing more specialized. But I'm
becoming less and less convinced that it is a wise choice for a lot of
digital library projects--at least, in certain environments.

As an aside, I've spent several hours searching through the archives of
this list and I *have* found statements made and even whole threads that
do confirm my thoughts. But I haven't been able to find these issues
addressed anywhere else, and it's entirely possible that I'm making
mountains out of molehills. But what I need is validation! :-)

I think the crux of my problem with using DC--specifically, qualified
DC--for sophisticated resource description has to do with the underlying
data model and how DC has developed in relation to that underlying data
model.

First of all, the DC Abstract Model is wonderful. In general terms, it's
essentially the same as the data model underlying RDF, and it absolutely
makes sense to me. Before going to library school--and even *in* library
school--I was heavily into database design, and so the concept of having
flat data structures (i.e., "descriptions"), each pertaining to a single
entity, and some explicitly related to one another is intuitive to me.
The problem is that the DCAM wasn't formalized and documented until just
a year or two ago--long after DC was established as a popular metadata
standard. Reading through some of the archived postings of this mailing
list confirms that, even a couple of years after DC had been in use,
there were still some *very* conflicting ideas about its purpose and its
use--i.e., the infamous tension between the minimalist and structuralist
camps. For better or worse, DC has developed in both
directions--seemingly without a common, underlying data model to guide
all DC implementations, until recently. The DCAM does a great job of
reconciling both of these conflicting uses of DC and putting both of
them into a common framework. Again, the problem is that this didn't
come about until very recently, and so there are long-standing
conventions in many applications of DC that don't fit the DCAM.

A vital part of the DCAM is the 1:1 rule--that each description pertains
to one and only one resource. Reading through the archives, this has
been a serious source of contention in the past. Most discussion
surrounding this rule has dealt with it in a FRBR-like context--e.g.,
can a single DC description relate to a painting, a photograph of the
painting, and a scanned version of the photograph of the painting? But
there is a subtler application of the 1:1 rule that perhaps wasn't made
sufficiently clear until the DCAM. When you realize that people,
corporations, and conceptual ideas can also serve as resources and thus
may need their own descriptions, you begin to realize that more complex
metadata cannot be expressed using just one flat description. But it
doesn't seem that this has been widely understood, and so some qualified
DC implementations have set precedents for data structures that lead to
severe data incongruities. This is most apparent in some of the element
refinements that people have used that don't fit DC's rules for element
refinements.

Here's a purely hypothetical example:

DC.identifier = "0-8389-0882-9"
DC.title = "Metadata in Practice"
DC.contributor.Firstname = "Diane"
DC.contributor.Middleinitial = "I"
DC.contributor.Lastname = "Hillman"
DC.contributor.Firstname = "Elaine"
DC.contributor.Middleinitial = "L"
DC.contributor.Lastname = "Westbrooks"
DC.publisher = "American Library Association"
DC.publisher.Location = "Chicago"

Obviously, the "refinements" here aren't refinements at all--they're
entirely separate sub-elements that describe different resources than
the primary resource being described (the one entitled "Metadata in
Practice"). So, in this example, there should be four separate
descriptions to handle the four separate resources: the book, the two
editors, and the publisher. Flattening what should be a
multi-dimensional description set into a single description leads to
data problems when you try processing this. Which groups of contributor
sub-elements go together? Are the contributors' names Diane I. Hillman
and Elaine L. Westbrooks, or are they Diane I. Westbrooks and Elaine L.
Hillman, etc.?

For reference, the first that I saw this issue explicitly addressed in
this list's archives is here:

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind9907&L=dc-general&T=0&F
=&S=&P=4874

And then I've seen a more recent discussion regarding how to express
publisher location in a DC record. It's related to this issue, even
though 1:1 is not explicitly discussed:

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0505&L=dc-general&T=0&F
=&S=&P=561 (and thread)
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0505&L=dc-general&T=0&F
=&S=&P=775 (and thread)

These situations are extremely common in library metadata. Look at
MARC--how many entities besides the resource in hand does a typical MARC
record describe? Obviously DC is not MARC and the two schemas serve very
different purposes. But that only adds to my thought that DC is not
ideal for a lot of digital library applications.

Going back to the example given above, one could devise a better XML
representation:

<record>
	<dc:identifier>0-8389-0882-9</dc:identifier>
	<dc:title>Metadata in Practice</dc:title>
	<dc:contributor>
		<nameschema:first_name>Diane</nameschema:first_name>
		<nameschema:middle_initial>I</nameschema:middle_initial>
		<nameschema:last_name>Hillman</nameschema:last_name>
	</dc:contributor>
	<dc:contributor>
		<nameschema:first_name>Elaine</nameschema:first_name>
		<nameschema:middle_initial>L</nameschema:middle_initial>
		<nameschema:last_name>Westbrooks</nameschema:last_name>
	</dc:contributor>
	<dc:publisher>
		<pubschema:name>American Library
Association</pubschema:name>
		<pubschema:city>Chicago</pubschema:city>
	</dc:publisher>
</record>

And this solves the data problems. Separate descriptions for separate
resources are...well, separate...and nested correctly. Dumbing down
might be a problem, as the system wouldn't necessarily know what single
value representation to use for the contributor and publisher elements.
But the *main* problem with this solution is that it's non-standard.
Although I realize that DC isn't supposed to standardize syntax, syntax
is an important practical part of interoperability, which is the
ultimate goal of DC. If you're forced to use non-standard syntax in
order to take full advantage of the DCAM, then that seems to defeat one
of the main purposes of using DC in the first place.

A message written yesterday to the DC-ARCHITECTURE list confirms that
"*none* of the current DC syntax specifications are based on the
abstract model."

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0512&L=dc-architecture&
T=0&F=&S=&P=618

Furthermore, if you look at the specs themselves, they even say that
they don't support multiple descriptions in a single record (except for
the proposed recommendation for expressing qualified DC using RDF/XML,
which was last updated over three years ago).

So, if a digital library project currently wants to implement DC, and
they want to conform to the DCAM (multiple-description records and all),
then they essentially have to develop their own local encoding format.
This would probably also entail doing a lot of programming on the system
itself to support the custom encoding format and to allow the system to
output simple DC records for interoperability. And then interoperability
would only be at a very basic level, considering that the only shareable
records would be those put into an accepted simple DC format.

A lot of libraries--mine included--just don't have the programming
resources for this. It seems a better option, then, might be to go with
a better-defined metadata schema such as MODS (depending on the
collection). But then you've got a different problem--use of DC is so
widespread that most systems only support DC or DC-like metadata out of
the box, and so you still have to do some programming to get your system
to support a different schema.

Considering the number of digital library initiatives that *do* employ
DC, combined with the lack of material that's out there dealing with
these perceived shortcomings of DC for digital library projects, I feel
very much alone in my thinking. Am I just making too big a deal out of
this? Can anybody provide me with something that might either support or
contradict my reasoning?

If my reasoning is solid, then why does none of the literature support
or even address these issues?

I thank you for any help you can offer!

Jason Thomale
Metadata Librarian
Texas Tech University Libraries
(806) 742-2240