At first glance, these workshops may not seem to have much to do with Copac:  after all, the first one even specifies that it is a ‘workshop for library staff’ and, as you may know, Copac isn’t based in a library.  (We’re based in a lovely office, with the Archives Hub team, and daffodils outside the window to distract us.)  However, Copac is all about supporting researchers, with our roots as the OPAC for the Consortium of Research Libraries (CURL), now Research Libraries UK (RLUK).  One of RLUK’s values, as set out on their website, is to ‘work with the research community to promote excellence in support of current research and anticipate future needs’.  This is what we aim to do at Copac, and I got some good ideas for how to do it from these workshops.

Moira and Pat led an interesting discussion about ‘what is research?’, before introducing us to their model of the ‘seven ages of research’ (see slides 8-11).  This was particularly interesting for me, as we’ve recently been conducting some stakeholder analysis, and while we ended up with 5 divisions of librarians with different needs/priorities, we only had one for researchers.  If we are to fully consider and meet the needs of all our users, and ensure that we are communicating with them effectively, then we need to consider the differences highlighted by this model.

Bill Hubbard’s workshop on ‘developments in scholarly communication’ concentrated mainly (and unsurprisingly, given Bill’s role as manager of SHERPA) on Open Access and repositories.  A very timely workshop, following the publication of the much-talked about Houghton report, and one that you might think would be better attended by one of my colleagues from Jorum or Intute repository search.  But it is important that Copac interacts with the OA landscape as well.  Bill returned to the theme of differences between researchers.  This time, it was differences of research methodologies between disciplines:  to crudely condense Bill’s example, economists love pre-prints and working papers, biomedical scientists won’t touch them with the proverbial bargepole.  This, of course, has implications for the types of material that will be appearing in repositories.  It also has implications for how Copac can best serve the needs of these researchers.

So, from our stakeholder analysis which had undergrads, postgrads, and academic researchers all in one nice little box, it now appears that we have to look at not only the career stage of the researcher, but their discipline as well.  Can we do this?  Well, we’re getting closer…  The new Copac Beta (open to members of UK Access Management Federation institutions) is our first step towards a personalised Copac – and the more personalisation we enable, the better able we are to meet the needs of a wide range of users.  It’s still early days, but we’re asking for feedback to find out what you think of the new features, and suggestions for further developments or improvements.

So, if you tried to login to Copac Beta and received a “Login failed” message, please try again. And please let us know if you still can’t get access.

Thanks for persevering everyone.

[Added 30/3/2009] Tagging in ‘My references’ currently broken. We’re looking into it and hope to have it fixed soon.

[31/3/2009] Tagging issues now look to be fixed. However, when I was looking through the logs I spotted another problem which may reveal the reason some people are having difficulties searching Beta. Investigations are in progress.

[1/4/2009] It looks like some people are unable to gain access to Copac Beta because their Identity Provider isn’t providing us with an anonymised userid, or to use the jargon, a TargetedID. We do need this so we know which is your Search History and References.

There’s not a lot we can do about this. It is up to your Institution to release the TargetedID to us. However, if you are getting a “Login Failed” message please contact us, telling us which Institution you are from and we’ll try hassling your system admins.

Authentication poses a problem. We need to authenticate so that we can identify the user and show them their records and not someone elses. We didn’t want people to have to register to use Copac and neither did we want to get into developing a mechanism to handle user registration, etc. So, we have used the JISC supported UK Federation (aka Shibboleth) Access Management system. This allows users to login to Copac using their own instiutional username. Registering separately with Copac is not needed to gain access.

The downside is that Shibboleth is designed to work with web browsers. I don’t know the technacalities of it all, but a login with Shibboleth seems to involve multiple browser redirects, possibly a WAYF asking “Where are you From?” and a web page with a bunch of Javascript that the browser has to interpret that redirects the browser yet again. I’ve tried accessing the Shibboleth protected version of our APP Interface with some APP client software and none of it could get past the authentication — however, it is very hard to diagnose where the problems are.

I also tried the command line program “curl” to access the APP Interface and while it can handle the redirects and the username and password I think it fails when it gets to the page with the Javascript. Which is fair enough, “curl” isn’t a web browser, it is just a program that retrieves urls.

So, can we make do without Shibboleth? Well we can, but the options are either not terribly insecure or not practical. The options I can think of are:

1. We put a token (eg a unique id) in the url. This effectively makes the users collection of records and search history public if the url is published.
2. We put the token in a cookie. This is still insecure and subject to cookie highjacking, but is more private as the token isn’t in the url. Many high profile web sites seem to use such an cookie for authentication, and if they do, then I don’t see why we shouldn’t? However, I’m not sure how practical it is to get third party APP clinet software to send the cookie — unless the APP client was written as part of a web browser that already has the cookie.

You can try accessing the Shbboleth protected APP server for yourself at the following url:

• https://copac.ac.uk/atom/

If you’ve already used the Copac Beta then your Search History and My References collections can be found at the following urls in the form of Atom feeds:

• https://copac.ac.uk/atom/saved-searches/
• https://copac.ac.uk/atom/my-references/

Please let us know how you get on! I’ve tried the above urls with Firefox and Safari. Firefox gets through the authentication and displays the Atom feeds and Service Documents. Safari seems to put itself into an infinite loop whilst trying to display the feed (maybe this is something to do with the XML in our Atom feed?)

We’d be very interested to hear your thoughts on the above.