SUSHI Webinar Q&A
Below are listed questions that were submitted during the NISO SUSHI
Webinar. Answers from the presenters will be added shortly. Not all the
questions could be responded to during the live webinar, so those that could
not be addressed at the time are also included below.
Feel free to contact us if you have any additional questions about library, publishing, and technical services standards, standards development, or if you have have suggestions for new standards, recommended practices, or areas where NISO should be engaged.
SUSHI: Beyond Trial into Real Use
Webinar Questions & Answers
October 2, 2008
- Is SUSHI actually ready to use? I am unclear on this. Where and
Answer (Hana Levay): SUSHI is ready to use now. UW 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. Serials Solutions COUNTER360 product is working on this, and there are some librarians working on their own home-grown systems to be able to do this).
- For both Adam and Hana: Do you have a sense of how much time the
implementation of SUSHI will save you in managing data
Answer (Hana Levay): We've found it takes roughly 30 hours to collect usage statistics for all of our 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. The more resources move to collection via SUSHI feeds, the fewer places we have to visit 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, we would not collect on a monthly basis but rather on a quarterly basis because it was so time consuming.
- Adam: you mentioned that deploying SUSHI was expensive for vendors. Can you tell us more about what's involved for them and what impacts the costs? Is it very time consuming for them to implement?
- How time consuming is it for vendors to implement SUSHI? Do they have
to do programming? Something else? What's involved that's holding vendors
back from implementing now?
- Who has SUSHI implemented?
Answer (compiled from attendees): Marlo Harris, Wiley, noted: "We don't have it implemented at the moment, we plan to have it in place when we meet the Counter3 COP later next year." Gale's SUSHI service went live in August. EBSCO claims to be the first vendor to have implemented SUSHI (some time in the past few weeks).
- What is the holdup... why are so many e-resource vendors not SUSHI compliant? What's it going to take to get them there?
- Are there any SUSHI implementations driven by the librarian
community, not a commercial source? What exactly does Scholarly Stats
provide that is lacking elsewhere?
- Please explain the "Code of Practice" lingo.
- What are the plans for COUNTER/SUSHI with e-book
Answer (Hana Levay): The current version of COUNTER includes e-book reports. Since SUSHI is just a protocol to transfer data, it could work with e-book data now. The sticking point would be the ILS system, such as Innovative ERM in my case, configuring the system to accept the SUSHI data. Right now, Innovative ERM is only configured to accept journal data.
- Can individual libraries step up SUSHI to grab Counter data from
- If we don't have an ERM how do we receive the xml files (where else
can it go)?
- We use III for our ILS. If we want to implement SUSHI, do we need to
have our IT people develop the code using SUSHI, or is there an out-of-the
box product that we can purchase that will send SUSHI to our III
Answer (Hana Levay): If you have the latest version of III ERM, your IT people shouldn't need to get involved at all. You should be able to set it up like I show in my slides. If you do not have III ERM, then you would need your IT people to develop your own client-side system. There has been some work done on this by library communities but I do not think it is a packaged out-of-the-box system you can use yet.
- Can a Library utilize SUSHI without an ERM client?
- What other vendors (other than Scholarly Stats) can provide SUSHI
- Do we know how many sites have SUSHI actually installed and
- We have just chosen a new serials subscription vendor. They say that
they are expecting to have SUSHI enabled counter usage stats available
soon-much like Hanna's SUSHI reports-how do you feel about serials
subscription vendors offering this service?
- Are there electronic medical reference vendors that use SUSHI or
COUNTER? Such as MDConsult, Lexi-Comp, Micromedex, etc.?
Answer (Hana Levay): Science Magazine from AAAS is COUNTER compliant but in general I don't know of any others that are off the top of my head. UW is not collecting any medical reference vendor data via SUSHI at this time.
- We find that stats are very often not truly CONTER compliant despite
vendors' claims that they are. What reason do we have to hope that SUSHI
providers will do any better?
- This is a follow-up to the last question... If, as we have noticed,
that up to 40 percent of the COUNTER reports contain errors in formatting,
how can we expect these same vendors to implement SUSHI services any more
- Has anyone successfully implemented importing directly from the
vendors, not via Scholarly Stats or Serials Solutions?
Answer (Hana Levay): I have not attempted to send a SUSHI request to any vendors, but I am going to try that as more vendors provide the SUSHI feed service.
- What vendor/system do you use for acquisitions module?
Answer (Hana Levay): UW uses Innovative Interfaces for the acquisitions module.
- Is Scholarly Stats part of III?
Answer (Hana Levay): No. ScholarlyStats is a vendor University of Washington has outsourced some of our usage statistics collection to. Their role is simply to provide that usage data to us via SUSHI feeds. This is in addition to the other reports they provide via Excel spreadsheets.
- Why is the customer-id different for each provider?
Answer (Hana Levay): 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.
- For the access provider 5-digit code: are you using the contact
record to create that?
Answer (Hana Levay): Yes, the access provider code comes from the contact record.
- How is 'use' defined? Is it searches, page views, etc?
Answer (Hana Levay): For journal usage reports, a use is defined to be a full-text download, either HTML or PDF. This is defined in the COUNTER Journal Report 1.
- Since there is a lack of standardization within the COUNTER/SUSHI
community, what is considered a "use" and how can that definition be applied
to Cost-Per-Use calculations across subscription titles and packages?
- Do you add the HTML use and the PDF together?
Answer (Hana Levay): Yes. A use is a full-text article download, either HTML or PDF.
- Are you required to input the from and to columns for CPU
Answer (Hana Levay): Yes. If the dates are not included in the from and to columns the CPU will not be calculated.
- Is the information which populates the columns entered
Answer (Hana Levay): The dates in the 'From' and 'To' columns are now entered automatically, but we have to manually enter dates for previous years.
- If there is no ISSN on the record, how do you relate the
Answer (Hana Levay): That is a problem. Sometimes there is no ISSN so I wasn't able to match those titles. However, we've found that matching on ISSN is the best way and provides a match for most of the titles.
- Am I understanding correctly that you created serials database using
fields from your ERM?
Answer (Hana Levay): The serials database uses many different tables. The central table was created using data from our acquisitions module, but many of the other tables used data from other sources, including from our ERM, usage reports, and Eigenfactor.
- How have you dealt with the complications caused by title
Answer (Hana Levay): Title changes are a problem. We just continue to match on ISSN and since we only have one year of data that hasn't been a problem yet. I could see that being an issue as we try to match multiple years together.
- Is UW an Oracle site?
Answer (Hana Levay): No.
- Hana: 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
Answer (Hana Levay): 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.
- Hana: Do you anticipate no longer needing Scholarly Stats when SUSHI
has been adopted among vendors?
Answer (Hana Levay): SUSHI is only one of the things we use ScholarlyStats for, we find their other reports to be useful as well. We don't anticipate dropping their service anytime soon. I could see them becoming a third-party provider for SUSHI feeds for vendors who do not want to implement the system themselves.
- Hana: Did you find that you needed to do various clean up projects or
preparation before implementing? In using the contact record: is that where
you are keeping the administrative information relating to gathering usage
Answer (Hana Levay): Yes, there was some clean up we had to do, but also we didn't want to spend too much time on cleaning data as it wasn't worth the time spent. Mainly the cleanup involved making sure ISSNs were correctly formatted (such as when the leading 0s are lost). We do keep some administrative records for usage data in the contact record, but mainly that information is kept in a master Word document that is now roughly 50 pages long. Collecting usage statistics is a cumbersome process.
- Do you collect statistics for the vendors that aren't available
through Scholarly Stats?
Answer (Hana Levay): We go to those websites manually, log in, and download usage reports.
- Are you using this to collect database search stats?
Answer (Hana Levay): At this time, III only is able to collect data for
journals using SUSHI feeds.
- Do all your titles have OCLC #?
Answer (Hana Levay): Most of our titles have OCLC#s but we do not use those numbers for this process.
- If someone puts the data (xml usage) manually, will this work? Or is
one wedded to Scholarly Stats and the SUSHI protocol?
Answer (Hana Levay): At this time, if you input the xml usage into the usage statistics tab manually, the cost per use calculations are not computed by III. The data needs to be imported using the SUSHI protocol. You are not wedded to ScholarlyStats; you could send requests to any vendor/provider that has set up a SUSHI server, though at this time there aren't many that are providing that service yet. That is why we are only using ScholarlyStats SUSHI feeds right now.
- How do you import the impact factor and Eigenfactor data into your
Answer (Hana Levay): I was able to create spreadsheets with Impact Factor data and another with Eigenfactor data, and then I could easily import those spreadsheets into Access. We have a subscription to Impact Factor so we already had that data in-house, and I got the Eigenfactor data from the Eigenfactor group since I have been collaborating with them. You can look up Eigenfactors for individual journals but there is not yet a way to download that data.
- Hana: Can you reconcile cases where your users can access a resource
from two hosts but which correspond to one payment?
Answer (Hana Levay): I am not sure that we have this situation here. Since we start by looking at each payment rather than each journal, it seems like this wouldn't come up.
- Hana: It sounds like you are using ISSN for the primary key. What if
you have the same journal with more than one package/vendor?
Answer (Hana Levay): Actually, the primary key for my database is our internal order number which corresponds to payments for journals titles or packages. Then, I match on ISSN to pull in information about the title. Since we were interested in bibliometrics on journal titles, it didn't matter as much to make sure there was a one-to-one match up. For the 2007 use, I added together the uses the title got from all sources and we looked at that value as a general measure, rather than really focusing on how much use Journal A got through Resource 1 versus Resource 2. We may change the database in the future for another project in order to answer that last question, but for now what we have works.
- How does UW deal with titles that have both ISSN and
Answer (Hana Levay): We are only using ISSN, not e-ISSN. It seems that e-ISSN has not been widely adopted.
- Hana; Are you going to vendors directly other than Scholarly Stats
for SUSHI services?
Answer (Hana Levay): Not yet. That is something I look forward to trying as they become more available.
- What is the name of the person at Penn State that is creating an
- If a library signs up with Scholarly Stats now can it get usage data
from previous years?
Answer (Hana Levay): I'm not sure. You would have to ask them directly to see if that is something they can do for you.