Okay, “standards” might be a bit strong. But Library of Congress Marc to Dublin Core proposals do not work with Repositories. And the reason is that Library collections have a different purpose and function from Repository collections.
Some examples. 110, 111, 710 and 711 all map to dc:creator according to loc’s Marc to DC crosswalk. We can forget the 110 and 111 because our university institutional repositories simply don’t archive papers by corporate bodies or conference meetings. They only store articles and papers by personal authors. That’s their purpose — to showcase/archive the intellectual output.
But what of those added entries? In a repository record one would expect here to see a “dc:relation” to the author/record — the conference for which the paper was written, frex.
A library houses a conference publication and the “conference” is the primary “statement of responsibility” and therefore “dc:creator” of the published volume. But the repository houses each paper as a discrete entity, so in each case it is the personal author who is the dc:creator and the conference is unavoidably the dc:relation.
Ditto for the Mark 508 tag for Credit. LOC proposes this as part of the dc:description element. But surely credits are contributors if not outright creators. Why not map to dc:contributor if this field is found in a repository archive?
And how is a repository meant to handle a marc 538 “system details” note? Values in this tag can refer to either a format (e.g. DVD) or relation ((e.g. system requirements:…). LOC suggests 538 go into a Simple DC’s dc:description element, but into a dc:relation.requires Qualified DC element. Often I’m sure it would fit best in a repository’s dc:format.
And should 524 citation map to dc:description as per LOC’s proposal for simple dc, or to dc:identifier if one wanted it to appear in the Simple DC datastream?
And 651 is mapped to dc:coverage everywhere one looks in loc recommendations — and this is of course an obvious tag for harvesters to search for ‘coverage’, but it does look odd being separated in portal displays to a separate element type from the 650, 600 and 653 tags. There are after all 043 and 522 and 650 $z’s for coverage already there.
These are just some of the anomalies that present themselves when the library and repository worlds, harvesting and display needs, meet, or crash.
Repository collections are not library collections and they require their own mapping standards modifications. Should there be a get-together or special discussion list of interested parties to nut out some of these issues?
Metalogger 