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
