Summary: | Prioritize cover image sources such as Amazon, Google and add fail over i.e. if first source fails, go to next | ||
---|---|---|---|
Product: | Koha | Reporter: | Koustubha Kale <kmkale> |
Component: | OPAC | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P4 | CC: | arm, bibliwho, brendan, cbrannon, chris, dcook, dubyk, egpetridis, f.demians, fridolin.somers, george, gveranis, iming, indradg, jens.weber, luce.barbey, magnus, marjorie.barry-vila, nick, patrick.robitaille, poonambanyal, robin, s.hierl, ssammons, tmisilo, tomascohen, veron, viktor.sarge |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2131 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9991 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11982 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9580 |
||
Change sponsored?: | Seeking cosponsors | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Koustubha Kale
2011-11-06 09:18:49 UTC
I found bug 2131 with a very old patch attached that sounds like a duplicate to this. I am linking both together for someone interested to work on this. *** Bug 7574 has been marked as a duplicate of this bug. *** *** Bug 7657 has been marked as a duplicate of this bug. *** I propose the addition of two new sysprefs for this task: a) Choose a default cover location (Local, Google, Amazon, etc) (combo with fixed values) b) Choose whether to traverse the list of services looking for the cover (starting from the default) or 'just use the default' (YesNo syspref. (In reply to comment #4) > I propose the addition of two new sysprefs for this task: > > a) Choose a default cover location (Local, Google, Amazon, etc) (combo with > fixed values) > b) Choose whether to traverse the list of services looking for the cover > (starting from the default) or 'just use the default' (YesNo syspref. Perhaps this way AmazonLocale (Use Amazon data from its [American|British|Canadian|French|German|Japanese] website) will no longer be necessary. The fixed values combo would contain all Amazon locales, so that should a book not be found in the Amazon US site, koha would look it up in the other Amazon sites as well. One thing we need to decide on is whether the logic that checks multiple sources should be in JavaScript on the client side or Perl on the server side. I'm leaning towards Perl on the server, for two reasons: 1. Displaying an image could be as simple as this: <img src="opac-ver.pl?biblionumber=x" /> 2. We could cache the results of looking through multiple sources. (Caching might violate the terms of service for e.g. Amazon, but then we could check them last, after we have checked the ones that we can cache.) I tend to think that in Perl is a better solution too, however it's worth noting that it'll make firewalling harder. As for the caching, I think if you cached "what was the first service that gave me a meaningful result", that wouldn't violate anything, and is also the best way to do that (short of caching the image, which really is forbidden.) I think some sources allow it (but not Amazon) and we can store covers locally now, so those should be checked first of all. Another plus on doing it server side would be better privacy. A cover source I'd like to add (NZ Nat Lib) also doesn't allow caching of images, so relying on "only the last one doesn't allow caching" is not ideal. Caching images from those that do allow it is worthwhile however. I think maybe the sequence should be user configurable? With an option to use the first that answered? (In reply to comment #10) > I think maybe the sequence should be user configurable? With an option to > use the first that answered? That's what I'm thinking too. I'd consider that a separate enhancement. If we try to cram too much stuff in for the first go, it'll never get done. Also, I don't think our syspref system allows that kind of configuration. (In reply to comment #12) > I'd consider that a separate enhancement. If we try to cram too much stuff > in for the first go, it'll never get done. Also, I don't think our syspref > system allows that kind of configuration. I am working on a similar configuration issue on bug 8726. Once that patch is up, perhaps you can adapt^Hborrow^Hshamelessly steal the code for that. Being able to drag things around to order them is pretty cool, and once I figured out how to do it, not hard at all. Hi to all, as I know Open Library, Library Thing and Google allow to cache book'covers. I try to find Amazon license for book covers but I don't find it. As I see in Vufind (an opac written with PHP) they cache also covers from Amazon. They use Amazon strictly only for covers. (In reply to comment #6) > One thing we need to decide on is whether the logic that checks multiple > sources should be in JavaScript on the client side or Perl on the server > side. I'm leaning towards Perl on the server, for two reasons: > > 1. Displaying an image could be as simple as this: > > <img src="opac-ver.pl?biblionumber=x" /> > > 2. We could cache the results of looking through multiple sources. (Caching > might violate the terms of service for e.g. Amazon, but then we could check > them last, after we have checked the ones that we can cache.) Just a comment from an end-user: Could it be that Amazon returns an image, even when no cover image is available in its systems? I'm referring to the "No image available" with a hint of a smile/bent arrow below image. Unless Amazon does provide for an indication that the image it provides is a placeholder for the cover image it does not [yet] have, caching might prove tricky, for it could hinder future [successful] look-ups in Amazon. Furthermore, should Amazon be at the top of the list, successfuly fetching a placeholder image from Amazon would prevent koha from retrieving a correct cover image from some other source down the list. Good points, Manos! Yeah, I am trying to figure out a way to check if the image returned is a placeholder or not, that is kind of crucial. And caching should not last forever. I've updated the RFC page with my plans for getting something done. This won't be the full solution, but I think a good-enough starting point that can be built on. It's also possible I'll have some sponsorship for this. (In reply to comment #6) > One thing we need to decide on is whether the logic that checks multiple > sources should be in JavaScript on the client side or Perl on the server > side. I'm leaning towards Perl on the server, for two reasons: > > 1. Displaying an image could be as simple as this: > > <img src="opac-ver.pl?biblionumber=x" /> > > 2. We could cache the results of looking through multiple sources. (Caching > might violate the terms of service for e.g. Amazon, but then we could check > them last, after we have checked the ones that we can cache.) I know it is quite late, but it just came to me that using server-side code might simplify using/intergrating local images with the ones provided by external sources, and allow for displaying the same images at the OPAC and the administrative calatogs. While not explicitly discussed, this is covered in my plan. There will be a set of "plugins" to handle each image source, and this'll include local ones. I've sent the details to the library, I'm just waiting for them to get back to me about whether they'll be keen to go for it. An additional thought -- I believe that at present an ISBN is required to retrieve cover images. Many movies in particular, however, lack ISBNs. In Amazon at least, many searches for the UPC will retrieve the correct item. EG UPC 043396275140 retrieves: http://www.amazon.com/District-9-Single-Disc-Sharlto-Copley/dp/B002SJIO4A/ So perhaps the 024 tag could be added as a potential source for cover images? Note that in the example above Amazon provides yet another identifier, namely, the ASIN (B002SJI04A). The ASIN is always present & could be added to the 024 by staff so that in theory users would have to only rarely, if ever, upload local cover images. That said, I have no idea how the various APIs work. Hopefully they're compatible with the above approach. (In reply to comment #21) > In Amazon at least, many searches for the UPC will retrieve the correct > item. EG UPC 043396275140 retrieves: > http://www.amazon.com/District-9-Single-Disc-Sharlto-Copley/dp/B002SJIO4A/ The question is not whether you can retrieve a record on Amazon with a UPC, but whether the Amazon cover image service works with UPC. It does not. If it did, you could replace the ISBN in a link like this: http://images.amazon.com/images/P/0596001320.01.MZZZZZZZ.jpg ...with a UPC. But this doesn't work: http://images.amazon.com/images/P/043396275140.01.MZZZZZZZ.jpg (In reply to comment #22) > The question is not whether you can retrieve a record on Amazon with a UPC, > but whether the Amazon cover image service works with UPC. It does not. Hmmm... No doubt you're correct, Owen. Amazon's Product Advertising API seems to allow the use of a number of different identifiers, including ASINs: http://docs.amazonwebservices.com/AWSECommerceService/latest/DG/ItemLookup.html Presumably Koha is using a different service. Note that the LibGuides folks have added a separate option for users to specify a URL source for cover art for each record ... http://guidefaq.com/a.php?qid=2200 (In reply to Cab Vinton from comment #23) As VuFind has been mentioned above, I thought I'd confirm that VuFind separates its book covers functionality from the book previews API -- and that it can search the various sources (Google Books, Amazon, Open Library, and Hathi Trust) by ISBNS, LCCNs, and OCLC numbers: https://github.com/vufind-org/vufind/blob/master/themes/bootstrap/js/preview.js Thus, not only the most recent publications that have ISBNs are retrieved/linked to in the OPAC, but also those that have OCLC and LCCN #s, thus numerous titles that are available in full text--which is the point of such a feature, i.e. to link to the full text for immediate access. > (In reply to comment #22) > > The question is not whether you can retrieve a record on Amazon with a UPC, > > but whether the Amazon cover image service works with UPC. It does not. > > Hmmm... No doubt you're correct, Owen. Amazon's Product Advertising API > seems to allow the use of a number of different identifiers, including ASINs: > > http://docs.amazonwebservices.com/AWSECommerceService/latest/DG/ItemLookup. > html > > Presumably Koha is using a different service. > > Note that the LibGuides folks have added a separate option for users to > specify a URL source for cover art for each record ... > > http://guidefaq.com/a.php?qid=2200 *** Bug 11177 has been marked as a duplicate of this bug. *** (In reply to Robin Sheat from comment #20) > While not explicitly discussed, this is covered in my plan. There will be a > set of "plugins" to handle each image source, and this'll include local ones. > > I've sent the details to the library, I'm just waiting for them to get back > to me about whether they'll be keen to go for it. Robin, did you ever hear back about this? (In reply to David Cook from comment #26) > Robin, did you ever hear back about this? Alas no. Here is a proposal to raise funds for this development: http://lists.katipo.co.nz/pipermail/koha/2014-May/039491.html I chose to participate in the fundraiser and can report that work is being done on this. *** Bug 2131 has been marked as a duplicate of this bug. *** Work in progress is here http://git.catalyst.net.nz/gw?p=koha.git;a=shortlog;h=refs/heads/wr222309 It is almost ready to be submitted as a patch set What's the news about this patch ? Thanks This is being tested by clients, you can (as always) see the work on the catalyst repo. Has this been submitted on another bug? I just looked at the git repo and haven't seen an update in awhile. Thanks, Brendan (In reply to Chris Cormack from comment #33) > This is being tested by clients, you can (as always) see the work on the > catalyst repo. (In reply to Brendan Gallagher from comment #34) > Has this been submitted on another bug? I just looked at the git repo and > haven't seen an update in awhile. As far as I know they are not happy with performance yet and will rework this patch before anything interesting starts happening. I do hope that it will get done in time for the may release since it's a feature I'd love to see, but I don't think anything is happening right now. Bug 9580 feature is an alternative option which is functional. We are actually evaluating 9580 at the moment to see if it will meet all the requirements of this bug. Will let you know shortly Hi Chris, any update on this maybe? Looking forward to this feature. :) Would love to see more consistent covers throughout Koha. (In reply to Chris Cormack from comment #37) > We are actually evaluating 9580 at the moment to see if it will meet all the > requirements of this bug. Will let you know shortly Any results from the evaluation yet? ;-) We are really interested in this as well - centralizing the code would make it easier to add new content providers. Yes, bug 9850 meets all the requirements of this. We have it in production for our sites. So we will not be doing any more work on this. Our recommendation is to use coce for book covers (In reply to Chris Cormack from comment #42) > Yes, bug 9850 meets all the requirements of this. We have it in production > for our sites. So we will not be doing any more work on this. > > Our recommendation is to use coce for book covers Bug 9850 is about Koha 3.12 help files. Was that a typo, Chris? Ah, bug 9580 I'm guessing. I really need to look into Coce... (In reply to David Cook from comment #44) > Ah, bug 9580 I'm guessing. > > I really need to look into Coce... ByWater has a coce server that anyone is welcome to use (the more users the more images ready for use) https://coce.bywatersolutions.com Hanover has started using Bywater's Coce server. :-) It did not work for us at first but is working this week. It certainly does provide a wider range of jacket images than Amazon, especially for older titles and non-book media. Considerations: 1) The first ever call for a particular jacket prompts the Coce server to search for it, but it is not returned to the Koha search until the page is refreshed or search done again or details page opened. That is easy for staff to work with but not so good on the OPAC where so many entries load with no images until Coce has retrieved them at least once. 2) Coce is only set up to work for OPAC, not staff interface. If we had the choice, two options the same as for Amazon jackets, to turn it on for either or both would be nice. Then staff could judge when Coce returns enough images to turn on for our users. We have decided to run with both Amazon and Coce for now, so that in time the image links we need will be generated. Two jacket images looks untidy but until the server has most of the links, two jackets sometimes is better than no jacket frequently. The more libraries use the server, the sooner it will be able to provide a comprehensive resource for jacket images. Thank you to everyone who worked on this and Bywater for providing the server service. This is still needed to prioritize local cover image over remote cover image (Coce Amazone, ...) Hi, Does anyone work on this? The possibility to prioritize cover image sources would be a usefull add for Koha. Thanks, Patrick. > Does anyone work on this?
I think the introduction of Coce has solved this problem well enough that there isn't much demand for more work. However, I agree with Frodolin that it would be good to make Coce and local cover images work better together.
I'm resetting the "ASSIGNED" status of this because I think it's not actively being worked on by anyone.
I'm interested in the outcome but don't have the time to work on this :( Someone who solved by js https://catalog.sll.texas.gov/opac-tmpl/bootstrap/js/localcovers_18.0510000.js sorry mistake, wrong reply (In reply to George Veranis from comment #51) > Someone who solved by js > > https://catalog.sll.texas.gov/opac-tmpl/bootstrap/js/localcovers_18.0510000. > js I've accidentaly reset the component this bug report was set to. Bugzilla brought up the next bug in list upon saving changes to a bug I had just opened and I thought that I had mis-selected on first try. My bad. *** This bug has been marked as a duplicate of bug 28180 *** |