David Sorry I only just got back to this. Your thinking seems to accord with my own. See comments below On 24/07/2023 01:11, David Cook wrote:

Hi Nigel,

While it's been a while since I worked in a library myself, I've got the librarian degree, I've been working in the library world for nearly 20 years, and I've been working on Koha for over 10 years. In cases like this, the answer is often "it depends".

I would be tempted to put the OpenLibrary ID into the 024$a but as you've noted there isn't an easy standard way to indicate that it's an OpenLibrary ID, which is quite important for a case like this. That certainly makes things tricky.

You could send a request for an "openlibrary" code to be added to the official Standard Identifier Source Codes list: https://www.loc.gov/standards/sourcelist/index.html#maintenance . Honestly, I'm a little surprised there isn't already an entry for it there. I'm sure they'd approve a request for it.

I think this might be the proper way forward and I'll kick off a request

Now here's where "it depends" comes in the most. Are you going to exchange your MARC records with other systems or just use them locally? If it's just locally, you could cheat and use a 024$2 of "openlibrary". Of course, you'd still need to write code to look for a 024$a with a 024$2 of "openlibrary". It would be fine if you kept that code local to your Koha, but the Koha community might not accept it upstream.

Having worked for many, many years in the opensource community I'd be very wary of taking this route. Local code changes that aren't folded back into the mainstream always end up going down the rat hole of non-maintainability.

Another option could be to use a 024$2 of "uri" and store the whole OpenLibrary URI like https://openlibrary.org/books/OL49198571M/Analogue_Men. The code could look for URIs with a hostname of "openlibrary.org" and then extract the ID from the URI. There's a growing usage of URIs for identifiers in the MARC world (long story why). You often see these as $0 subfields: https://www.loc.gov/marc/bibliographic/ecbdcntf.html. This would fit within the rules for MARC, but the downside is it would require you to write new code. It's also still arguably unconventional.

This is a possibility and it's certainly a route I could go. Writing code isn't out of the question. I've got a Javascript manual glaring at me as I write.

As Jonathan pointed out, Koha only uses the ISBN to get OpenLibrary covers, although it looks like the OpenLibrary API has some options available for things like the OpenLibrary ID. Extending that API usage by Koha would probably involve Javascript, Template Toolkit changes, and maybe Perl changes. Keeping custom code local can be a bit of a headache in the long-run though, as then you can't rely on the regular releases from the Koha community without doing a fair bit of extra work.

Agreed

If you're running Koha 23.05+, you could look at writing a Koha plugin, which uses the new "opac_cover_images" hook[1]. This would involve some short-term work, but it would let you implement what you need.

Unfortunately I'm stuck with 22.05.13.000 for the moment as the server is shared with a sympa server which has a clash of libraries with koha. I'm getting to the end of my tether with sympa, however, and I may migrate back to mailman.

Going back to "it depends", in the library world we like to follow standards... until they don't work for us. Then we have local policies. Every library has their own way of doing things. (Another thing to notice with MARC is that when you encounter the number "9", it typically stands for a local field/subfield. Koha uses some of these fields/subfields for its own local purposes, and you can always do the same. The limit is just that "9" only makes sense for your library. You could always use a 024$9 of "openlibrary" along with a Koha plugin to achieve your goal. It wouldn't be following the library standards 100% but it's the kind of thing that does get done in the library world. Does that make sense?

I really like to stay with standards if possible. I'll go the route of requesting Openlibrary be added to the SISC list and if that gets turned down I'll reconsider options. Many thanks for your help Nigel

[1] https://wiki.koha-community.org/wiki/Koha_Plugin_Hooks https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32680

David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia

Office: 02 9212 0899 Online: 02 8005 0595

-----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Nigel Titley Sent: Friday, 21 July 2023 11:06 PM To: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Cc: koha@lists.katipo.co.nz; koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] [Koha] Where would I put the OpenLibrary ID in the MARC record

Understood.

I'm sure that a Real Librarian (tm) will answer at some point.

Thanks anyway

Nigel

On 21/07/2023 13:20, Jonathan Druart wrote:

...

No idea, I'm really just a programmer ;)

Le ven. 21 juil. 2023 à 14:06, Nigel Titley <nigel@titley.com> a écrit :

...

Thanks for the response... makes sense to use the ISBN and it explains the observed behaviour.

I've had a look at the code. One of these days I'll blow the dust off my JS manuals and see if I can do something to extend the code (JS isn't my favourite language and I've probably not written any for about 15 years).

Is my supposition about where it would go in the MARC record correct?

Thanks

Nigel

On 21/07/2023 12:29, Jonathan Druart wrote:

...

Looks like it's only using the ISBN. The code is in koha-tmpl/opac-tmpl/bootstrap/js/openlibrary.js

https://gitlab.com/koha-community/Koha/-/blob/master/koha-tmpl/opac- tmpl/bootstrap/js/openlibrary.js#L19

and opac-results: 899 [% IF OpenLibraryCovers %]KOHA.OpenLibrary.GetCoverFromIsbn();[% END %]

Le ven. 21 juil. 2023 à 13:03, Nigel Titley <nigel@titley.com> a écrit :

...

Furthur on this and reading a bit more into MARC it looks like the information would go into MARC Field 024 with a source of 8. If there was a defined Standard Identifier for Openlibrary then the source would be 7 with the defined Standard Identifier for Openlibrary, but there isn't.

I'm straying into Real Librarian Territory here and I'm starting to feel a little lost (I'm really just a programmer). If the person who wrote the code for fetching covers from Openlibrary is around I'd be grateful if they could confirm/deny what their code does (or even point me to where I could look it up myself). To this end I've copied in the Koha Development community.

Or I may be barking up an entirely wrong tree. In which case feel free to say "Down boy, down".

Nigel

On 20/07/2023 23:20, Nigel Titley wrote:

...

Just to give an example of an OpenLibrary record that I created earlier today

https://openlibrary.org/books/OL49198571M/Analogue_Men#details

If at all possible I'd like to be able to display the cover using the OLID (OL49198571M) but I'm not sure where to put it.

Thanks

Nigel

On 20/07/2023 22:43, Nigel Titley wrote: > Gentlefolk > > I'm using the Openlibrary cover facility to display covers in my > OPAC and it generally works very well (in the case where the > cover doesn't exist in Openlibrary I scan and upload it). > However, if the Biblio record doesn't have an ISBN or LCCN the > cover lookup fails (obviously). Is there any way of recording the > Openlibrary ID (OLID) in a Biblio record so that the cover lookup > will work, even if there is no ISBN or LCCN? > > I've done a (fairly cursory) scan of the documentation but can't > find and reference to where I should put the OLID so that Koha > will look up the cover even if there is no ISBN or LCCN. Of > course the facility may not exist, in which case I'd be grateful > for confirmation from Someone Who Knows. > > Many thanks > > Nigel Titley > > _______________________________________________ > > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________

Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

---

Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-deve l website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/

_______________________________________________

Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

_______________________________________________

Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

---

Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/