As batch projects accumulate, I have slowly been building up little bits of Python hackery that make the path to a batch import a little smoother. I have a Name class for parsing author names (and I can see a Namelist class on the horizon, because I do more damn HTML screenscraping than any six people should), I have a DC class for writing DSpace’s goofy little dublin_core.xml file without me having to think about it (and I can see a Contents class on the horizon—that one’s pretty easy, but I shouldn’t be rewriting the code all the time as I do now), and I’ve got a fair amount of actual code from previous import projects to analyze.
And it gives me to think more broadly about the repository’s getting-started and ingest processes and how they may be getting in my way. Call it my techie bias speaking if you will, but when Stevan Harnad quite rightly says “the only thing that has been standing between us and 100% OA for years now is keystrokes,” my response does not accord with his “an administrative keystroke mandate is all that is needed.”
My response is “Fewer keystrokes!”
It isn’t just keystrokes, though. It’s the notion of cognitive load, and it’s a simple notion: the more we make people think about putting stuff in the repository, the less of it they’ll actually do, because don’t we all have too much to think about?
I already reduced some of the cognitive load involved in getting set up to use the repository by shortening and clarifying the forms involved. Now I’m thinking to myself, “… forms?” I should find a way to get rid of them. It would help if I could bless other people to create DSpace communities and collections, or at least to access the web form involved and have me bless the creation later—that way they could actually do something instead of filling out a form to have me do it.
But, honestly, even that is too much. A faculty member interested in depositing content is interested in depositing content, not in navigating stupid DSpace hierarchies. So to hell with the hierarchies, to hell with forms, to hell with communities and collections. I want a bucket collection that any person signing up with an appropriate email address automatically gets deposit rights to. I’ll deal with the oversight, moving, and mapping myself, as need be. I’m the librarian; organization is my job. When they’re ready to move beyond the bucket and have a space of their own, damn straight they’ll let me know, and I’ll be happy to oblige.
What scares me about the above possibility (and it is technically feasible to do this, with the repository I run at least) is the vast undergraduate horde… but Shibboleth may be coming soon to a repository near me, so that would presumably solve the problem. Faculty, academic staff, or grad student? You’re in. Undergrad, check with the librarian first.
Also, this licensing thing, argh. It’s ridiculous to do this on a per-item basis. The relationship between faculty and repository is an ongoing one. It shouldn’t be formalized per-item. It should be formalized via something more like a memorandum of understanding, or—hey! Websites have those! They’re called Terms of Service agreements! So I want me one of them, and the legalese to back it up, and the tech to make new registrants click through it once when they sign up, record that they have done so, and never bother them with licensing again. Just as legal, and less cognitive load on every single deposit. Win!
(Creative Commons licensing does have to be done per-item, and I don’t have a problem with that. But the contract between the depositor and the IR doesn’t change—or shouldn’t—per item, so let’s just deal with it once, okay?)
The other big cognitive-load problem is, in a word, backfiles. Everybody but the newest, greenest faculty has a publication history. Nearly everybody who has come to me with a collection idea has some kind of backfile to deal with. Nobody wants to face the hassle of doing all that themselves, and quite right, too. Hassle is my job.
So I need another bucket, probably outside the repository altogether (because the thought of hacking DSpace to do this gives me heartburn), where they can just dump the backfiles and let me deal with them, with my little library of Python hacks and a lot of patience. Additionally, I need some kind of workflow that involves the least metadata-typing possible on my part. (Bum wrists, don’t you know.) Once I’m through with a project I’m doing now that involves an EndNote RIS export (and that I’m very happy about because it’s essentially simple, unlike HTML screenscraping!), I believe I am going to investigate what Zotero can do for me. I think it’s within my capacity to write an export filter for it that dumps stuff out in dublin_core.xml, and once that’s done its metadata-sucking capability should save me a lot of typing and get me better metadata than the usual run. Win!
And Zotero is something that I could teach other people to use. Since I’ve got 26 campuses to worry about, that’s a major desideratum.
So. Anybody in the LazyWeb, especially DSpace hackers, interested in helping me with any of this? I’ll be bringing up the policy and legal parts at my next DSpace meeting.
