Caveat Lector

All the cool kids are going to see Serenity. And I’m not. Because public transportation around here sucks beyond belief, especially on weekends.

Sigh.

O ye who have TypePad or many other third-party-hosted blogs: I hope you don’t think you can move anything but your words. You can’t, not legally.

I went digging through TypePad’s terms of service to see how feasible it would be for the repository to pick up a blog hosted there that’s written by some grad students at MPOW. I found what I expected to find, which was discouraging enough: TypePad owns its designs, and one needs “express written permission” to do anything with them.

So what the heck, I sent them email inquiring about said permissions, and explaining why I wanted them. The answer was a flat no. I can ask the blog authors to export their stuff (I don’t know what TypePad exports into; I suspect it’d be something like the old MovableType flat-text file), and I can futz with said stuff to get it back into HTML, and I can build my own design around that. But I can’t archive TypePad’s HTML/CSS.

I hope they’ve got an Atom export. I truly do. I’d far rather work with that than try to build a MT-flat-file-to-HTML hack all on my ownsome.

In any case, I’m not pleased. Let this be a warning to libraries using services like TypePad: don’t put anything there unless you’re willing to redesign it from the ground up for archival or use on another system.

Amazing, what commenting out one line of code will do.

Uche Ogbuji got in touch with me to inquire about my 4Suite issues. Because I am not terribly skilled with XSLT, I couldn’t even make a stab at explaining what had gone wrong, so I just sent him my stylesheets and source and let the 4Suite developers have at it.

Today he sent me back a link to 4Suite’s CVS. Comment out one line of code, he said; that’s the fix.

So I did, and it was. Stylesheet is now zippy as a pinhead, and I don’t have to worry about bindings to some other XSLT processor. This makes me very happy, and I thank Mr. Ogbuji and the other 4Suite developers!

I also thank Norm, Aristotle Pagaltzis, and my buddy Marc M. for lending a hand in response to my original yell for help.

I spent a fair bit of time reading this examination of scholarly digital projects in literature (specifically American literature).

As the authors themselves say, if you’ve kept your eyes open for a while, there isn’t much here that’s new. Old-school tenure committees won’t give digital editions any credibility. Creating a good digital edition takes time, money, and technical skill, none of which grows on trees. The academy is far more eager to consume digital texts than produce them. Some folks are dog-in-the-manger, seeing no benefit to sharing their work for others to use or expand upon; others won’t participate in a digital project they can’t sell. (Before you laugh, librarians, I heard a librarian espouse precisely that latter attitude a week or so ago. Dogs in our manger too.)

Read carefully, though. Watch the negative spaces; what’s missing from the discourse?

Right. Libraries and librarians. Other than a few tentative mentions of institutional repositories, and some lip service to “hey, maybe we oughta get the librarians involved,” we might as well not exist.

Who’s got the technical skill to do TEI right? We do, damn straight. (In passing, I note another disadvantage to losing track of former graduate students. In the case of medievalists, certainly, you lose a lot of potential text geeks.) Who’ll commit to keeping a digital project available indefinitely without so much as breaking a URL? Hell yeah, we will. Where do you find geeks with advanced degrees in the humanities? Among us, you better bloody well believe. For whom are digital projects a welcome and expected part of the job? For us. Not you. Us. Us librarians.

Where are the partnerships? Where?

Eh, well. Some colleagues and I are trying to nurture a nibble from a faculty member who means well, but doesn’t quite know what to ask us for. Of such seeds are great things born, I dearly hope.

This business of being a sysadmin, even in the small and limited way I am one, doesn’t turn out to be the drunk-on-geekly-power experience it’s sometimes touted as.

See, I want to install this gizmo that gives individual DSpace submitters their own mini-CVs. It’s a nice gizmo, works well, would be a great draw for potential submitters…

… and I’m not going to install it, because it’s not a real plugin; it monkeys with existing code. I’m not willing to commit to the additional upgrade hassles, particularly the danger that I might not be able to upgrade at all for a serious length of time because I can’t afford to break the new gizmo.

If DSpace were further along in the development curve, I wouldn’t be as upset; I could stand to wait a bit to let the gizmo developers over at Rochester catch up. As it stands, though, every new release of DSpace adds serious new functionality. I don’t want to delay upgrades any longer than I absolutely must.

This too will pass. Eventually we get a real plugin architecture. I’m finding it silly hard to wait, though.

I finally got around to writing up and shipping off my comments on NARA and RLG’s audit checklist for trusted digital repositories. I see no particular reason not to share them more widely; I hope other commenters do the same, because I expect to learn from their comments.

I have elided references to MPOW; otherwise, verbatim.

–

I am impressed with the thought and consideration that produced the Audit Checklist for the Certification of Trusted Digital Repositories, as well as the clarity with which it is written. It is already informing my policy- and procedure-development work, and I am extremely grateful to have it.

My comments on the August 2005 draft follow. I am open to further discussion, and would welcome additional opportunity to affect the document’s development.

General comments:

• Some listed technical requirements, particularly in sections B and D, seem to pertain more to repository-software platforms than to individual instantiations of those platforms. Would it be acceptable for an individual repository to point to its platform software’s documentation as evidence of adherence to these guidelines during an audit? If not, audits will entail significant duplication of documentation effort by individual repositories running identical software.

  On a similar theme, might NARA-RLG consider a requirements checklist aimed specifically at repository-software developers? And what remediation will be required of individual repositories running out-of-the-box or experimental software? Is filing a feature request sufficient, or must the repository hire developers to fix deficiencies?

• I would like to see this document address usability and accessibility of the digital-repository user interface. In my experience, attention is only paid to accessibility for (e.g.) the print-disabled when documents such as the Audit Checklist require it. Also, it is important to note that the user interface that end-users of content see is only one relevant interface. When submission to a digital repository is performed by the content creator or owner via a software interface (as it often is), that interface absolutely should not bar content creators and owners with disabilities from submitting content.

Section B2.7:

• I would like to see enumeration or discussion of non-straightforward cases where the integrity of a collection could be called into question. What exactly is at issue, besides discrepancies between a collection description and the actual collection? Also, what internal or external documentation is adequate to bolster claims made in a collection description? What language should be used or avoided in collection descriptions to prevent discrepancies?

Section C (and Appendix 1):

• I am deeply concerned about this entire section. Any repository that serves multiple constituencies will find satisfying this section’s requirements an administrative nightmare with dubious (if any) return in improved service or preservation potential.

  What repositories serve multiple constituencies? Mine, certainly. The [repository I manage] is intended to serve the entire university: all of its departments, all of its research units, all of its professional and teaching faculty. Nor is [the repository] unusual in that respect. I might also point out the Washington Research Library Consortium, whose soon-to-launch repository will serve half a dozen entire institutions. Entire states (entire countries!) are starting repositories to serve wide-ranging constituencies. One-constituency repositories are few and far between, and given the current environment (e.g. demonstrated publisher hostility to subject-specific repositories) are likely to remain so.

  I find myself in a cleft stick. If I write a Designated Community statement that covers every possible community that a university department or research unit might target, the statement’s obligatory vagueness and breadth will destroy any conceivable use of the statement as a diagnostic tool. If I myself try to write separate Designated Community statements for every community that uses [the repository], I will undoubtedly write some of them poorly or incorrectly.

  Moreover, I will have shouldered a major administrative burden, considering that Designated Communities will certainly change over time, especially as the Audit Checklist currently defines them. For example, hardware and software requirements for content access form part of Designated Community statements. Must I revisit statements on every release of relevant software?

  Finally, if I ask potential communities to write and maintain a Designated Community statement as a condition of submitting work to [the repository], I erect a barrier to attracting submitters. Current library literature says loudly and clearly that attracting submitters and content is the most difficult aspect of running a successful repository. Barriers are bad, and I find this one especially troublesome because submitters are unlikely to acknowledge or even understand the necessity.

  And I have not even touched on the administrative burden imposed by C4.1, in which I am supposed to test every single agreed-upon Designated Community for apparently unlimited aspects of content understandability! If none of my other comments receive attention, I must ask that this section be rewritten to enumerate the aspects of “understandability” that must be tested. I see metadata and hardware/software requirements mentioned in this section; if that is all, the section should say as much. If the repository’s user-interface usability is also implicated, this section should make that clear. The fuzzy statements about understandability in Appendix 1 simply do not suffice.

• Reading through the intended uses of the Designated Community statement, I find that it is a yardstick for metadata quantity and quality (C2.1), content-delivery constraints (C3.1), hardware/software requirements for content consumption (C1.3, C3.1, C4), and access restriction (C3.3).

  Of this list, only access restriction seems easily and productively definable in terms of designated communities. I fully expect that my constituencies will consult me if they need to restrict access, and I fully expect to document their requirements, comply with them, and be able to demonstrate that I have done so.

  I would prefer that metadata quantity and quality be defined in terms of adherence to published metadata standards and best practices. I understand perfectly why I should have to make clear that [the repository] uses Dublin Core metadata; published standards such as OAI-PMH mandate Dublin Core use. I do not understand what [the repository]’s use of Dublin Core has to do with any or all university-specific constituencies or user communities.

  I would prefer that content-delivery constraints be uncoupled from designated communities entirely. When such constraints exist, they should be properly documented; that should suffice.

  I would prefer that hardware and software requirements for content consumption be defined primarily in terms of content format, not content audience. (The sole exception I can imagine would be blanket protection for classes of users such as the print-disabled. Even then, such protection cannot be absolute, or repositories would not be able to accept scanned images of written or typeset pages.) Documenting the software and hardware requirements for accessing content in an uncommon format is eminently reasonable, as is documenting migration or transformation plans for uncommon or proprietary formats.

  Defining this necessary documentation in terms of user communities senselessly complicates otherwise straightforward issues. If 90% of my constituencies only submit PDF and HTML preprints, for which preservation and access issues are well-understood, should I not focus my documentation efforts on the remaining 10% and their unique needs, rather than impose a bureaucratic burden that 90% of my constituencies will find pointless?

I salute RLG and NARA for producing the Audit Checklist, and I hope these comments on the August 2005 draft prove helpful.

I like Mac OS X. I like it a lot. I dig GUI plus command-line.

But not being able to turn off handholding I don’t need drives me crazy. So before I bash (no pun intended) my G5 with something large and heavy, let me ask: is there a way to turn off OS X’s damnably annoying spellchecker permanently, for all applications?

I know, I know, Edit menu to Spelling, uncheck Check Spelling As You Type. For some of my apps, that only lasts for the one session. I want it to be for always, and I don’t want to have to uncheck the same damned menu option for every app I use.

There must be a way. What is it? I’ll update this post with the (credited, of course) answer when I get it.

Today was so nice I think I want to repeat it. Since I have twice as much vacation time as I’ve ever had in my life, I think I may use a day every month or two to go do something fun.

(In passing—the vagaries of the public transportation system here make “doing something fun” vastly easier on a weekday than weekend. I mean, that differential is everywhere, but it’s extreme here. DC public transport caters to commuters. Period. I shall have more to say about this one of these days, but in the meantime, I am seriously considering asking whether I can move my workweek to Tuesday through Saturday, or Sunday through Thursday. It’d honestly make my life easier and more fun.)

Anyway, David and I metroed ourselves down to the zoo, which despite being under heavy construction has a tremendous lot to see. Five rowdy adolescent cheetahs did their level best to terrorize the Grevy’s zebra next door; the zebra eventually told the younguns what was what with a snorting bray and an impressive display of kicking.

Tian Tian the panda was asleep in his enclosure with his back to his adoring public. Oh, well.

In the birdhouse, the male Malaysian argus pheasant had hopped out of his enclosure with the white-faced ducks and was parading about in front of it. When somebody else got too close for his comfort, he simply hopped to the top of the fence and right back in. He’s got the right idea; the fences are to keep us out, not him in. He’s a right impressive-looking specimen, too. The aviary was delighfully free of screaming children (which it never is on weekends), so we had a wonderful time birdspotting with binoculars and matching voices to faces. The sunbittern, alas, was quite silent.

We cruised around the big cats, ate lunch with the hippo, watched the orangutans and the gorillas (and felt terribly sorry for the big silverback who kept holding his fists to his ears to block some of the horrid construction noise) and scooted down to the mammal-house (past the outdoor golden-lion tamarins) just in time to see a very patient keeper showing off Pandora the tenrec, a hedgehoggy sort of critter hailing from Madagascar with a mobile snoot and cute grabby feet.

Eventually we meandered down to Amazonia. On the upper level, we happened upon a railing sporting a scarlet ibis. I duly gave the creature space, edging past it to the opposite end of the rail so that I could look over and see the big turtles in the water underneath.

The ibis sashayed down the rail toward me. I froze. The ibis regarded me for a moment, decided I wasn’t dangerous, and started nobbling at my hands with its beak. Said beak looks far more dangerous than it turns out to be; it’s blunt-ended and doesn’t close hard enough to pinch. Special attention was paid to the rings on both my hands; David surmises that the creature is descended from ancient Egyptian temple ibises accustomed to accepting gifts. Me, I think it’s just used to hand-feeding. Either way, I have been most thoroughly ibis-nobbled. (And if the poor bird has been infected with avian flu, I’m a dead woman. Oh, well. Interesting thing to die for, at least.)

And Amazonia has another sunbittern, who was gracious enough to serenade us. There isn’t a lovelier sound on this earth than a sunbittern whistling.

The invertebrate house boasted a tank of chambered nautilus; the animals are as handsome as their shells, which I hadn’t previously known. We also saw an enormous sort of gaudy-colored lobster, whose keeper proudly brought out the shell from when it last molted. Lobsters have furry feet. Truth. Who knew?

I’m leaving a lot out—it was a full day. Afterwards, we meandered down to Meze on 18th Street for dinner, which we thoroughly enjoyed. Anything they make with red lentils is a winner, and the veggie kabobs are nummy too.

My feet are raw and tired and I’m salt-skinned from sweating, today being tropically humid. But my instinct was right—the way to start feeling at home here is to start building a store of memories that just couldn’t have happened anywhere else. I will not soon forget being ibis-nobbled.

The Dream seems to be healing from his gimpitude. He still limps, but not all the time, and less painfully than before. Makes me happy. He’s a good citizen, Dream is—to everyone but his sister, anyway.

We’ve accepted an offer on the house. Inspection pending; if all goes well, close end of next month. Don’t quite dare to breathe the sigh of relief yet, but I’m definitely happier than I was.

I’m thinking at the moment that we’ll wait a bit to buy something. I’d prefer to be past my first contract renewal, for one thing, and for another, my sense is that prices locally will be stagnant to down for a while. Even with that, we could stand to save a bit more before we wade into the hip-deep housing prices around here.

I’m playing hooky from work tomorrow (not really—I duly asked for and was granted time off) to go to the zoo. Been spending too much time in the apartment, which is no way to put down roots in a place. Looks as though it’ll be a mite rainy tomorrow, but that doesn’t necessarily signify. The National Zoo has a wonderful indoor aviary, for one thing.

See, I knew right from the day I interviewed at MPOW that the liaison librarians were going to be my salvation or my damnation, one or the other. Fortunately, it turns out they’re more interested in saving me.

They kindly afforded me 45 minutes yesterday to tell them what the repository was all about. (With their schedules, 45 minutes is truly a kindness.) Less than a day later, I have a strong lead, two introductions pending, and an appointment next week to build a game plan for a likely department.

Mua-hahahaha. I’ll make this a success yet.

My first unmediated chance at faculty comes October 5, when I give an open lecture as part of an IT-talks series. The big job there is going to be replacing screenshots of the old MARS in my presentation, which task I’ve slated for tomorrow. Wish me luck…