getlibraries - multi-library google map
Submitted by Tim Hodson on Wed, 2006-07-05 22:42.
Well, I have just (over the last two weeks!) put together something that uses SPARQL, XSL, Javascript and a dash of XHTML to pull a list of locations under one collection from the silkworm directory, and display them in a google map.
Find out more here...
InformationTakesOver - getlibraries
Tim
Herefordshire Maps
Good work Tim, exactly what the Directory and APIs are there for.
Have you thought of putting an OPAC search box inside the pop-ups?
There is example of how just dropping a form element in to the html for the box could give you this in the Simple Library Search: Using the Bibliographic Deep Linking API API User Guide article.
Keep the Mashup Competition in your sights!
Richard Wallis
Technology Evangelist - Talis
I did think about it...
I did think about it.
I wanted a "Search THIS library..." box to search ONLY the library that is selected. I had a word with your Prism Guru only yesterday, and the word is that Prism won't as yet allow me to do that...
However, that won't stop me trying!
UPDATE - 10:51
OK, so this URL works...
http://opac.herefordshire.gov.uk/TalisPrism/doOpenURLSearch.do?st1=keyword&sv1=badger&searchSites=BT&searchLocation=talislms&searchCollection=2
Test me...
But, when I try to use the bib deeplinking, it seems to be stripping the paramaters I am adding, and returning a pointer to only the openURLsearch.do. This is presumably because the api is only accepting three search parameters.
The Deep linking URL I used was...
http://api.talis.com/1/node/items/he.swdefault/bib?st1=keyword&sv1=badger&searchSites=BT&searchLocation=talislms&searchCollection=2
Now, I would obviously have to construct the working URL using either a form or a bit of javascript (actually I had thought of switching search type between title, author, keyword and ISBN using checkboxes).
But what I don't want to do is hard code my library opac baseURL, as this defeats the whole point of using the directory and creating a scrit that is portable and potentially always points in the right direction.
Tim Hodson
Herefordshire Libraries
www.timhodson.com
informationtakesover.co.uk (blog)
Location specific parameters
Hi Tim,
You have hit on an issue that has been taxing the brains here and I would be interested in your, and anyone else's, input on it.
One of the fundamental principles of a Platform is that it hides the complexity of accessing a resource from the user of the Platform API. The deep-linking API does just this, all you need to know is the id of the Collection and it takes care of the address and type of OPAC being accessed on your behalf.
In your case it maps 'he.swdefault' to be a Talis Prism OPAC located at 'opac.herefordshire.gov.uk'.
What it doesn't do, yet, is take this to the next level down. As you have correctly identified, Prism takes extra URL parameters causing it to search in a way relevant to a particular branch location.
Applying the principle of hiding complexity, the Directory should allow you to logically associate information with a Location which is used to effect the way that the Service associated with the Collection constructs the url created to access your OPAC. In that way, users of the API who would want to access the view of the Herefordshire Collection from the perspective, of say Belmont Branch, would just need the logical name [something like 'belmont.he.swdefault' perhaps] and no knowledge of Prism URL syntax whatsoever.
To do this would require some API enhancements and also some Directory interface changes, to allow the capture of this information.
There is another way of course. We could enhance [if that is the right word in this case] the Deep Linking API, to pass on any unrecognised URL parameters to the target OPAC. This would allow what you tried to do to work. But, although it would be comparatively simple resolution to the issue you have highlighted, it would drive a coach and horses through the principle of hiding complexity.
What do you think?
Richard Wallis
Technology Evangelist - Talis
Hide complexity to lower the entry barrier
I agree that the platform should hide complexity. But perhaps the complexity is hidden to lower the barrier to entry?
Currently the deeplinking api maps the title (etc) search to the OpenURLSearch.do 'interaction' for herefordshire's service. if there was a similar parameter set* for prism systems to match a location, and if the location entity described by belmont.he.swdefault had an attribute 'sitecode' or somesuch, then the deeplinking api could put two and two together to provide a location specific search.
* when experimenting with which attributes I could omit and still have a keyword search at a specific location, the shortest I have it down to is 4 parameters. (?st1=keyword&sv1=badger&searchSites=BT&interface=local)
Of course, in the true spirit of the mashup and the disruptive internet, then passing paramaters would allow those 'in the know' to mash to their heart's content!
What I want the directory to ALWAYS know is the base URL of my opac. On top of that I can build all sorts of little gizzmos that allow me to "reserve this" from a list of frequently requested items, or search a particular subset of the catalogue, without fear that a myriad of links will suddenly die.
Tim Hodson
Herefordshire Libraries
www.timhodson.com
informationtakesover.co.uk (blog)