[OPEN-ILS-GENERAL] Evergreen for Academics meeting today
Hi all, Evergreen for Academics has a meeting scheduled today for 2 p.m. Eastern, 11 a.m. Pacific, 19:00 UTC in the #evergreen IRC channel. A draft agenda is available at http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:2014-12-11. Feel free to add additional discussion topics to the agenda. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier
Re: [OPEN-ILS-GENERAL] Improving LC Call Number Displays Behaviors
Thank you for pulling this list together Don! I have a couple of questions/comments. Issue #2 Multiple Suffixes in Volume and Copy Creator The suffix structure is not sufficiently complex to handle LC call numbers that include multiple suffixes such as volume 1, part 1, volume 1, part 2, etc. Currently, the only way to account for these exceptions is to simply include it as part of the text in the Call Number text box. Are you talking about the suffix field here or the parts field? I was thinking the parts field would be the most appropriate place to store the volume/part information. Is there a reason you can't have a part listed as volume 1, part 1 or as volume 1, part 2? Issue #5 No entries found when doing Bib Call Number searches We've had discussions about the bib call number search at various times in IRC, the most recent one being last week when you sent this e-mail. The relevant bug report is at https://bugs.launchpad.net/evergreen/+bug/1074096. The thought was that this search probably works with call numbers stored in the 099 field, but I haven't had a chance to confirm this behavior. If you wanted it to work with another call number field, then I think you would need to adjust the bibcn entry in the config.metabib_field table in the database to point to another field. You would then need to reingest your records to get the call number search working with the new tag(s) However, what I have heard is that many sites (including ours) do not use the bib call number search nor do they really see a need for the bib call number search. For consortia, this makes sense since the individual libraries within the consortium use different call numbers and wouldn't all necessarily be using the same call number that is on the bib record. However, we even had a single, academic institution mention in IRC that they have disabled the bib call number search. There has also been discussion of removing that search from the default install of Evergreen. It would still be there for people who had a need for it, but they would need to customize the numeric search of their catalog to add it. My question for you and anyone else who uses the bib call number search is if there is a need for that search that can't be fulfilled by an asset.call_number search, which is the call number that you add when you are adding volumes/copies to the record. Is it primarily because you dislike the display of the results when doing a Call Number (Shelf Browse) search? If so, I would wholeheartedly support an alternate project that brings about an alternate, text-based display for that search. It's something MassLNC once put out as a possible development project (see http://masslnc.cwmars.org/search/node/call%20number), but ultimately decided not to fund the project. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 12/4/2014 9:01 AM, Donald Butterworth wrote: Colleagues, Another priority that emerged from the Evergreen for Academics survey is Library of Congress Call Numbers displays and behaviors. My assignment is to identify issues. To that end an Evergreen DokuWiki was created entitled Improve LC Call Number Displays Behaviors http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:improved_lc_call_number I have identified 10 issues so far. Please note that the examples, problems and wishlist items listed originate from behaviors in my local 2.6.1 catalog http://evergreen.asburyseminary.edu/eg/opac/browse. Also please understand that we have used Evergreen for less than six months. So there may be some issues listed that are the result of incorrect settings, or some issues may already have been addressed in more recent releases. The Evergreen for Academics group greatly appreciates your feedback. If you have an opinion or comment on any item please share it. If there are issues or outstanding bug reports that you would like to see listed, please email me directly and I will add them to the Wiki. Don -- Don Butterworth Faculty Associate / Librarian III B.L. Fisher Library Asbury Theological Seminary don.butterwo...@asburyseminary.edu mailto:don.butterwo...@asburyseminary.edu (859) 858-2227
Re: [OPEN-ILS-GENERAL] Improving LC Call Number Displays Behaviors
Hi Kathy Issue #2 Multiple Suffixes in Volume and Copy Creator Are you talking about the suffix field here or the parts field? I was thinking the parts field would be the most appropriate place to store the volume/part information. Is there a reason you can't have a part listed as volume 1, part 1 or as volume 1, part 2? My understanding of how suffixes and part designation works is that you can create a suffix v. and then enter a value in part designation 1 Providing a call number like BR 60 .C49 v.1 I don't see how you can create a call number BR 60 .C49 v.1 pt.5 with the current structure. Am I missing something? Issue #5 No entries found when doing Bib Call Number searches We've had discussions about the bib call number search at various times in IRC, the most recent one being last week when you sent this e-mail. The relevant bug report is at https://bugs.launchpad.net/evergreen/+bug/1074096. The thought was that this search probably works with call numbers stored in the 099 field, but I haven't had a chance to confirm this behavior. If you wanted it to work with another call number field, then I think you would need to adjust the bibcn entry in the config.metabib_field table in the database to point to another field. You would then need to reingest your records to get the call number search working with the new tag(s) I'm not sure what all is going on with Bib Call Number Search. I was simply reporting the behavior. However it makes no sense to me why a default setting for this feature would only index locally assigned call numbers instead all LC or Dewey number. My supposition was that Bib Call Number Search should index call numbers from the bib record while the Call Number (Shelf browse) indexes the copy/item record. Personally I only see the need for the Shelf browse. The other seems superfluous, but perhaps I am missing something. I can't recall any other ILS that has two different call number indexes. I would recommend eliminating this option, especially since it returns null results. As an aside, it would make sense to me to include the Call Number (Shelf Browse) option in the Browse the Catalog Browse for: dropdown list. Blessings, Don On Thu, Dec 11, 2014 at 9:09 AM, Kathy Lussier kluss...@masslnc.org wrote: Thank you for pulling this list together Don! I have a couple of questions/comments. Issue #2 Multiple Suffixes in Volume and Copy Creator The suffix structure is not sufficiently complex to handle LC call numbers that include multiple suffixes such as volume 1, part 1, volume 1, part 2, etc. Currently, the only way to account for these exceptions is to simply include it as part of the text in the Call Number text box. Are you talking about the suffix field here or the parts field? I was thinking the parts field would be the most appropriate place to store the volume/part information. Is there a reason you can't have a part listed as volume 1, part 1 or as volume 1, part 2? Issue #5 No entries found when doing Bib Call Number searches We've had discussions about the bib call number search at various times in IRC, the most recent one being last week when you sent this e-mail. The relevant bug report is at https://bugs.launchpad.net/evergreen/+bug/1074096. The thought was that this search probably works with call numbers stored in the 099 field, but I haven't had a chance to confirm this behavior. If you wanted it to work with another call number field, then I think you would need to adjust the bibcn entry in the config.metabib_field table in the database to point to another field. You would then need to reingest your records to get the call number search working with the new tag(s) However, what I have heard is that many sites (including ours) do not use the bib call number search nor do they really see a need for the bib call number search. For consortia, this makes sense since the individual libraries within the consortium use different call numbers and wouldn't all necessarily be using the same call number that is on the bib record. However, we even had a single, academic institution mention in IRC that they have disabled the bib call number search. There has also been discussion of removing that search from the default install of Evergreen. It would still be there for people who had a need for it, but they would need to customize the numeric search of their catalog to add it. My question for you and anyone else who uses the bib call number search is if there is a need for that search that can't be fulfilled by an asset.call_number search, which is the call number that you add when you are adding volumes/copies to the record. Is it primarily because you dislike the display of the results when doing a Call Number (Shelf Browse) search? If so, I would wholeheartedly support an alternate project that brings about an alternate, text-based display for that search. It's something MassLNC once put out as a possible development
[OPEN-ILS-GENERAL] Acq - Copy location UI scoped to registered workstation
Hello all, I apologize for the duplicate email, I sent this to the dev list and it was suggested that I send it to the general list: I couldn't find a bug on this. We are using acq for the first time and I don't want to jump to any conclusions. When creating a PO and assigning the copies to their branches and copy locations, we noticed that the UI only shows the copy locations for the branch that you happen to be registered to. We have a scenario where a single branch is doing all of the PO's for all of the sibling branches. Are we doing something wrong? During some experimenting, I found that if you register the user to the system level instead of the branch level, it will show all of the copy locations for each branch. That, of course, is not a good idea for other reasons. We ruled permissions out by assigning the EVERYTHING^consortium to the user. It seems like if the software allows the copies to be assigned to different branches, it should also allow copies to get assigned to the respective shelving location in that branch. -- -Blake- Conducting Magic MOBIUS
Re: [OPEN-ILS-GENERAL] Improving LC Call Number Displays Behaviors
Hi Don, Some answers inline below. Hi Kathy Issue #2 Multiple Suffixes in Volume and Copy Creator Are you talking about the suffix field here or the parts field? I was thinking the parts field would be the most appropriate place to store the volume/part information. Is there a reason you can't have a part listed as volume 1, part 1 or as volume 1, part 2? My understanding of how suffixes and part designation works is that you can create a suffix v. and then enter a value in part designation 1 Providing a call number like BR 60 .C49 v.1 I don't see how you can create a call number BR 60 .C49 v.1 pt.5 with the current structure. Am I missing something? Our sites put the entire string in the parts field, and I believe most other Evergreen sites do the same thing. However, I'm guessing that the parts information prints all on one line instead of printing in the way you identified above. The feature request, then, may be to support a way to break up that information in spine label printing rather than adding an enhancement to the suffix field. The original intent of the suffix field was not to work together with the parts field. It's not to say it can't be used to serve purposes outside of the original intent, but it's something that some of our libraries use to add some extra information to the call number field that may not be appropriate for the prefix field. Personally I only see the need for the Shelf browse. The other seems superfluous, but perhaps I am missing something. I can't recall any other ILS that has two different call number indexes. I would recommend eliminating this option, especially since it returns null results. I concur with eliminating this option and have added a working branch to do so on the bug at https://bugs.launchpad.net/evergreen/+bug/1074096. Most of the people I spoke to do not use this option, but this opinion has mainly been expressed through IRC discussions rather than list discussions. Is there anyone who objects to removing this option from the numeric search? Kathy Issue #5 No entries found when doing Bib Call Number searches We've had discussions about the bib call number search at various times in IRC, the most recent one being last week when you sent this e-mail. The relevant bug report is at https://bugs.launchpad.net/evergreen/+bug/1074096. The thought was that this search probably works with call numbers stored in the 099 field, but I haven't had a chance to confirm this behavior. If you wanted it to work with another call number field, then I think you would need to adjust the bibcn entry in the config.metabib_field table in the database to point to another field. You would then need to reingest your records to get the call number search working with the new tag(s) I'm not sure what all is going on with Bib Call Number Search. I was simply reporting the behavior. However it makes no sense to me why a default setting for this feature would only index locally assigned call numbers instead all LC or Dewey number. My supposition was that Bib Call Number Search should index call numbers from the bib record while the Call Number (Shelf browse) indexes the copy/item record. Personally I only see the need for the Shelf browse. The other seems superfluous, but perhaps I am missing something. I can't recall any other ILS that has two different call number indexes. I would recommend eliminating this option, especially since it returns null results. As an aside, it would make sense to me to include the Call Number (Shelf Browse) option in the Browse the Catalog Browse for: dropdown list. Blessings, Don On Thu, Dec 11, 2014 at 9:09 AM, Kathy Lussier kluss...@masslnc.org mailto:kluss...@masslnc.org wrote: Thank you for pulling this list together Don! I have a couple of questions/comments. Issue #2 Multiple Suffixes in Volume and Copy Creator The suffix structure is not sufficiently complex to handle LC call numbers that include multiple suffixes such as volume 1, part 1, volume 1, part 2, etc. Currently, the only way to account for these exceptions is to simply include it as part of the text in the Call Number text box. Are you talking about the suffix field here or the parts field? I was thinking the parts field would be the most appropriate place to store the volume/part information. Is there a reason you can't have a part listed as volume 1, part 1 or as volume 1, part 2? Issue #5 No entries found when doing Bib Call Number searches We've had discussions about the bib call number search at various times in IRC, the most recent one being last week when you sent this e-mail. The relevant bug report is at https://bugs.launchpad.net/evergreen/+bug/1074096. The thought was that this search probably works with call numbers stored in the 099 field, but I haven't
Re: [OPEN-ILS-GENERAL] Improving LC Call Number Displays Behaviors
Issue #5 No entries found when doing Bib Call Number searches Speaking of bib call numbers, I wish they weren't included in the keyword index. These can add clutter to search results -- LC subdivisions like SF and TX get in with Science Fiction and Texas searches, and strings of numbers from both Dewey and LC can also match on numbers and dates that are part of the search. I think this is especially confusing because the bib level call numbers are not displayed in the full record (at least not in systems I am familiar with) so the user has no way of understand why a certain record was found when it doesn't appear to have one of the search terms. (Unless of course they are motivated enough to go searching through the MARC, which they aren't.) -- Elizabeth Thomsen, Member Services Manager NOBLE: North of Boston Library Exchange 26 Cherry Hill Drive Danvers MA 01923 E-mail: e...@noblenet.org
