Re: [Koha-devel] Subfields 952 $i, $k
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.
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.)
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? I don't think everyone has the time to follow all bugs (I certainly missed this one), maybe the development team could assure us that 952 $[A-Z] are fully working and available for local use, while 952 $[a-z] are for Koha use? Best - Paul
For search you would need to add new indexes to your Zebra configuration. This is independent from the way you store the data in your database.
Hope this makes sense and is helpful for you,
Katrin
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Paul Sent: Monday, April 18, 2011 4:04 PM To: koha; koha-devel@lists.koha-community.org Subject: [Koha-devel] Subfields 952 $i, $k
[Apologies for cross-posting, users and devel]
Marc 952 $i, $k are not used in "standard" Koha. They can be added to the default framework (allowed by Koha), but this appears to require a modification to the Mysql structure. Has anyone tried to do this?
Background: for Serials, we want to add at *item* level "Extended Keywords" (952$z is limited to 255 characters) and "Abstracts" (at *biblio* level, we use 520 $a and $b.)
This will require new "Koha Fields" - e.g, in the same way that 952$z uses "items.itemnotes" we will need to introduce "items.itemkeywords" and "items.itemabstracts".
I am looking for suggestions as to how to best add these fields so that they can be usefully searched by the OPAC - and of course for any pitfalls or showstoppers.
Thanks
Paul Tired old sys-admin
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
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
participants (2)
-
Chris Cormack -
Paul