Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
Title: Sincerely,
Regarding Dan's list, which is a good breakdown of the various
issues, Part (d) really should be a case of one or the other. There
should not be both a $e relator term and $4 relator code in the same
field.
I am not an RDA expert (or a particularly big fan), but if we are
looking to the future I think the $e relator term should take
precedence over the $4 relator code. All the RDA records we are
seeing are using the $e rather than the $4 and when our consortium
just went through the RDA process on all of our records with
Backstage, all the $4 codes were converted to $e relator terms.
Thanks,
Chris
Chris
Owens
Director
Blanchester
Public Library
110 N.
Broadway
Blanchester,
OH 45107
937-783-3585
937-783-2910
(fax)
cow...@blanlibrary.org
On 5/29/2015 10:57 AM, Dan Scott wrote:
It sounds like there are a few issues here, let me
see if I can separate them out:
a) bug: relator term $e is not being recognized as the
relator, but is included in the text display along with
parenthetical notation for the default relationship (e.g.
700 = (added author))
b) bug: multiple $4 relator codes are not displayed
properly, where "properly" might mean something like "$700
$a White, Jack $4 cre $4 dir" should be displayed as "White,
Jack (creator, director)"
c) bug: the default relationship of "added author" for
7xx fields when no relator code or term is specified needs
to reflect the underlying item type (e.g. for a musical
recording, should display something like "Added artist")
d) discussion issue: when both $e relator terms and $4 relator
codes are included in the same field, it's not clear what to
display
e) (unknown if this is an issue, but "probably") $e relator
terms and $4 relator codes may or may not be indexed as
expected
For my part on (d), I'm still firmly of the belief that $4
relator code should take precedence; it's value can easily be
translated in the display (and is, for French) and can be used
for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc),
whereas the $e relator terms are effectively uncontrolled text
fields that make both translation and linked data much, much
more difficult.
Dan
On Fri, May 29, 2015 at 8:56 AM, Hardy,
Elaine eha...@georgialibraries.org
wrote:
+1
Elaine
J.
Elaine Hardy
PINES Collaborative Projects Manager
Georgia Public Library Service
1800 Century Place, Ste 150
Atlanta, Ga. 30345-4304
404.235.7128
404.235.7201,
fax
eha...@georgialibraries.org
www.georgialibraries.org
www.georgialibraries.org/pines
From:
Open-ils-general [mailto:open-ils-general-boun...@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?)
A summary of what I
propose:
If no subfield e or
4, no term should be displayed.
D
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
I think it is LC practice to use the terms rather than the codes. Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Chris Owens Sent: Monday, June 01, 2015 9:05 AM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) Regarding Dan's list, which is a good breakdown of the various issues, Part (d) really should be a case of one or the other. There should not be both a $e relator term and $4 relator code in the same field. I am not an RDA expert (or a particularly big fan), but if we are looking to the future I think the $e relator term should take precedence over the $4 relator code. All the RDA records we are seeing are using the $e rather than the $4 and when our consortium just went through the RDA process on all of our records with Backstage, all the $4 codes were converted to $e relator terms. Thanks, Chris Chris Owens Director Blanchester Public Library 110 N. Broadway Blanchester, OH 45107 937-783-3585 937-783-2910 (fax) cow...@blanlibrary.org On 5/29/2015 10:57 AM, Dan Scott wrote: It sounds like there are a few issues here, let me see if I can separate them out: a) bug: relator term $e is not being recognized as the relator, but is included in the text display along with parenthetical notation for the default relationship (e.g. 700 = (added author)) b) bug: multiple $4 relator codes are not displayed properly, where properly might mean something like $700 $a White, Jack $4 cre $4 dir should be displayed as White, Jack (creator, director) c) bug: the default relationship of added author for 7xx fields when no relator code or term is specified needs to reflect the underlying item type (e.g. for a musical recording, should display something like Added artist) d) discussion issue: when both $e relator terms and $4 relator codes are included in the same field, it's not clear what to display e) (unknown if this is an issue, but probably) $e relator terms and $4 relator codes may or may not be indexed as expected For my part on (d), I'm still firmly of the belief that $4 relator code should take precedence; it's value can easily be translated in the display (and is, for French) and can be used for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc), whereas the $e relator terms are effectively uncontrolled text fields that make both translation and linked data much, much more difficult. Dan On Fri, May 29, 2015 at 8:56 AM, Hardy, Elaine eha...@georgialibraries.org wrote: +1 Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@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?) 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)
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
Hi all, Just wanted to say “thank you” for all the good discussion(s) about this. We are now evaluating the responses and working with our catalogers to see how they want to tackle this issue. So going forward, should we file additional bug reports on this—or what’s the best way to bring about change? Appreciate it!!! --Tony Tony Bandy to...@ohionet.orgmailto:to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074 (Direct) 614-486-2966 x19 From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Hardy, Elaine Sent: Monday, June 1, 2015 9:33 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) I think it is LC practice to use the terms rather than the codes. Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.orgmailto:eha...@georgialibraries.org www.georgialibraries.orghttp://www.georgialibraries.org www.georgialibraries.org/pineshttp://www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Chris Owens Sent: Monday, June 01, 2015 9:05 AM To: open-ils-general@list.georgialibraries.orgmailto:open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) Regarding Dan's list, which is a good breakdown of the various issues, Part (d) really should be a case of one or the other. There should not be both a $e relator term and $4 relator code in the same field. I am not an RDA expert (or a particularly big fan), but if we are looking to the future I think the $e relator term should take precedence over the $4 relator code. All the RDA records we are seeing are using the $e rather than the $4 and when our consortium just went through the RDA process on all of our records with Backstage, all the $4 codes were converted to $e relator terms. Thanks, Chris Chris Owens Director Blanchester Public Library 110 N. Broadway Blanchester, OH 45107 937-783-3585 937-783-2910 (fax) cow...@blanlibrary.orgmailto:cow...@blanlibrary.org On 5/29/2015 10:57 AM, Dan Scott wrote: It sounds like there are a few issues here, let me see if I can separate them out: a) bug: relator term $e is not being recognized as the relator, but is included in the text display along with parenthetical notation for the default relationship (e.g. 700 = (added author)) b) bug: multiple $4 relator codes are not displayed properly, where properly might mean something like $700 $a White, Jack $4 cre $4 dir should be displayed as White, Jack (creator, director) c) bug: the default relationship of added author for 7xx fields when no relator code or term is specified needs to reflect the underlying item type (e.g. for a musical recording, should display something like Added artist) d) discussion issue: when both $e relator terms and $4 relator codes are included in the same field, it's not clear what to display e) (unknown if this is an issue, but probably) $e relator terms and $4 relator codes may or may not be indexed as expected For my part on (d), I'm still firmly of the belief that $4 relator code should take precedence; it's value can easily be translated in the display (and is, for French) and can be used for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc), whereas the $e relator terms are effectively uncontrolled text fields that make both translation and linked data much, much more difficult. Dan On Fri, May 29, 2015 at 8:56 AM, Hardy, Elaine eha...@georgialibraries.orgmailto:eha...@georgialibraries.org wrote: +1 Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128tel:404.235.7128 404.235.7201tel:404.235.7201, fax eha...@georgialibraries.orgmailto:eha...@georgialibraries.org www.georgialibraries.orghttp://www.georgialibraries.org www.georgialibraries.org/pineshttp://www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.orgmailto:open-ils-general-boun...@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?) 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)
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
+1 Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@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?) 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)
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
It is my understanding that, under RDA, relator terms (|e) should be the controlled values that can be coded in |4 (http://www.loc.gov/marc/relators/relaterm.html). However, records cataloged using AACR2, the |e would not necessarily have been a controlled term, or at least, not a the current controlled terms (|e ill. vs |e Illustrator, for example). So, I think Dan’s point for the relator code to take precedence is a good one since our bib databases will contain a mixture of RDA and AACR2 (and previous rules!!) records for a long time to come. Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Dan Scott Sent: Friday, May 29, 2015 10:57 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) It sounds like there are a few issues here, let me see if I can separate them out: a) bug: relator term $e is not being recognized as the relator, but is included in the text display along with parenthetical notation for the default relationship (e.g. 700 = (added author)) b) bug: multiple $4 relator codes are not displayed properly, where properly might mean something like $700 $a White, Jack $4 cre $4 dir should be displayed as White, Jack (creator, director) c) bug: the default relationship of added author for 7xx fields when no relator code or term is specified needs to reflect the underlying item type (e.g. for a musical recording, should display something like Added artist) d) discussion issue: when both $e relator terms and $4 relator codes are included in the same field, it's not clear what to display e) (unknown if this is an issue, but probably) $e relator terms and $4 relator codes may or may not be indexed as expected For my part on (d), I'm still firmly of the belief that $4 relator code should take precedence; it's value can easily be translated in the display (and is, for French) and can be used for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc), whereas the $e relator terms are effectively uncontrolled text fields that make both translation and linked data much, much more difficult. Dan On Fri, May 29, 2015 at 8:56 AM, Hardy, Elaine eha...@georgialibraries.org wrote: +1 Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@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?) 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)
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
It sounds like there are a few issues here, let me see if I can separate them out: a) bug: relator term $e is not being recognized as the relator, but is included in the text display along with parenthetical notation for the default relationship (e.g. 700 = (added author)) b) bug: multiple $4 relator codes are not displayed properly, where properly might mean something like $700 $a White, Jack $4 cre $4 dir should be displayed as White, Jack (creator, director) c) bug: the default relationship of added author for 7xx fields when no relator code or term is specified needs to reflect the underlying item type (e.g. for a musical recording, should display something like Added artist) d) discussion issue: when both $e relator terms and $4 relator codes are included in the same field, it's not clear what to display e) (unknown if this is an issue, but probably) $e relator terms and $4 relator codes may or may not be indexed as expected For my part on (d), I'm still firmly of the belief that $4 relator code should take precedence; it's value can easily be translated in the display (and is, for French) and can be used for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc), whereas the $e relator terms are effectively uncontrolled text fields that make both translation and linked data much, much more difficult. Dan On Fri, May 29, 2015 at 8:56 AM, Hardy, Elaine eha...@georgialibraries.org wrote: +1 *Elaine* J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines *From:* Open-ils-general [mailto: open-ils-general-boun...@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?) 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)
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
+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 jschra...@cwmars.orgmailto:jschra...@cwmars.org From: Open-ils-general [mailto:open-ils-general-boun...@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 sar...@zionsvillelibrary.orgmailto:sar...@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 kluss...@masslnc.orgmailto:kluss...@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 kluss...@masslnc.orgmailto:kluss...@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
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
Comment on point b: Properly for me would be to display multiple ones separated by commas. Comment on point c: Without a code or term how would the system recognize the relationship between the 7xx field and the item described? Not all 7xx fields for a music recording are added artists except in the broadest sense, some may be arranger, composer, musician, performer, producer. Comment on point d: Relator codes and terms came from two different cataloging rules. I think it unlikely that the same 7xx field would have a combination of the two. I prefer ‘4’ with the codes but none of the RDA records I’ve imported into my system use ‘4’ and I don’t have the time to replace the ‘e’s. Elaine, aren’t the RDA terms controlled vocabulary? We haven’t started using RDA yet so I’m not sure but I thought they were. 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 jschra...@cwmars.orgmailto:jschra...@cwmars.org From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Hardy, Elaine Sent: Friday, May 29, 2015 12:03 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) It is my understanding that, under RDA, relator terms (|e) should be the controlled values that can be coded in |4 (http://www.loc.gov/marc/relators/relaterm.html). However, records cataloged using AACR2, the |e would not necessarily have been a controlled term, or at least, not a the current controlled terms (|e ill. vs |e Illustrator, for example). So, I think Dan’s point for the relator code to take precedence is a good one since our bib databases will contain a mixture of RDA and AACR2 (and previous rules!!) records for a long time to come. Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.orgmailto:eha...@georgialibraries.org www.georgialibraries.orghttp://www.georgialibraries.org www.georgialibraries.org/pineshttp://www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Dan Scott Sent: Friday, May 29, 2015 10:57 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) It sounds like there are a few issues here, let me see if I can separate them out: a) bug: relator term $e is not being recognized as the relator, but is included in the text display along with parenthetical notation for the default relationship (e.g. 700 = (added author)) b) bug: multiple $4 relator codes are not displayed properly, where properly might mean something like $700 $a White, Jack $4 cre $4 dir should be displayed as White, Jack (creator, director) c) bug: the default relationship of added author for 7xx fields when no relator code or term is specified needs to reflect the underlying item type (e.g. for a musical recording, should display something like Added artist) d) discussion issue: when both $e relator terms and $4 relator codes are included in the same field, it's not clear what to display e) (unknown if this is an issue, but probably) $e relator terms and $4 relator codes may or may not be indexed as expected For my part on (d), I'm still firmly of the belief that $4 relator code should take precedence; it's value can easily be translated in the display (and is, for French) and can be used for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc), whereas the $e relator terms are effectively uncontrolled text fields that make both translation and linked data much, much more difficult. Dan On Fri, May 29, 2015 at 8:56 AM, Hardy, Elaine eha...@georgialibraries.orgmailto:eha...@georgialibraries.org wrote: +1 Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128tel:404.235.7128 404.235.7201tel:404.235.7201, fax eha...@georgialibraries.orgmailto:eha...@georgialibraries.org www.georgialibraries.orghttp://www.georgialibraries.org www.georgialibraries.org/pineshttp://www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.orgmailto:open-ils-general-boun...@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?) 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)
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
In response to Dan's points a) Yes. b) Yes. c) I think this is a discussion issue as well. I would prefer using no terms at all when there is no term or code, because it's not possible to sufficiently determine the relationship of the person to the work. A 700 field in a book record could be for an added author, an illustrator, an editor, a preface author, etc. For media, the possibilities are equally varied or even moreso. I think if no information is supplied in the record, we shouldn't try to supply a descriptor. Just give the name. It's frequently explained in notes or the 245. d) Yes. This but this situation would be fairly rare, so I think it's the least pressing issue. I'm fine with giving subfield 4 precedence. e) Haven't noticed anything in this area, but it would be wise to look into it and resolve if needed. The terms in RDA are controlled-ish. There is a list of terms to be used, but catalogers can supply their own if none in the list are considered appropriate. On Fri, May 29, 2015 at 10:57 AM, Dan Scott d...@coffeecode.net wrote: It sounds like there are a few issues here, let me see if I can separate them out: a) bug: relator term $e is not being recognized as the relator, but is included in the text display along with parenthetical notation for the default relationship (e.g. 700 = (added author)) b) bug: multiple $4 relator codes are not displayed properly, where properly might mean something like $700 $a White, Jack $4 cre $4 dir should be displayed as White, Jack (creator, director) c) bug: the default relationship of added author for 7xx fields when no relator code or term is specified needs to reflect the underlying item type (e.g. for a musical recording, should display something like Added artist) d) discussion issue: when both $e relator terms and $4 relator codes are included in the same field, it's not clear what to display e) (unknown if this is an issue, but probably) $e relator terms and $4 relator codes may or may not be indexed as expected For my part on (d), I'm still firmly of the belief that $4 relator code should take precedence; it's value can easily be translated in the display (and is, for French) and can be used for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc), whereas the $e relator terms are effectively uncontrolled text fields that make both translation and linked data much, much more difficult. Dan On Fri, May 29, 2015 at 8:56 AM, Hardy, Elaine eha...@georgialibraries.org wrote: +1 *Elaine* J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines *From:* Open-ils-general [mailto: open-ils-general-boun...@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?) 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) -- Sarah Childs Technical Services Department Head Hussey-Mayfield Memorial Public Library 250 North Fifth Street Zionsville, IN 46077 317-873-3149 x13330 sar...@zionsvillelibrary.org
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
a) Yes b) Yes c) I agree with Sarah – if neither subfield is present, then the name should display with no terms. There is no one term to rule them all here. d) See earlier post. I also think it would be a rare occurrence; but I prefer to plan for it in case LC decides to add both in the future. e) Agree with Sarah here as well. I like the term controlled-ish. Describes RDA in a lot of places. The list at http://www.loc.gov/marc/relators/relaterm.html is pretty comprehensive but does probably leave something out. Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Sarah Childs Sent: Friday, May 29, 2015 1:40 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) In response to Dan's points a) Yes. b) Yes. c) I think this is a discussion issue as well. I would prefer using no terms at all when there is no term or code, because it's not possible to sufficiently determine the relationship of the person to the work. A 700 field in a book record could be for an added author, an illustrator, an editor, a preface author, etc. For media, the possibilities are equally varied or even moreso. I think if no information is supplied in the record, we shouldn't try to supply a descriptor. Just give the name. It's frequently explained in notes or the 245. d) Yes. This but this situation would be fairly rare, so I think it's the least pressing issue. I'm fine with giving subfield 4 precedence. e) Haven't noticed anything in this area, but it would be wise to look into it and resolve if needed. The terms in RDA are controlled-ish. There is a list of terms to be used, but catalogers can supply their own if none in the list are considered appropriate. On Fri, May 29, 2015 at 10:57 AM, Dan Scott d...@coffeecode.net wrote: It sounds like there are a few issues here, let me see if I can separate them out: a) bug: relator term $e is not being recognized as the relator, but is included in the text display along with parenthetical notation for the default relationship (e.g. 700 = (added author)) b) bug: multiple $4 relator codes are not displayed properly, where properly might mean something like $700 $a White, Jack $4 cre $4 dir should be displayed as White, Jack (creator, director) c) bug: the default relationship of added author for 7xx fields when no relator code or term is specified needs to reflect the underlying item type (e.g. for a musical recording, should display something like Added artist) d) discussion issue: when both $e relator terms and $4 relator codes are included in the same field, it's not clear what to display e) (unknown if this is an issue, but probably) $e relator terms and $4 relator codes may or may not be indexed as expected For my part on (d), I'm still firmly of the belief that $4 relator code should take precedence; it's value can easily be translated in the display (and is, for French) and can be used for linked data (like pointing to http://id.loc.gov/vocabulary/relators/dtc), whereas the $e relator terms are effectively uncontrolled text fields that make both translation and linked data much, much more difficult. Dan On Fri, May 29, 2015 at 8:56 AM, Hardy, Elaine eha...@georgialibraries.org wrote: +1 Elaine J. Elaine Hardy PINES Collaborative Projects Manager Georgia Public Library Service 1800 Century Place, Ste 150 Atlanta, Ga. 30345-4304 404.235.7128 404.235.7201, fax eha...@georgialibraries.org www.georgialibraries.org www.georgialibraries.org/pines From: Open-ils-general [mailto:open-ils-general-boun...@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?) 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) -- Sarah Childs Technical Services Department Head Hussey-Mayfield Memorial Public Library 250 North Fifth Street Zionsville, IN 46077 317-873-3149 x13330 sar...@zionsvillelibrary.org
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
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 kluss...@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 kluss...@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 to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074 (Direct) 614-486-2966 x19 614-486-2966%20x19 -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative(508) 343-0128kluss...@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 sar...@zionsvillelibrary.org -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative(508) 343-0128kluss...@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
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 sar...@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 kluss...@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 kluss...@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 to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074 (Direct) 614-486-2966 x19 614-486-2966%20x19 -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative(508)
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
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 kluss...@masslnc.org mailto:kluss...@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=authorauthor. (Author).Herrmann, Edward,1943- http://blanchester-training.cool-cat.org/eg/opac/results?query=Herrmann%20%20Edward%201943;qtype=authornarrator. (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 to...@ohionet.org mailto:to...@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 kluss...@masslnc.org mailto:kluss...@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 sar...@zionsvillelibrary.org mailto:sar...@zionsvillelibrary.org -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
Hi Kathy, folks, Thanks much for the update-this helps! Given this, has any other library with a mix of old and new records (pre-RDA and newer RDA) found a work-around for this in your authors.tt2 file? If you have would you be willing to share your coding or any other information? I've checked here, http://docs.evergreen-ils.org/2.7/_designing_your_catalog.html, but didn't see anything about custom designs on the logic. I'm thinking that adjusting the labels would be the quick fix, but our older records would not display too well --Tony Tony Bandy to...@ohionet.orgmailto:to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074 (Direct) 614-486-2966 x19 From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Kathy Lussier Sent: Thursday, May 28, 2015 2:48 PM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) 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 to...@ohionet.orgmailto:to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074 (Direct) 614-486-2966 x19 -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.orgmailto:kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
I agree that the system supplied parenthetical terms are not useful and in the case of films “added author” is misleading. It’s much more informative to have persons associated with a film have that relationship described in the OPAC display rather than having all simply display as “Added author” as rarely are any authors. We need development so that EG will correctly display the relator terms in subfield ‘e’ as well as the relator codes in subfield ‘4’. Evergreen does not correctly display the relator terms in subfield ‘e’ so it shows these as plain text following the name. Being able to display the terms in subfield ‘e’ would be a huge improvement as more and more RDA records are added with these terms. 700 1\ $a Hermann, Edward, 1943- $e narrator = Hermann, Edward. Narrator (Added author) But 700 1\ $a Hermann, Edward, 1943- $4 nrt = Hermann, Edward, 1943- (Narrator) A corollary to this is the problem that if the 7xx field has multiple subfield ‘4’s only of them displays, the last one. There are cases where a person may be a director, screenwriter, and actor. 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 jschra...@cwmars.orgmailto:jschra...@cwmars.org From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Kathy Lussier Sent: Thursday, May 28, 2015 3:23 PM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?) 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 kluss...@masslnc.orgmailto:kluss...@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 to...@ohionet.orgmailto:to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074tel:614-484-1074 (Direct) 614-486-2966 x19tel:614-486-2966%20x19 -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128tel:%28508%29%20343-0128 kluss...@masslnc.orgmailto:kluss...@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 sar...@zionsvillelibrary.orgmailto:sar...@zionsvillelibrary.org -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.orgmailto:kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
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=authorauthor. (Author).Herrmann, Edward,1943- http://blanchester-training.cool-cat.org/eg/opac/results?query=Herrmann%20%20Edward%201943;qtype=authornarrator. (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 to...@ohionet.org mailto:to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074 (Direct) 614-486-2966 x19 -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-GENERAL] Duplicate entry in authors.tt2 (is this bug 958954?)
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 kluss...@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 to...@ohionet.org OHIONET 1500 West Lane Ave. Columbus, OH 43221-3975 614-484-1074 (Direct) 614-486-2966 x19 -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative(508) 343-0128kluss...@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 sar...@zionsvillelibrary.org
