Bug 14198 - RDA: Indexing 264 field (Zebra)
Summary: RDA: Indexing 264 field (Zebra)
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Héctor Eduardo Castro Avalos
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 14304 15704
  Show dependency treegraph
 
Reported: 2015-05-13 17:00 UTC by Héctor Eduardo Castro Avalos
Modified: 2018-09-06 13:02 UTC (History)
9 users (show)

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


Attachments
Bug 14198: RDA: Indexing 264 field (Zebra) This patch add zebra indexes to RDA 264 field. The new Provider index is added too. The XSLT for staff and OPAC has been updated to reflect the index. (21.10 KB, patch)
2015-05-19 15:33 UTC, Héctor Eduardo Castro Avalos
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 14198: RDA: Indexing 264 field (Zebra) (21.31 KB, patch)
2015-05-19 23:09 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
Bug 14198: RDA: Indexing 264 field (Zebra) # 1/2 (9.27 KB, patch)
2015-06-01 04:31 UTC, Héctor Eduardo Castro Avalos
Details | Diff | Splinter Review
Bug 14198: RDA: Indexing 264 field (Zebra) # 2/2 (8.36 KB, patch)
2015-06-03 04:31 UTC, Héctor Eduardo Castro Avalos
Details | Diff | Splinter Review
Bug 14198: RDA: Indexing 264 field (Zebra) (5.32 KB, patch)
2015-07-10 20:17 UTC, Héctor Eduardo Castro Avalos
Details | Diff | Splinter Review
[SIGNED OFF]Bug 14198: RDA: Indexing 264 field (Zebra) (5.38 KB, patch)
2015-09-03 22:03 UTC, Nick Clemens
Details | Diff | Splinter Review
[PASSED QA] Bug 14198: RDA: Indexing 264 field (Zebra) (5.41 KB, patch)
2015-10-23 14:38 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Héctor Eduardo Castro Avalos 2015-05-13 17:00:55 UTC
Since RDA has been published, Koha need support for this Code. In this way 264 field need to be searchable.
Bib-1 set a new index for provider <http://www.loc.gov/z3950/agency/defns/bib1.html>
Provider 1225, although I think 264 should be included like 260 $a$b$c

Patch coming soon.
Comment 1 Héctor Eduardo Castro Avalos 2015-05-19 15:33:52 UTC Comment hidden (obsolete)
Comment 2 Héctor Eduardo Castro Avalos 2015-05-19 15:53:09 UTC
I add here maybe some interested in RDA development for Koha

Regards
Comment 3 Bernardo Gonzalez Kriegel 2015-05-19 23:09:10 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2015-05-31 20:09:10 UTC
Comment on attachment 39317 [details] [review]
[SIGNED-OFF] Bug 14198: RDA: Indexing 264 field (Zebra)

Review of attachment 39317 [details] [review]:
-----------------------------------------------------------------

Hi Hector,

thx for providing this patch! I think it's about time we get ready for RDA a bit more, indexing being a part of it.

I have added some comments - can you please take a look?

For next time: I think it would be a bit nicer if you had split out the XSLT changes into a separate bug - keeping indexing and display separate issues, but I can see how this works together here.

::: etc/zebradb/biblios/etc/bib1.att
@@ +220,4 @@
>  att 9010    cn-suffix
>  att 9011    Suppress
>  att 9012    Identifier-other
> +#att 9013    arp

What is arp? It seems unrelated to the patch set, but is added by it.

::: etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml
@@ +431,4 @@
>    <index_data_field tag="260">
>      <target_index>pl:w</target_index>
>    </index_data_field>
> +  <!--Index for Provider 260-->

There are already entries for 260 and its subfields - why keep this separate and not add the new <target_index> entries within the existing ones?

::: etc/zebradb/marc_defs/marc21/biblios/record.abs
@@ +129,4 @@
>  melm 260$b      Publisher:w,Publisher:p
>  melm 260$c      copydate,copydate:s
>  melm 260        pl
> +melm 260$a      Provider-place:w,Provider-place:p

The changes to record.abs are not necessary and should be removed, as GRS1 is deprecated.
I'd leave them in, but I think they are also not correct. There should only be one entry for each MARC field in record.abs - the new indexes should be listed additionally with the old entries. Easier to remove the file from the patch set.

::: koha-tmpl/opac-tmpl/bootstrap/en/xslt/MARC21slimUtils.xsl
@@ +273,5 @@
>          <xsl:value-of select="$field/marc:subfield[@code='a']"/>
>          <xsl:text> </xsl:text>
> +        <xsl:choose>
> +            <xsl:when test="$url='1'">
> +                <a href="/cgi-bin/koha/catalogue/search.pl?q=pb:{$field/marc:subfield[@code='b']}">

I believe the link here is for the intranet, while it should be an OPAC link.
Comment 5 Héctor Eduardo Castro Avalos 2015-06-01 04:31:13 UTC Comment hidden (obsolete)
Comment 6 Héctor Eduardo Castro Avalos 2015-06-01 04:59:29 UTC
Hi Katrin.

I fix all the comments in the comment 4.

I filed a new bug <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14304> for XSLTs in OPAC and Intranet to show the link for Publisher like 260 field. I will correct the link for the OPAC there.


Just one comment on etc/zebradb/biblios/etc/bib1.att
@@ +220,4 @@
>  att 9010    cn-suffix
>  att 9011    Suppress
>  att 9012    Identifier-other
> +#att 9013    arp

This is an index that really exist in the bottom of the file, I put it there in a commented line because it tends to confuse, this was eliminated from the new patch.

Please review the patch again and give us a feedback to proceed with the signed-off process.

Regards
Comment 7 Katrin Fischer 2015-06-01 06:05:48 UTC
Hi Hector,

> I filed a new bug
> <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14304> for XSLTs
> in OPAC and Intranet to show the link for Publisher like 260 field. I will
> correct the link for the OPAC there.

Thx! Sorry for causing you more work. :(

> Just one comment on etc/zebradb/biblios/etc/bib1.att
> @@ +220,4 @@
> >  att 9010    cn-suffix
> >  att 9011    Suppress
> >  att 9012    Identifier-other
> > +#att 9013    arp
> This is an index that really exist in the bottom of the file, I put it there
> in a commented line because it tends to confuse, this was eliminated from
> the new patch.

Ah, that makes sense - I didn't spot that from the patch file.

One more thought looking at this a bit more awake: Currently the new and the old indexes look as they will be mostly identical - they both index 260 and 264. I see the note about the Provider index being based on a suggestion from LOC, so that makes sense to me. But do we really need the other 2 new indexes Provider-place and Provider-date? Should we make them different or maybe just map them as an alias in ccl.properties to the existing indexes?
Comment 8 Héctor Eduardo Castro Avalos 2015-06-02 02:19:49 UTC
(In reply to Katrin Fischer from comment #7)

Hi Katrin,

> 
> Thx! Sorry for causing you more work. :(
> 
No problem, you've got right and that's your work. You see things that I haven't seen before. I really appreciate your help on this.

> One more thought looking at this a bit more awake: Currently the new and the
> old indexes look as they will be mostly identical - they both index 260 and
> 264. I see the note about the Provider index being based on a suggestion
> from LOC, so that makes sense to me. But do we really need the other 2 new
> indexes Provider-place and Provider-date? Should we make them different or
> maybe just map them as an alias in ccl.properties to the existing indexes?

I think that we don't need the two new indexes. I just include them here because make sense with counterpart 260 field, even though both indexes don't exist and they are not in any suggestion or standard, i.e., I have included them here to map at the same as 260 field and find the same results. They work as an alias of the indexes pl and copydate. If you prefer I will remove both.
Comment 9 Katrin Fischer 2015-06-02 06:20:08 UTC
Hi Hector,

I think what you could do is remove most of the index definitions for the Provider-* indexes and just solve it by adding one line in the ccl.properties file, as it allows you to add other names for an index. For example we have bc as a shortcut for the barcode index:

1016 barcode 1=8023
1017 bc barcode
Comment 10 Héctor Eduardo Castro Avalos 2015-06-03 04:31:11 UTC Comment hidden (obsolete)
Comment 11 Héctor Eduardo Castro Avalos 2015-06-04 01:06:13 UTC
Hi Katrine

I don't know if there are another observation of your part, or if the patch is OK and Beranardo can sign-off the patch again.


In advance thank you very much.
Comment 12 Katrin Fischer 2015-06-06 11:14:44 UTC
Comment on attachment 39791 [details] [review]
Bug 14198: RDA: Indexing 264 field (Zebra) # 2/2

Review of attachment 39791 [details] [review]:
-----------------------------------------------------------------

Hi Hector,

overall this looks good, sorry for the many iterations. I see you have decided to remove the new indexes - it's probably the easiest for now.

One suggestion: could you squash your 2 patches? As they are not signed off yet, that will make it a little easier to handle and see the changes.

::: etc/zebradb/ccl.properties
@@ +584,4 @@
>  #                           multiple indexes for            270$abcd
>  #                           publication/production info.
>  Provider 1=1225
> +pv Provider Place-publication Publisher copydate

I am not sure what you are trying to achieve with this line. I would have expected just:
pv Provider
to crate a short index form for searching the Provider index. 
I am not sure listing multiple works here.
Comment 13 Héctor Eduardo Castro Avalos 2015-06-08 02:37:30 UTC
(In reply to Katrin Fischer from comment #12)
> Comment on attachment 39791 [details] [review] [review]

Hi Katrin

> One suggestion: could you squash your 2 patches? As they are not signed off
> yet, that will make it a little easier to handle and see the changes.

Yes, I will squash it.
 
> ::: etc/zebradb/ccl.properties
> @@ +584,4 @@
> >  #                           multiple indexes for            270$abcd
> >  #                           publication/production info.
> >  Provider 1=1225
> > +pv Provider Place-publication Publisher copydate
> 
> I am not sure what you are trying to achieve with this line. I would have
> expected just:
> pv Provider
> to crate a short index form for searching the Provider index. 
> I am not sure listing multiple works here.

Doing this let us have two indexes one just for 260 and the another for both field (i.e., 260 and 264) since Publisher its just for 260. I just followed up the yaz documentation at <http://www.indexdata.com/yaz/doc/tools.html#CCL> in section 1.2.2.2 Qualifier alias. In this sense Provider will harvest the three indexes for 260 (Place-publication, Publisher, and copydate) and the same Provider index applied to all field in 260 and 264.

So let me do four prepositions:

1) Let me enumerate the above as the first one.
2) The second one:

In ccl.properties:
Provider 1=1225
pv Provider

and apply provider to all field in 260 and 264 in biblio-koha-indexdefs.xml file as:
  <index_subfields tag="260" subfields="a">
    <target_index>pl:w</target_index>
    <target_index>pl:p</target_index>
  </index_subfields>
  <index_subfields tag="260" subfields="b">
    <target_index>Publisher:w</target_index>
    <target_index>Publisher:p</target_index>
  </index_subfields>
  <index_subfields tag="260" subfields="c">
    <target_index>copydate:w</target_index>
    <target_index>copydate:s</target_index>
  </index_subfields>

<index_data_field tag="260">
  <target_index>pl:w</target_index>
  <target_index>Provider:w</target_index>
</index_data_field>
<index_data_field tag="264">
  <target_index>Provider:w</target_index>
</index_data_field>

3) And the last one:
In ccl.properties:
Provider 1=1225
pv Provider

and apply the three indexes of 260 to 264, i.e., copying the indexes of 260 and adding the tags for all field as follow:
<index_data_field tag="260">
  <target_index>pl:w</target_index>
  <target_index>Provider:w</target_index>
</index_data_field>
<index_data_field tag="264">
  <target_index>pl:w</target_index>
  <target_index>Provider:w</target_index>
</index_data_field>

And 4) do me a preposition to work with.

Finally I don't know if is Ok to choose to use "pv" or another one like "provider" without capitalization in the alias for Provider index.


I will change the bug as In discussion status.


Regards
Comment 14 Héctor Eduardo Castro Avalos 2015-06-15 02:24:13 UTC
Hi Katrin

I don't know what you think about the proposals above?

Sorry about my bad English, sometimes I think in Spanish when typing.

Thanks in advance.
Comment 15 Héctor Eduardo Castro Avalos 2015-07-10 20:17:40 UTC Comment hidden (obsolete)
Comment 16 Nick Clemens 2015-09-03 22:03:29 UTC Comment hidden (obsolete)
Comment 17 Kyle M Hall 2015-10-23 14:38:17 UTC
Created attachment 43855 [details] [review]
[PASSED QA] Bug 14198: RDA: Indexing 264 field (Zebra)

This patch add zebra indexes to RDA 264 field.
The new Provider index is added too.
QA comments corrected.

To test:
1) Download RDA records with 264 fields from this attachment <http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=36825>. Import the file and re-index/rebuild zebra. These records contain 260 and 264 fields per record.
2) Do a search with pb:Bethany two records will appear with title The guardian. Search with pl:Minneapolis too, the two records will appear.
3) Select one record of both records and delete the 260 field keeping the 264 field and save, rebuild your zebra.
4) Search again with pb:Bethany and just one record will appear. Thats mean 264 is not indexed.
5) Apply patches.
6) Rebuild your zebra but this time all biblio records.
7) Search again with pv:Bethany or Provider:Bethany, this time will appear the two records, 264 is indexed. Note that if you search again with pb only one record appear. This is because the suggestion of LOC.
10) Search with copydate:2013 only launch records with 260 fields and pv:2013 show both fields, i.e., 260 and 264.
11) Apply QA Test Tools

Sponsored-by: Universidad de El Salvador
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 18 Tomás Cohen Arazi 2015-11-02 15:42:15 UTC
Parche aplicado en master.

Gracias Hector!