+1 for Sarah’s proposal The plain text I mentioned was not what I wanted, that is what happens now. Subfield ‘e’ is currently being treated as a “note” appended to the 7xx field instead of replacing the default parenthetical qualifier as subfield ‘4’ does.
I have tested multiple subfield ‘4’s on our record for Game of Thrones: The complete third season which has lots of 7xx fields to play with. If there are multiple subfield ‘4’s only the last one displays. If the last one is not defined in whatever table stores these codes then the default displays even if one or more of the others is in the table. Can anyone let me know what needs to be done to update that table? 700 1\ . ‡aWeiss, D. B. ‡4cre ‡4aus ‡4tlp Displays as: Weiss, D. B. (Added author) Evidently our system does not recognize the codes for Screenwriter or Television producer. 700 1\ . ‡aWeiss, D. B. ‡4cre Displays as: Weiss, D. B. (Creator) I haven’t tested multiple subfield ‘e’s yet. Janet Janet Schrader Bibliographic Services Supervisor C/W MARS, Inc. 67 Millbrook Street, Suite 201 Worcester, MA 01606 Tel: 508-755-3323 ext. 25 FaX: 508-757-7801 [email protected]<mailto:[email protected]> From: Open-ils-general [mailto:[email protected]] On Behalf Of Sarah Childs Sent: Thursday, May 28, 2015 4:51 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) That should be (Added Author) for the 700 field. And I would be on board with displaying the subfield e as a parenthetical instead of the plain text as Janet describes, although, alternatively if we displayed information from the subfield 4 consistently with the subfield e display, I'd be fine with that too, just so long as it's consistent one way or the other. And I hadn't looked for cases where the subfield 4 is repeated, but if only one is displaying, I agree that should be remedied. On Thu, May 28, 2015 at 4:44 PM, Sarah Childs <[email protected]<mailto:[email protected]>> wrote: It seems that the current behavior is that there is always a parenthetical, and if there is a subfield e present, it always displays as well. I added a subfield 4 to a record, and it appears that what the bug fix does is to use the code from the subfield 4 to replace the parenthetical information with more descriptive information than the default. Unfortunately, the subfield 4 is actually used really rarely, because it's optional and catalogers never really got on board with it. So the vast majority of the time you get the default, which is either (Author) for the 100 field or (Added Author) for the 100 field. That's so general as to be not particularly useful, since when it's accurate that information is usually clear from the 245, which is displayed above it. For media it's basically always wrong, and it's wrong pretty frequently for books, too. Based on that, the main change I'd like to see is that the parenthetical not be displayed when there is no subfield 4. Right now if we have both subfield 4 and subfield e, both are displayed, so I wouldn't really describe subfield e as a fallback. I think if both are present we should display one or the other, but I don't really feel strongly about which. Whichever is easier is fine with me. :-) A summary of what I propose: If no subfield e or 4, no term should be displayed. Display subfield e if present Display terms based on codes in subfield 4 if present If both subfield e or 4 are present, display one or the other. (Either is fine with me) On Thu, May 28, 2015 at 3:22 PM, Kathy Lussier <[email protected]<mailto:[email protected]>> wrote: Hi Sarah, Looking at the subfield e information in that bug, Dan says: Fall back to the $e if there is no explicit relator code; It sounds like you are proposing the opposite, use the $e and, if it's not available, fall back to the relator codes (subfield 4). I would support that change in direction. It sounds like an LP bug is in order! :) Kathy On 05/28/2015 03:15 PM, Sarah Childs wrote: If the bug is not the same problem as the one Tony is describing, it's very closely related. The bug does refer to the subfield e, the RDA terms, and it looks like that's what the non-parenthetical terms are in his example. I would vote for ditching the parenthetical terms entirely. If there are relator terms, display them (subfield e). If there are not, but there are relator codes (subfield 4), translate and supply those. (Don't give codes, give terms.) If there is nothing, give nothing, just the names. The parenthetically supplied terms are usually not that useful and often are misleading, redundant, or both. On Thu, May 28, 2015 at 2:47 PM, Kathy Lussier <[email protected]<mailto:[email protected]>> wrote: Hi Tony, I think this is a different issue. The issue here is that we previously added (Author) or other relator information in parentheses for pre-RDA records. Now that we have RDA records, the record is also now displaying the relator information from subfield e. Kathy On 05/28/2015 02:41 PM, Tony Bandy wrote: Hello everyone, Quick check if you have a moment? I’m working on TPAC cleanups for our consortium and am noticing title results that include duplicate author notations such as this: Hillenbrand, Laura,<http://blanchester-training.cool-cat.org/eg/opac/results?query=Hillenbrand%20%20Laura;qtype=author> author. (Author). Herrmann, Edward, 1943-<http://blanchester-training.cool-cat.org/eg/opac/results?query=Herrmann%20%20Edward%201943;qtype=author> narrator. (Added Author) Doing some digging around, this looks to me like Bug #958954 (see: https://bugs.launchpad.net/evergreen/+bug/958954) ------------------------- Has anyone encountered this? Do you think this bug is the same thing? I can fix this somewhat by going into the authors.tt2 file and removing the default label, but with that approach, if there is nothing in the subfield, then there will be zero notation after the author’s name. If I look at the details for the bug, Dan mentioned there was a fix released? Thanks in advance for any thoughts you might have! --Tony Tony Bandy [email protected]<mailto:[email protected]> OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074<tel:614-484-1074> (Direct) 614-486-2966 x19<tel:614-486-2966%20x19> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128<tel:%28508%29%20343-0128> [email protected]<mailto:[email protected]> Twitter: http://www.twitter.com/kmlussier -- Sarah Childs Technical Services Department Head Hussey-Mayfield Memorial Public Library 250 North Fifth Street Zionsville, IN 46077 317-873-3149 x13330 [email protected]<mailto:[email protected]> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128<tel:%28508%29%20343-0128> [email protected]<mailto:[email protected]> Twitter: http://www.twitter.com/kmlussier -- Sarah Childs Technical Services Department Head Hussey-Mayfield Memorial Public Library 250 North Fifth Street Zionsville, IN 46077 317-873-3149 x13330 [email protected]<mailto:[email protected]> -- Sarah Childs Technical Services Department Head Hussey-Mayfield Memorial Public Library 250 North Fifth Street Zionsville, IN 46077 317-873-3149 x13330 [email protected]<mailto:[email protected]>
