Group items tagged

"Summon Search API uses an authentication scheme based on secret key verification via an HMAC-SHA1 digest. The API performs both authentication and authorization via the same HTTP Authorization header. Creating an Authorization header for an API request requires an access ID, a paired secret key, a client key, and access to certain elements of the HTTP request being authenticated. To create the Authorization header, specific request elements must be assembled into a string that uniquely identifies the request. This ID string is then turned into a digest using the HMAC-SHA1 algorithm as defined in RFC 2104. The digest is then Base64-encoded according to RFC 2045, and assembled into a header along with the access ID. When the API server receives a request, the first thing it does is check the x-summon-date header to make sure it is within a reasonable margin of the server time. If the header time is not within one hour of the server time then authentication fails immediately. If the request timestamp is acceptable, then the server goes on to check that Summon authentication is being used in the Authorization header. If Summon authentication is being used, the server extracts the access ID, client key and encoded authentication digest from the Authorization header, and looks up the paired secret key using the access ID. Finally the server performs the same algorithm described in the previous paragraph to produce a test digest, and compares the test digest against the digest provided in the Authorization header. If the two digests are identical, the request is authenticated."

"But commercial vendors, smelling a new market, are stepping in. Serials Solutions, a subsidiary of ProQuest, released a software product in July called Summon. The company has been negotiating deals with publishers and content providers to create a searchable index of their content. It's like Google, except what Summon provides is an index of the "deep Web" of paid content. So now university libraries that pay for a subscription to Summon can let their users search their licensed content as well as locally owned stuff, together. Summon has 17 customers so far, including Arizona State University and Dartmouth College. The catch? It can be expensive. Andrew S. Nagy, senior discovery-services engineer at Serials Solutions, wouldn't say how expensive. But the cost of a subscription can run into the tens of thousands, said one university administrator who was not authorized to discuss price and thus wanted to remain anonymous. Summon also does not have permission to display the full text of articles."

"Le principe de base de Summon est: la recherche doit être simple, l'accès aux résultats aussi. Sauf que ce n'est pas forcément la vision qu'ont les bibliothécaires. Exemple? Summon utilise un créateur de liens qui ne rend qu'une ressource pour un titre donné. Si le titre est paru dans plusieurs références, on n'y a pas accès. Les bibliothécaires préfèrent avoir toutes les références, persuadés qu'ils sont que les « chercheurs » préféreraient aussi. Alors quel intérêt d'avoir un outil de recherches qui ne reprend que les sources que vous avez déjà? Comment vous dire…je ne sais pas. En ce qui concerne les étudiants -du moins les licence- qui ont l'habitude faire la majorité de leurs recherches sur Google, je ne suis pas persuadé de l'intérêt de Summon. Pour les chercheurs, ils ont des habitudes, des sources préférées, et le fait de ne pas afficher -de prime abord- toutes les sources pourrait leur déplaire, ou leur compliquer la tâche. Pour les bibliothécaires, il y aurait des items à modifier, il faudrait indiquer toutes les sources, ce qui contrarie le commercial (!)."

"Contrairement aux moteurs de recherche fédérée, Summon s'appuie sur un index unique, constamment mis à jour, qui contient les méta-données des ressources que propose la bibliothèque, ce qui garantirait un temps de réponse plus court. Concernant l'affichage des résultats, il se fait « selon leur pertinence », sans que l'on puisse savoir sur quoi cette pertinence est basée. Il semble cependant que l'algorithme traite principalement les métadonnées des notices plutôt que celles du texte intégral pour ne pas générer de bruit. Les résultats sont proposés sous la forme d'un affichage à facettes, avec des possibilités pour affiner sa recherche (tri par contenu, par date, par bibliothèque…), et un fil RSS est proposé sur les résultats de la recherche. Summon est construit sur une architecture logicielle « libre » (Lucene). Rien n'est à installer « en dur » localement, tout est hébergé sur les serveurs de SerialsSolutions (Seattle, WA). Summon bénéficie de la puissance de feu de ProQuest-CSA (métadonnées de Ulrich's) et a passé des accords avec de nombreux éditeurs pour proposer aujourd'hui un index riche de plus de 500 millions de documents indexés, provenant de plus de 70 000 périodiques et plus de 100 fournisseurs de contenus dans sa base de connaissance. L'interrogation des bases d'archives ouvertes est possible."

"We learned that they've turned on a new back end that greatly increases the speed of the product, with 80% of all searches being fully returned in 1 second or less. Go ahead and try it with the U of Calgary implementation. Don't like a hosted URL? Check out what the U of Virgina has done with the Summon API for their mobile interface! There's a lot of long-tail stuff out there. One of the content managers pointed out that the average academic library holds 24% of Ulrich's Core Journals, and Summon has 40%. I'm really revitalized over this project, and will be heading back to Calgary with an aim towards cleaning up our metadata in order to really leverage Summon. Lots of good stuff coming in the next few months."

"Summon occasionally fails to successfully link to articles in EBSCO databases. Instead, the full-text article link drops users at a more general EBSCO search screen and it's not clear how to get to the actual article. (...) Some vendors do not provide article-level linking. * Summon will provide a direct link to articles available through the NCSU Libraries. Sometimes, however, Summon only provides a link to a Journal, or the article link fails to turn up the full text. This is due to a lack of article-level links available through some publishers. "

"One of the topics of discussion at last week's Summon Advisory Board was the status of de-duping records returned by Summon. On the face of it it seems to be a simple issue - if the titles and authors match, throw the duplicate records out and you're good to go. The Summon technical team explained why it's a little harder than that though. "

Summon at the University of Huddersfield http://library.hud.ac.uk/summon

"I don't think its obvious, but what OCLC is trying to do with WorldCat is much bolder than Serials Solutions and Summon. With Summon, libraries are basically throwing all of their content into one index to break down the data silos within an institution. But what you end up with is a big search silo for that institution. With WorldCat, the vision is to break down not only the silos within institutions but also the silos between institutions. And not just break down those silos in the sense of harvest-and-search. The concept is that libraries and their patrons will be working together to improve a shared database through intentional and professional metadata. This shared database will be big enough to have a real impact on the web. Its records will surface in search engine results. Its interface will be familiar to many, and it will be customizable for a particular audience via the WorldCat Local route."

"The University of Calgary's Libraries and Cultural Resources became a beta partner with Serials Solutions' unified discovery service, Summon, in the spring of 2009. Since then it has worked to include metadata from numerous disparate systems in a single index to drive discovery in a Google-like environment. The University of Calgary has examined how MARC and other metadata schemas are mapped into Summon with an eye to ensuring the maximum possible population of index fields representing facets in addition to adhering to the established standards for cross mapping metadata schemas and indexing. The University of Calgary has investigated existing standards and worked closely with the Summon team to create mappings that reflect how MARC and other metadata can ultimately be used in big indexes. Combined with the normalization or collapsing of metadata records representing the same resource into a single metadata-rich record, fully leveraging MARC and other metadata in big indexes should not only level the metadata playing field but make competition between records a non-issue."

"We recently had a visit from Serials Solutions staff to talk about Summon. We are currently running an Endeca based catalog we call Mango for 11 State University Libraries. We were told that there are a couple of options for implementing Summon, one is to switch to their interface and use it as your whole catalog, with articles metadata integrated into your search results. The other option is to use their API to integrate the article searching into your next-gen catalog."

"My primary concern relates to the management of data and the suitability of search functions to allow for academic coverage that is comprehensive without being overwhelming. For example, a basic search of the term UK Transport Policy through Summon reveals nearly 60,000 results on the University of Huddersfield's Library website. There are of course filters to help sort the data, but my first impression is that these are not particularly effective (I also find the automatic updating of the results after the selection of a single filtering item to be very frustrating). Similarly, having had a brief play around with it, I find the advanced search feature slightly confusing with regards to the search terms that it uses (this assessment must be quantified by the fact that I speak as a regular user of MetaLib, so am of course used to the nuances of that particular system). For novice users of the system then, I wonder if they might just find it all a bit too much!?"

"It is interesting that Summon is built using an open-source product architecture - and ditching the need for a federated search back-end is quite a radical step forward into the cloud. I'm wondering if this is related to their different approach to authentication: both Summon and Metalib seem to be 'authentication agnostic' and could work with a variety of authentication systems: but ExLibris seems to prefer the 'up-front' password challenge as opposed to Serials Solutions who give you it the other way round: metadata first and only authenticate later. Is it harder to integrate authentication, as opposed to searching for content, into an institutional login this way round? I don't yet know as I think it depends what choices we make on identity management. Personally I'm drawn to the 'up-front' approach - even though the simplicity of what Serials Solutions are doing is very attractive, I prefer my password challenges at the beginning - rather than at the end of the process. What about others?"

"(...) the relevancy ranking within Summon is based on term frequencies as Aaron said, but many other algorithms are used as well, such as field weightings and inverse term frequencies to counterbalance any skewing from the full text content. Additionally, each record in Summon has a static rank that allows for balancing records from one collection against another to ensure all records are treated equally. "

This article will explore the space between Summon's out-of-the-box user interface and full developer API, providing practical advice on tweaking configuration information and catalog exports to take full advantage of Summon's indexing and faceting features. The article then describes the creation of OSUL's home-grown open source availability service which replaced and enhanced the availability information that Summon would normally pull directly from the catalog.

tone, Graham (2010) Searching life, the universe and everything? The implementation of Summon at the University of Huddersfield. In: 39th LIBER Annual General Conference, 29 June - 2 July 2010, Aarhus University, Denmark . (Submitted)

"I recently received an e-mail that the next Serials Solutions/Library Journal webcast about Summon will discuss - among other things - the differences between federated search and unified discovery systems. Upon discovering this, I decided to review the entries I've written about these differences. Since the last post I wrote on this topic was written last August, it is not surprising that many of the observations I made then are now incorrect. I'd like to take this opportunity to correct some of the statements I made."