Quoting MJ Suhonos <[log in to unmask]>:

>> dcterms so so terribly lossy that it would be a shame to reduce MARC to it.
>
> This is *precisely* the other half of my rationale — a shame?  Why?   
>  If MARC is the mind prison that some purport it to be, then let's   
> see what a system built devoid of MARC, but based on the best   
> alternative we have looks like.

OK, now I've got to go back and define my terms, sorry I was unclear ....

1. MARC the data format -- too rigid, needs to go away
2. MARC21 bib data -- very detailed, well over 1,000 different data  
elements, some well-coded data (not all); unfortunately trapped in #1

So, back to my statement, let me re-state it as:

"dcterms is so terribly lossy that it would be a shame to reduce  
MARC21 bib data to it."

You might want to browse around in http://kcoyle.net/rda/ where I have  
made simple lists of the RDA data elements (because that's easier for  
me to view than looking in the rather complex RDA documentation or the  
metadata registry, and I haven't yet made a similar list for MARC21).  
Some of those elements may seem to be overkill ("Alternative  
Chronological Designation of First Issue or Part of Sequence"), but  
the fact is that someone somewhere in cataloger land has found a use  
for it. And where in RDA elements you have, for example,

Place and date of capture
Place associated with the corporate body
Place associated with the family
Place of birth
Place of capture
Place of death
Place of distribution
Place of manufacture
Place of origin of the work
Place of production
Place of publication
Place of residence

I don't think any of these are available in dcterms.

My general rule has always been to retain the most detailed level of  
granularity that you can, because in indexing, display, etc. you can  
easily mush elements together, but once you've put them together it's  
devilish to get them back apart again.

I'll do more work on enumerating the MARC elements. Some data is here:

   http://futurelib.pbworks.com/Data+and+Studies

That also has links to some CSV files of MARC elements that make it  
easy to play with them (deduping, sorting, counting, etc.). It's those  
files that need to be made into something more useful, which will take  
some editing and analysis.

kc

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234  
begin_of_the_skype_highlighting              1-510-435-8234      end_of_the_skype_highlighting
skype: kcoylenet