Someone from the list asked me to forward the following, which was originally
a contribution on USMARC, but makes statements about DC in relation to it:
> Sally McCallum recommends the USMARC introduction
>
> > http://www.loc.gov/marc/umb/
>
> and indeed, it is an excellent work.
>
> Incidentally, we have just this week mounted a kind of electronic textbook,
> in German, on library data formats in general:
>
> http://www.biblio.tu-bs.de/allegro/formate
>
> It contains material on USMARC but also the German formats (MAB1/MAB2) and
> the Dutch Pica3 and Pica+.
> There is one particular section I want to point out to this list:
>
> "TOP33 - the 33 most used USMARC fields"
>
> at http://www.biblio.tu-bs.de/allegro/formate/formneu.htm#top33
>
> This list gives the percentages of use of fields in LC records as evaluated
> in a German project (all LC bib records were evaluated as of Dec 1997)
> Added to this list are the DC element names relating to the MARC fields,
> to show whether or not those supposedly iportant fields are represented
> in Dublin Core.
>
> I'm now beginning to wonder: Since there is no other format better documented
> and field tested than USMARC, why is it necessary to invent another syntax,
> completely different, for DC data? If you look at DC data with USMARC-trained
> eyes, you find them extremely clumsy, bulky, wasteful, and still way behind
> the versatility and expressiveness of USMARC - when the original intention
> was for something much simpler than USMARC...
>
After second thoughts, let me add this:
Even with XML, there's no necessity to use XML syntax conventions for
metadata. Even more so than with HTML, it is very well possible, and a most
sensible approach to embed, for example, a USMARC record in its original
syntax, and then use "user defined syntax" procedures, which open up all
kinds of possibilies.
If you say, "USMARC is too kryptic", then we must keep in mind that the
HTML or XML-implementations of DC syntax are not to be looked at and written
by humans either! Everybody is using metadata makers and editors. Exactly
how these store the data need be no user's concern.
Another aspect: for USMARC, there's not only a very large user base and
widespread knowhow all in place, and software aplenty, there is also
an established clearinghouse (LC itself) and maintenance and documentation
are fully institutionalized. To try and accomodate within this well-
functioning framework the extra requirements that arise out of metadata
projects should be, or so I think, the logical approach.
Unless, of course, the USMARC community saw reasons to object...
B.E.
Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329,
D-38023 Braunschweig, Germany
Tel. +49 531 391-5026 , -5011 , FAX -5836
e-mail [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|