 |
 |
On Sep 25, 2011, at 6:45 PM, Karen Coyle wrote: > Before we start revising data formats, shouldn't we get very clear about our requirements? If those requirements can be fulfilled with a revision of MARC, then that's what we should do. > Good point. I passionately believe they can--we need to at least explore this before we move on. > However, I have a feeling that we haven't even begun to define our requirements (and "just like MARC" isn't a requirements definition). I did one blog post with some very general concepts [1], but it needs to be taken much further. > You're correct. We need to make sure generalities are replaced by solid specifics. > I've heard some requirements that we can begin to gather up: > > - the field names need to be easy to 'universalize' in a language-neutral way. MARC tags do this nicely, with the downside that they have to be learned and therefore only work with trained users. Perhaps we can have it both ways, in a sense the way we do today, with underlying codes for experts who need to communicate widely with colleagues, and display forms for the less expert (both users and inputters). Funny you should say that. Way back in the 1980s and early 1990s, NOTIS systems did exactly that. There was a feature which one could use a three character 'mnemonic' tag instead of the numeric tags. I accidentally was recompiling the tag table, and had the wrong flag set and the next morning the catalogers woke up to 'TIT' for the 245 and 'AUT' for the 100, and then the filing on/off indicators were set to N for Negativa or A for Affirmativa as to whether that tag was to be indexed (or produce a card in those days). So we could easily assign a alpha character set when learning MARC, if it was to be expanded to say 4 characters--a better mnemonic than with only 3.. > - the ability to carry both display text and identifiers for controlled vocabularies, with the option to have both or either without disrupting the data format. Yes, are you also speaking of a VOC $ that links it to the authority record? > - ISO 2709 has been used for MARC21, Unimarc, MAB and other formats. The next data carrier needs to be at least that flexible. > - there is a need to create relationships between bibliographic items, such as part/whole relationships. (MAB and other formats already have this ability.) > > I'd like to add: > - that our data needs to play well on the Web Absolutely. Now here's where some xml magic may work in the display of the data. > - that it uses data where possible, not text Please explain what the different data and text is. > > I'm sure there is a lot more, but we have to be clear on our goals before we select or modify a data format. > This is great that we are talking about "that which must-not-be-spoken". I know we are just tossing out ideas. I hope from this, we can create the synergy necessary to move this into reality. Jeffrey Trimble System LIbrarian William F. Maag Library Youngstown State University 330.941.2483 (Office) [log in to unmask] http://www.maag.ysu.edu http://digital.maag.ysu.edu ""For he is the Kwisatz Haderach..."