On the subject of XPath, the example I crabbed about is EASY compared to some of the things one has to do to get the right data out of MARCXML. The XPath syntax when one has to get a particular subfield from a particular field with certain indicators, is IMHO extremely convoluted. The two problems I see with using MARCXML is that the person writing the code has to have a pretty good knowledge of XPath to deal with, and that same person needs to understand the intricacies of the MARC record syntax. Frankly, I don’t find that all that common in libraries, let alone outside of libraries.

Which leave us caught between using a complex and cumbersome standard - MARCXML and a simpler standard which isn’t rich enough from a metadata perspective - Dublin Core. Forgive me but I just don’t find that satisfactory.

Name ::= (Letter | ‘_’ | ‘:’) (NameChar)*

… so it has to begin with a letter, underscore, or colon.

Even if XML allowed numeric names, I don’t see how it’s significantly more difficult to match nodes with XPath syntax like “//245″ vs. “//datafield[@tag='245']“. Selecting records based on the value of leader position 18 certainly isn’t fun, but then it isn’t much fun in MARC21 either.

So MARCXML is nothing more than re-encoding MARC21 in XML format. The major benefit over MARC21 is that you get to work with standard tools and standard encodings.

The benefits are pretty clear once you’ve considered what MODS is actually providing. As a first-order example, you get semantic interpretation of MARC for free. For instance, titles, with all their constituent parts, are separated out for simple use using straightforward XPath. This means you don’t have to be a cataloger to actually build a display system around the data. No referencing AACR2, no learning the (sometimes vague and often confusing) interplay between subfields and indicators. Just simple, straightforward, explicit data with a well thought out structure and layout.

It’s hard to overstate just that benefit alone, really, because most library developers are not, in fact, catalogers.

Also, consider newly emerging efforts, such as the Bibliographic CQL Conext Set ( http://www.loc.gov/standards/sru/cql-bibliographic-searching.html ) which explicitly references MODS as the structural model for searching. Non-cataloger developers, let alone non-library developers, can read that and understand easily and at a glance how to implement a standards-compliant SRU interface to thier data or even how to consume other sites data, MARC or otherwise. One of the implications is that we can push ourselves and our data out into the wider world by lowering the barriers to entry for library/non-library collaboration.

I may sound like I’m gushing a bit, but I honestly believe that MODS is one of the most important foundational (and, unfortunately, one of the more under-utilized and under-appreciated) technologies that the library world has developed.

–miker