Mark Leggott
University of Prince Edward Island
Leggott moved to UPEI in 2006, forever altering the Canadian library landscape. Either you were at Access and/or know Leggott and get the joke, or you have no idea what I'm saying. For my part, I always find listening to Leggott to be worth my while. He has both an effective manner of communicating and a lot of challenging ideas.
He gave an overview of UPEI and the library reorganization he led when he took over. He added two departments--Outreach and Communications & Data and Research Services--the latter of which is central to his talk. For K-State's purposes, the lessons he lays out that relate to Data and Research Services have import for our Repository Services initiatives. What he's doing differs fundamentally from our approach, as will be seen below, and I think a close look at what he's done could be valuable for us.
The work performed by his technical staff is based on the skunkworks approach, i.e.- no committee or structure, just an idea and some work. He builds a team that wants to get right to work and turns them loose. They 'play' with technology rather than discuss it, and they gain experience and expertise quickly by diving right in and getting their hands dirty.
He turned his attention to the repository, noting that many of us are asking if the IR is worth all of the work we're exterting, implying that in many cases it is not since we have failed to engage researchers in meaningful and sustainable ways. For UPEI, they opted to use Fedora for its rich functionality. It does have a high learning curve and has no interface or workflows out of the box. So, he asked, why use it with a total library staff of 28? He wanted a product that would be invisible, i.e.- doing the work without smacking the user in the face, a product that would recognize the user's context and make use of that knowledge, and one that could integrate with all other software systems, even Office and GroupWise (a daunting notion, to say the least).
Using open source software builds staff capacity, since anyone can take part, and people can be encouraged to play since there are no buy-in costs. This play process is part of redefining the tradition of libraries. Our current image is that of a steward for books and journals (in any format), and this no longer works. We need a different infrastructure and need to move past this limiting image. The library needs to be critical across the entire organization, yet invisible since it's ubiquitous (no need to toot one's horn to draw attention, I think he's saying, if you've really made yourself essential).
What goes into a repository? He used the concept of landscapes. First, there's the administrative landscape: records, archives, canonical datasets. Along these lines, a library should take on such tasks as the campus calendar, since it's little more than a data presentation these days. We're good at that, or should be. Then there's the learning landscape. He wants to get Fedora into the learning management system (they use Moodle), for example, to power e-reserves. Last, there's the research landscape. He wants to steward research data--all of it!--in Fedora.
Their repository is called the Virtual Research Environment (VRE). He pointed out at this point that he often looks to projects sponsored by JISC or by its Australian counterpart, as he feels that they are getting a lot of things right. He showed a diagram (hopefully the organizers will soon be posting the speakers' slides so I can link to this) outlining the stages of research: Conceptualizing, Initializing, Analysis, Initial Results, Formalizing, and Popularizing. He astutely points out that libraries are typically only concerned with the Formalizing stage, i.e.- the point where research finds its expression in the form of publication in the literature of a discipline. The key to moving beyond that is knowing the user and their context. He showed some sketches of the VRE structure, which are better seen than described.
One interesting technical note is that they use Drupal as a front end for Fedora. Beyond providing a flexible and friendly interface, it also handles the contextual data for Fedora. In other words, when a user authenticates in Drupal (I believe they use basic LDAP), it can pass that data to Fedora. So, when a researcher deposits any item in the system, it already knows their name, affiliation, and so forth. Easier submission = better chance it will be used. This is a common discussion that revolves around every IR, and I think they've found a nice solution.
Comments