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?

I recently had an interesting experience from an academic friend of mine who, on learning that I worked on team involved with repository development, hit me hard over the head with all that she thought was absolutely evil about repositories. It’s a bit of a shock having a friend you think you are helping turn on you as if you’re the devil incarnate (maybe repositories have the power to turn friendships into marriages?) — but her concerns did provoke some soul-searching and discussion among other colleagues of mine and myself, and I am happy to say the story has finally had a happy ending (no divorce).

The whole experience was a reminder of

• finding ways to tailor the different advantages of repositories to different audiences (and academics and faculties/schools/depts are not all the same);
• a most rewarding insight in some of the details of the pressures academics work under;
• the importance of getting both workflows and housekeeping tasks right;
• and the broader need of the whole university to be involved from the VC down to assist in the promotion of the right culture and support to sustain repositories.

Those interested in the details can check my recent posts at my personal blog
Neil Godfrey
http://metalogger.wordpress.com

I’d be interested in hearing from anyone interested in this topic what sorts of things they’d expect or like to hear about in a presentation on this topic. Are there any here who are interested in this topic, whether DSpacers or VITALizers or Fezers or EPrinters or others?

Since I’ve been asked to do a presentation on this topic to others who are starting out with their repositories so I’d love to hear from you.

My background is that I used to work as an eprints repository editor in early days when we were all learning as we went and I’m currently with the RUBRIC project. I’ve already been lucky enough to have had 2 others describe their eprints workflows to me, but now I’m sitting down to work out a presentation I’m sure there must be many aspects and questions that I should be aware of that may be on the minds of others across a wider range of experiences.

Thanks in advance,
Neil Godfrey

http://metalogger.wordpress.com

I’d love to hear from anyone in library-land who has used/heard of/rejected/embraced/toyed with MODS (metadata object description schema) as the next evolutionary step from MARC.

I asked this question more locally about a year ago when I first started seriously to inform myself about metadata and got either blank or ‘don’t touch that’ looks back then. Since then the MODS question has hit me again and I am wondering what I don’t know about it for it not to be more broadly known and used. From my reading it appears to be a brilliant alternative to MARC in the new world of things like interoperability, repositories, electronic databases…. It looks damn easy to understand (no marc tags for the uninitiated to navigate) and maps well to anything from the simplest Dublin Core to the most complex ONIX.

One negative comment I did hear was that it cannot catch all MARC data but when I wrote up a table comparing all the fields one could want in a repository I could not see any problem that way at all: the only thing it loses is the excess MARC bits and pieces that are simply not relevant to repositories and the sharing and searching of collections in the new info world. Things like the 246 indicator that codes a varying title as being a “spine” title — what’s a spine in an electronic resource anyway?
Thoughts? Would love feedback since am planning on soon applying all I’ve read about it to the real test world and seeing what happens.