> So, um, could librarians everywhere start being just a tad bit more
> demanding about this stuff? You know, before your profession becomes
> obsoleted from this planet?

The basic problem is that the real value of a catalog is its
consistency, and the legacy data in these fields is already too
inconsistent to have much value.

The good news is that despite the fact that some fields are just
hopeless, many things in the catalog are decent. The consistency of
structure and the quality of content in author, title, and subject
fields is significantly better in a library catalog than it is in
other sources. That is why faceting works pretty well.

Where things really start falling apart are the special purpose
fields. Between some libraries deciding these aren't worth filling in,
catalogers not being aware of them, etc, they are inconsistently
applied. Even among the few that entered relatively consistently (such
as 043), there is usually a better source of data (e.g. 6XX |z)
somewhere else in the record

If data aren't consistent enough, it's just not useful no matter how
good your system is. Plus, any system that actually knew all the MARC
tag and indicator twiddling would be hideously complex. Do you really
want to design a system that exploits the special tag indicating if a
piece is a Festschrift, has color illustrations, or a portrait? Do you
think that exploiting the full power of the 007 would not confuse the
heck out of everyone or that a special field which exists only to
discuss funding associated with the content of the piece needs special
treatment and that any work units or task numbers associated with that
funding need to be stored separately?

The data in the fields above are hideously inconsistent, but even in a
perfect world where it is all correct, I'd argue it's still not worth
screwing with -- especially since there are plenty of basic aspects of
the patron and staff experience that need serious work.

> Actually, I was wondering what areas MODS can't handle which MARC
> does, hijack and / or change MODS to fit it (what I know of it seems a
> bit limiting, but through XML certainly extensible). Shouldn't folks
> start by demanding at least MODS (or XOBIS if we're *really* crazy :)?

Frankly, the important stuff is there and it would be possible to
modify MODS to accommodate the things that aren't. The main reason
you're stuck with MARC is that there are a lot of legacy loaders out
there so even if all transmission was done in MODS, you'd still have
to convert it to MARC.

There are arguments to do so, but the business case is not strong.
That data providers won't send MODS until libraries demand it.
Libraries won't demand it until their systems use it. Systems won't
use it until libraries demand it because that's what their data
providers require.

It's a vicious circle, so we're stuck with MARC. The only people who
aren't happy with this arrangement are those who are trying to create
something new. Many librarians who think they use MARC every day have
no idea that it is a binary format that is unfriendly to eyes and
machines.

Just because something makes sense does not mean it will happen. The
QWERTY keyboard is terrible, every modern operating system can support
the technically superior Dvorak layout, yet we never switch. I'm a bit
more optimistic getting the content of the catalog record into a
container better than MARC, but that will take a long time.

kyle