Caveat Lector

??? ! ?! !! ? !!!

I may at some point come up with coherent commentary. I’m not counting on it, though. I’m still stuck at “Bwuh?”

We all have certain songs that we find irresistible. Songs for dancing. Just gotta get up and shake some booty.

I’m not quite sure what it means that my husband’s shake-your-booty song is the Doctor Who theme. I am, however, vastly amused by it.

Everybody knows about xkcd. It’s one of those best-kept secrets that everybody knows. For a long time, this was my favorite xkcd ever, because regexes were the first really nerdy programmerish thing I ever learned to work with, and I was ever so proud of myself at the time.

Alas, that most excellent cartoon has been relegated to second place. Just too much win in today’s. I laughed, I identified (I’ve been in that IRC room!), I pumped my fist, I Twittered it, I rejoiced.

I’ve seen some concern here and there that “Joanna” isn’t the person in the ’toon who has voice; Hat Guy explains it all. This does not in fact bother me, because I think a subtle point is being made (and unfortunately missed): women should not be the only people put off by this buffoonery, and men can damned well speak up about it too, and should.

Plus, Joanna gets the EMP cannon. Mua-hahahahahahahahaha. I want one!

Rock on, xkcd. You just rock right the hell on. The title text (hold your mouse over the image) is just the crowning glory.

And for those who think the Wyoming mudflap girl is no big deal, consider this non-work-safe variant. Still no big deal? Think about your reactions. Think hard, damn it.

(The notion that the Wyoming campaign is somehow “reclaiming” the mudflap-girl image is just weak. Reclamation of offensive terminology is done by the offended group, y’all. If that’s going to happen to mudflap-girl, it has to be done by women, the group that the image systematically turns into raw meat. Librarians != women, and women != librarians. Try harder, people, really.)

Apparently it’s not possible to Creative-Commons-license a DSpace submission via the UI after the ingest process is complete. This is brain-dead stupid, but so much is.

There appears to be a technical way around this, though it is somewhat cumbersome. Use it with all due care; I refuse to be responsible if you CC-license something you shouldn’t and an angry faculty member comes after you with long knives. Also, I’m in the middle of testing this myself; I’m not 100% sure it works yet.

The way CC licensing works in DSpace is that various files (”license_rdf”, “license_text”, and “license_url”) get added to an item in a CC-LICENSE bundle when a depositor clicks the appropriate buttons to add a CC license. So if you add those files to that bundle for an existing item, as far as I can tell, it’s CC-licensed.

If you’re going to try this hazardous little trick (did I mention it was hazardous?), the first thing you need to do is collect those three files for the various available CC licenses. There is probably an easy way to do this, but the hard way is to hop onto your test server (you do have a test server, right?) and put in a few faux items with CC licenses, then use the command-line ItemExport tool to export them. The license files will be in the exported directory.

Now use the ItemExport tool to export the item you want to license. Add the three files pertaining to the appropriate license to the exported item directory. Then add these three lines to its “contents” file:

license_rdf	bundle:CC-LICENSE
license_text	bundle:CC-LICENSE
license_url	bundle:CC-LICENSE

Make sure that the separator between filename and bundle is a tab character.

Stick the new improved item directory back on your server (if it’s not already there), and (this is important!) run ds_migrate on it, because if you don’t you’ll have even more junky useless format and date metadata than DSpace usually keeps. Then use the regular item importer on it, remembering to add the –replace flag.

Should do the trick. I hope. We’ll see.

Edited to add: Works as advertised. I have a whole CC-licensed collection now!

The latest issue of the Journal of Digital Information is all about institutional repositories. A lot of it is garbage. Some is reports on initiatives that may well be worthwhile but won’t bear fruit for years (”asset actions” are definitely the right idea, but my head hurts at the mere idea of implementing them in something other than Fedora). Some is more vague business-speak happytalk prescriptions, and nobody needs that any more.

(Repository-rat to Thibodeau: It takes two to tango. The repository can do its level effing best to court allies, but if the platform is crap and possible allies just plain aren’t playing, what next? And does all the fault lie with the repository and its managers, as your article implies? If I sound frustrated, it’s only because I am. No fun being everybody’s whipping-boy.)

Now to my thesis: No more surveys. No. More. Surveys. Damn. It. They produce no insight, no practical suggestions, and no comfort. They’re useless. Stop sending them out.

Their counts are highly suspect, especially when they try to interrogate growth over time. This is partly because item counts are themselves substantially useless, and partly because I do not waste my precious work time obsessively keeping track of how much stuff I have at any given moment. I don’t know how fast the repository I run has grown—but I do know that some of the apparent growth is spurious, because I imported a large image collection recently, one item per image. Item counts are useless.

Since these surveys are usually not designed by repository-rats, the questions are often poorly-phrased or unanswerable. I do not know who does submissions in a lot of the repository I run. The software is designed such that I don’t have to know that, and frankly I don’t want to! I do not know, except in vague and impressionistic (and likely wrong) terms, what proportion of the materials in the repository are peer-reviewed versus student research versus ETDs versus interesting tidbits like the snowflake collection and the audio-lecture series I’m currently working on. I do not know which disciplines contribute what, and frankly I think it’s a useless question.

DSpace statistics suck. Find out how badly they suck before you ask me statistics questions (downloads, most popular authors, most popular collections, etc.) that I can’t bloody answer.

Moreover, I cannot accurately estimate the success rate of any of my outreach efforts, most crucially because results are rarely immediate. Sometimes something I do that I think is a complete dud bears fruit months or years later. Sometimes success is completely random. Sometimes interventions that I have good reason to believe would be successful are completely out of my reach. That’s life in big bad Repository City, and if it makes your damnable surveys unreliable, stop doing them.

I’ve bailed on a few repository surveys recently, they’ve made me so mad with their genial cluelessness and the number of questions on them that I can’t realistically answer. Keep that in mind when you read the next bog-standard research article based on a survey.

Qualitative research (which in my opinion is the way to go right now) hasn’t been done well yet. I talked to somebody a while ago who was very enthusiastic and fun to interact with, but obviously hadn’t done her homework in the library literature and didn’t know nearly enough about how academia and academic libraries function. I don’t have high hopes for what gets distilled out of her interviews; I’d rather see her publish transcripts, frankly, because those might be good.

Right now I’ve got some researcher wanting to talk to me about the planning process for the repository I run. Hello? I wasn’t there. Hiring the repository-rat is what happens after the planning process is done. This basic failure of clue makes me want to say extremely impolite things. I won’t, except here; I’ll be good and let myself be interviewed.

But I ask you, what does it take to find some researchers in possession of a clue, not to mention an actual desire to help people like me instead of treating us like lab-rats?

So one of the problems with DSpace in both its JSP and Manakin incarnations is that authors get lumped together with editors, translators, advisors, and many other sorts of contributors in a number of the displays. This is confusing at best and outright wrong at worst. I promised several of my colleagues that I’d fix that in Manakin.

I’m trying to start slowly here, with the simple display of titles and authors found in (for example) the Recent Submissions section on community and collection pages. Found that bit (and let me congratulate the Manakin devs on the nice, sensible display choices here):

        <div class="artifact-title">
            <a>
                <xsl:attribute name="href"><xsl:value-of select="@url"/></xsl:attribute>
                <xsl:choose>
                    <xsl:when test="$data/dc:title">
                        <xsl:copy-of select="$data/dc:title[1]/child::node()”/>
                    </xsl:when>
                    <xsl:otherwise>
                        <i18n:text>xmlui.dri2xhtml.METS-1.0.no-title</i18n:text>
                    </xsl:otherwise>
                </xsl:choose>
            </a>
        </div>
        <div class=”artifact-info”>
            <xsl:choose>
                <xsl:when test=”$data/dc:contributor”>
                    <xsl:copy-of select=”$data/dc:contributor[1]/child::node()”/>
                </xsl:when>
                <xsl:otherwise>
                    <i18n:text>xmlui.dri2xhtml.METS-1.0.no-author</i18n:text>
                </xsl:otherwise>
            </xsl:choose>
            <xsl:text> </xsl:text>
            <span class=”date”>(<xsl:copy-of select=”substring($data/dcterms:issued/child::node(),1,10)”/>)</span>
        </div>

So, okay, for title we’re grabbing the first dc:title element, and for author we’re grabbing the first contributor element regardless of its qualifier (which is the problem that I want to fix), and for date we’re going straight to something (element unimportant, as I read it) with a qualifier of “issued”.

Huh. So if I read this right, we’re assuming that no two DC elements happen to have the same qualifier for any reason. I suspect that works out fine in practice (though what about dc.contributor and dc.creator?), but it seems, well, brittle. Hacky. Kludgy.

What I don’t quite see how to do is create an XPath that takes both element and qualifier into account, since they’re in different namespaces and may not have any structural relationship to each other. (Where’s the documentation on this particular METS profile, anyway?) Anybody got a brilliant answer?

When last we saw Mouser, she was a skittish, scrawny little thing with scabs all over her forehead.

Check her out now. Sleek, healed, and happy.

As for the integration project:

Each of them knew the other was there. Neither cared to make a chancery case of it.

Edited to add: A fan club. Mouser haz it. I’ve gotten two emails and an IM already!

Woke up this morning, ate me some breakfast, and settled down on the couch with Buffle to get some work done. Fantasy read-alikes, this week’s class lecture, more on the ASIST poster…

Kernel panic.

Reboot. Kernel panic. Reboot again. Kernel panic. Try to reboot from the install DVD. Kernel panic. In desperation, hit up Google (from husband’s machine) and learn how to reboot into single-user mode. Do so. Run fsck, which comes up clean. Reboot. Kernel panic.

A very patient friend to whom I now owe substantial quantities of good booze reminded me about target disk mode and walked me through backing up my home directory to my husband’s machine. Crisis demoted to emergency, I tried the next trick: reinstalling OS X to Buffle in target mode from my husband’s machine.

In one of those brainstorms that always happens ten seconds too late, I realized five seconds after I booted my husband’s machine from Buffle’s install DVD that Buffle is an Intel Mac and my husband’s machine is a G5, and never the twain shall use the same install DVD. My husband’s machine promptly kernel-panicked, and wouldn’t restart from disk instead of DVD, either. Nor could I eject the DVD.

Just then, Buffle the Wonder-Duck earned its sobriquet. In desperation, I tried one more time to boot it, and it booted, and I slammed my husband’s machine into target disk mode and ejected the DVD. Husband’s machine fixed, I turned my attention back to Buffle the Wonder-Duck—

—which promptly kernel-panicked.

I hopped on the crosstown bus to Madison’s Apple Store and bellied up to the Genius Bar. The Genius on duty tried not to wince at the words “kernel panic,” tried a few diagnostics that didn’t work, and popped the case on hearing that I had third-party RAM installed. “Oh,” he said. “These aren’t even installed right.” He shoved them in, and lo and behold, Buffle was fine.

My weekend’s work is shot to hell, of course, so I’m taking the day off work tomorrow to get caught up. But three cheers for smart friends, the Genius Bar, and Buffle the Wonder-Duck!

I am a total sucker for word art. I love it. Letter shapes, colors, design and layout… I am a complete putz with visual art and design, and the only time it bothers me is when I see calligraphy. That I wish I could do.

Fortunately, Alma Swan can. All y’all have just got to be checking out this year’s and next year’s Open Access calendars (PDF, of course). They are made of win and awesome, and yes, if they come out in a nice glossy calendar thing I’ll buy several.

One small suggestion: these images would be fantastic to use in slideshows and printed promotional materials. Could they be put online in various resolutions under CC licenses?

My students are the connected ones, the technically-minded ones, the ones unafraid of novelty. Some of them flat-out don’t believe me when I try to (more or less gently) pass out clues about the technical atmosphere of librarianship. That’s okay. They’ll find out for themselves, and they’ll remember what I said, and they won’t be as shocked by it as I was.

I read through the freeform comments on Nicole Engard’s survey about what people learned and wish they had learned in library school, and I recommend that you do the same. It’s a curious mix. There’s a raft of comments wanting more (and more practical) technology training. There’s also a raft of comments wanting more and better cataloguing training.

Wait, what? Cataloguing? Not “cataloguing and metadata,” not “information management,” not “bibliographic and other sorts of description.” Cataloguing. From a bunch of librarians who manifestly aren’t cataloguers. What gives?

I’ve been letting that question percolate in the back of my head since I read the survey responses. I’m afraid the answer is probably an it’s-all-more-complicated constellation of mindsets and external forces, but I want to push back against what I see as the easiest and most obvious conclusion that could be drawn from the evidence, which is that MARC cataloguing is the center of the library universe.

(It ain’t the center of my universe. I don’t get anywhere near it myself, and I’m firmly in the Roy Tennant “MARC Must Die!” camp. If that makes me not a librarian, well, okay. I’m sure Peter Murray-Rust would find work for me somehow or other.)

Some while ago I went to a library-internal meeting at which people shared what they’d learned at the last big ALA conference. Someone had gone to one of Roy Tennant’s ILS talks, and had emerged rather shocked by his ideas. After all, she said, structured bibliographic description can’t disappear forever!

Aha. So now we have one locus of confusion. MARC and structured bibliographic description are not equivalent, except (it would appear) to a lot of confused librarians. I’m willing to bet that some of the librarians in Nicole’s study are reacting to what they see as a threat to the larger world of information organization, perceiving MARC as a proxy therefor. This is nonsense, of course, but who’s going to tell them that in such a fashion that they understand it?

I am consistently boggled by people asking me for training on DSpace’s deposit interface. It’s a series of brain-dead web forms, for Pete’s sake. No, they’re not perfectly usable (in fact, there are some pretty brain-dead design choices in there), but they’re just web forms! If you can do your banking online, you can deposit stuff in DSpace. Training?

But I see this all the time; it’s a much larger issue than DSpace. Librarians are a timorous breed, fearful of ignorance and failure. We believe knowledge is power, which taken to an unhealthy extreme can mean that we do not do anything until we think we understand everything. We do not learn by doing, because learning by doing invariably means failure. So a librarian just won’t sit down with AACR2, Connexions, and the AUTOCAT mailing-list archive and work out how to catalogue a novel item. Nor she won’t sit down at the computer and beat software with rocks until it works.

She’ll sit passively, hands in lap, and ask for training, feeling guilty the whole time for displaying ignorance.

So what does this have to do with how often cataloguing came up in Nicole’s results? Well, I don’t think all these librarians are asking for cataloguing training because it’s vitally important to their everyday work. They’re asking because they feel ignorant about something that they have been told (hat-tip to Yee and Gorman) is the center of their profession, and they don’t feel capable of learning on their own. MARC/AACR2 is bloody complicated, after all—and the more complex something is, the more librarians shy away from learning by picking apart one piece at a time.

Fundamentally, cataloguing training is not going to help these people. It won’t help them feel confident about MARC and AACR2, because I don’t know anybody who does (and I do know some cataloguers, thanks). It won’t help them feel more confident about the future of the profession, because like the librarian at the ALA-wrapup meeting, they won’t understand that the external forces that are forcing MARC out of the picture don’t really threaten them. (”I don’t see how programmers can do any better [than MARC]!” blustered one of Nicole’s respondents. That’s not arguing from a position of considered strength. That’s flat-out ignorance, is what that is. Go sit in the corner until you’ve done some reading up on data mining.) And it won’t help them do their jobs any better.

What they need is to kick off the training wheels, honestly. Their locus of control vis-a-vis technology needs to move a long way inward. There is nothing more frustrating than dealing with fear-based apathy. I don’t mind intelligent skepticism; I’ll prove a given tool’s worth or I’ll abandon it. I don’t mind dealing with genuine problems. They happen.

I do mind, quite a lot, having to stand over a grown professional’s shoulder teaching her to use a set of essentially self-explanatory web forms because she cannot be bothered to learn by doing. And I do this a lot. Once I’m done with the repository redesign, I’m going to come up with a screencast on the subject so that I don’t have to do it so often.

I think training-wheels culture may be the source of a lot of the friction between so-called “twopointopians” and their opposite numbers. When “look, just give it a try, okay?” falls on wilfully deaf ears, strident advocacy is a natural, expected response. I myself roll my eyes at some of the more “moderate” responses to Library 2.0 and new OPAC developments and whatnot because I know perfectly well that training-wheels culture uses “moderate” responses as figleaf excuses not to change, not to learn, and not to try.

One of the things I’m trying to do with my class is encourage them to lose their training wheels. Some of them don’t have any—but a few do, and I’m hoping I can do my little bit to encourage the decline and fall of training-wheels culture.