KMLM List

["Michael T. Puff" <mtpuff@xxxxxxxxxxxx>]

Oliver,

Can you point me to some documentation that shows what is expected to  
be transferred on request for each of the COUNTER reports (both  
required and optional)?

Michael

On Apr 20, 2009, at 4:05 PM, Oliver Pesch wrote:

> The COUNTER XML is really about transfering the base data not trying  
> to replicate the Excel.
>
> Tae is correct, the expectation is that the html and pdf counts are  
> included at the month level.
>
>
> Oliver
> --------------------------
> Sent from my BlackBerry Wireless Handheld
>
>
> From: Michael T. Puff
> To: Kim, Tae
> Cc: sushidevelopers@xxxxxxxxxxxxx
> Sent: Mon Apr 20 17:59:12 2009
> Subject: Re: [sushidevelopers] Counter XML Question
>
> For me, this begs the question of intent on the part of COUNTER.   
> Are we creating an xml version of the existing COUNTER JR1 report or  
> are we creating an xml report with the base data so that the user  
> can create a JR1 report?  The way I read the COUNTER Code of  
> Practice leads me to believe the former.  If it is the latter, I  
> think more guidance is required.
>
> -Michael
>
> On Apr 20, 2009, at 3:43 PM, Kim, Tae wrote:
>
> > The idea is the pdf and html counts should be split up monthly as  
> > well. Of course, if the sushi service doesn’t store that data at  
> > that granular level and instead just as a YTD total, that data  
> > can’t be returned in a sushi call anyway because the requestor can  
> > request stats for an arbitrary length of months, for example Nov  
> > 2007 to Feb 2008.
> >
> > -Tae Kim
> >
> >
> > On 4/20/09 3:35 PM, "Michael T. Puff" <mtpuff@xxxxxxxxxxxx> wrote:
> >
> > It would seem to me that multi-month would be required for a proper  
> > COUNTER JR1 report.  The monthly counts represent ft_total which  
> > can be a combination html, pdf, etc.  While the JR1 "YTD TOTAL"  
> > column is a simple sum of the monthly columns (and admittedly  
> > redundant), the JR1 columns for "YTD HTML" and "YTD PDF" cannot be  
> > derived from the monthly counts.  I think you would need multi- 
> > month instance to report these two figures as ft_html and ft_pdf  
> > else the report would not meet the JR1 specification.
> >
> > -Michael
> >
> > On Apr 20, 2009, at 9:09 AM, Dennis Vaux wrote:
> >
> >
> > At Innovative, we have coded our SUSHI client to ignore any period  
> > counts for periods that span more than one month.   I agree that no  
> > one needs this "summary" data, but it isn't explicitly prohibited  
> > by the xsd, and we were unsuccessful when we tried to get Scholarly  
> > Stats to stop sending these summary counts in their SUSHI response  
> > when we first tested SUSHI 1.0 with them.
> >
> >
> > -----Original Message-----
> > From: Kim, Tae   [mailto:Tae.Kim@xxxxxxxxxxxxxxxxxxxx]
> > Sent: Friday, April 17, 2009   9:30 AM
> > To: sushidevelopers@xxxxxxxxxxxxx
> > Subject:   [sushidevelopers] Counter XML Question
> >
> > I’m   working with Proquest sushi service and they return the stats  
> > for every month   and a total for all the months.
> >
> > For example if I ask for Jan-March, it   returns something like:
> > 2008-01-01 to 2008-01-31: 3 requests
> > 2008-02-01   to 2008-02-28: 4 requests
> > 2008-03-01 to 2008-03-31: 1   requests
> > 2008-01-01 to 2008-03-31: 8 requests
> >
> > I’d LIKE to tell them   that really, the last is redundant and  
> > spans multiple months so it shouldn’t   be in the result.
> > But really, I can’t find anything in the SUSHI or COUNTER    
> > standard that dictates that each data point should be exactly one  
> > month in   duration.
> >
> > The xsd of course can’t really validate  anything like   this.
> >
> > Can anybody point me to something in the standard? Usage stats    
> > spanning multiple months is kinda problematic for me and I imagine  
> > for other   clients as well.
> >
> > Tae Kim
> > Software Developer
> > Serials   Solutions
> >
> >
> >
> > ---------------------
> > Michael T. Puff
> >
> > Systems Specialist,
> > HighWire Press, Stanford University
> > Phone: 650-723-8348; Fax: 650-725-9335
> > mtpuff@xxxxxxxxxxxx
>
>
> ---------------------
> Michael T. Puff
>
> Systems Specialist,
> HighWire Press, Stanford University
> Phone: 650-723-8348; Fax: 650-725-9335
> mtpuff@xxxxxxxxxxxx
>
>
>
>
> 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.