 |
 |
> 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