Well, here's a third voice in the mix... 

I have a different kind of perspective, based more on experience with
IEEE LOM, RDF and machine-semantic interoperability, and also from my
participation in the formulation of the DCAM. So while I can't really
comment on MODS in particular, I feel I must say something about the use
of DC for semantics interoperability in general.

Let me first try to summarize your argument (please correct me if I
missed anything):

1. "the DC Abstract Model is wonderful"
2. "the DCAM wasn't formalized and documented until just
    a year or two ago"
3. "there are long-standing conventions in many applications
    of DC that don't fit the DCAM"

In particular:

4. "more complex metadata cannot be expressed using just one
    flat description"
5.  *none* of the current DC syntax specifications are based on the
    abstract model.
6. "one could devise a better XML representation"
7. "the *main* problem with this solution is that it's non-standard"

Thus:

8. "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"
9. "a better option, then, might be to go with a better-defined  
    metadata schema such as MODS"

But:

10. "use of DC is so widespread that most systems only support DC or  
     DC-like metadata out of the box"

If this summary is correct, I think your main argument - that there *is*
an issue with interoperability in DC - is correct. From the perspective
of perfect interoperability, DC has not yet reached its full potential.
But it never will, and so will none of the other
standards/specifications you are considering...

I think what you are seeing is a slow shift in the foundations of DC -
from human semantics to machine semantics. The 15 elements and their
definitions were originally mostly for human consumption. If they were
used by a piece of software, their meaning was hard-wired into the
applications, and there was no real need for a framework around them.

This, as you have noted, is still reflected in many applications of DC.
They treat DC elements merely as human-semantic flags, using them as for
tagging parts of their data structures with references to a
human-readable definition, without real regard for the framework in
which they are defined. Surely many uses of the dot-notation (as in your
example) use this free-form DC in this way. And of course they are free
to, but this free-form metadata is no longer Dublin Core-compliant.

The need for a supporting framework that supported some kinds of
automatic processing of metadata (such as dumb-down) has slowly grown,
and led to the development of the grammatical principles, and in the
end, the DCAM (in parallel, the RDF suite of specs has matured as well).

The DCAM represents the first time that the DCMI has turned around and
declared that the fundamentals of DC lies not the elements, but in the
framework. And the DCAM makes it very clear that the semantics of the
framework is not optional, but mandatory. If you declare a refinement,
there are hard rules to follow. And the reason for that is simple: it is
expected that these rules will be implemented in software, so if you
break the rules, such applications will break in unpredictable ways.

This was never the case in the hard-wired legacy applications, because
they did not process metadata based on the framework, but used ad-hoc,
idiosyncratic processing of each element. So they could not break
because they never supported the kind of semantic extensibility that is
encoded in the DCAM.

Now, your argument is that most DC applications are not fully
interoperable in view of the DCAM. This is true. But on the other hand,
what other metadata standards, apart from RDF, tries to do what the DCAM
does? Surely not many, and absolutely not MODS... So it turns out you're
comparing apples and oranges. 

In my view, Dublin Core has put itself (back) right in the front line of
metadata standards with the DCAM. Machine semantics, and
machine-processable interoperability as codified by ontologies and
application profiles are going to be the main area of metadata
development over the next decade, and the DCAM gives DC access to
precisely that. The argument that not all DC application support all of
that yet, is particularly weak given that few other metadata standards
even *try*.

So I'd be inclined to say that using DC is still the most future-proof
choice you can make.

/Mikael



fre 2005-12-23 klockan 10:44 -0600 skrev Thomale, J:
> 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 
> 
-- 
Plus ça change, plus c'est la même chose