On Tuesday, April 29, 2003, at 07:00 PM, Roy Tennant wrote:
> 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:
> 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.
Yes, yes, yes! I forgot to mention the issue of dates and similar
things, but I fully and totally agree, and this was indeed also behind
my original question.
> ...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.
Right. Indeed, my interest is in potentially using MODS as the basic
data exchange format for open source bibliographic formatting apps
(like Endnote, Reference Manager, etc.), but as soon as you add these
strange holdovers from the past, you limit flexibility for the kinds of
uses I envision. While it is indeed true that one can avoid coding
records this way, I worry about how such traditions will limit the MODS
spec itself unless there's a conscious effort to go beyond them (as
well as future records themselves). Is it currently possible to code
Roy's copyright date example above?
But also, I was just pointing out that the guidelines should encourage