Caveat Lector

Via IM: “I think barbrarians are exactly what this world needs.”

I think that neologism is made of such immense mountains of win that I am going to steal it. And possibly have it tattooed on my arm.

I’ve been itching to post about this for quite some time, but it wasn’t general knowledge. Now it is, and I want to call attention to it.

The Bamboo Project (PDF) is—well, I’ll let them explain it:

Bamboo is an multi-institutional, interdisciplinary, and inter-organizational effort to bring together researchers in arts and humanities, computer and information scientists, librarians, and campus information technologists to collectively tackle the question: How can we enhance arts and humanities research through the development of shared technology services?

It’s a grant project that they’re asking Mellon to fund, and Mellon would be fools and madmen not to. (The folks at Mellon aren’t fools or madmen. Ergo I expect great things. Small disclaimer: MPOW may be touched by this project if it is funded—though I fell in love with it before I knew that.) But even the summary I just linked to is thirty-odd pages of distilled brilliance for anyone who’s interested in research computing, humanities research, digital humanities, or (yes) repository services. You must read it. You simply must. I can’t talk about how brilliant it is without babbling inanely, and everyone else I know who’s read it has been agog at its wonderfulness.

Any study project of this nature faces two major hurdles: have you fully and clearly understood the problem, and have you a workable and practical solution to it? IRs clear the first bar, but fall all over themselves at the second. This proposal soars high over both bars. I couldn’t be more impressed.

This is just my attempt to get a little buzz started around it.

Now that I have personas, I can actually talk about repository design.

Well, sort of. I do want to talk out-of-band about a couple of the personas first. Les Carr pointed out to me in email that Ulysses is a bit of a luxury item; a lot of libraries combine him with Menelaus. This is absolutely true, and I was considering building a persona on a satellite campus to reflect that reality. However, the “maverick manager” model exists too (I’m one, and the model applies broadly to consortial repositories), and my suspicion is that the more complex solutions that work for the Ulysses/Menelaus division will also work for institutions where Ulysses and Menelaus are the same person. So for now I’m going to stick with what I’ve got, reserving the right to revisit that decision later.

Something else to notice about Ulysses is that he is also a stand-in for libraries that outsource the repository IT to vendors. They’ll face many of the same functionality and responsiveness problems that poor Ulysses does.

If you’ll recall, Cassandra Athens wants to use Achaea’s repository for two things: to export the problem of potentially-copyright-violating faculty postings to Ulysses, and to form automatically-generated CVs for faculty websites. Let’s talk about the former problem first.

Since Cassandra isn’t stupid, she has probably set up her CMS to have an upload area, disallowing any other way for faculty to put random files up on the Basketology website. (And Dr. Troia and others probably howled about it, but so it goes.) Faculty have two options: they can use Cassandra’s uploader, which Cassandra would vastly prefer they do, or they can put their files someplace else and link to them from the Basketology pages they control, which lands Cassandra right back in the quagmire she’s trying to escape from.

Some social engineering will be required here; Cassandra may well have to go to the chair of Basketology and make a stink about copyright liability. She’ll be much happier about doing that, though, and the chair much happier about dealing with the problem, if Cassandra has a workable alternative to propose.

The design goal, therefore, is to have Cassandra’s CMS talk to Ulysses’s repository such that faculty find it easier and safer to use Cassandra’s upload mechanism than to bypass it—without adding significantly to Cassandra’s ongoing workload. (Ulysses has time to throw at this; except for a few up-front development and testing cycles, Cassandra doesn’t.)

“SWORD!” you may be yelling at me at this point. No. SWORD won’t work, because SWORD more or less assumes you have a nice tidy well-described object to swap around. At most, Cassandra can squeeze a file and a (badly-formatted unpredictable text) citation out of faculty; sometimes they won’t even bother pasting in the citation. Moreover, SWORD is a difficult target for Cassandra to program against, and her CMS doesn’t natively deal with it.

She needs to be able to tell her CMS to email or FTP the file, the CMS’s identifier for the file, and what little information it has about the file somewhere; her CMS needs to receive the item’s handle or other permanent identifying URL in return along with the CMS’s identifier, so that she and/or faculty can link to the item in the repository easily.

This problem can be solved in several ways. Many people reading this will doubtless come up with better solutions than I could. If you do—no fair changing the design constraints, do you understand me? The design constraints are the whole point of this exercise. If your solution doesn’t work for Cassandra, it doesn’t work at all. (You think I’m draconian about this? Read Alan Cooper.)

Ulysses needs the repository to receive the CMS’s email or watch the FTP folder it has been told to watch, and to notify him that Cassandra’s CMS has fired a file at him. He then rights-checks the submission, applies metadata liberally, arranges for licensing, and (assuming that all checks out) sends the item live, whereupon the repository knows to notify Cassandra’s CMS. Ideally, the repository would even construct and shoot back a pretty, properly-formatted HTML citation! None of this can involve Ulysses interacting directly with the repository server, because Ulysses isn’t allowed to do that.

I repeat: This problem can be solved in several ways. Many people reading this will doubtless come up with better solutions than I could. If you do—no fair changing the design constraints, do you understand me? The design constraints are the whole point of this exercise. If your solution doesn’t work for Ulysses, it doesn’t work at all. (Seriously. The Inmates are Running the Asylum. He means you, software developers.)

A few DSpace-specific notes. DSpace’s per-item licensing paradigm is all wrong, and I suspect it shares this problem with EPrints, because the root of the difficulty is the OAIS model, in which rights information must be tightly associated with the object to which the rights pertain. This is great for the OAIS model, in which happy little computers talk to other happy little computers, but it’s a disaster for any kind of ongoing interaction between actual people and the repository, as Ulysses’s paper-license insanity illustrates. (That, by the way, was drawn directly from a real-world situation. I refuse to point fingers; you’ll have to take my word for it.)

A Terms of Service agreement is a much human-friendlier solution; Dr. Troia can be told to go click through it, and after she does, neither she nor Ulysses has to be bothered with licensing, and the repository can be smart enough to put the correct rights information in each item. For third-party deposit, Ulysses might have to indicate which author is to be considered the licensing author—but honestly, the repository ought to be smart enough to check the author list against ToS signatories, and let the deposit go through if even one author has signed.

(The repository must also allow for un-signing of the ToS; the obvious use-case is a faculty member leaving the institution. This cannot be allowed to affect previously-deposited items, but it should halt deposit of future items that depend on that faculty member’s consent.)

DSpace’s other major problem is its unwieldy workflow system, which doesn’t really cover the use-case just expressed. DSpace doesn’t even kick an item into the workflow system until it’s been uploaded and all the metadata is complete, which is exactly bass-ackwards from what Cassandra and Ulysses need it to do. Ulysses needs a staging area where Cassandra’s CMS can dump stuff until he can get to it. DSpace doesn’t have that.

There are other minor nits. The reject notice for an item that doesn’t pass a rights check needs to go to the corresponding author(s), not to Ulysses. DSpace needs an external-facing notification mechanism more sophisticated than email. Ulysses needs to be able to shove Basketology off on Menelaus, once everything is running right and Menelaus has learned how to check rights—Ulysses can’t possibly handle the entire campus doing as Cassandra has done, because there aren’t enough hours in the day. All of this is solvable, some of it trivially.

So. Let’s get to work? I hear there’s a repository-programming event coming up…

A week ago Tuesday, I power-walked down my street and onto the shore drive, only to stop dead and stare… at an immense full moon setting over the Park Street corridor, blessing even that ugly mass of brick and concrete with beauty.

Walking home from the class I’m auditing that same day, I enjoyed the privilege of watching the moon rise over Monona Bay, huge and deep-orange and just a bit shape-distorted from being so low over the horizon. I chivvied my husband into going out to look at it as soon as I got home. He thanked me for sending him out into the subzero cold.

Holy cats, this is a beautiful place.

Only in Wisconsin: I walk out into the roughly-freezing-point air this morning, happy that I don’t have to wear my goofy-looking hat to keep my ears from frostbite, and have a neighbor greet me with “Isn’t it nice and warm out?”

Yes. Yes, it sure is. Pity it won’t last. But I wouldn’t trade my Frozen North for all the beaches and deserts in the world.

This is another in my series of personae related to institutional-repository development. Previous personae include Menelaus Fox, Cassandra Athens, and Dr. Helen Troia.

This entry requires a somewhat stronger disclaimer than the last few. Ulysses Acqua is not me, not even a thinly-disguised me. (For one thing, I’m not typical, and Ulysses is as typical of what I call the “maverick manager” class as I can make him. For another, Ulysses is a lot more sympathetic a character than I am.) Achaea University is neither the University of Wisconsin nor George Mason University. (For one thing, Achaea’s librarians are tenure-track, and I’ve never been.) I’ve been a repository-rat for two and a half years; I’ve heard a lot of stories, talked to a lot of repository managers, read a lot of books and articles and pondered their subtext. All of that, in addition to my personal experience, informs the portrait of Ulysses Acqua.

One more note: This portrait is limited to aspects of the repository-manager’s job relevant to repository software design. Ulysses also faces serious institutional and social barriers that I’m not talking about, because they can’t be developed away. For those, read Roach Motel.

Ulysses Acqua was hired six months ago to take the reins of Achaea University’s new institutional repository. The planning process for the repository had gone completely by-the-book; his job description reads as though it came straight from SPARC. Unfortunately, the book Achaea University was reading from didn’t say anything about pilot projects or signing up participants before the repository opens. Ulysses walked in the door to an empty repository, no plan for filling it, and no further contact with the repository-planning working group, whose charge was fulfilled when the repository-librarian job ad went out.

Ulysses doesn’t have to do the systems-administration work involved in running the repository; that’s handled by campus IT. At first, Ulysses was relieved by this, because he isn’t fluent in Unix or SQL or Java. A few months into the job, though, he discovered a great many things that he simply can’t do because he doesn’t have server access, from batch ingest to metadata quick-fixes to doing something about the repository’s hideous sore-thumb visual design and confusing interaction patterns. When he talked to campus IT about this, he got a runaround; the library is only paying campus IT to install and maintain the repository, not customize it or develop for it, and librarians are never given command-line server access because of security concerns. When he brought this barrier up with his supervisor, he was told that he’d have to live with it, because the library can’t afford to jeopardize its good relationship with IT, and certainly can’t afford to divert funds into repository development. Maybe next fiscal year, if the repository deserves the expenditure. Ulysses walked out of that meeting muttering something about chickens and eggs under his breath. Why hadn’t the planning committee foreseen this need?

He is frankly embarrassed by how ugly the system is, and how little it does; he finds himself apologizing for it constantly. Can he show statistics by author and item? No. Can faculty edit items they’ve ingested? Um, no. Ulysses explains that the repository is an archival system. Faculty shrug. They don’t need an archival system; they need somewhere to stash their stuff, including stuff they’re still working on. Does the repository take learning objects? Not really; it’s not set up for the right kind of metadata. Can it preserve the dynamic, database-backed website one faculty member’s image collection lives in? No. What about a straightforward image collection? Sure, but the browse process is painful and can’t be tweaked. What about TIFF page images from a scanned book or article? Yes, but again, there’s no good browse interface for them, never mind OCR. What about a CGI calendar application? No. What about a journal run? Sure—but it can’t easily display articles by journal issue without the overhead-heavy process of creating a new collection for each issue. Can it connect items with other items? No. Can it connect material ancillary to a published article with the article it pertains to? No.

Deep breath. Onward.

Can it produce CVs or departmental-activity reports automatically? No. Can it be tweaked so that the Basketology collection looks like the Basketology website? No. (The software can do that, in fact, but Ulysses can’t.) Can it talk to campus IT’s file-storage-cum-website servers? No. Can it harvest faculty articles from disciplinary repositories? No. Can it deliver records straight to Achaea Library’s catalogue? No. Can it have access controls per item, such that items are shared with specific people only, with the list controlled by the depositor? No. Can it embargo items, for a certain length of time or indefinitely? No. Can it read a citation, check rights on the journal, and go fetch the paper if rights are cleared? Dream on. Can it restrict items for campus-only access by IP address? No. Does it talk to RefWorks and Zotero and similar bibliographic managers? No. Does it do version control? No.

In short, there are quite a few campus functions that Ulysses and his repository can almost help with—he’s talked with endless faculty, and lots of academic staff like Cassandra Athens—but “almost” isn’t good enough for anybody, and the repository (he is told by campus IT) isn’t easy to mash up with other services, or develop on top of. He wishes he could do better; Ulysses sees real needs going begging, and he likes to be useful. With no developer talent available to him, shackled to a hopelessly inadequate tool, he doesn’t know how he can.

In the early days of his job, Ulysses brought up his use-cases on the mailing list for the software his repository runs on. Mostly he was ignored; once one of the developers insulted him for his lack of technical expertise, since what Ulysses wanted was apparently possible if he had server access to tweak some settings. Ulysses doesn’t bother writing to that mailing list any more, and his email client filters its messages to their own folder and automatically marks them read—there’s nothing there that can help him.

The licensing process is another major headache for Ulysses. He went down to University Legal shortly after he started his job, since the planning committee hadn’t done this part of the planning for him. He was told that any license had to have two signatures on it: that of the person licensing their content, and that of someone with signature authority for the university. Who has that? Achaea’s dean of libraries. In practice, this means that Ulysses has to get a license signed on paper for any item that Ulysses ingests on behalf of a faculty member—and frankly, that’s almost all of them! The irony of paper licensing for a digital repository isn’t lost on him, you’d better believe! He keeps a file of these paper licenses, since there’s no way to make the repository cognizant of them. If the library building he works in burns down, oh well.

The overhead involved in getting faculty ready to deposit is another stumbling-block. A faculty member told that he can put stuff in a digital archive signs up to put stuff in a digital archive! He doesn’t sign up to create “communities” and “collections,” whatever those are, and he’s certainly not going to wait (not even ten minutes!) while Ulysses scurries around behind the scenes getting him deposit privileges. Ulysses reads Jakob Nielsen, so he knows to say that his “conversion rate” is completely dismal. Not that there’s anything he can do about it.

Although he believes strongly in the open-access movement and is convinced that over the long term it will change the way researchers and libraries do business, Ulysses has to face facts: Achaea’s repository isn’t going anywhere and isn’t likely to, and that has serious repercussions for his still-young career. He is scrabbling together articles and conference presentations at a great rate (in areas of librarianship having nothing to do with his actual job) in hopes that notoriety will placate the tenure gods. He is also looking seriously at jobs in library website management, instructional technology, and grantwriting, as well as considering further training in scientific data curation.

Placed as he is, what else can he do?

This is another in my series of personae related to institutional-repository development. Previous personae include Cassandra Athens and Dr. Helen Troia. Menelaus is a fabrication based on experiences I have had and people I have talked to.

Menelaus Fox is a collection-development librarian at Achaea University; Basketology is one of the several departments whose library collection he is responsible for. Every semester, Menelaus canvasses those departments’ faculty asking what books he should acquire and what journals he should consider subscribing to. Response is at best mixed; many faculty never answer at all, though Menelaus values the easy, collaborative relationships he has developed with a few, such as Dr. Helen Troia of Basketology. Menelaus spends a lot of time skimming publisher catalogues, book reviews, local faculty CVs, and other sources of information to make the Basketology collection the most useful it can be; he also reviews books in his area that come in via publisher approval plans, to make the final acquisition decision.

Menelaus also handles specialized and in-depth reference questions for the departments he serves; he has even been listed as coauthor on one or two Basketology publications by grateful faculty. When Basketology comes up for reaccreditation, Menelaus will write the report section on the library’s Basketology holdings and Basketology-related services.

Achaea University librarians are on the tenure track, and Menelaus is not yet tenured, so he somewhat reluctantly spends some of his time researching and writing articles for publication, as well as serving on two library-association committees, one for the state library association and one for ALA. Add to that all the usual library group work—search committees, Librarians’ Assembly, outreach committees, monitoring the Faculty Senate on behalf of the library, et cetera—and the occasional reference-desk shift or instruction session, and there just aren’t enough hours in Menelaus’s day.

Menelaus’s time crunch became all the more acute when a collection-development colleague retired and her budget line was removed from the collection development department to allow for the hiring of something called a “Repository Librarian.” Menelaus has nothing against the man they hired, Ulysses Acqua, but the loss of a position hurt his department badly; several of his colleagues are even more hurt and resentful than he. He won’t say so, but the shift in hiring priorities worries him. Is what he does still valued by the library and by Achaea University? Or has everyone gone off the digital deep end?

It’s not that Menelaus is technophobic. He adapts; he has to. When ordering went electronic, when book reviews went online, when he had to learn to evaluate online databases for quality, he adapted alongside his colleagues. He even likes instant-messaging, as it saves him a lot of pointless phone-tag. But librarianship began with the book, and it’ll live and die by the book—all this digital stuff won’t last past the next natural disaster, and then we’ll all value the printed word as it deserves.

Menelaus isn’t quite sure what to make of Ulysses and the service he runs. He isn’t even sure what Ulysses does all day; they didn’t have digital repositories when Menelaus was learning his profession. He understands all too well that journal prices have gone completely beyond insane (when Elseviley bought the American Journal of Basketology its price doubled almost instantly, and hasn’t stopped rising since), but he doesn’t see how a website is going to make a difference.

He’s looked at the site. It’s ugly; the mid-1990s want their web design back! It doesn’t look anything like the library’s regular website, either—what, does Ulysses have some kind of problem with the library? There isn’t much in it: some technical reports, a podcast or two, one or two retiring faculty putting their entire CV’s worth of publications in. A few hundred items, no more. Menelaus isn’t impressed, and that’s before one mentions the unbelievably pathetic cataloguing. He heard somebody in Tech Services sneer about that the other day, but he didn’t mention anything to Ulysses, because Ulysses is a decent enough fellow, earnest and very much invested in what he does. Whatever that is.

At Ulysses’s polite urging, Menelaus tried bringing up “open access” at a Basketology faculty meeting. It went over like a lead balloon, and Menelaus hasn’t made another attempt. Ulysses asked him about putting his own publications in the repository too, but Menelaus courteously put him off. It’s not like Menelaus doesn’t have plenty of other things to do, and he sure isn’t hearing any urgency from library management or faculty outside the library on this score.

He’s just going to wait and see.

This is another in my series of personae related to institutional-repository development. The first persona is Dr. Helen Troia. Cassandra is a fabrication based on people I have met and problems I have tried to help solve.

Cassandra Athens is the webmaster for the Department of Basketology at Achaea University. She isn’t only the webmaster, though that is her title because it sounds good; she also does some hardware and software purchasing for the department as well as a lot of highly-unofficial technical support that eats up much too much of her time. Since she does a little bit of everything, Cassandra’s technical skills are broad and shallow rather than narrow and deep; she has to jockey Apache as well as Dreamweaver, MySQL as well as Photoshop, elementary Javascript as well as elementary CSS.

After months of meetings and private cajoling, Cassandra succeeded in convincing Basketology to move from their existing set of haphazard unmanaged web pages to an open-source content-management system. Cassandra hopes this will empower faculty to do some of the website-maintenance work themselves, instead of emailing her whenever they see something wrong. She’s not entirely sanguine about this—in her experience faculty don’t take ownership of the departmental web presence no matter how easy she’s tried to make it—but lowering the barrier can’t hurt, and the new CMS should make Cassandra’s job easier too.

While Cassandra was migrating existing faculty websites to the new CMS, she noticed something troubling: several tech-savvy Basketology faculty have been posting their research papers to their part of the departmental website. Cassandra isn’t at all sure that’s legal, and she worries that if there is a copyright-related incident or lawsuit, either the department or (scarily) the legal system itself will make her the scapegoat, since she runs the server. When she asked about this on the Achaea University general-technology mailing list, a librarian named Ulysses Acqua (yes, upcoming persona) told her that most (though not all) of the faculty postings were actually legal, though she didn’t entirely understand his explanation.

That was the best Cassandra could do, so she let it go. If she took down the papers unilaterally, Basketology faculty would be furious, and she isn’t sure she could explain the problem well enough (especially given Acqua’s contention that what faculty were doing was mostly legal) to content them. She knows she doesn’t have sufficient understanding to tell which postings are legal and which aren’t—and anyway, “copyright cop” is not in her job description.

Mr. Acqua offered to help her move those papers that could legally be posted into a service that he runs, but that represented a lot of work for Cassandra, who knows that faculty won’t redo their links so she’d get stuck with the job. Anyway, Basketology faculty would just keep posting new papers to the department’s webspace instead of Mr. Acqua’s service, so Mr. Acqua’s kind offer won’t actually make the problem go away. If Mr. Acqua’s service could somehow be integrated into her CMS, that might be something, but Mr. Acqua told her sadly that the software his service runs on isn’t set up to do that, and he doesn’t have a software-development budget to make it do that.

What Basketology faculty really want for their individual web pages is a comprehensive, current listing of their publications and professional activities. At first, Cassandra thought Mr. Acqua might have a solution to that. Unfortunately, Mr. Acqua’s service can only make records when it is actually taking in files, so faculty listings based on it wouldn’t be comprehensive. Worse still from Cassandra’s perspective, the service’s listings reside outside the Basketology webspace and just don’t look like part of Basketology’s carefully-designed web presence, so Cassandra can’t outsource listing creation to it. It’d be great if she could, because the chair of Basketology is making loud noises about raising Basketology’s profile on the wider web, and a big part of that is keeping faculty-activity listings current. Faculty nod their heads when the chair expresses this need to them—but they won’t lift a finger to do it, in Cassandra’s experience. Cassandra herself simply doesn’t have time; faculty submit their yearly activity reports in word-processed files, the conversion or cut-and-pasting of which would be a nightmare.

Now and then the copyright problem keeps Cassandra awake at night. She doesn’t see a viable way out, however, so she waits and watches and hopes nobody decides to try to make an example of Basketology.

Look, I am not a professional HCI or interface-design person, let’s just take that as read. If you want to watch the real experts go at it, I recommend Boxes and Arrows. I’m as much a design guru as I am a programmer, and I’m not a programmer. (Though our godly sysadmin has agreed to take on a small pair-programming project with me; if this keeps up I may actually start to suck less at programming.)

That said, let’s talk a little bit about what persona development like yesterday’s is intended to accomplish, and how that relates to where we are vis-a-vis design in repositoryland.

It’s really hard to put yourself in the mindset of “the user” when you’re trying to put a piece of software together. Working from standards or other specifications, that’s easy; the worst you’ll run into is linguistic ambiguity. But “the user”? Who the heck is “the user”? And that’s the point. There’s no such animal as “the user.” There’s various sorts of people who will be using your software. Persona development is an attempt to ditch “the user” in favor of a portrait that actually resonates, a concrete mental image that one can build a product or service design around.

Many design processes attempt to circumvent the “the user” problem with focus groups and survey research. This produces useful information—but with serious caveats. One, you can’t design for a statistic any more than you can design for “the user.” Two, you cannot rely on people to reliably introspect about (or even tell the truth about) their current or future desires. You just can’t. If you could, we’d all be designers! What you can, if you’re careful, get a sense of is what their current behaviors are and what their needs (expressed or un-, and they’re mostly un-) might be, and that information can and should fuel persona development.

We know a fair bit about researcher behavior vis-a-vis their research products; we really do. We also understand the landscape researchers operate in. This is all good, and I used my personal understanding of this realm to create Dr. Troia. But understanding is not quite enough; there’s one more small trick to persona development that I think illustrates where the repositoryland train jumps the tracks. Videlicet and to wit: a good persona is, insofar achievable, the typical case, as unextraordinary for the represented population as possible. The thinking is that if you design really well for a few mostly-typical cases (and yes, you’re allowed to throw more than one persona at a design problem, though you want to stop at five or so), what you come up with will more often than not handle your edge people too!

We have not been designing repositories for a typical, representative faculty member. We have been looking at physicists and computer scientists because they are self-archiving in huge numbers, and we have tried to imitate what worked for them. The catch, of course, is that most faculty aren’t physicists and computer scientists. They aren’t even like them; if they were, we wouldn’t have this self-archiving problem, would we? Physicists and computer scientists are an edge case. If we design for them, we lose everybody else.

So Dr. Troia isn’t a physicist or a computer scientist. Mutatis mutandis, she isn’t a flaky technophobe from comparative literature, either. (Everybody knows that potshot was at me myself, right? I have a BA in comp lit.) As best I could, I tried to make her what I normally run into, what I generally expect to see when I meet a new faculty member.

What does Dr. Troia need? Well, first, let’s look at what she doesn’t need. She doesn’t need increased citations. Sure, they’d be nice, but she doesn’t need them. She needs to get her work in the right journals with as little pain as possible. Similarly, she doesn’t need someplace to put her preprints and postprints; these are of so little value to her that she essentially throws them away. If we as repository designers and managers want those preprints and postprints, we’re going to have to get them as a byproduct of a system that does something Dr. Troia does need.

Worse yet, she doesn’t need to manage her copyrights; see above about the right journals. If we want her to (and we want to know when she’s done it), we’d better change her motivations or make copyright management an inescapable part of our systems. She doesn’t need a self-archiving mandate, either. We might like her to have one, but that’s not the same thing. She would comply with one if it existed (because she complies with everything she’s required to comply with; like most faculty, she is a pretty compliant creature where money and career prospects are concerned), but she would never suggest one, never fight for one, never even vote for one, because she does not need it and it represents additional work for her.

(I am reminded of the standard template for software-development projects: “1 Build code. 2 ???? 3 Profit!” Except here it’s more like “1 Say the word ‘mandate.’ 2 ???? 3 100% self-archiving rates!” The reason I fell in love with Minho’s solution is that they sensibly put “Bribe faculty” in slot 2.)

What Dr. Troia does need, and would immediately admit that she needs, is secure, networked, backed-up, maybe even version-controlled storage with access controls. Not (I cannot say this strongly enough) archival storage, because she needs to use it for in-progress work. But storage that had archival bolted onto the side with nice pointers about what to archive and when and how, that she might well use. Goes double if the system makes it easier for her to send her work to journals, or comply with data-retention or funder open-access requirements.

Do our repositories make any of that easier? Do they hell. They make it harder, and they don’t sweeten the pot by solving Dr. Troia’s other problems. No wonder all the Dr. Troias out there don’t use them.

I hope to write up a few more repository-related personas in the next week or so, and then (hello, Les) I can start talking turkey about repository system and service design.

I’ve been rereading Alan Cooper. This is dangerous; it makes me want to create personas. So, herewith, a portrait of a potential institutional-repository user, Dr. Helen Troia of the Department of Basketology at Achaea University. Dr. Troia is a fabrication based partly on my own observations and experience, partly on the heinous amounts of reading I have done in the literature about faculty publication behaviors and attitudes, and partly on focus groups done at MPOW for the BibApp and a local scholarly-asset-management study group.

Dr. Troia goes up for tenure next year. She is hard at work on three peer-reviewed journal articles in various states of completion: one is still in draft, one was just accepted for publication, and one is sitting on her desk awaiting her review of the copyedits. She will be the first to tell you that she doesn’t keep very good track of her computer files. If asked to find a file from her first published paper five or six years ago, she probably couldn’t—after all, she was still a doctoral candidate at Troy Tech then!

She knows that her tenure approval will depend on the prominence of the journals her work is published in. Basketology tenure committees do look at post-publication measures such as impact factors and citation rates, but when the rubber meets the road, publication numbers and journal prestige are what count. Although they use electronic resources heavily, Basketology faculty (especially more senior faculty) look somewhat askance at electronic-only journals, a fact of which Dr. Troia is well aware. As for popular basketology, well! faculty are supposed to engage in discourse with other serious researchers, not with the ignorant public.

Dr. Troia is a fan of Achaea University’s library; as far as she is concerned, she has access to all the literature she needs, thanks to her department’s excellent collection-development librarian. She is aware that the library has been cancelling journals, and has spoken up in the faculty senate for better library funding, but she hasn’t paid attention to the nitty-gritty details. She does not often go to the physical library building; in fact, the library rarely impinges on her consciousness as a researcher, although she does take advantage of bibliographic instruction by librarians for her classes.

Dr. Troia’s basketology data, which are unique and could not be recreated if they were to disappear, live on the computer in her office. This computer is not to her knowledge backed up. Dr. Troia doesn’t want to put data on the department’s shared network drive, because she isn’t sanguine about its security, and her data are vital to her professional advantage, not to be pawed over by just anyone. Some of her older data are in a file format her current software can’t open; Dr. Troia shrugs about that—it’s just how software works, and she has a workaround (though a tedious and annoying one) for any file she absolutely must get into.

Dr. Troia signs whatever publication agreements are put in front of her. The important thing for her career is getting her work into the right places. She has no idea how copyright gets swapped around, and isn’t sure why she should care, since she has no choice but to accept publisher agreements if the publications her career depends upon are to happen. She might file her publication agreements away, but she isn’t sure where they’d be or if she threw them out in her last fit of office-decluttering.

Open access? Dr. Troia looks puzzled. Isn’t that for software? She doesn’t do computational basketology. Oh, putting her work on the Web? Well, isn’t it there already? She can go to her computer at work and download her own articles, though when she’s at home she has to sign in. Oh, openly? Doesn’t that violate copyright? Well, yes, I suppose some of my colleagues do have their papers on their departmental websites. That’s good enough, isn’t it? Why does there need to be another place?

Oh, says Dr. Troia. I didn’t know the library did that. Can I use it for syllabi? What about the draft I’m working on? Oh, just finished work. Just research. Well, it sounds like a nice idea, but I’m very busy and I don’t see much benefit in it for myself. I just don’t have time to go through hard drives and old floppy disks for my old work, and I’m sure if I did one of my publishers would get angry with me. Citation advantage? Well, okay, but my committee won’t pay much attention to putting work anyplace that’s not peer-reviewed—and besides, if it’s in the right journals everyone who really needs to will see it.

What about my students’ work, though? That might be good. Theses and dissertations, yes! But my own work? Mine?

Well, why would I want my own work in the same place as my students’?

Long ago, David got me a gorilla hand puppet. It was one of those things. You had to be there.

Turns out that gorilla hand puppets are great tools for dealing with kitten aggro. Kitten gets to kill something that feels like it’s worth killing; housemonkeys get to keep miscellaneous body parts intact.

It seems, however, that a certain detente has been reached between kitten and gorilla: