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 (July 2003)Back to main MODS pageJoin or leave MODSReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Tue, 29 Jul 2003 17:36:30 -0400
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Tod Olson <[log in to unmask]>
Subject:      Re: New schema and citation changes
Comments: To: [log in to unmask]

On Wed, 23 Jul 2003 10:47:24 -0700, Karen Coyle <[log in to unmask]> wrote: >At 06:43 AM 7/23/2003 -0800, you wrote: > > >>I probably wasn't being clear. By saying MODS "enforces" I am simply >>meaning that there is, AFAIK, not any facility to indicate in MODS "this >>is an unsure date, the name of the author of this record is unknown." >> >>I am thinking about stuff like: >> >><date qualifier="unsure">1923</date> >> >>or... >> >><namePart qualifier="unknown"/> >> >>Surely there are better terms than those I use above, of course... > >There is a date qualifier in MARC in the fixed field area for dates. That >has bunches of codes, including "questionable date" and "date unknown." >That element wasn't included in MODS, however. I think what Bruce is getting at is that XML lets us separate data encoding from data presentation. This makes it a different animal from MARC, and there is good reason to rethink how cataloging rules are to interact with the data storage mechanism. In particular, cataloging rules proscribe data presentation, e.g., AACR2 *still* focuses on how to lay out a catalog card. The data encoding and presentation are not divorced, as they are in XML. Therefore, we should be cautious in how we allow cataloging rules to influence our encoding decisions. Sticking to the date-encoding part of the conversation, I think it a disservice to allow something like the following: <date>c. 1954</date> <date>c1972</date> It's poor encoding, and it makes it difficult to use the date as a retrieval criterion. I argued this on the list back in May. Another problem is that notation in the <date> field cannot be modified. Consider the following encodings: <date qualifier="unsure">1954</date> <date qualifier="copyright">1972</date> Don't think your users understand the "c." abbreviation, or the Latin circa? You can change how an uncertain date is displayed. Users don't understand that "c1972" is a copyright date? The local system can display "copyright" as a literal, or the copyright symbol. It is this flexibility that data encoding can give us. But if "c. 1954" is acceptable in MODS, then that flexibility is shot. In the case of dates in particular, ISO dates, for example, can express ranges and different resolutions and additional attributes can add qualifications to the date. XML validators can check that the encoded data is, in fact, valid, and presentation to the user is a separble issue. Anyhow, XML allows use to separate data encoding from presentation. This is true for date, authors, whatever. Cataloging rules, specifically AACR2, do not allow for this. Attempts to support various cataloging rules should not cause us to throw away the benefits of this separation. Tod A. Olson <[log in to unmask]> "How do you know I'm mad?" said Alice. Sr. Programmer / Analyst "If you weren't mad, you wouldn't have The University of Chicago Library come here," said the Cat.


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

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