[OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)

Fri May 29 11:15:21 EDT 2015

+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
jschrader at cwmars.org<mailto:jschrader at cwmars.org>

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] 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 <sarahc at zionsvillelibrary.org<mailto:sarahc at zionsvillelibrary.org>> 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 <klussier at masslnc.org<mailto:klussier at masslnc.org>> 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 <klussier at masslnc.org<mailto:klussier at masslnc.org>> 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
tonyb at ohionet.org<mailto:tonyb at ohionet.org>
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>

klussier at masslnc.org<mailto:klussier at masslnc.org>

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
sarahc at zionsvillelibrary.org<mailto:sarahc at zionsvillelibrary.org>

--

Kathy Lussier

Project Coordinator

Massachusetts Library Network Cooperative

(508) 343-0128<tel:%28508%29%20343-0128>

klussier at masslnc.org<mailto:klussier at masslnc.org>

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
sarahc at zionsvillelibrary.org<mailto:sarahc at zionsvillelibrary.org>

--
Sarah Childs
Technical Services Department Head
Hussey-Mayfield Memorial Public Library
250 North Fifth Street
Zionsville, IN 46077
317-873-3149 x13330
sarahc at zionsvillelibrary.org<mailto:sarahc at zionsvillelibrary.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20150529/fb3af949/attachment-0001.html>