Use cover image/blurb URL from field 856

[Pasi Kallinen]

Wishlist item:

MARC 21 uses field 856 for electronic "links", where you can have URLs for example covers images and/or blurbs.

Most of the libraries in Finland get the cover image and blurb data URLs via http://btj.fi/ and the fields (after conversion from our old system to EG) look like this:

856 4 2. ‡uhttp://www.btj.com/btjcgi/arvo/get_add_info.cgi?type=IMAGE&key=5116919745956040
856 4 2. ‡uhttp://www.btj.com/btjcgi/arvo/get_add_info.cgi?type=PRES&key=5116919745956040 ‡qTEXT ‡zKuvaus

The URL "key" parameter has nothing to do with ISBN or anything else in the MARC.

It should be possible to configure EG so that 856‡u that matches a (configurable) regexp, or if 856‡z matches some text, or if 856‡q is "IMAGE", the URL is used as the cover image.
Or grabbing the blurb from the url, if some other rules are matched.

From the discussion on IRC:
< jeff> paxed: there are two major approaches that come to mind: 1) seek the url in the template tookit bits and populate/use it if found. you will encounter mixed content warnings/errors when logged in unless you proxy the image or it is served by an https url. 2) write an added content handler that extracts the url from the marc. you will need the added content by record id branch as a starter.
[18:41] < jeff> paxed: as i mentioned, i'm interested in this and would probably work on option 2 myself. it has applicability for other bib sources, and benefits from some caching which would skip the need to parse the bib on every cover image display.

[Pasi Kallinen (paxed)]

I wonder if this could tie into bug 1065378

[Pasi Kallinen (paxed)]

I've got branch at user/paxed/ac-image-url-in-marc - it adds a new Added Content handler ImageURLinMARC. Configuration in opensrf.xml allows defining which MARC field it looks for, and a regex the value of the field must match.

[Galen Charlton (gmc)]

I think the general idea is a good one and worth reviving. Rather than relying on fetching and parsing MARC though, I think it might be faster to fetch asset.uri rows related to the record and check patterns against asset.uri.label and asset.uri.use_restriction.

As a side note, looks like records from iVerse Media include cover images.

856 40 ‡zCover Image ‡uhttps://s3.amazonaws.com/iverse_public/store/cover/padmedium/13A2B12F79C.png

[Terran McCanna (tmccanna)]

Removing pullrequest for the time being since the proposed patch is now 7 years old and there has been an alternate approach suggested. At the very least, it would need to be rebased against current master before testing.

[Jeff Godin (jgodin)]

Chiming in in 2024 to note some renewed interest in this kind of thing, and some quick thoughts: There are a few different ways that an external image URL is included in a MARC tag from certain sources. A new approach for this should allow for some flexibility / configurability, and should probably not be an all-or-nothing Added Content module, since it's likely many libraries would be mixing records that have these URLs (possibly in multiple places for different records) with records that do not have embedded cover image URLs, and need to fetch from a more typical source / Added Content handler.

[Jeff Godin (jgodin)]

Also worth noting that some vendors may use images that have very different aspect ratios from what we get from typical added content providers, such as the 480x270 (16:9) example referenced in related bug 2047962.

[Galen Charlton (gmc)]

> and should probably not be an all-or-nothing Added Content module

Agreed, although I think this is an opportunity to consider teaching added content modules how to operate in fallback chains, at least for cover images.