τεχνοσοφια

I confess: prior to today, I had never heard of Ada Lovelace. A number of bloggers whom I follow wrote about Ms. Lovelace today, which is apparently Ada Lovelace Day: "an international day of blogging to draw attention to women excelling in technology."

Inspired by their words, I thought I would say my piece as well. And so, this being the first Ada Lovelace Day, I'd like to celebrate the woman who is most responsible for my own love of libraries[1] and technology: my mother, Diane. My mother is neither a technologist nor a mathematician, and I'm pretty sure she's not comfortable in front of a Python interpreter. She was an employee at Rutgers University's Alexander Library during their first automation efforts in the '70s, partly while I was in utero. I like to think that library automation entered my bloodstream through osmosis back in 1973 and I've been working at this, well, not quite since then, but long enough. More than that, she got me hooked on libraries many years ago through frequent trips to neighborhood libraries and also by including me, in snot-nosed kid form, in her genealogical research that took us to some rural Maryland libraries and, yes, the Library of Congress. This thirst for knowledge (not to mention her constant and unwavering support for me despite the wacky paths I've chosen over the years) is why I celebrate my mother today.

Notes

1. I realize Ada Lovelace Day is about technology, not about libraries, but I hope you'll give me some slack. [↩]

Former colleague Trevor Dawes has written a thorough piece about a name change proposed by the faculty of Rutgers' School of Communication, Information and Library Studies (SCILS). They have voted on and approved a new name, School of Communication and Information, and it is now awaiting approval from the Board of Governors.

Trevor received e-mail from a current SCILS faculty member after getting involved in a discussion of the name change on a listserv. I find part of that e-mail[1], specifically the rationale for the name change, absolutely puzzling:

We just have so many programs now — we can't possibly cover all of them in our school's name. School of Communication and Information is something of a compromise name, but it does encompass all our departments and programs in the school.

So in order to cover more programs, the name of the school ought to communicate less? Does dropping "Library Studies" somehow represent Journalism, Media Studies, and Informatics students more?

I fail to see how removing "Library Studies" makes the name of the school more meaningful. Why not follow this rationale to its logical conclusion, then, and shorten the name to School of Information? Or iSchool? Or how about "School?" Yes, that's it, "School!" Then all the departments and programs are equally well-represented. Huzzah, faculty!

I should be clear about my objection. I don't mind SCILS becoming an iSchool. In fact, I think my education there could have benefited from a more iSchoolish curriculum. But any problems with the school then were not related to the name, and I doubt they are now. What I object to is the oddball rationale for the name change, and the notion that in order to affect change and improve the school, well, clearly a change in name will do the trick! It's putting the cart before the horse, especially when the MLIS program lacks a core curriculum[2]. This is change in name only and that is perhaps a missed opportunity.

Notes

1. Taken out of context, true. [↩]
2. An opportunity for real change, though I will admit that there are good arguments against having one. [↩]

While doing some reading for a little talk my colleague, Ed Summers, and I are giving at code4lib 2009, I came across a paragraph that sparked a crazy thought. So crazy that it's not crazy at all. So not crazy that I am sure other people have thought of it. But nonetheless, here I am writing about it just in case.

From Sarah Currier's paper on SWORD (emphasis mine):

One of the most frequently cited barriers to academics depositing their teaching materials into repositories is the keystroke-count involved in logging into a repository, uploading the resource, creating metadata, perhaps selecting a licence, and publishing the resource. It was a quick win, therefore, to create a drag-and-drop desktop tool to allow a single keystroke deposit of resources, including multiple resources in one action. For a repository that supports automatic metadata generation, administrative metadata can be created at the point of entry to the repository without the user needing to create any.

And I wondered how many repositories supported automatic metadata generation. I wondered how many repositories supported automatic generation of rich metadata. And lastly I wondered, might this be a more or less natural role for catalogers: augmenting stub metadata records or doing original cataloging for institutional repository deposits? Especially at a time when many of them are being reclassified as acquisitions specialists or digital projects managers?

Potential issues and questions:

• Author ignorance: Maybe catalogers are already doing this and I'm a moron?
• Scale: Is it realistic to expect to be able to "keep up" with repository deposits?
• Granularity: Does cataloging at the level of articles, and perhaps at even finer granularities, introduce challenges?
• Duplication: If pre-prints are cataloged in the IR, for instance, will they need to be cataloged again later?
• … there are others I thought of on my commute this morning but have since forgotten them. Feel free to add comments.

I will admit here that I've been somewhat out of the (academic) institutional repository space a while, and cataloging is something I don't share thoughts about very often because my exposure is limited to having taken one course a couple years ago.

I assume there's a body of research about this out there somewhere but I figured I'd post this anyway.

Lack of Talent, its hour come round at last, slouches towards podcastdom to be born.

It's late and I'm tired, so here's the skinny: at the beginning of the year I ambitiously[1] resolved to record one song per month. Instead I've serendipitously turned up the LOT recording sessions from July 2005, which we call the Burlap Overseas, and which I never really went through. Now that stuff is backed up six ways from Sunday[2] and I owe it to my fellow Lack of Talenteers to go through all these hours of raw audio and pick out some interesting bits so we have something to build on the next time we get together[3].

If you're interested, feel free to subscribe to the podcast and listen along. Updates will be sporadic, perhaps even spasmodic or spastic. Now the disclaimers: you should know that LOT was never about songs or practice or technique or order or music, really; we are true to our name[4]; it's about some friends gathering in my grandparents' basement with lots of music gear[5], even more alcohol, a box fan to keep us cool, a washing machine to clean Gramma's clothes, and a microphone that runs the whole darned time. This is booze-soaked sonic experimentation among close friends and even if you hear nothing else, you should hear hints (or squeals, or yawps) of joy amidst the cacophony.

Notes

1. Read: foolishly [↩]
2. Phew. I am a paranoid backup freak. [↩]
3. Est. 2013 [↩]
4. At least I am [↩]
5. We switched instruments often, sometimes even playing the ones we could "play." [↩]

Dear Future Me,

It has been a while, hasn't it? Yes, it has[1].

Did you try to view an HTTPS/SSL URL in Lynx[2] again, only to be met, most cruelly, with the following error message?

$ lynx https://example.org/resource/[3]
Alert!: This client does not contain support for HTTPS URLs.

Well, have no fear! The lynx package, at least within the aptitude repositories for Ubuntu 8.10 (Intrepid Ibex), has no SSL support as you have just witnessed. The lynx-cur package, on the other hand[4], does! Support SSL, that is. Fix yourself thusly:

$ sudo apt-get install lynx-cur

N.B. the new lynx looks for its configuration in a different place than the old lynx, so you may need to fiddle with things if you've tricked out lynx with bells and whistles and racing stripes and nitrous boosts. Otherwise, huzzah!

Notes

1. In the future you will have evolved beyond answering your own questions, no doubt, but here in the past, in this quaint and backwards era, it is quite common to hold conversations with yourself. Or myself. But I (i.e., you) digress! (We digress in the past as well! Quite the confusing state of affairs, conversationally speaking!) [↩]
2. Do they even have Lynx in that brave new world of the future? Does the lynx species still exist? Did the polar ice caps melt and wipe out all non-domesticated felines? Inquiring, unevolved minds of the past want to know! [↩]
3. I am assuming that in the future example.org remains a reserved dummy domain. [↩]
4. I hear that in the future hands will be replaced by hooks and detachable chainsaws and the like? [↩]