Re: [IUG] Cover Art using UPC or OCLC numbers

[Bob Duncan <duncanr at lafayette dot edu>]

I'd like to try and shed a little light on the whole Syndetics cover 
art based on upc/oclc thing.  First, responses to two replies to 
Lauren's original query;  second, some observations based on some 
testing I did in our staging port.  It's a long one; turn back now if 
you can...


At 08:10 PM 1/13/2009, Catherine wrote:
> WNCLN just initiated Syndetics this afternoon, using BIBIMAGE with a 
> url that is
> based on ISBN, UPC or OCLC number.  So far we have not noticed any 
> of the issues
> mentioned.  We did just migrate to a new IBM server and will keep our fingers
> crossed.

If you're using the BIBIMAGE wwwoption for cover art, you are *not* 
sending UPC or OCLC numbers to Syndetics, because the current 
out-of-the-box WebPAC has no mechanism for getting those numbers into 
the URL.  (Check the Syndetics URLs in the source code of a 
page.)  The only way to send UPC and/or OCLC number to Syndetics (or 
anyone else, AFAIK), is to use WebBridge and the ENH_IMAGE wwwoption 
(or WebBridge on its own, or some handy dandy scripting).


At 05:54 PM 1/13/2009, Dan wrote:
> ...UNC Coastal Library Consortium experiences severe slowdown when 
> we enable the ENH_IMAGE web option required for displaying Syndetics 
> cover art based on UPC or OCLC number. I have had a call open about 
> this issue since early Sept. - c1083716 (NCCOA):  WebBridge not 
> working with Syndetics Cover Art.  When I last checked, the issue 
> had been sent to Software Engineering with no estimated resolution 
> time.  We are unable to use this functionality because of this poor 
> response time...

I'm a little confused by the subject of the call---"WebBridge not 
working with Syndetics Cover Art"--- and why it's even an Innovative 
call, because it would seem to be a Syndetics problem and not a 
WebBridge problem.  WebBridge's function is to grab the values for 
UPC and OCLC number from the record and pop them into the Syndetics 
URL(s).  If you enable ENH_IMAGE, configure WebBridge appropriately, 
do a keyword search, stop the page from loading, then look at the 
source code, you'll probably see that WebBridge has populated all of 
the Syndetics URLs with upc and/or oclc values (for those records 
that have them).  In my experience WebBridge does that pretty 
speedily;  the hold up with loading images is not WebBridge (nor the 
WebPAC server), but Syndetics' response to the calls for images based 
on the information in the URLs.  (If WebBridge is not populating the 
upc and oclc# values, then it's indeed "WebBridge not working...")


We don't use Syndetics, but I did some testing in our staging port 
using the Syndetics client codes for three different libraries and 
got some pretty interesting results.  (Note that Syndetics doesn't 
limit calls for content in any way other than checking for a valid 
client code.)  I configured the Syndetics image URL using one code, 
did some searches, recorded the time it took to load the results 
pages, then emptied my browser's cache, altered the Syndetics URL to 
use the next library's code, then did the searches over again.  I 
played around with sending isbn, upc, and oclc#, and different 
combinations of these values absent the others.  I did it all over 
again, then all over again a day later.

The most startling thing I observed was that on Day1, it routinely 
took about 10 times as long to finish loading the same page of images 
when using Library A's code as it did when Library B's code was 
used.  (Roughly 90+ seconds versus 9 seconds.  For a page of 50 
results with 40+ images, 9 seconds seemed acceptable to me.  90+ 
seconds made me want to toss in the towel.)  Typical complete load 
time when using Library C's code was about twice as long as when when 
using B's.  The same server (my WebPAC), the same Syndetics URLs, the 
same batch of images, but the response time for complete loading of 
all images varied drastically based on which client code was used in 
the URL.  I don't know how Syndetics does things, so don't know 
precisely what conclusion to draw from this, but it doesn't seem like 
correct behavior.

On Day2, Library B and Library C were comparable (and just as speedy 
as Library B on Day1), but Library A typically took just 2-3 times as 
long instead of 10 times as long.  On Day3, I did real work.

Other observations:

-  For books, Syndetics never returned a cover image based on 
anything other than an ISBN.  I.e., if there was no image for the 
ISBN, having the OCLC number didn't increase the chances of returning 
a cover image.  (This may be consistent with what Syndetics promises 
for the UPC/OCLC#?)

-  For videos, Syndetics returned an image based on the OCLC# about 
25% of the time for recent stuff;  the percentage decreased with the 
pub date (to be expected).  For the same list of videos, images were 
returned based on the UPC about 65% of the time for recent 
stuff.  When both UPC and OCLC# were offered, the percentage remained 
at ~65% with just a few more images returned.  I think considering 
the nature of our video collection---academic library, but with a 
pretty strong collection of feature films and popular culture 
stuff---that seems like a pretty reasonable return, but I don't know 
what (if anything) Syndetics is promising.

-  The complete load time didn't vary when images were produced based 
on UPC (vs. on ISBN).

-  A RightResult-sorted keyword search sometimes took longer to fully 
load than a date-sorted keyword search.  Since the top 50 results in 
a date-sorted results are more likely to have more cover images than 
the top 50 results in a RR-sorted list (which will usually have old 
and new titles in the top 50), I think this just suggests that the 
total load time is faster when Syndetics can find images right off, 
and they don't have to check multiple values in the image URL before 
serving up the "empty" image.


Back to real work.


Bob Duncan



~!~!~!~!~!~!~!~!~!~!~!~!~
Robert E. Duncan
Systems Librarian
Editor of IT Communications
Lafayette College
Easton, PA  18042
duncanr at lafayette dot edu
http://library.lafayette.edu/