Bug 35981 - Add authorized values for Relator Terms
Summary: Add authorized values for Relator Terms
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement with 6 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-01 17:02 UTC by Esther Melander
Modified: 2024-02-28 21:22 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Esther Melander 2024-02-01 17:02:56 UTC
Bug 34677 updates the relator terms and codes list. There are authorized values for Relator Terms but not for Relator Codes. This should be separated out so that the codes can be selected for $4, which is more correct for that subfield. While it is possible for a user to add authorized values for Relator Codes, it would be nice if they were included.
Comment 1 Katrin Fischer 2024-02-27 21:33:29 UTC
(In reply to Esther Melander from comment #0)
> Bug 34677 updates the relator terms and codes list. There are authorized
> values for Relator Terms but not for Relator Codes. This should be separated
> out so that the codes can be selected for $4, which is more correct for that
> subfield. While it is possible for a user to add authorized values for
> Relator Codes, it would be nice if they were included.

I think this is not quite right:

RELTERMS AV category has the authorised values for the codes, not the terms. 

What happens is that we resolve the code in the MARC record to the term when the XSLT is parsed for display automatically. So you see the description when looking at it in Koha, but when you export the record, it has the code. So we have $4, but are missing values for $e maybe?

I wonder if using AV codes is the best way here. Maybe we should have a cataloguing plugin that automatically populates the other subfield depending on the value chosen?
Comment 2 Esther Melander 2024-02-28 20:05:36 UTC
Yes, I can see the codes as the authorized value. However, when selecting RELTERMS for $4 in the framework, the description is what is displayed. The description is equivalent to the terms and not the codes. $4 should display the codes as a code rather than the associated term as that should be in $e.

This is an example:

100	1	 	Presthus, Robert Vance, ǂe author ǂ4 aut

Also, reading up on this, $4 is repeatable. Another example:

100	1	 	Wagner, Kate, ǂe composer, ǂe instrumentalist ǂ4 cmp ǂ4 itr

The example above also suggests there is not always a one to one relationship between a term and a code.

Would a plugin address what data is displayed? It would be easier to maintain one list of codes and terms.
Comment 3 Katrin Fischer 2024-02-28 21:22:59 UTC
I think we need to separate display from what is actually stored in the MARC record.
The trick we use for AVs in frameworks make it so you always see the AV description, while the code is actually stored in the record.
If you want display and MARC record to match, the easiest way would be to edit the RELTERMS list and set the description to the code values.  
Similar, if we wanted the terms, we'd need to set code and description to the term, which doesn't really feel like an all that great idea (not sure if the code length is still limited).
Using a cataloging plugin might be actually be more flexible and could help if we want fields to depend on each other in some way.