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-boun...@lists.koha-community.org> On Behalf Of
Nigel Titley
Sent: Friday, 21 July 2023 11:06 PM
To: Jonathan Druart <jonathan.dru...@bugs.koha-community.org>
Cc: k...@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 <ni...@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 <ni...@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
k...@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list http://koha-community.org
k...@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 k...@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list http://koha-community.org k...@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/
_______________________________________________
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/
