Bug 11586

Summary: Better default framework for UNIMARC
Product: Koha Reporter: Gaetan Boisson <gaetan.boisson>
Component: Installation and upgrade (web-based installer)Assignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: dcook, gmcharlt, jonathan.druart, mathsabypro, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12477
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 11021, 11030    
Bug Blocks: 16797    
Attachments: Bug 10586: Better default framework for UNIMARC - framework
Bug 11586: Better default framework for UNIMARC - framework
Bug 11586: Better default framework for UNIMARC - authority
Bug 11586: Better default framework for UNIMARC - AV
Bug 11586: Better default framework for UNIMARC - zebra conf
Bug 11586: Better default framework for UNIMARC - framework
Bug 11586: Better default framework for UNIMARC - authority
Bug 11586: Better default framework for UNIMARC - AV
Bug 11586: Better default framework for UNIMARC - zebra conf
Bug 11586 follow-up
Bug 11586 follow-up, FA framework update
[PASSED QA] Bug 11586: Better default framework for UNIMARC - framework
[PASSED QA] Bug 11586: Better default framework for UNIMARC - authority
[PASSED QA] Bug 11586: Better default framework for UNIMARC - AV
[PASSED QA] Bug 11586: Better default framework for UNIMARC - zebra conf
[PASSED QA] Bug 11586 follow-up
[PASSED QA] Bug 11586 follow-up, FA framework update

Description Gaetan Boisson 2014-01-20 18:16:06 UTC
On a clean (french) UNIMARC install, a large number of subfields are not configured for items, or not properly linked. It can mean several features are not available by default, and the user has to do some extra configuration to get them working. I am not sure yet if the chosen language has an influence on this set-up.

The linked subfields are :

995$9	items.itemnumber 
995$b	items.homebranch 
995$c	items.holdingbranch 
995$e	items.location 
995$f	items.barcode 
995$j	items.stocknumber
995$k	items.itemcallnumber 
995$n	items.onloan 
995$o	items.notforloan 
995$r	items.itype 
995$u	items.itemnotes 

Here is a suggestion to make this more complete :

995$1	items.cn_source 
995$4	items.damaged (linked to the appropriate AV list)
995$8	items.coded_location_qualifier 
995$a	items.booksellerid 
995$d	items.datelastseen 
995$g	items.replacementprice 
995$i	items.replacementpricedate 
995$p	items.price 
995$s	items.cn_sort (with the appropriate zebra configuration done)
995$t	items.stack 
995$w	items.issues 
995$x	items.renewals 
995$y	items.reserves 
995$z	items.nonpublicnote 
995$0	items.withdrawn (linked to the appropriate AV list)
995$2	items.itemlost (linked to the appropriate AV list)
995$3	items.restricted 
995$5	items.dateaccessioned (linked to the appropriate plugin)
995$6	items.copynumber 
995$7	items.uri 
995$h	items.ccode (linked to the appropriate AV list)
995$l	items.materials 
995$m	items.datelastborrowed 
995$v	items.enumchron
Comment 1 Gaetan Boisson 2014-01-21 12:44:00 UTC
I might have tried too hard to link every single field in the database. The idea is that we might as well link everything, and rename the field if we need to recycle it. Since this means adding a number of fields that are not necessary to most users, or which don't even make sense in unimarc, i suggest hiding them by default. The configuration will exist and recycling the fields will be easy.

Here's a corrected suggestion :

995$1	items.cn_source (linked to the appropriate AV list - which is technically not an AV list but you can chose it in the dropdown when configuring the subfield)
995$4	items.damaged (linked to the appropriate AV list)
995$8	items.coded_location_qualifier (should be hidden, doesn't exist in unimarc)
995$a	items.booksellerid 
995$d	items.datelastseen (should be hidden in the editor, since the user shouldn't be able to change this himself)
995$g	items.replacementprice 
995$i	items.replacementpricedate 
995$p	items.price
995$s	items.cn_sort (with the appropriate zebra configuration done. This field should be completely hidden as it is only functionnal)
995$t	items.stack (should be hidden, doesn't exist in unimarc)
995$w	items.issues (should be hidden in the editor, since the user shouldn't be able to change this himself)
995$x	items.renewals (should be hidden in the editor, since the user shouldn't be able to change this himself)
995$y	items.reserves (should be hidden in the editor, since the user shouldn't be able to change this himself)
995$z	items.nonpublicnote 
995$0	items.withdrawn (linked to the appropriate AV list)
995$2	items.itemlost (linked to the appropriate AV list)
995$3	items.restricted 
995$5	items.dateaccessioned (linked to the appropriate plugin)
995$6	items.copynumber (should be hidden in the editor as it doesn't make sense by default)
995$7	items.uri (should be hidden in the editor as it doesn't make sense by default)
995$h	items.ccode (linked to the appropriate AV list)
995$l	items.materials 
995$m	items.datelastborrowed (should be hidden in the editor, since the user shouldn't be able to change this himself)
995$v	items.enumchron
Comment 2 Gaetan Boisson 2014-06-02 13:42:50 UTC
More changes will be proposed to correct the default framework.
This patch will focus on French UNIMARC only.
Comment 3 Jonathan Druart 2014-07-11 15:29:41 UTC
Gaetan, just looking at damaged and withdrawn: the dom file defined 995$1 for damaged and 995$3 for withdrawn (etc/zebradb/marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml ~l.1565).

Who is right?
Where can I found a ref?
Comment 4 Gaetan Boisson 2014-07-11 15:37:36 UTC
There is no standard to follow here. So we'll have to pick values, and make they work with the rest.
[+] Comment 5 Jonathan Druart 2014-09-29 10:41:52 UTC Comment hidden (obsolete)
[+] Comment 6 Jonathan Druart 2014-09-29 10:44:41 UTC Comment hidden (obsolete)
[+] Comment 7 Jonathan Druart 2014-09-29 10:44:49 UTC Comment hidden (obsolete)
[+] Comment 8 Jonathan Druart 2014-09-29 10:44:53 UTC Comment hidden (obsolete)
[+] Comment 9 Jonathan Druart 2014-09-29 10:44:57 UTC Comment hidden (obsolete)
[+] Comment 10 Paul Poulain 2014-10-10 13:48:28 UTC Comment hidden (obsolete)
[+] Comment 11 Paul Poulain 2014-10-10 13:48:41 UTC Comment hidden (obsolete)
[+] Comment 12 Paul Poulain 2014-10-10 13:48:59 UTC Comment hidden (obsolete)
[+] Comment 13 Paul Poulain 2014-10-10 13:49:06 UTC Comment hidden (obsolete)
[+] Comment 14 Paul Poulain 2014-10-10 13:51:25 UTC Comment hidden (obsolete)
[+] Comment 15 Paul Poulain 2014-10-10 13:51:39 UTC Comment hidden (obsolete)
Comment 16 Katrin Fischer 2014-10-15 14:41:19 UTC
Created attachment 32336 [details] [review]
[PASSED QA] Bug 11586: Better default framework for UNIMARC - framework

This patch updates the framework_DEFAULT.sql for unimarc_complet.

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 17 Katrin Fischer 2014-10-15 14:41:40 UTC
Created attachment 32337 [details] [review]
[PASSED QA] Bug 11586: Better default framework for UNIMARC - authority

This patch updates the framework for authorities (unimarc_complet only).

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 18 Katrin Fischer 2014-10-15 14:41:45 UTC
Created attachment 32338 [details] [review]
[PASSED QA] Bug 11586: Better default framework for UNIMARC - AV

This patch updates the authorised_values.sql file.
New WITHDRAWN and RESTRICTED.

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 19 Katrin Fischer 2014-10-15 14:41:49 UTC
Created attachment 32339 [details] [review]
[PASSED QA] Bug 11586: Better default framework for UNIMARC - zebra conf

This patch updates the Zebra configuration for unimarc.

995$d and 995$j should not be indexed.

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 20 Katrin Fischer 2014-10-15 14:41:53 UTC
Created attachment 32340 [details] [review]
[PASSED QA] Bug 11586 follow-up

 * itemtype = a mix was made between 099$t (biblioitems level) and 995$r (items level).
   I've chosen 099$t (manual change still possible for librarians that want it)
 * the 616$z is mistakenly displayed in tab 0. Switched to 6
 * field "abimé" (995$1) activated, it's better

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 21 Katrin Fischer 2014-10-15 14:42:04 UTC
Created attachment 32341 [details] [review]
[PASSED QA] Bug 11586 follow-up, FA framework update

This follow-up also improves the FA framework, removing some fields that should not be in FA

Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 22 Katrin Fischer 2014-10-15 14:47:30 UTC
I am not sure removing fields form the FA framework is the best way to go as it can result in data loss, but as the framework is incomplete already, this is a non-blocker for me.
Comment 23 Mathieu Saby 2014-10-22 12:59:44 UTC
Hello

Could you explain where the line
"('900', 'forme rejetée des zones 70X et 72X', '', 0, 0, NULL, ''),"
come from in attachment 32336 [details] [review] ?

I suppressed it from current framework some monthes ago, because it is not used by Electre, nor by the BNF. Maybe Electre added it again? Or is it simply a copy-paste mistake?
Same remarks for other fields added by this patch (910, 960...)

For 009 phrasing : it may contain the ARK N° of the BNF, but only for libraries that use BNF records (so, not for the academic libraries).



Mathieu Saby
Comment 24 Mathieu Saby 2014-10-22 13:09:24 UTC
Also, maybe I am wrong (far from Koha...), but if the framework you touched is the one used by academic libraries, why deleting 359 field, which is used in Sudoc network, and why adding "Vendangeur" (not used).


More generaly, but maybe out of the scope of this bug, don't you think it could be a good point to rename the french frameworks?
Because for example a "Conservation" framework means nothing for me. And if the "complete" framework is supposed to be used in academic libraries, why not renaming it, and suppressing useless fields like "091 vendangeur"?
Or mabye creating a new framework specifically made for academic libraries?


Mathieu
Comment 25 Tomás Cohen Arazi (tcohen) 2014-10-23 19:06:07 UTC
Patches pushed to master.

Thanks Jonathan!