On Tuesday, April 29, 2003, at 03:18 PM, Barbara B Tillett wrote:
> Please remember that the GMDs (including [sound recording] and
> [electronic resource]) are separately subfield coded in MARC 21 ($h) so
> can be displayed or not as a local system wishes.
>
Bingo. _Because_ it is so encoded in MARC, it can be processed as
appropriate. But the problem before us in MODS is that it isn't so
encoded, it is dropped into the title field as if it belongs there.
Another, similar gripe I have is this example from the Guidelines:
<dateIssued>c1999</dateIssued>
The "c" is apparently to qualify the date as the copyright date. But
since when should we be adding attributes to CDATA? Shouldn't it be
something like <dateIssued type="copyright">1999</dateIssued>? This
would then allow a processor to either ignore it, or place a "c" in
front of it.
Are we visiting the sins of MARC on MODS? That is, are we once again
building a structure with which we can mimic the layout of a card from
our card catalog, without thinking critically about what metadata we
actually need and how to best encode it? The web site says that MODS is
"a bibliographic element set that may be used for a variety of
purposes," but on further exploration as well as based on discussions
here on the list it appears more and more to be limited in scope to
MARC and MARC-like activities. I hope I'm wrong, since I think it may
be possible to come up with a bibliographic metadata standard that
would be more generally useful if we could for once free our thinking
from the specific requirements and limitations of MARC/AACR2/current
library catalog software.
Roy
|