Re: [OPEN-ILS-GENERAL] Covers and ISBNs
On Fri, Oct 07, 2011 at 03:57:47PM +0100, Ian Bays wrote: Hi Gordona, (dev list copied in case we need to submit a patch) - I have just seen Dan's latest post so will contribute it properly:-) Thanks Ian. I've committed a variant of your patch to master through rel_2_0 so it will appear in the next maintenance releases of Evergreen. Note that the in-the-wild placement of Amazon IDs in the 020 a field/subfield (defined as the ISBN location) was a bit of a surprise to me - it's a workaround to get cover art to show up for entities without an ISBN, I guess, but it tells me that we need to refactor our added content layer to support other kinds of identifiers rather than to encourage further metadata abuse of this nature... (Paging Jeff!)
Re: [OPEN-ILS-GENERAL] Covers and ISBNs
Hi Ben, Brian et al, We came across this when trying to show images from Amazon. We know from experience that Amazon mostly only responds to 10-digit ISBNs as the Amazon ID matched the 10-digit ISBN. Amazon's line has always been that they provide images keyed on their Amazon ID. When loading data there are 10-digit and 13-digit ISBNs often in no particular order. So we found the script in Evergreen that forms the URL for the image from Amazon and test if the ISBN is 13-digits, and if so convert it using Business::ISBN perl module to be a 10-digit ISBN. So no messing with the data in bib at all. Seems to work well. On our system the script to change is: /openils/lib/perl5/OpenILS/WWW/AddedContent/Amazon.pm We're happy to share - it's just a few lines. Maybe this should be on the DEV list? Also we noticed that if your ISBNs have hyphens in them then the ISBN only comes through as the digits up to the first hyphen (in our case usually 0). We do get lots of cataloguers who believe ISBNs should have hyphens. So we are weighing up removing hyphens in data conversion versus finding the code that writes the ISBN field and getting it to skip/ignore hyphens. Should make it look real pretty! All the best. Ian On 06/10/2011 18:56, Ben Shum wrote: Hi Brian, As far as I know, the first ISBN entry of a record will always be used to retrieve added content images. I'm not familiar with any workarounds other than editing the records to order the information in them accordingly, but maybe someone is working on this? Otherwise, I think that'd be a useful feature to have in the future. -- Ben On 10/6/2011 1:17 PM, Brian Greene wrote: In many cases covers won't display in our OPAC if the 13-digit ISBN is above the 10-digit ISBN in the bib record. If I switch the order of the ISBNs so that the 10-digit one is first then the cover displays. This is the case most of the time, although I have come across instances where the 13-digit ISBN displays the cover properly. Does anyone know of a fix for this? Is there a setting we can change to use a second ISBN if the first one doesn't retrieve a cover? We're running 2.1. Thanks, Brian Greene, Library Director Columbia Gorge Community College The Dalles, Oregon 97058 (541) 506-6080 | www.cgcc.cc.or.us http://www.cgcc.cc.or.us/ -- Benjamin Shum Open Source Software Coordinator Bibliomation, Inc. 32 Crest Road Middlebury, CT 06762 203-577-4070, ext. 113 -- Ian Bays Director of Projects PTFS Europe mobile: +44 (0) 7774995297 phone: +44 (0) 800 756 6803 skype: ian.bays email: ian.b...@ptfs-europe.com
Re: [OPEN-ILS-GENERAL] Covers and ISBNs
Hi Ian, I would be interested to know how you got this to work. Thanks! Gordana Gordana Vitez Library Services Systems Coordinator NC Libraries and Learning Commons Niagara College 300 Woodlawn Rd Welland Ontario L3C 7L3 Phone: (905) 735 2211 ext 7404 Fax: (905) 736 6021 gvi...@niagaracollege.ca Ian Bays ian.b...@ptfs-europe.com 10/7/2011 5:52 AM Hi Ben, Brian et al, We came across this when trying to show images from Amazon. We know from experience that Amazon mostly only responds to 10-digit ISBNs as the Amazon ID matched the 10-digit ISBN. Amazon's line has always been that they provide images keyed on their Amazon ID. When loading data there are 10-digit and 13-digit ISBNs often in no particular order. So we found the script in Evergreen that forms the URL for the image from Amazon and test if the ISBN is 13-digits, and if so convert it using Business::ISBN perl module to be a 10-digit ISBN. So no messing with the data in bib at all. Seems to work well. On our system the script to change is: /openils/lib/perl5/OpenILS/WWW/AddedContent/Amazon.pm We're happy to share - it's just a few lines. Maybe this should be on the DEV list? Also we noticed that if your ISBNs have hyphens in them then the ISBN only comes through as the digits up to the first hyphen (in our case usually 0). We do get lots of cataloguers who believe ISBNs should have hyphens. So we are weighing up removing hyphens in data conversion versus finding the code that writes the ISBN field and getting it to skip/ignore hyphens. Should make it look real pretty! All the best. Ian On 06/10/2011 18:56, Ben Shum wrote: Hi Brian, As far as I know, the first ISBN entry of a record will always be used to retrieve added content images. I'm not familiar with any workarounds other than editing the records to order the information in them accordingly, but maybe someone is working on this? Otherwise, I think that'd be a useful feature to have in the future. -- Ben On 10/6/2011 1:17 PM, Brian Greene wrote: In many cases covers won't display in our OPAC if the 13-digit ISBN is above the 10-digit ISBN in the bib record. If I switch the order of the ISBNs so that the 10-digit one is first then the cover displays. This is the case most of the time, although I have come across instances where the 13-digit ISBN displays the cover properly. Does anyone know of a fix for this? Is there a setting we can change to use a second ISBN if the first one doesn't retrieve a cover? We're running 2.1. Thanks, Brian Greene, Library Director Columbia Gorge Community College The Dalles, Oregon 97058 (541) 506-6080 | www.cgcc.cc.or.us ( http://www.cgcc.cc.or.us/ ) -- Benjamin Shum Open Source Software Coordinator Bibliomation, Inc. 32 Crest Road Middlebury, CT 06762 203-577-4070, ext. 113 -- Ian Bays Director of Projects PTFS Europe mobile: +44 (0) 7774995297 phone: +44 (0) 800 756 6803 skype: ian.bays email: ian.b...@ptfs-europe.com
Re: [OPEN-ILS-GENERAL] Covers and ISBNs
On Fri, Oct 7, 2011 at 5:52 AM, Ian Bays ian.b...@ptfs-europe.com wrote: Hi Ben, Brian et al, We came across this when trying to show images from Amazon. We know from experience that Amazon mostly only responds to 10-digit ISBNs as the Amazon ID matched the 10-digit ISBN. Amazon's line has always been that they provide images keyed on their Amazon ID. When loading data there are 10-digit and 13-digit ISBNs often in no particular order. So we found the script in Evergreen that forms the URL for the image from Amazon and test if the ISBN is 13-digits, and if so convert it using Business::ISBN perl module to be a 10-digit ISBN. So no messing with the data in bib at all. Seems to work well. On our system the script to change is: /openils/lib/perl5/OpenILS/WWW/AddedContent/Amazon.pm We're happy to share - it's just a few lines. Maybe this should be on the DEV list? Please do share: it's an open-source project and it sounds like a good incremental improvement to Amazon added content. The contribution process is at http://evergreen-ils.org/dokuwiki/doku.php?id=contributing - it would be great to see your name / company added to the contributor list! Also we noticed that if your ISBNs have hyphens in them then the ISBN only comes through as the digits up to the first hyphen (in our case usually 0). We do get lots of cataloguers who believe ISBNs should have hyphens. So we are weighing up removing hyphens in data conversion versus finding the code that writes the ISBN field and getting it to skip/ignore hyphens. Should make it look real pretty! There are multiple ways of addressing this. I would err on the side of letting cataloguers enter whatever they want and cleaning up the results when you pull the ISBN - it looks like the cleanISBN() function in opac_utils.js is a candidate, and/or in the AddedContent Perl layer (given that requests may come in from places other than rdetail.js / result_common.js).
Re: [OPEN-ILS-GENERAL] Covers and ISBNs
Hi Gordona,
(dev list copied in case we need to submit a patch) - I have just seen
Dan's latest post so will contribute it properly:-)
So in case you want it before it goes through the process here it is.
Using documentation from Business::ISBN:
Changes are to:
/openils/lib/perl5/OpenILS/WWW/AddedContent$ diff Amazon.pm Amazon_safe.pm
9d8
use Business::ISBN;
70,81d68
#open( my $diag, '/tmp/diagISBN.log' );
#print $diag before: $key\n;
#print $diag length: . length($key) . \n;
if (length($key) == 13) {
my $isbn = Business::ISBN-new( $key );
$isbn = $isbn-as_isbn10 if $isbn-type eq 'ISBN13';
if (defined $isbn) {
$key = $isbn-as_string([]);
}
}
#print $diag after : $key\n;
#close ($diag);
So the subroutine (without diagnostic comments) is:
# returns the HTTP response object from the URL fetch
sub fetch_response {
my( $self, $page, $key ) = @_;
my $uname = $self-userid;
if (length($key) == 13) {
my $isbn = Business::ISBN-new( $key );
$isbn = $isbn-as_isbn10 if $isbn-type eq 'ISBN13';
if (defined $isbn) {
$key = $isbn-as_string([]);
}
}
my $url = $self-base_url . $key.01.$page;
return $AC-get_url($url);
}
This of course assumes you are using Amazon content. I think we had to
restart caching to make it work.
Good luck.
Ian
On 07/10/2011 15:18, Gordana Vitez wrote:
Hi Ian,
I would be interested to know how you got this to work.
Thanks!
Gordana
Gordana Vitez
Library Services Systems Coordinator
NC Libraries and Learning Commons
Niagara College
300 Woodlawn Rd
Welland Ontario
L3C 7L3
Phone: (905) 735 2211 ext 7404
Fax: (905) 736 6021
gvi...@niagaracollege.ca
Ian Bays ian.b...@ptfs-europe.com 10/7/2011 5:52 AM
Hi Ben, Brian et al,
We came across this when trying to show images from Amazon. We know
from experience that Amazon mostly only responds to 10-digit ISBNs as
the Amazon ID matched the 10-digit ISBN. Amazon's line has always
been that they provide images keyed on their Amazon ID.
When loading data there are 10-digit and 13-digit ISBNs often in no
particular order. So we found the script in Evergreen that forms the
URL for the image from Amazon and test if the ISBN is 13-digits, and
if so convert it using Business::ISBN perl module to be a 10-digit
ISBN. So no messing with the data in bib at all. Seems to work well.
On our system the script to change is:
/openils/lib/perl5/OpenILS/WWW/AddedContent/Amazon.pm
We're happy to share - it's just a few lines. Maybe this should be on
the DEV list?
Also we noticed that if your ISBNs have hyphens in them then the ISBN
only comes through as the digits up to the first hyphen (in our case
usually 0). We do get lots of cataloguers who believe ISBNs should
have hyphens. So we are weighing up removing hyphens in data
conversion versus finding the code that writes the ISBN field and
getting it to skip/ignore hyphens. Should make it look real pretty!
All the best.
Ian
On 06/10/2011 18:56, Ben Shum wrote:
Hi Brian,
As far as I know, the first ISBN entry of a record will always be
used to retrieve added content images. I'm not familiar with any
workarounds other than editing the records to order the information
in them accordingly, but maybe someone is working on this?
Otherwise, I think that'd be a useful feature to have in the future.
-- Ben
On 10/6/2011 1:17 PM, Brian Greene wrote:
In many cases covers won't display in our OPAC if the 13-digit ISBN
is above the 10-digit ISBN in the bib record. If I switch the order
of the ISBNs so that the 10-digit one is first then the cover
displays. This is the case most of the time, although I have come
across instances where the 13-digit ISBN displays the cover
properly. Does anyone know of a fix for this? Is there a setting we
can change to use a second ISBN if the first one doesn't retrieve a
cover? We're running 2.1.
Thanks,
Brian Greene, Library Director
Columbia Gorge Community College
The Dalles, Oregon 97058
(541) 506-6080 | www.cgcc.cc.or.us http://www.cgcc.cc.or.us/
--
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113
--
Ian Bays
Director of Projects
PTFS Europe
mobile: +44 (0) 7774995297
phone: +44 (0) 800 756 6803
skype: ian.bays
email:ian.b...@ptfs-europe.com
--
Ian Bays
Director of Projects
PTFS Europe
mobile: +44 (0) 7774995297
phone: +44 (0) 800 756 6803
skype: ian.bays
email: ian.b...@ptfs-europe.com
[OPEN-ILS-GENERAL] Covers and ISBNs
In many cases covers won't display in our OPAC if the 13-digit ISBN is above the 10-digit ISBN in the bib record. If I switch the order of the ISBNs so that the 10-digit one is first then the cover displays. This is the case most of the time, although I have come across instances where the 13-digit ISBN displays the cover properly. Does anyone know of a fix for this? Is there a setting we can change to use a second ISBN if the first one doesn't retrieve a cover? We're running 2.1. Thanks, Brian Greene, Library Director Columbia Gorge Community College The Dalles, Oregon 97058 (541) 506-6080 | www.cgcc.cc.or.us
Re: [OPEN-ILS-GENERAL] Covers and ISBNs
Hi Brian, As far as I know, the first ISBN entry of a record will always be used to retrieve added content images. I'm not familiar with any workarounds other than editing the records to order the information in them accordingly, but maybe someone is working on this? Otherwise, I think that'd be a useful feature to have in the future. -- Ben On 10/6/2011 1:17 PM, Brian Greene wrote: In many cases covers won't display in our OPAC if the 13-digit ISBN is above the 10-digit ISBN in the bib record. If I switch the order of the ISBNs so that the 10-digit one is first then the cover displays. This is the case most of the time, although I have come across instances where the 13-digit ISBN displays the cover properly. Does anyone know of a fix for this? Is there a setting we can change to use a second ISBN if the first one doesn't retrieve a cover? We're running 2.1. Thanks, Brian Greene, Library Director Columbia Gorge Community College The Dalles, Oregon 97058 (541) 506-6080 | www.cgcc.cc.or.us http://www.cgcc.cc.or.us/ -- Benjamin Shum Open Source Software Coordinator Bibliomation, Inc. 32 Crest Road Middlebury, CT 06762 203-577-4070, ext. 113
Re: [OPEN-ILS-GENERAL] Covers and ISBNs
Hi Brian, We came across the same problem back in the summer and I think the only thing to do is ask the materials provider to switch the order. I did get a good explanation from Galen and I'll include it here: For what it's worth, arranging the 020s so that the ISBN-13 comes first, followed by the ISBN-10, is actually supposed to be the standard behavior. For example, see: http://www.loc.gov/catdir/cpso/020-13%20plan.pdf http://www.ingrambook.com/isbn13/libraries/default.asp#4 Consequently, requesting that your materials providers provide 020 fields in the opposite order, while that all *that* non-standard, is nonetheless bucking the trend. Furthermore, for any records that you manually import, reversing the 020s just seems like a workflow step that is better avoided. I recommend an alternative approach, namely consider using the OpenLibrary added content provider rather than the Amazon one, as it appears that it readily recognizes both the 10- and 13- digit forms of the ISBN. It wasn't an option for us to use OpenLibrary for content as they do not offer DVD covers...and they are very important to the public libraries in our consortium. It is still my understanding that covers can only be retrieved from one provider. So we're in a situation where we have to go with the reversed order. I would be very interested to hear if there have been any further development regarding this issue. Thanks! Gordana Ben Shum bs...@biblio.org 10/6/2011 1:56 PM Hi Brian, As far as I know, the first ISBN entry of a record will always be used to retrieve added content images. I'm not familiar with any workarounds other than editing the records to order the information in them accordingly, but maybe someone is working on this? Otherwise, I think that'd be a useful feature to have in the future. -- Ben On 10/6/2011 1:17 PM, Brian Greene wrote: In many cases covers won't display in our OPAC if the 13-digit ISBN is above the 10-digit ISBN in the bib record. If I switch the order of the ISBNs so that the 10-digit one is first then the cover displays. This is the case most of the time, although I have come across instances where the 13-digit ISBN displays the cover properly. Does anyone know of a fix for this? Is there a setting we can change to use a second ISBN if the first one doesn't retrieve a cover? We're running 2.1. Thanks, Brian Greene, Library Director Columbia Gorge Community College The Dalles, Oregon 97058 (541) 506-6080 | www.cgcc.cc.or.us ( http://www.cgcc.cc.or.us/ ) -- Benjamin Shum Open Source Software Coordinator Bibliomation, Inc. 32 Crest Road Middlebury, CT 06762 203-577-4070, ext. 113
Re: [OPEN-ILS-GENERAL] Covers and ISBNs
On Thu, Oct 06, 2011 at 04:14:16PM -0400, Gordana Vitez wrote: Hi Brian, We came across the same problem back in the summer and I think the only thing to do is ask the materials provider to switch the order. I did get a good explanation from Galen and I'll include it here: For what it's worth, arranging the 020s so that the ISBN-13 comes first, followed by the ISBN-10, is actually supposed to be the standard behavior. For example, see: http://www.loc.gov/catdir/cpso/020-13%20plan.pdf http://www.ingrambook.com/isbn13/libraries/default.asp#4 For what it's worth, at least in the context of BibTemplate, it wouldn't be too hard to teach the code to iterate through all of the possible ISBNs and find the 10-digit ones. The issue is that rdetail.js is using the record.isbn() value, which comes from the old slim MODS representation of the bibliographic data. Ripping out the pertinent code from rdetail.js and dropping it into the rdetail_summary.xml / result_table.xml display would be how I would go about doing such a thing if I were to do such a thing as quickly as possible with minimal disruption. We're already doing part of that at Conifer, just to show all of the ISBNs for a given record: see http://ur1.ca/5bjbu for example; extending that to say okay, just give me the 10-digit ISBN wouldn't be much more work. Of course, a better way to handle this might be to push the logic down into the added content layer, such that each added content provider would be responsible for pulling out the preferred ISBN - or ISSN, or UPC, or other identifiers of interest beyond the currently limited ISBN-only approach - and sending that to the added content service. Jeff Godin had started towards this approach at the Evergreen hackfest in 2011, it would be great to move along that path further.
