KMLM List

["Oliver Pesch" <OPesch@xxxxxxxxx>]

The intent of BR2 was to report usage by book title, not section title. The 
reason it was different than BR1 is that BR1 is only for books where there is 
no choice but to download the whole book.

As you can imagine, a book which delivers content in sections will potentially 
have a lot more downloads than a book delivered in a single PDF. 

So think of BR2 in the same way you would JR1... Where sections are the 
equivalent to articles.

Also, if you sites only deliver book content in sections, then you would not 
offer BR1 since that does not apply to you.

Oliver 
-------------------------- 
Sent from my BlackBerry Wireless Handheld 


________________________________

From: sushidevelopers@xxxxxxxxxxxxx 
To: sushidevelopers@xxxxxxxxxxxxx 
Sent: Tue Oct 26 09:51:01 2010
Subject: [sushidevelopers] creating a SUSHI service for COUNTER books reports 
(BR1- BR6) 


OUP is planning to add reports from the COUNTER CoP for books to its SUSHI 
service. I'm not sure whether that has been tried before much if at all, and 
I'd be interested in learning about anyone else's experiences of doing this. I 
also have a specific issue about rendering the BR2 report by SUSHI- please may 
I outline our current thinking about this, and ask for your perspectives?:
 
The BR2 report covers successful section requests by title. The definition of a 
"title" is largely left to the service provider, but it is clear to us on the 
OUP project that users would like a title to be pretty granular. This sometimes 
results in long reports - the Oxford Scholarship Online service has 4,264 
titles, for example. Oxford Handbooks Online has 83 titles (but over 2,700 
articles in them - obvioulsy you have to stop somewhere sensible; the Oxford 
Dictionary of National Biography has over 57,000 entries and we DO NOT plan on 
reporting each of those as a seperate line in a BR2 report :-) ). 
 
To avoid some severe performance and un-usability issues arising from gigantic 
reports, customers turning up at the OUP stats service in person will get 
separate BR2 reports for different sites - e.g. one for Oxford Scholarship 
Online, another for Oxford Handbooks Online and so forth. 
 
For SUSHI delivery, however, we DO plan to combine all section request data 
into the one BR2 report. The report could become very big - maybe 5,000 lines 
for a customer with the right set of subscriptions. Currently our thinking is 
that IN PRINCIPLE this is exactly the kind of scenario that SUSHI is made to 
handle - how to get a big rich report for processing at your lesiure. Some CR1 
reports are as big, for example. So we are not seeing this as a problem.
 
That is just as well because, as far as I can see, SUSHI does not have the 
syntax to allow a SUSHI client to request one of several different BR2 reports 
for a given institution/time period. The SUSHI client can specify which account 
it is collecting for, which report is required, and what date range. So for 
example if I am the Librarian at Gotham University, I can send my SUSHI client 
to get "the BR2 report for GothamCity  University for January to March 2011". 
The SUSHI client cannot specify that it wants "the BR2 report for Gotham City 
University's use of Oxford Scholarship Online for January to March 2011"  
(which is what Ms Barbara Gordon, Librarian at Gotham City University CAN do if 
she logs into the OUP stats service to get BR2s in person). 
 
So to recap my questions:

*       
        We plan to have mightly BR2 reports by SUSHI, which cover all titles to 
which an institution subscribes in the one SUSHI report . These could be large  
(e.g. 5,000 lines). 
*       
        We don't think there is a way of breaking the BR2 down into BR2s per 
site - if I have missed an obvious way of doing that, I would welcome your 
thoughts on how to do it,
*       
        Has anyone tackled this problem already (or is about to do so)? If so, 
I'd be most grateful to share your experiences. Alternatively if we are 
breaking ground here I would like to do so in a way that makes the OUP service 
as useful and as inter-operable as we reasonably can

 
Thanks
Chris Baker
 
 
PS - Barbara Gordon is both Batgirl and Oracle 
(http://en.wikipedia.org/wiki/Barbara_Gordon) and as a fictional superhero and 
computer genius has probably got all our data anyway, if she wants it. I just 
enjoy using "Gotham City University" as a fictional example customer....

Oxford University Press (UK) Disclaimer

This message is confidential. You should not copy it or disclose its contents 
to anyone. You may use and apply the information for the intended purpose only. 
OUP does not accept legal responsibility for the contents of this message. Any 
views or opinions presented are those of the author only and not of OUP. If 
this email has come to you in error, please delete it, along with any 
attachments. Please note that OUP may intercept incoming and outgoing email 
communications.

CONFIDENTIALITY NOTICE

This email and any files transmitted with it are confidential and solely for 
the use of the intended recipient. It may contain information which is covered 
by professional or other privilege. If you are neither the intended recipient 
of this email nor the person responsible for delivering it to the intended 
recipient, be advised that you have received this email in error and that any 
use of it is strictly prohibited. Please notify the sender immediately by reply 
email and then delete it from your system. EBSCO accepts no liability for any 
loss or damage suffered by any person arising from the use of this email. 

Please consider the environment before printing this email.