This week's muffin (non-vegan, store bought):
Assorted. Would you bake if it was over 100F and you didn't have AC in the house? Exactly.
This week's movies:
Part 5 of
Diane Hillman's Metadata Standards & Applications: metadata interoperability and distributionHow to build the semantic web using Dublin CoreLabels: 4M, metadata
I have resigned from CC:DA. The meetings at this year's ALA Annual will be my last as a voting committee member. As a new manager I've had less time to deal with the deluge of detail. My attitude since formally resigning last winter is wake-me-when-its-over. Once it's released I'll work with colleagues in my institution to determine whether or not we need to implement.
Let the triumvirate figure out the business case.
Don't get me wrong. I think RDA is a good thing. There's a good conversation happening at the
Inquiring Librarian about RDA implementation and the LC statement. I agree with Jenn Riley that
that RDA is overall a positive thing, and that it represents a necessary (although of course not perfect) step forward in the ongoing evolution of libraries
I'm also with Irvin Flack, who commented on Jenn's post
I want RDA to work but I've decided I'm going to wait for the full final draft before I try to read any more of it. I become too frustrated and confused. I can't afford to lose any more hair! I find myself wondering: why on Earth did they write that rule that way?
A-effing-men!
They wrote RDA by cutting and pasting wholesale portions of AACR2 then re-writing bits -- not a good way to create a whole new means of looking at content standards for cataloging, IMHO. It also introduced a lot of the consistency errors within the text. Then they re-arranged the ordering of the parts and only released certain parts at at time. I found it impossible to keep a cohesive mental model of the drafts. I look forward to the full release. I don't think I'll read it though. Life's too short. I resigned from CC:DA because I don't have time to faithfully review it and contribute to its development anymore. I'd love to follow it, but I need to be practical with my time and my health since
beginning to have problems in that realm. Not to mention
the hernia risk.
I intend to test catalog some things using the electronic version of RDA when available. Let the print version die please! I realize that some small, less funded, libraries will still need to work from a print version hence the JSC's decision to stick with publishing both print+online. But couldn't we write it online and let the people with less money print out customized versions rather than writing it as if we still live in a print-centric world when it comes to "standards" for working with metadata? That could help with the cohesiveness issues in the text.
As a manager of a small cataloging and acquisitions operation I sometimes wonder just how relevant RDA is going to be in our future. I suspect not much. Sorry. I had to talk about the elephant in my room.
Shelf-ready monographs, umpteen thousand title electronic resource packages, open access eBooks, etc. mean that I'll be ingesting more records directly from publishers. And do publisher's give a rat's ass about RDA? (see
EDitEUR) As for legacy bib records in my OPAC, I predict that somebody will write a MARC/RDA translator and that we'll be automating the migration of records (if it proves necessary, which I believe it may not).
I suspect it will be better for MPOW to play the middle road. Wait until other libraries adopt RDA and see how they do. I've got other priorities right now. MPOW is a specialized research institution. Our metadata services are moving in the direction of assisting with the information management of resources created on campus. Sure we'll always order books and journals but that stuff is going to become more automated as time goes by. RDA is not on my radar as a skill set I need to be training people to have. Understanding metadata formats and interoperability is a bigger concern. Ditto metadata for digital preservation and data curation. I suspect repositories and reference will be our library's life blood. I believe
John Wilbanks was right when he said providing things like namespaces will be the bread and butter of the new-school library. We need to have the skills to do that type of thing or we risk diminished relevancy when our primary clientèle's needs are not being met. And yeah, we need to do the appropriate needs assessment to determine that we prioritize in terms of evolving the library.
I'm filing RDA under nice-to-be-aware-of but not worth following in detail anymore. But that's just me. Your mileage may vary.
Labels: cataloging, CC:DA, life1.0, metadata, RDA
I've been spending a lot of hours of the past two weeks doing a batch import of 5001 ebook records from Literature Online.
It's been quite the educational adventure for me. Although I've been a working librarian for 13 years, I've only been a "cataloger" for the past five. At my former job I only ever had to use cataloging, serials, and, rarely, the acquisitions modules of Innovative Interfaces Millennium. Within each module I only used some of the functions with any regularity.
When I signed on at MPOW, they accepted my caveat that I wasn't a Millennium maven. They were comfortable that I could RTFM, especially since our Innovative coordinator would be handling most of the Millennium sys-admin. I know enough to bootstrap myself. Which I've done. Painfully.
Given the small size of our team in the Metadata Services Group, I've had to take on some more complicated batch imports. I knew how to do a data exchange, no problem. What I didn't know was that globally editing a large bunch of bibliographic records would fill up the transaction file on the server and cause
the.entire.system to crash. And I mean crash. No circulation check-outs, no back-end processing, nothing, nada, zip.
I learned this after doing a global update prior to going to a 2 hour meeting. Guess who got called out of the meeting? It was a bit hairy until I could locate our Millennium coordinator who saved the day by doing a manual back-up of the system.
Huh? A back-up? WTF? Apparently the only way to access a system menu option to clear the transaction file is during the back up dialog. That is stupid. I hope there is some technical reason for this because I think it should be possible to send a command to a server to clear a file without having to back-up (somebody please correct me if I'm way misinformed here). Of course, we don't have command line access to our server. Innovative keeps a tight grip on that type of thing. I can understand why, they probably don't want people to have enough rope with which to hang themselves. Whatever. When we migrate to a different ILS, which is inevitable (there's only two kinds of librarians. Those who've done a migration and those who will), I will insist that our requirements list include full shell access to the system. I know that Millennium lets one use regular expressions but I'm under the impression that access to that is still controlled from the GUI.
⟨rant⟩ We shouldn't let vendors have so much control over our systems. I recognize that there are situations where it's good for vendors to hold the reins (like small operations with no staff skilled to do the sys-admin). But there is an opportunity cost to the nimbleness of the library who relies on the vendor.⟨/rant⟩
One could do the global updating of records more quickly and easily with shell access and the right skill set. But, how many cataloging librarians are well versed in regex apart from the code4lib folk? Um, yah. Right.
MarcEdit came to my rescue, once again (I heart Terry Reese). Sorry
Robert, I wanted to use MARC Magician but they were too slow sending me a password for a free trial.
Global updating via MarcEdit is rather painless, once you get the hang of it. Getting the hang of it took me a few hours of messing around, however. The real bitch was doing the data transfer. Word up to my fellow Millennium users - 'tis sometimes better to use Data Exchange natively in Millennium than use records transfer from within MarcEdit. It's the only way to easily make a review file of records transferred.
I had to do several batch imports/deletes
before I got it right.
The #*$@!!% frustrating thing is that there were some global updates that could only be done natively within Millennium. Each run filled up my transaction file ~30% . Three big globals a day and you crash. That sucks. What will we do when bigger bulk imports are needed? Five thousand records is
nothing compared to the bulk ingests I foresee in our future (think GoogleBooks, etc.)
Naturally, I didn't want to keep interrupting our Innovative coordinator with requests to do a manual back-up. We have an automatic back-up each day at midnight. So each time the transaction file got 75-80% full I needed to stop for the day and await the magical file emptying before I could continue my learn-as-I-go batch work . Factor in that I had to each global a few times as I'd make newbie mistakes. You can understand why doing this took a few hours of my day for the past few weeks.
The final insult is that if you fill the transaction file in the midst of doing a global, the records which aren't yet updated will freeze. Twice I had this happen. Innovative only allows one to "free records in use" individually. A batch free-ing must be requested via their support ticketing system. And it may take them a day or two to do it. FRUSTRATING!!
There has GOT to be a better way. Really.
Labels: ebooks, III, MarcEdit, metadata, MPOW, what i did today
For each step two steps forward, there is the requisite step back.Last week's two steps forward: the
Rockefeller Press announcement (via Issues in Scholarly Communication) and the Harvard Law School joining the Harvard Faculty of Arts and Sciences in
unanimously adopting an OA mandate (via same).
Last week's step back:
Thompson-ISI puts restrictions on how authors using ResearchID (via Disrupted Library Technology Jester).
Thompson-ISI isn't high up on my fave vendor list because of their abysmal treatment of ISSNs within Web of Knowledge (don't get me started on the difficulties I encounter administering links to WoK within SFX). To their credit they're working on that. But this ResearchID thing makes it very obvious how they're developing their market -- they want to lock up author identifiers so only they can create web services with them. They've lost their monopoly on citation analysis now that Google, Scopus etc. are in the game. Makes me think that academic libraries better get on the ball with developing author identifier tools for their repositories and/or institutions. This is something I've been thinking about. I would love to make authority files for each faculty member and research group on campus and OpenID them or some such so that doing bibliographic citation analysis becomes more rationalized.
That's in keeping with a lively discussion the librarians at MPOW had with John Wilbanks of Science Commons during lunch last Monday. Wilbanks talked about the economic issues involved in creating and maintaining namespaces, largely who is to be responsible for long term funding and support. Wilkins said he believes that this is the type of work where librarians will find their niche as the academy moves towards cyberinfrastructure/eScience what-have-you.
Maybe. There's a big gap between the idea of librarians doing server/database/webby stuff and the reality of the technology skills of librarians on the front lines. I sure as heck don't know how to install and configure a namespace server. There are research and commercial interests which are way ahead of us on providing those types of services. Why should a researcher go to his librarian for help with managing his online identity if ResearcherID-type services already exist?
I don't know how to bridge that gap when it comes to what type of things I should be working on as professional development. Is it worth the energy to bootstrap myself into managing the technology behind semantic-webified authorities? That takes not only time but day-to-day projects with which to practice skills.
And technical services librarians are enmeshed in economically unsustainable models of cataloging and electronic resource maintenance anyway. For example, I've had to fix all the records for Proceedings of the Royal Society at each single place I've ever worked (hey, 300 odd years of title changes and splits makes for hard slogging managing the 78Xs and OpenURLs). This is the forest in which we toil and the trees are fading from view.
My only means of dealing with it is to partner with public service librarians to liaise with researchers, do user needs assessment for cyberinfrastructure services that we're capable of developing and delivering, then develop pilot projects from which to learn the requisite skills.
I fear that this type of work is too little too late for academic librarians. Yet, what choice do we have other than to persevere?
Labels: metadata, namespaces, open access, scholarly communication
This week's muffin (vegan as always): Lemon poppyseed
This week's movies: Part 4 of Diane Hillman's
Metadata Standards & Applications: Specific metadata standards and application overviewsTalis' Rob Styles on
Finding Relationships in MARC
Yay!
Shane joins the repository blog-o-verse . Personally, I don't mind the term repository-rat, having mentioned it on the
main page of the infodiva web site no-less.
Shane and
Dorothea mention the plethora of repository-related blogs. I think there are a fair number, actually, if you include digitization, scholarly communication, and open access as topics and if you are international in your scope. The folks in the U.K. pop to mind.
Note to self: look into making repository planet to bring these related blogs together.
Note to self: continue writing more here on Rep4Rest and begin promoting the blog. If I'm not visible I'm contributing to the perceived problem that there's a dearth of repository related blogs.
Welcome Shane!
Labels: open access, repositories, scholarly communication
MSG's weekly meeting with movies and muffins.
This week's muffin (vegan as always):
Carrot with walnuts & raisins (adapted from The Joy of Cooking)
This week's movies:
Part 3 of Diane Hillman's
Metadata Standards & Applications: Relationship ModelsSocial bookmarking in plain EnglishLabels: 4M, metadata
