The moderated discussion hosted and sponsored by Nylink went pretty well. Also, I don't need the records to have fun with the data "” I just need robust APIs. (In fact, as I said today, I'd prefer not to have to deal with the MARC records directly.) Robust APIs would help making prototypes like this one I hacked together in a few hours into a real, usable service.
I understand why the MARC leader position 08 is a good idea in theory. In fact, MARBI Proposal 97-07 suggests:
a change in definition to Leader/08 code "a" for clarification; making code "t" (Manuscript language materials) obsolete in Leader/06 and using code "a" instead; redefinitions of codes "a" and "p" in Leader/06; renaming the 008 for Books to "Textual (Nonserial); and deleting field 006 for Mixed material.
I can safely say that some pretty funky stuff gets cataloged with the leader position 08 set as "a," and much of it is incorrect, at $MPOW and otherwise. What is Leader/08 actually supposed to be used for? MARBI Proposal 97-07 again states:
Code a indicates that the material is described according to archival descriptive rules, which focus on the contextual relationships between items and on their provenance rather than on bibliographic detail. The specific set of rules for description may be found in 040 $e. All forms of material can be controlled archivally.
It's a bad pun, but what can you expect from someone who neglects his blogs as much as I do?
I've been busy, somewhat, and one of my latest forays has been getting a grip on Python, an absolutely wonderful programming language. I actually enjoy writing code again, which is more than a bit scary. I was sick of the mangled scripts and workflows I came up with at MPOW to handle converting MARC data to HTML and other such nonsense. Writing Perl made me feel unclean.
After playing around with Ed Summers' pymarc module, I began hacking about and putting my own hooks into the code here and there. I longed for MARC8 to Unicode conversion, which is a necessary evil. Digging around, I came across Aaron Lav's PyZ3950 module, which had its own little MARC code. After bugging Ed via #code4lib, and hassling Aaron in the process, Ed began incorporating the code and I started some testing. Just a short while later, the conversion code worked.
I've been thinking about the biblioblogosphere's reaction to Casey Bisson's decision to use the $50,000 he was awarded by the Mellon Foundation for his work on WPopac to purchase LC bibliographic data and open it up to anyone who wanted to take a crack at it. Yes, this is a "Good Thing," and valuable to the library community as a whole, but I feel like there are some things we're overlooking. Dan Chudnov and I seem to agree, but I'm not going to go so far to damn those who herald this as a "new era." It's a little premature to say where it will go, but I have to admit that I'm occasionally confused and often a little bit insulted by some of the talk surrounding this issue.
I wonder how interesting all the bibliographic data of LC is to begin with. What's in the dump paid for by the Mellon Award money? I'd guess monographs and serials, and probably audiovisual materials.
The technical services world has been in an uproar lately, between LC's decision to stop creating series authority records (particularly since they didn't consult PCC members beforehand) and the fallout after Calhoun report. We might as well have another drink, because as librarian.net reports (along with several others), OCLC and RLG are about to merge. It's mindblowing to think that RLG employees did not find out any sooner than the rest of us, and that either organization has yet to consult its members. However, RLG plans to do so, but it will be interesting to see how this pans out. In particular, some folks worried about the merging of data and the future of RedLightGreen. I know it's not considerably better, but they seem to be overlooking Open WorldCat.