KMLM List
View email archives for the history of this mailing list.
|
|
|
|
sushidevelopers - Re: [sushidevelopers] Counter XML Question
|
Message Thread:
Previous |
Next
|
- To: <mtpuff@xxxxxxxxxxxx>
- From: "Oliver Pesch" <OPesch@xxxxxxxxxxxxx>
- Date: Mon, 20 Apr 2009 20:30:58 -0500
- Cc: <Tae.Kim@xxxxxxxxxxxxxxxxxxxx>, <sushidevelopers@xxxxxxxxxxxxx>
- Send Email to sushidevelopers@list.niso.org:
- Send new message
- Reply to this message
|
We are working on some of these details... Thanks to the recent activity on the
list we are discovering more holes inthe documentation and are working to fill
them. I hope we can point you to something by the end of the week including
some annotated simple sample files.
In the meantime keep the questions coming.
--------------------------
Sent from my BlackBerry Wireless Handheld
________________________________
From: Michael T. Puff
To: Oliver Pesch
Cc: Tae.Kim@xxxxxxxxxxxxxxxxxxxx ; sushidevelopers@xxxxxxxxxxxxx
Sent: Mon Apr 20 19:47:47 2009
Subject: Re: [sushidevelopers] Counter XML Question
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.
|
|
|
Mail converted by the most-excellent MHonArc 2.6.16
|
