[Koha] Some questions - and a suggestion - on treatment of ISBN in koha
egpetridis at yahoo.com
Tue May 7 02:48:23 NZST 2013
I agree that a way to work around the Z39.50 search issue would be to search
for both 10-chatacter and 13-character ISBNs. Depending on how the various
Z39.50 targets work when servicing such searches, koha may well have to
search using both hyphened and plain forms as well. That would quadruple the
request traffic, and could also mean that multiple results would be brought
back from the same target/source, either because the sw used there were
"smart" enough in their searches, or because the biblios there contained
more than one form of the ISBN used. The first issue, could be a problem
with targets that only accept/service a limited number of requests per
client per day. Therefore, a column could be added in z3050servers table,
instructing koha not to perform elaborate searches, i.e. not to try multiple
versions of the same ISNB when querying the specific server.
M. SABY mentions that auto-populating each entry with all four ISBN variants
would be against their cataloguing rules. That is exactly why I proposed
"two new options/preferences, one that would enable such behaviour
[auto-populating] and one that would instruct koha to use one 020a entry to
keep all four forms, or four discrete entries."
I believe that keeping all four entries (either automatically entered or by
hand) could make koha more friendly when servicing searches, either locally
(note the scenario I described in my original message) and as a Z39.50
From: koha-bounces at lists.katipo.co.nz
[mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Mathieu Saby
Sent: Sunday, April 28, 2013 3:14 PM
To: koha at lists.katipo.co.nz
Subject: Re: [Koha] Some questions - and a suggestion - on treatment of ISBN
improving the management of ISBN would be a nice enhancement.
This could improve search, and detection of duplicates.
I have never used Z3950 search, but if it is always translating 13 digits
isbn into 10 digits, it is probably not a good. It should search both forms.
Or search 3 forms in some cases : remember 13 digits isbn are not only made
with 978 prefix, but also 979. So, from a 10 digits isbn you can made two 13
For the way you must store isbn in the record :
In France, with UNIMARC and french cataloguing standard, we work like this :
010 $aISBN10 (WITH the hyphens)
and we add an other 010, ONLY if the two are printed on the book, or if the
book were printed with isbn10 and reprinted some years later with isbn13.
010 $aISBN13 (WITH the hyphens)
With AACR2 and Marc21, OCLC is also repeating the 020
But rather than populating automaticly the record with alternates versions
of ISBN - that would be against our cataloguing rules - I would prefer a
change in Search.pm, so that when a search is made on isbn index, Koha would
search alternates versions of the isbn.
For an isbn10 : search isbn10 OR 978-isbn10 (with correction of control
element) OR 979-isbn10 (with correction of control element) For an isbn13 :
search isbn13 OR isbn 10 This could be done for isbn index, but also for any
index if the string searched by a user is an isbn.
Le 28/04/2013 10:28, Manos PETRIDIS a écrit :
> Please consider the following scenario:
> I have a book in my hands that bears ISBN-13 9780553507065, and wish
> to make a biblio entry in koha. I go to Home > Cataloging and perform
> a "Cataloging search" i.e. "Search the catalog and the reservoir" with
> the ISBN on the book. Failing to find it, I then perform a Z39.50
> search, select a fitting entry and try to import it in my koha, only
> to find that the book already exists there. Odd...
> Correct me if I'm wrong, but koha staff client cataloging search at
> /cgi-bin/koha/cataloguing/addbooks.pl seems to look for specific
> strings of characters.
> Therefore, when one enters an ISBN number of 9780006483113 as a search
> string for example, koha fails to find entries bearing ISBN numbers of
> i.e. the alternate forms of the same ISMB number.
> I also remember reading here in the list, that when performing Z39.50
> searches koha first "translates" the ISBN-13 user input to ISBN-10
> before querying Z39.50 targets.
> Thus, should one select a Z39.50 result with ISBN-10 and fail to "correct"
> it before saving the new entry, is prone to the problem described above.
> Furthermore, should that be the case, if one chooses to use the
> ISBN-13 form only when editing his own entries, they would fail to
> appear on other people's searches on his own koha installation, if
> their own system was koha too (or preformed along similar lines).
> If one wishes to enter all four alternate forms of the same ISBN, is
> it better to use multiple 020a entries (in USMARC) or to use multiple
> occurrences within the same 020a entry?
> Do other libraries/systems use the notion "A | B | C | D" I see in
> Z39.50 results, or is it simply a convention used to display in one
> line values kept as discrete entries in the originating system?
> I guess there is some valid reasoning behind the behaviour described
> above, resolved when these koha modules were created, I wonder however
> if it would be useful that koha would automatically populate the
> bibliographical entries with the missing alternate 020a entries (in
> USMARC), either at the time of user input, or by some batch procedure,
> that would also take care of existing entries. This could well be
> controlled by two new options/preferences, one that would enable such
> behaviour and one that would instruct koha to use one 020a entry to
> keep all four forms, or four discrete entries.
> kind regards,
> Manos PETRIDIS
> Athens, Greece
> Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz
Service d'Informatique Documentaire
Service Commun de Documentation
Université Rennes 2
Téléphone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr
Koha mailing list http://koha-community.org
Koha at lists.katipo.co.nz
More information about the Koha