KMLM List
View email archives for the history of this mailing list.
|
|
|
|
sushidevelopers - Re: [sushidevelopers] Counter XML Question
|
Message Thread:
Previous |
Next
|
- To: "Kim, Tae" <Tae.Kim@xxxxxxxxxxxxxxxxxxxx>
- From: "Michael T. Puff" <mtpuff@xxxxxxxxxxxx>
- Date: Mon, 20 Apr 2009 15:59:12 -0700
- Cc: "sushidevelopers@xxxxxxxxxxxxx" <sushidevelopers@xxxxxxxxxxxxx>
- Send Email to sushidevelopers@list.niso.org:
- Send new message
- Reply to this message
|
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
|
|
|
Mail converted by the most-excellent MHonArc 2.6.16
|