On 04/08/2011 09:59, J. McRee Elrod wrote:
<snip>Of course, catalogers never see the raw MARC format either. The problem with producing XML from MARC is that much of the internal structures of MARC is transferred into the XML. This is primarily why so many have said that MARCXML is not one bit better than MARC as it is now. (I disagree and emphasize that it is a very important, and inexpensive *single step* in the right direction compared to what we have now) In my own opinion, I agree that retaining numbers instead of the names (in English) would be much better, but so many have been so vehement about this, I just gave up--because in the end, it's all just computer codes and to the computer, it makes no difference whether something is coded "100a" or "personalNameMainEntry" or anything else you can come up with. The way the code is then displayed to the searchers or to the inputters (catalogers) is entirely up to the system designers, so that "100a" or "personalNameMainEntry" can display to them this way, or in Russian, Chinese, UNIMARC codes or pictures of Elvis Presley during different periods of his life! :-) They can display any way at all. Plus, one person on a computer can have one rendering, while a person on the computer sitting right next to it, looking at exactly the same record, can have it in a completely different rendering.
But seriously, XML is certainly inadequate as a medium for data input and editing. A software interface will have to shield the raw XML entirely from the view of catalogers.Exactly. MARC is a shorthand - so much easier to say 130 and 240 than to give them verbal names.
XML has the ability to "play with others", but we can produce XML from MARC more easily than we can create it directly.
One of the real practical advantages to users, (at least I think) of XML comes with being able to create web services that can do all kinds of things. So for example, if I am interested in the archaeology of Rome, I could download an app to my Iphone, or an API to place on my website, that would automatically query the LC catalog for the 10 latest books on Roman archaeology and retrieve only the titles, which would have links to the complete records in the LC catalog so that if I am interested in something, I could get more information. Or the same could work with catalogs in Italy (non-MARC21) or the Blackwells catalog (perhaps in ONIX) or some websites I may have selected personally on Roman archaeology that provide reviews or something, plus some other full-text databases on Roman archaeology (who knows what any of these formats would be?).
Or better yet, as is very possible today, to search all of this at once automatically and bring them all together into a single page for me to peruse and to further sort and work with in all kinds of ways. There are thousands of variations on this but ISO2709/MARC21 breaks down in this kind of environment since its purpose is to transfer complete catalog cards from one library catalog to another. It is also very probable that in such an application, MARC21 (i.e. library data) would not be the most utilized format, and if there were no handy and relatively easy-to-use XML format, developers would think it wasn't worth their time and not include it, resulting in the disaster that our data would end up being ignored completely by the vast majority of people who are interested in the archaeology of Rome. (This refers to my comments in the first paragraph about why I changed from mind about changing from the MARC numbers to entire words)
What role does, and should, the cataloger, with unique skills, play in such an environment? The cataloger should play a very, very big role, I think, but we must first consider what a cataloger does in ways that are different from the traditional roles.