[Koha-devel] Subfields 952 $i, $k

[Chris Cormack]

On 19 April 2011 04:19, Paul <paul.a at 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