KMLM List

["Oliver Pesch" <OPesch@xxxxxxxxxxxxx>]

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.