τεχνοσοφια

Moving Day has come. In approximately six-and-one-half hours, movers will show up at my front door to take my crap — which seems to have multiplied, making me wonder if dark closets are particularly romantic environments for inanimate objects — and haul it down to Virginia. How did we accumulate so much crap? Why can we put a man on the moon, and a monkey into space, and yet we still can’t teleport matter? But I digress.

As excited as I am about working at LC, deciding to leave Princeton and the New Jersey area was not easy. New Jersey’s my home state, where most of my friends and family still live, and though I keep moving away, I’ve wound up coming back each time. (Insert obligatory Godfather “pull me back in” impression.) I was completely comfortable and very happy working at Princeton, where we were making real headway on building out the digital library. I’ll miss my colleagues greatly — the people I met at Princeton were all friendly and created a laidback workplace. I will miss our semi-regular lunches at Triumph brewery.

I have to thank Kevin Clarke specifically for making my time a real joy. He sheltered me and my colleague, Parmit, from a lot of administrivia and committees and meetings (oh my!), allowing us to concentrate on the job at hand, and was always supportive of our technology choices — I’m glad I’ve left a legacy at Princeton, namely saddling my replacement with a bunch of Ruby code and a couple Rails apps. I was especially thankful that Kevin and our administrators were fully behind my decision to release much of the software I wrote as open source (MIT/X11 license). They made the procedure an absolute snap, allowed me to retain copyright, and were flexible with regard to the choice of license. As an open source neophyte, I appreciated the flexibility.

Time to hit the hay, and hope that tomorrow’s move goes smoothly. We’ll have ten days to unpack and settle in, and I start at LC on the 29th of this month. I noticed today that one of the big projects my team has been working on got a write-up in the NY Times today (hat tip: Ed). I can’t wait to jump on board and start wrapping my mind around these projects. I fully expect to be overwhelmed and challenged. I’m really looking forward to it and I’ve got a great team to work with. But for now, I’ve got to rest. The movers will be here before I know it and we have a long day/week ahead of us.

The hard drive on my laptop is slowly failing and a combination of being busy, lazy, and cheap is preventing me from replacing it. About once every two weeks over the past couple months, one of the Windows registry files becomes corrupted and the XP disk is unable to repair it. And the HD fails basic manufacturer-provided diagnostics. But I’m stubborn. So I’ve been routinely resuscitating this box and I decided to post the process I use.

If you boot and see a message like

Windows could not start because the following file is missing or corrupt
C:\windows\system32\config\system

then you may be interested in this.
Continue reading…

Dorothea left a comment on a post announcing the publication of a little conference review some colleagues and I splurted out. In the announcement I lamented a bit about impact and she wisely suggested I consider depositing the review in a subject repository such as E-LIS.

We looked into our agreement with the publisher and it was actually quite permissive. (Way to go, Emerald.) And here’s the review in all its open access glory.

Thanks, Dorothea!

Reading Adam Smith’s D-Lib article has got me thinking about identifiers again. I don’t agree with some of the assertions in the section titled “A Persistent Identifier Primer” — URIs are in fact persistent; we just break them through poor management — and so I’m led to a fundamental question: what are the good use cases for Handle (or ARK, or PURL) identifiers?

I get the need for persistent and globally unique identifiers; I’m just wondering why one needs special software with a separate URI namespace to gain persistence.

One potential use case might be resources that are outside of the organization’s control — i.e., licensed content from vendors — but surely folks are using Handles for many resources that are created and managed within the organization. And I’m curious why they have decided that Handles are more durable than native URIs (the URIs to which Handles redirect), and how they deal with the problem of downstream (post-redirection) citation and bookmarking. How useful is this sort of identifier scheme if your users never even see the supposedly more persistent URI for a resource?

As a former proponent of Handles and ARKs, this may seem like a hypocritical question to pose. If I had to answer my own question, I would say that Handles seem like a good option because they save you some work and headaches in the short-term; you don’t need to get together with your web team and come up with a scalable and sustainable URI policy; just assign native URIs in the usual haphazard way and generate Handles to compensate for a lack of identifier policies.

But if you’re already making an organizational commitment to identifier persistence — and if you’re rolling out Handles, I’d wager that’s likely — why not do so by minting carefully-considered cool URIs? Less management and technology overhead and less confusion for your users are two good reasons to consider it.

On Monday I woke up with a very mild and very annoying bronchial infection. Doctor Me prescribed two days of rest, relaxation, and chicken soup. Where “chicken soup” is “finally dropping the unreasonably expensive and embarrassingly outdated web hosting package at Speakeasy and transferring all of my domains and content to Dreamhost,” that is. I am now paying less than a third of what I had been for a hell of a lot more features. And, I must say, administering DNS records, transferring files, and upgrading long-neglected software is rather amusing when you’re loopy and feverish.

My experiences thus far with Dreamhost are very promising. I’m impressed but perhaps that’s because I’ve been in the web hosting ghetto for so long. I understand there will very likely be downtime and sluggishness — that I can deal with. Being shackled to 1999 technologies for $30/mth, while my e-mails go unanswered, not so much.

I upgraded both Technosophia and my wife’s blog to the latest WordPress release (2.3) from something ridiculous like 2.0.3. In doing so, I also switched to the svn upgrade configuration Ryan Eby detailed a while back.

I crossed my fingers and it turns out the unAPI server plug-in still works in WP2.3. Huzzah! Not sure if it works in the 2.1 or 2.2 branches, but I suspect it does.