KMLM List

["Radermacher, Ulrich" <Ulrich.Radermacher@xxxxxxxxx>]

This seems a(n) undocumented convention, not a defintion in the xsd

met vriendelijke groeten

Ulrich Radermacher

_______________________________________________________
Si j'étais Dieu, j'aurais pitié du coeur des hommes (Maeterlinck)



-----Oorspronkelijk bericht-----
Van: Oliver Pesch [mailto:OPesch@xxxxxxxxxxxxx]
Verzonden: di 21-4-2009 1:08
Aan: Radermacher, Ulrich; sushidevelopers@xxxxxxxxxxxxx
Onderwerp: Re: [sushidevelopers] Counter XML Question
 
The date ranges of usage is expressed in the Request. The response includes 
details for each month represented by the request. So if the request asks for 
jan thru march... The response would return stats for jan, feb, and mar as 
separate nodes. 
-------------------------- 
Sent from my BlackBerry Wireless Handheld 


________________________________

From: Radermacher, Ulrich 
To: sushidevelopers@xxxxxxxxxxxxx 
Sent: Mon Apr 20 18:00:48 2009
Subject: RE: [sushidevelopers] Counter XML Question 



How can a Sushi client expect that when requesting data from januari to march 
to receive 3 "columns", one for each month? Wouldn't the client be required to 
ask 3 times for one month, if he/she wants to receive data "per month"?

met vriendelijke groeten

Ulrich Radermacher

_______________________________________________________
Si j'étais Dieu, j'aurais pitié du coeur des hommes (Maeterlinck)



-----Oorspronkelijk bericht-----
Van: Kim, Tae [mailto:Tae.Kim@xxxxxxxxxxxxxxxxxxxx]
Verzonden: di 21-4-2009 0:43
Aan: Michael T. Puff; sushidevelopers@xxxxxxxxxxxxx
Onderwerp: Re: [sushidevelopers] Counter XML Question

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










 

Disclaimer
Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor 
de geadresseerde. Indien u niet de bedoelde ontvanger bent, wordt u verzocht de 
afzender te waarschuwen en dit bericht met eventuele bijlagen direct te 
verwijderen en/of te vernietigen. Het is niet toegestaan dit bericht en 
eventuele bijlagen te vermenigvuldigen, door te sturen, openbaar te maken, op 
te slaan of op andere wijze te gebruiken. Ordina N.V. en/of haar 
groepsmaatschappijen accepteren geen verantwoordelijkheid of aansprakelijkheid 
voor schade die voortvloeit uit de inhoud en/of de verzending van dit bericht.

This e-mail and any attachments are confidential and are solely intended for 
the addressee. If you are not the intended recipient, please notify the sender 
and delete and/or destroy this message and any attachments immediately. It is 
prohibited to copy, to distribute, to disclose or to use this e-mail and any 
attachments in any other way. Ordina N.V. and/or its group companies do not 
accept any responsibility nor liability for any damage resulting from the 
content of and/or the transmission of this message.


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.




Disclaimer

Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor 
de geadresseerde. Indien u niet de bedoelde ontvanger bent, wordt u verzocht de 
afzender te waarschuwen en dit bericht met eventuele bijlagen direct te 
verwijderen en/of te vernietigen. Het is niet toegestaan dit bericht en 
eventuele bijlagen te vermenigvuldigen, door te sturen, openbaar te maken, op 
te slaan of op andere wijze te gebruiken. Ordina N.V. en/of haar 
groepsmaatschappijen accepteren geen verantwoordelijkheid of aansprakelijkheid 
voor schade die voortvloeit uit de inhoud en/of de verzending van dit bericht.

This e-mail and any attachments are confidential and are solely intended for 
the addressee. If you are not the intended recipient, please notify the sender 
and delete and/or destroy this message and any attachments immediately. It is 
prohibited to copy, to distribute, to disclose or to use this e-mail and any 
attachments in any other way. Ordina N.V. and/or its group companies do not 
accept any responsibility nor liability for any damage resulting from the 
content of and/or the transmission of this message.