Bug 11026 - in UNIMARC, pubdate index should be based on 100 field and not 210
Summary: in UNIMARC, pubdate index should be based on 100 field and not 210
Status: RESOLVED DUPLICATE of bug 11202
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-09 17:24 UTC by Mathieu Saby
Modified: 2013-11-05 18:09 UTC (History)
0 users

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Saby 2013-10-09 17:24:09 UTC
210$d, curently indexed as pubdate, contains the date of the document
The content can be a complex string like "impr. 2010, cop. 2009" (according to cataloguing standard). Not sure how zebra
For ancient books, the date could be in latin numbers (MCM...) Zebra does not like that ;-)

Dates are also in roman numbers 100 coded field. In fact there is 2 dates (pos 9-12 and 13-16) and a code in pos 8 giving the type of date. In most case the 1st date should be indexed and not the 2d one.

Other issue : Sometimes date are uncertain and if the decade only is known, we will have 198X in 210 field, and "198 " (but I have found 198X and 198. in real word...). Zebra does not like that too...

M. Saby
Comment 1 Mathieu Saby 2013-10-14 17:26:12 UTC
An other option would be to declare pubdate index both on 210$d AND 100pos9-12
So, if a library does not have 100 filled, the record will still be indexed with 210.


M. Saby
Comment 2 Mathieu Saby 2013-10-23 10:05:12 UTC
in MARC21 : 261$c is index in "copydate"
210 is the UNIMARC equivalent.
So let's index too 210$d in "copydate"
Comment 3 Mathieu Saby 2013-11-05 18:09:08 UTC

*** This bug has been marked as a duplicate of bug 11202 ***