SUSHI FAQs: Librarian Questions

For librarians or other end users who wish to gather usage reports via the SUSHI protocol.
Last updated April 9, 2009

1. What are the benefits of using the SUSHI protocol?
The primary benefit of SUSHI is that it automates a tedious and repetitive process. Current practice for statistics retrieval calls for library staff to go to each individual publisher’s website and manually retrieve statistical data. In some cases, this data is in COUNTER format, but sometimes it is the publisher’s own internal format. Occasionally it is available only through a web screen and cannot be downloaded; only printed. The SUSHI protocol automates the process; but also, by default, encourages the publishers to put usage data into a standard format (COUNTER XML). Therefore the retrieval is not only automatic but far easier to use.

2. Do you have a sense of how much time the implementation of SUSHI will save you in managing data collection?
The University of Washington has found it takes roughly 30 hours to collect usage statistics for all of their resources when it involves navigating to Web sites, logging in, finding the reports, downloading the reports, and storing the reports where collection development librarians can find them. As more resources move to collection via SUSHI feeds, the fewer places have to be visited manually. This is a huge time saver since once the feeds are set up they require no attention and will be collected automatically on a monthly basis. When collecting statistics by hand, UW would not collect on a monthly basis but rather on a quarterly basis because it was so time consuming.

3. How do I implement SUSHI?
From the perspective of a library customer, it should only be necessary to purchase a system that supports SUSHI, then manually input the connection information for all the various vendors that support SUSHI.  For customers trying to implement SUSHI using Innovative ERM, see Question 13.

4. What COUNTER reports can be delivered with SUSHI?
SUSHI 1.6 supports retrieval of any COUNTER report. The standardized names of the COUNTER reports to be used with the SUSHI protocol are listed on the SUSHI Report Name Registry.

5. Is it intended that SUSHI implementations support older Releases of the COUNTER reports?
Release 3 of the COUNTER Code of Practice now requires content providers to support the SUSHI standard and provide reports in XML format (adhering to COUNTER3_0.xsd). Given this, the expectation is that reports conforming to COUNTER 3.0 will form the baseline for SUSHI support.  New implementations of both clients and servers should focus on support for this version of COUNTER reports -- particularly since full compliance with COUNTER 3.0 is expected within the next 9 months.

Going forward, when changes to the schema do occur (this is not expected to happen often), COUNTER recommends that the current release and one previous release of its Code of Practice be supported.

The above does not prevent a SUSHI client service provider or content provider from supporting earlier versions of COUNTER reports if they feel there is customer demand; however, it should be clear that it is not an expectation nor a requirement.

6. Can a single SUSHI request aggregate multiple vendor reports?
The protocol is designed as a one-report-at-a-time service. If a client needs multiple reports of different types or from different vendors, then it would simply make a separate SUSHI call for each one.

Results will need to be aggregated by the requesting library, either manually or using software such as an ERM system. In many cases, the request and aggregation process will be automated within the software that makes the request. For example, the system could be programmed to request all of last month’s reports on the 15th of this month, assuming that all of the content providers had their report data complete by that date. However, such automation is outside the scope of the SUSHI protocol.

7. How does SUSHI handle the requesting of consortium reports?
Release 3 of the COUNTER Code of Practice for Journals and Databases introduced two reports specifically to address the needs of consortia. Using SUSHI (or by requesting the XML version of these reports from the content providers website), the consortium can request a report by identifying the consortium. The report that is returned will include the usage details for each member of the consortium.

8. Can I use SUSHI to receive or deliver non-COUNTER reports?
Yes. COUNTER reports are the primary focus of the SUSHI standard, but other reports, agreed upon by the trading partners, can be retrieved as well. These custom reports would have to meet the standard's requirements for report naming and would have to be deliverable in an XML format.

There is a Registry of standardized report names. All COUNTER reports are included in the registry, however, registration of other customized reports is voluntary, so not all reports in use may appear here.

9. Are there any limits to how many or how often I can request reports with SUSHI?
No, there are no SUSHI-based limits. The individual content provider servers may have access rules relating to frequency of requests and numbers of downloads. If the server is unable or unwilling to deliver a requested report through SUSHI, an Exception message is returned in the SUSHI response that describes the problem.

10. Is there any limit to the time frame of the reports content which I can request?
SUSHI places no time limits on the time frame of reports. Availability of reports for a particular range of months or years is determined by the content provider and the service provider of the SUSHI server that makes available the publisher’s data. If the publisher has not made statistics for certain years available, then SUSHI cannot retrieve it.  If a request is made for an unavailable report, the SUSHI protocol will return an exception indicating why no data was returned. (Note: some ERM systems can only retrieve data within a single year. Data spanning multiple years will need to be retrieved one year at a time.)

11. Can issuance of the SUSHI request be automated?
Absolutely. Most current client-side SUSHI implementers are building automated triggering into their system to initiate SUSHI retrieval based on a known calendar of expected  availability of usage reports. The initiating software package needs to know the publisher’s URL, a customer number, and a calendar of when the vendor makes their updates statistics available, and the process can be automated. ERM vendors who are incorporating the SUSHI client protocol into their software may provide additional automation capabilities.

12. What vendors have implemented the SUSHI protocol in their ERM products?
Innovative Interfaces has released a version of their ERM product that supports the SUSHI protocol. Ex Libris is in the process of building SUSHI into their next version of Verde, their ERM product. Other vendors that have announced support for SUSHI are available on the SUSHI.

13. The following questions refer to configuring SUSHI in Innovative ERM - release 2007

  • Question: Why is the customer-id different for each provider?
    Answer: The customer-ID field in the autostat configuration is specific for each provider and is based on how the usage is organized. Each SUSHI feed is specific to each vendor and is how we keep all of the different journal titles separated.

  • Question: For the access provider 5-digit code: are you using the contact record to create that?
    Answer: Yes, the access provider code comes from the contact record.

  • Question: How is ‘use’ defined? Is it searches, page views, etc?
    Answer: For journal usage reports, a use is defined to be a successful full-text download request, either HTML or PDF. This is defined in the COUNTER Journal Report 1.

  • Question: Do you add the HTML use and the PDF together?
    Answer: Yes. A use is a full-text article download, either HTML or PDF. ([OP] Note that for most content providers this is true; however, it is not guaranteed that ft_html + ft_pdf = ft_total. Some content providers also provide content in postscript format and this would be counted separately.

  • Question: To get cost per use did you have to manually add data for 2007 to the order records? This feature wasn’t available in the earlier Millennium release.
    Answer: Yes, we had to manually add the dates in the From and To columns in the order records to get cost per use calculations to work for 2007. The dates are now automatically generated for current payments so 2008 calculations are more complete.

  • Question: Are you required to input the from and to columns for cpu calculation?
    Answer: Yes. If the dates are not included in the from and to columns the CPU will not be calculated.

  • Question: Is SUSHI actually ready to use? I am unclear on this. Where and how?
    Answer: SUSHI is ready to use now. University of Washington is using SUSHI to collect usage data for approximately 34,000 journal titles at this time. The hard part is finding the providers who offer SUSHI feeds (in our case, the usage data collection service ScholarlyStats does this, though other resource providers such as Gale and Ebsco are starting to offer SUSHI feeds as well), an ILS vendor that provides a way to make SUSHI requests and store the received data (in our case, Innovative ERM is configured to make SUSHI requests and store journal usage data. Other ILS are working on this, and there are some librarians working on their own home-grown systems to be able to do this).