Some questions - and a suggestion - on treatment of ISBN in koha
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 978-0-553-50706-5 0-553-50706-0 0553507060 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). Questions: 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 their Z39.50 results, or is it simply a convention used to display in one line values kept as discrete entries in the originating system? Suggestion: 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
Hello 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 digits isbn. 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 https://www.oclc.org/bibformats/en/0xx/020.html 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. M. Saby 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
978-0-553-50706-5
0-553-50706-0
0553507060
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).
Questions:
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 their Z39.50 results, or is it simply a convention used to display in one line values kept as discrete entries in the originating system?
Suggestion:
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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
When we convert our files for upload into Koha we remove all the spaces and hyphens. When staff members edit new records in Koha, they're supposed to delete hypens and spaces. This seems like a lot of extra work. I'd say only 20 per cent of our collection has ISBNs, so we don't rely on them that much for searching. But I find a similar problems to what M. Saby describes when searching for titles in Copac or other cooperative catalogues. What should be an aid (a standard number) is often an impediment, due to the inconsistency in cataloguing methods. Perhaps some bright programmer can come up with a solution to search all the variables, without bringing back too many false positives. On Sun, Apr 28, 2013 at 1:13 PM, Mathieu Saby <mathieu.saby@univ-rennes2.fr>wrote:
Hello 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 digits isbn.
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 https://www.oclc.org/**bibformats/en/0xx/020.html<https://www.oclc.org/bibformats/en/0xx/020.html>
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.
M. Saby
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/addb**ooks.pl <http://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
978-0-553-50706-5
0-553-50706-0
0553507060
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).
Questions:
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 their Z39.50 results, or is it simply a convention used to display in one line values kept as discrete entries in the originating system?
Suggestion:
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@lists.katipo.co.nz http://lists.katipo.co.nz/**mailman/listinfo/koha<http://lists.katipo.co.nz/mailman/listinfo/koha>
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
______________________________**_________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/**mailman/listinfo/koha<http://lists.katipo.co.nz/mailman/listinfo/koha>
-- Elaine Bradtke Data Wrangler VWML English Folk Dance and Song Society | http://www.efdss.org Cecil Sharp House, 2 Regent's Park Road, London NW1 7AY Tel +44 (0) 20 7485 2206 (This number is for the English Folk Dance and Song Society in London, England. If you wish to phone me personally, send an e-mail first. I work off site) -------------------------------------------------------------------------- Registered Company No. 297142 Charity Registered in England and Wales No. 305999 --------------------------------------------------------------------------- "Writing about music is like dancing about architecture" --Elvis Costello (Musician magazine No. 60 (October 1983), p. 52)
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 server/target. Manos PETRIDIS -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Mathieu Saby Sent: Sunday, April 28, 2013 3:14 PM To: koha@lists.katipo.co.nz Subject: Re: [Koha] Some questions - and a suggestion - on treatment of ISBN in koha Hello 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 digits isbn. 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 https://www.oclc.org/bibformats/en/0xx/020.html 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. M. Saby 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
978-0-553-50706-5
0-553-50706-0
0553507060
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).
Questions:
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 their Z39.50 results, or is it simply a convention used to display in one line values kept as discrete entries in the originating system?
Suggestion:
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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
participants (3)
-
Elaine Bradtke -
Manos PETRIDIS -
Mathieu Saby