Tuesday 29 June 2010
transitions
Dan has now returned to CARET from the University Library, and will be returning to the helm of this project over the next few weeks. So there will be less from me, and more from him!
Friday 25 June 2010
Google Code Site
Software Developers - have you checked out our Google Code site yet? This is where we're keeping documentation and code, and where we'll track any issues like bugs and feature requests.
In particular, you can browse our source code - all covered by the Apache License 2.0. We will be augmenting the code with full documentation of how to host, configure and install your own version of each widget in due course, but for now there is a snapshot of the code that currently powers the original Library Widget, and most of the code used in the prototype of the Exam Papers Widget.
If you simply want to use or try our widgets as-is, there's no need to delve around in the source code - find out more about how to use the Library Widget and the mobile version, CamLib.
In particular, you can browse our source code - all covered by the Apache License 2.0. We will be augmenting the code with full documentation of how to host, configure and install your own version of each widget in due course, but for now there is a snapshot of the code that currently powers the original Library Widget, and most of the code used in the prototype of the Exam Papers Widget.
If you simply want to use or try our widgets as-is, there's no need to delve around in the source code - find out more about how to use the Library Widget and the mobile version, CamLib.
Friday 18 June 2010
Cambridge Library APIs
I've blogged a few times about how our widgets and interfaces are underpinned by web service APIs to our data sources. We've now made the decision to publish all of our public APIs - documentation can be found at http://www.lib.cam.ac.uk/api/
This means that any developer can access and build functionality around Cambridge Library data. It's going to be interesting to see what they come up with!
This means that any developer can access and build functionality around Cambridge Library data. It's going to be interesting to see what they come up with!
Wednesday 16 June 2010
CamLib mobile interface and Aquabrowser
One of our aims in this project was to integrate our widgets with the new (forthcoming) Aquabrowser discovery layer, which will be launched later this summer. Cambridge library resources come in from a huge variety of data sources, including eight (yes, eight) Voyager databases. Searching across these collections presents a huge challenge for our users. Look at the previous search options:
Aquabrowser takes feeds from all these data sources and rearranges and tidies up the data (through a mixture of straight deduplication and FRBR) to make it all more manageable - and more importantly provides a single point from which to search all of our collections.
We've now managed to integrate Camlib, our mobile interface, with the Aquabrowser APIs to provide a much improved search service. Our new search options are:
The search results are very differently presented - one result for each title, followed by a list of the libraries who have a copy.
In short, if you are looking for all copies of a particular title in Cambridge, instead of having to make eight separate searches and plough through multiple results in each, you make one search with all the relevant information returned under one result.
We're hoping that a by-product of this kind of searching will be increasing integration of library services in Cambridge - if people see us and our collections as an integrated whole, then we might move faster to meet their expectations.
And we've even got some funky book covers from Syndetics to spice up our results list ...
- UL & Dependents
- Departments and Faculties A-E
- Departments and Faculties F-M
- Departments and Faculties O-Z
- Colleges A-N
- Colleges P-W
- Affiliated Institutions
- Manuscripts
Aquabrowser takes feeds from all these data sources and rearranges and tidies up the data (through a mixture of straight deduplication and FRBR) to make it all more manageable - and more importantly provides a single point from which to search all of our collections.
We've now managed to integrate Camlib, our mobile interface, with the Aquabrowser APIs to provide a much improved search service. Our new search options are:
- Search All
- UL & Dependents (incl. Manuscripts)
- Departments and Faculties
- Colleges
- Affiliated Institutions
- Electronic Resources
The search results are very differently presented - one result for each title, followed by a list of the libraries who have a copy.
In short, if you are looking for all copies of a particular title in Cambridge, instead of having to make eight separate searches and plough through multiple results in each, you make one search with all the relevant information returned under one result.
We're hoping that a by-product of this kind of searching will be increasing integration of library services in Cambridge - if people see us and our collections as an integrated whole, then we might move faster to meet their expectations.
And we've even got some funky book covers from Syndetics to spice up our results list ...
Tuesday 8 June 2010
Proprietary web services and proxies
A couple of weeks ago I blogged about writing local web services to extract information and embed functionality. However, many data sources come with their own range of ready-made proprietary web services. The big advantage of using proprietary web services is that you don't have to write your own. The disadvantage is that (usually) you can't alter them. Unless you have a very good relationship with your system supplier, you're stuck with what you're given.
Most data sources will allow you to write web services which extract data from the system, but the majority won't allow you to write web services which alter data in the system. If you want to use functionality in your widgets rather than simply displaying information (i.e. renew books, rather than just say what you have on loan) then you may find yourself having to use proprietary web services.
Basically, if the existing proprietary web services do exactly what you want, use them. If not, you might want to consider writing your own to extract data. But as far as altering data in the system goes, you may well be stuck with the proprietary ones.
[In practice, we find ourselves using a mixture of local and proprietary web services for data retrieval, and proprietary web services for data alteration]
Somewhere in your system's documentation you should find a list of existing web services and some notes on how to use them. This should include the service address, input parameters and return values. Which translates as how to find the service, how to ask it to do something, and how it will respond. Pretty much the same as using locally written web services.
But there is one potential complication with proprietary web services. If you make a request to a web service from a browser and then try to read the response, the browser will first establish what the response is and where it comes from. If the response is in XML and the domain of the web service is different from the domain of the page calling it, the browser gets worried about security and the whole enterprise collapses.
There are two ways round this. If the proprietary web service has the capability to return its response in json then you don't have worry about where it's coming from. If not, you will have to write a proxy.
A proxy is an intermediate web service which can sit alongside your local web services, in your own domain. You access it just like any local web service, and your browser will treat the xml it returns as if it had come from a local web service.
When you send a request to a proxy it passes it on to the proprietary web service, reads the response and then passes it back to you. Because the proxy is not a browser it doesn't care where the proprietary web service is, and because the proxy is in your domain, your browser is cool with it too.
An additional advantage of going through a proxy is that if your system's proprietary web services return responses which are over-long, oddly structured or confusing, then you can talior that response on the way back so it gives you what you actually need.
We use one proxy web service to connect to all of our library management system's proprietary web services. So we pass the service name, and the request to the proxy. The proxy calls the appropriate service with the request. Then it processes it and returns it to the browser.
Most data sources will allow you to write web services which extract data from the system, but the majority won't allow you to write web services which alter data in the system. If you want to use functionality in your widgets rather than simply displaying information (i.e. renew books, rather than just say what you have on loan) then you may find yourself having to use proprietary web services.
Basically, if the existing proprietary web services do exactly what you want, use them. If not, you might want to consider writing your own to extract data. But as far as altering data in the system goes, you may well be stuck with the proprietary ones.
[In practice, we find ourselves using a mixture of local and proprietary web services for data retrieval, and proprietary web services for data alteration]
Somewhere in your system's documentation you should find a list of existing web services and some notes on how to use them. This should include the service address, input parameters and return values. Which translates as how to find the service, how to ask it to do something, and how it will respond. Pretty much the same as using locally written web services.
But there is one potential complication with proprietary web services. If you make a request to a web service from a browser and then try to read the response, the browser will first establish what the response is and where it comes from. If the response is in XML and the domain of the web service is different from the domain of the page calling it, the browser gets worried about security and the whole enterprise collapses.
There are two ways round this. If the proprietary web service has the capability to return its response in json then you don't have worry about where it's coming from. If not, you will have to write a proxy.
A proxy is an intermediate web service which can sit alongside your local web services, in your own domain. You access it just like any local web service, and your browser will treat the xml it returns as if it had come from a local web service.
When you send a request to a proxy it passes it on to the proprietary web service, reads the response and then passes it back to you. Because the proxy is not a browser it doesn't care where the proprietary web service is, and because the proxy is in your domain, your browser is cool with it too.
An additional advantage of going through a proxy is that if your system's proprietary web services return responses which are over-long, oddly structured or confusing, then you can talior that response on the way back so it gives you what you actually need.
We use one proxy web service to connect to all of our library management system's proprietary web services. So we pass the service name, and the request to the proxy. The proxy calls the appropriate service with the request. Then it processes it and returns it to the browser.
Tuesday 1 June 2010
Opening Hours and Library Pics
We've now integrated library information (address, opening hours) into various parts of CamLib
Opening hours are pretty important. When a user finds a book online, the next thing they want to know is usually "when can I get this book" - though in Cambridge they may also be asking "can I borrow this book" or even "can I use this library". All of this information is available in CamLib, but not in a particularly joined-up way.
The next challenge is not just to display this kind of information but to use it in the provision of relevant services - allowing users to filter searches to only bring back items in libraries they can use, or items in libraries they can use where they can borrow, or items in libraries which are open and which they can use.
We've also put some pictures of libraries up. Not all libraries have pics yet - we're adding them as they get sent in. The pics make the interface look nicer, but also have a practical purpose. The bigger sites in Cambridge have large numbers of buildings, often crowded together. A map reference only gets you into the general vicinity.
We asked libraries to include photos of the building as a whole and the entrance to the library so that when users are there or thereabouts they can use them to find the particular library they need.
Opening hours are pretty important. When a user finds a book online, the next thing they want to know is usually "when can I get this book" - though in Cambridge they may also be asking "can I borrow this book" or even "can I use this library". All of this information is available in CamLib, but not in a particularly joined-up way.
The next challenge is not just to display this kind of information but to use it in the provision of relevant services - allowing users to filter searches to only bring back items in libraries they can use, or items in libraries they can use where they can borrow, or items in libraries which are open and which they can use.
We've also put some pictures of libraries up. Not all libraries have pics yet - we're adding them as they get sent in. The pics make the interface look nicer, but also have a practical purpose. The bigger sites in Cambridge have large numbers of buildings, often crowded together. A map reference only gets you into the general vicinity.
We asked libraries to include photos of the building as a whole and the entrance to the library so that when users are there or thereabouts they can use them to find the particular library they need.
Subscribe to:
Posts (Atom)