SALT recommender API

Data Source: University of Manchester, John Rylands Library (circulation data: 2001 – 2011).

Note: Currently not regularly updated, although this is under review.

Licensing: CC-BY


Raw data also available here:
Note: these are LARGE files. 1GB of data in total

Go here if you want to learn more about how we processed this data


format Format of returned results.  Allowed values: xml and json [default: xml]
isbn ISBN (or JRUL control number) of item for which recommendations are required
threshold Minimum number of unique users who must have borrowed both the item in the request and any recommendation for the recommendation to be included in results [default: 15]
workID JRUL workID of the item for which recommendations are required


(i)        one of isbn and workID is required, though if values for both isbn and workID are given then isbn is used in preference (i.e. workID is ignored).

(ii)        a maximum of 40 suggestions are returned.

Results (with example data)

1.    Request successful, results found (results returned)

Returns HTTP Status 200 OK.

XML (default format)

<?xml version=”1.0″ encoding=”UTF-8″?>




<citation>Dawson, Graham. – Soldier heroes : British adventure, Empire and the imagining of masculinity 1994</citation>





JSON (with additional parameter format=json)

[{“isbn”:”041508881x”,”citation”:”Dawson, Graham. – Soldier heroes : British adventure, Empire and the imagining of masculinity 1994″,”workID”:”838073″,”ranking”:1}]

2.    Request successful, no results found (comment returned)

Returns HTTP Status 404 Not Found.

XML (default format)

<?xml version=”1.0″ encoding=”UTF-8″?>


<Comment>No suggestions found [isbn: 0552153575, threshold = 15]</Comment> </Response_getSuggestions>

JSON (with additional parameter format=json)

{“comment”:”No suggestions found [isbn: 0552153575, threshold = 15]”}

3.    Request unsuccessful, invalid parameter value (error returned)

Returns HTTP Status 400 Bad Request.

XML (default format)

<?xml version=”1.0″ encoding=”UTF-8″?>


<Error>Invalid isbn [0552153575%%]</Error>


JSON (with additional parameter format=json)

{“error”:”Invalid isbn [0552153575%%]”}

11 thoughts on “SALT recommender API

  1. Pingback: Introducing the SALT recommender API ( based on 10 years of University of Manchester circulation data) | SALT – Surfacing the Academic Long Tail

    • More and more I’m tiihknng that Open Data is nothing to do with Data, and everything to do with how we encourage innovation how we actually build a future based on it all.This feels like a great example of how we perceive success i.e. uptake in an attention-based economy. When many eyes are on a service, or many scripts are using it, the need for communication is not just desirable, it’s a must-have, because large-scale moaning when something fails is *public* failure.But innovation doesn’t work like this small numbers of small-scale dabblers always have to make the first steps, and these are the people that need the most support. Things don’t just launch, and then get used widely a day later. There has to be an attitude and a culture to support the early-adopter.Services which don’t consider themselves to have a mainstream audience seem naturally better at understanding this things like the NeSS Data Exchange may not always get it right (which is fine), but are very open about communicating both changes and problems that crop up. That’s nothing to do with the data, or the API, and everything to do with user-engagement.Personally, I’d like to see the same attitude from government across the board from Open Data industries, to emerging technology, green tech, social enterprises, etc etc etc. Merely applauding but otherwise not supporting (somehow) initial pathfinding efforts is pretty dire.

    • I would first argue with the troginelomy in your first statement: It is not correct to say JSON document . JSON is not a document format.One of the advantages of JSON is that its adoption invites you to reconsider the design of your structures. There are cases, such as here, where dependence on XML has caused an unnecessary injection of structural complexity. So I would want to render the final example differently:{ names! : [ {“gender” : “female”, “given-name”: “Anna Maria”, “lang”: “it”, “surname”: “Mozart”}, {“gender” : “male”, “given-name: “Fitzwilliam”, “lang”: “en”, “surname”: “Darcy”}, {“gender” : “male”, “given-name”: “Maurice”, “lang”: “fr”, “surname”: “Chevalier”}, {“gender” : “female”, “given-name”: 7.9, “lang”: “de”}]}This comes from a different perspective, regarding the information as data rather than a document. Of course you could make these same improvements in XML.

    • This is biaillrnt, David! I recently implemented a JSON mode for a RESTful style xml based service. I went in with the same preconceptions about the simplicity of JSON and was taken aback by how complex it became. I didn’t fully appreciate the point though until reading this.I think it would also be instructive to compare the three formats in terms of how data is accessed from them; i.e. xml via parsers or some usage of XPath, JSON through javascript or a specific language library and s expressions via LISP. My initial thought is that LISP wins here because it is itself made up of s expressions, and javascript comes second because JSON uses the native array and list structures. But I think that the javascript/JSON advantage over xml may suffer similarly to the way you have illustrated here. I’ll have to think more on that.

  2. Pingback: Announcing the Copac Activity Data Project (otherwise known as SALT 2) | Copac Activity Data Project

  3. you for your comnemt. I know that o.null is not a valid javascript. But that is not the point.The whole point I am making is: If something utterly wrong and irrelevant can be sent as JSON stringm, then why is it allowed? What is the point of allowing a name to be called null when null is the reserved word ? why not just remove names as strings from JSON?Also please remember that in large web applications it is impossible to see each and every JSON message. JSON will be not used only in one developer and his page situations. The whole enterprise messaging systems can be built on JSON. But right now, it is very unlikely, until people start realising its security deficiencies and start removing them. No security architect will allow JSON after seeing these examples.Such a loophole is unthinkable to pass as enterprise class computing.

  4. the thing I like about JSON is that it maps to a ocjbet oriented data structure, and the tooling surrounding it is just about serial/deserialization. in comparison, the DOM data structure used by XML is immensely frustrating to deal with. multiple text node children hanging off elements, content validation before you can .InnerText, theres just a never ending rigamaroll to do what is ultimately a very very simple task, and i for one do not enjoy writing such verbose kludgtastic code. the data structures built by xml tooling just suck horrendous ass.i’m still unsure as to the ultimate feasibility, but projects like jsonml to bridge json and xml seem like they could be vital in the future. there’s a lot of xml out there already, but at this moment, i can say i would like very much to be able to ignore it for the rest of my days, and consume it as json.

  5. Pingback: 1.8 million library loans from the University of Lincoln under CC0 – Copac Activity Data/SALT2 project | Paul Stainthorp

  6. Pingback: 1.8 million library loans from the University of Lincoln under CC0 – Copac Activity Data/SALT2 project | Paul Stainthorp

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>