Print

Print


There are various ways to approach this. One problem is that in terms of a
MARC to MODS conversion where the data being converted has used the
transcription rules of AACR2, it is unfortunately not that predictable the
way the data will appear. So the simple case is "c1999", but there are all
kinds of variations in what would be in the 260$c. If you look at the
format examples there are things like "1979 printing, c1975", "April 15
1977". You could also have "ca. 1820". So it may not be a good idea to
fool with the data and try to take out the "c", since the program would
have to look at the data and will only catch some of them.

There are a few options here:

1. Do what we've done and allow the "c1999" to come in if you're using the
MARC to MODS stylesheet. Now it just takes the whole 260$c string, which
could have all kinds of data. You don't have to use the "c" in your data
when you're creating a MODS record if you don't want to (even if it is a
copyright date). If librarians want to use it they just put it in the data
but they don't have to if they don't care to distinguish.

2. Define a type attribute copyright for dateIssued. Is there any value in
this? Does anyone care and want to do something special with these? Is
this something that might be important for the future for rights
management? Now we put in the "c" mainly because of the cataloging rules
but we don't use that data for anything. And, again, I'm not sure I'd want
to take out any "c" in MARC data being converted because of the variation.
If you took the "c" out of a date "ca. 1500" you'd be left with something
non-sensical.

Rebecca

On Tue, 29 Apr 2003, Roy Tennant wrote:

> <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
>