Re: After MARC...MODS?

To distill down, the model says:

The transport format uses:
1. an integrated schema (which is:
2. populated by guidelines (which are:
3. based upon rules (as:
4. expressed in interpretations (which are:
5. inclusive of punctuation (and:
6. applied in various fashions (which are:
7. subject to local decisions (and:
8. flavored by typographical errors

-Aaron
:-)'


> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Weinheimer Jim
> Sent: Tuesday, April 20, 2010 11:09 AM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] After MARC...MODS?
> 
> Bernhard Eversberg wrote:
> <snip>
> MJ Suhonos wrote:
> >>
> >> Can you envision catalogers talking MODS to the same effect and
> >> efficiency they are now talking MARC? Efficiency matters.
> >
> > There's the problem: cataloguers are *forced* to learn how to "talk
> MARC" and thus become superhuman.  MODS, in contrast, is readable by
> "mere" humans.  Why do we require cataloguers who aren't doing under-
> the-hood system maintenance to understand MARC?
> 
> >
> No, to learn MARC does not consist of learning all the numbers and
> codes, that's rather trivial. You have to learn the precise meanings
> and
> the concept, and that's the same with verbal tags. You only *think* you
> understand something when reading verbal tags, but without the
> understanding of the precise semantics you are prone to producing a
> hell
> of a mess. Dublin Core data have proved this point in abundance;
> read Roy Tennant's "Metadata's Bitter Harvest":
> </snip>
> 
> A few points.
> 
> Here is an example in the mapping from MARC21 to MODS for uniform
> titles from http://www.loc.gov/standards/mods/mods-mapping.html:
> 130, 240 $a$d$f$k$l$m$o$r$s
> 730 $a$d$f$k$l$m$o$r if ind2 is not 2
> Maps to:
> <title> with <titleInfo> type="uniform" and
> 130, 240, 730 $n (and other subfields following as above)
> Maps to
> <partNumber>
> 130, 240, 730 $p (and other subfields following as above)
> Maps to:
> <partName>
> 130, 240, 730 $0 	add xlink="contents of $0" (as URI)
> 
> Now, compare this to the MARC Guidelines for the 240 field:
> http://www.loc.gov/marc/bibliographic/bd240.html
> 
> and the LC Rule Interpretations (these are the additions to AACR2, not
> AACR2 itself) for uniform titles:
> http://sites.google.com/site/opencatalogingrules/aacr2-chapter-25
> 
> Here is the Uniform title in UNIMARC:
> http://archive.ifla.org/VI/3/p1996-1/uni5.htm
> 
> A non-cataloger will probably ask: What is a uniform title? And that
> would be the correct response because there are different types of
> uniform titles for different purposes and they are terribly complex. It
> should also be accepted that there are legitimate reasons for this
> complexity. The above rules work together intimately to ensure
> standards for both the coding and standards for the information.
> (Except for the UNIMARC, which has different standards)
> 
> When you look at the mapping of MARC to MODS, there is a great deal of
> data loss. Therefore, let us take the version information: 240$s (that
> I have personally agonized over at times) just gets bunged in together
> to <titleInfo type="uniform"> along with lots of other information.
> This is definitely a loss of information. UNIMARC is probably as
> complex with uniform titles, while all the other formats will probably
> be very difficult.
> 
> Bernhard would have different entry practices for entering the
> conceptual idea contained in 245$s, but I am sure they have their rules
> for this. Yet, how do we share that information using MODS? We don't.
> We can't, since it mushes everything together. Therefore, MODS is not
> good enough for us to share with, e.g. the Germans even they may code
> the same information separately as we do in our 245$s. The only way to
> share is to either forget the separate $s or recode locally.
> 
> Still, to calm the working catalogers, they need to be aware that this
> "loss of data" happens only when another organization harvests your
> record, and these others can select from different formats, e.g.
> harvesting from American Memory right now, you can choose Dublin Core,
> MARCXML or MODS.
> http://memory.loc.gov/ammem/oamh/oai_request.html In any case, the
> information in the local database that the catalogers create still
> exists and is fine.
> 
> How much of this does the computer programmer need to know? I don't
> know, but the programmer doubtless needs plenty of help and should not
> expect to do such things on their own. There should be a happy medium
> somewhere.
> 
> James Weinheimer  j.weinheimer_at_aur.edu
> Director of Library and Information Services
> The American University of Rome
> via Pietro Roselli, 4
> 00153 Rome, Italy
> voice- 011 39 06 58330919 ext. 258
> fax-011 39 06 58330992