Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (April 2003)Back to main MODS pageJoin or leave MODSReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Wed, 30 Apr 2003 11:22:06 -0400
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         "Rebecca S. Guenther" <[log in to unmask]>
Subject:      copyright dates
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

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 >


Back to: Top of message | Previous page | Main MODS page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager