The Search History and My References feeatures of the Copac Beta TestÂ Interface are stored in a database with an Atom Publishing Protocol (APP) Interface. The idea is to make the database open to use by otherÂ people and services and so enable re-purposing of the data.
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.
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:
- 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.
- 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:
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:
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.
Here’s a few questions for you. Would it be useful to be able to get your Copac search results as an Atom feed? If so, would it help in aggegrating Copac searches with results from other services? Would it make writing widgets for, say, iGoogle or Netvibes, easier? Would you like Copac urls to be RESTful (I hope so, as they will be before long.)
Yesterday I was thinking about the different search result formats we provide and I was wondering if Atom might be useful. Then a conversation I’ve had this morning with some colleagues have made me think an Atom format could be very useful in the areas outlined above. However, I don’t have experience of implementing widgets or working with Feeds, so I thought I’d ask here. Any thoughts, anyone?
One of the things I’d like to do for Copac is to re-write the code behind the web based user interface. The current architecture was designed to work with a Z39.50 server and I now consider it to be too complex. This makes it hard to debug when things go wrong and the complexity of it means that things do go wrong.
So, I’d like to move the interface over to a REST based stateless interface that talks dircectly to the database without going through our Z39.50 interface. This should decrease the time to produce a response after a user hits the search button and should be more reliable.
What I wasn’t too sure about, until now, was how we would incorporate Copac’s Search History feature into a stateless, REST based, interface. The answer came to me during the small hours this morning. We can put the searches into the same Atom Publishing Protocol (APP) repository that we plan to use for the Marked List. (The Search History and Marked List would be separate collections within the repository and so wouldn’t be mixed up together.)
The advantages of this are: the user can have an Atom feed of their searches, they can tag and annotate their searches and generally manipulate their search history by deleting and editing entries through APP client software. We might also be able to include searches from other services. I think such a search history would work for any REST based service. So if we can move other Mimas services, such as Zetoc and the Archives Hub over to a REST based interface, then a user could potentially have, in one place, an archive of all the searches they have performed over a number of different services.
As part of the D2D work we are enhancing the functionality of the “Marked List” feature in Copac. The Marked List allows you to save records from your search session, for downloading or emailing to yourself in a variety of formats. One of the drawbacks to the Marked List is that it is linked to your search session. That means that when you come back to Copac tomorrow, the records you saved today will have gone.
So, one enhancement is to make your List of saved records permanent, so when you come back next week, everything you saved last week is still there. The downside to this is that you will need to login so that we know who you are and which are your records. If you don’t want to login to use Copac, then you will still be able to, you just wont get the facility of a permanent Marked List.
The current plan is to provide an API to the Marked List and it seems most sensible to use the Atom Publishing Protocol (APP). One of the nice side effects of using APP is that you’ll get an Atom feed of the records you’ve saved, plus you’ll be able to manage your collection of records with a suitable APP client outside of the Copac web site. Your Marked List will be private to you, though we will look at adding an option to publish your List to make it public.
The fly in the ointment of all this might be Shibboleth (the UK Academic access management mechanism.) It isn’t clear to me if an Atom feed is going to work in a Shibbolized environment. I hope to have something to test soon and I’ll keep you informed…