On 19 April 2011 04:19, Paul <paul.a@aandc.org> wrote:
At 04:18 PM 4/18/2011 +0200, Fischer, Katrin wrote:
Hi Paul, in 3.4 a mapping and a new search index was introduced for 952$i and items.stocknumber (Bug 5839).
Many thanks for the answers. So if we upgrade to 3.4, I'll have to modify kohadb to take out the (varchar 32) constraint? So far, we have endeavoured to remain "faithful" to the Master version, but cataloguing our serials is an uphill challenge.
If you make local changes that don't go into master, then yes, if you don't commit them back you will have to reconcile on upgrade. This is the danger of local unsubmitted changes in any project. You could of course just remove the mapping in your framework, if its not linked to a colum in the items table it will just end up in the xml as Katrin says below. So if you don't want i to be stocknumber in yours, you can change the mapping.
You can easily add new subfields in your bibliographic frameworks. If you leave the mapping field empty the data will be stored in the more_subfields_xml column. As the name indicates it's stored in a XML format.
Perhaps easier to add specific items.xyx - I don't think the XML will be problematic, but wonder if these are all concatenated for OPAC display? (e.g. at the moment 520 $a and $b ARE concatenated. I'm looking for a way to undo this.)
Use the xslt stylesheets you can make them display any way you like
There are not many lowercase letters left for 952. According to the MARC21 Standard it's also possible to use uppercase letters, but I am not completely sure if Koha works correctly if you do. This would need some more testing, although we have done so in the past without running into problems.
This sounds like a possible solution - instead of "local" specialized uses (German remapping of 995$j to 952$i in this case) getting into the Master, surely it is more logical to leave more flexibility?
You totally misread the bug. Katrin suggested we add a stocknumber using the 952$i field. She pointed out that in UNIMARC they use 995$j. UNIMARC is a totally different standard to MARC21, there was no remapping. Marcel (who is dutch) agreed. People from all over the world also discussed this on IRC. In no way is this a German localised use. Chris