Evergreen

Bug #939570
Comment #14

Comment 14 for bug 939570

Revision history for this message

Kathy Lussier (klussier) wrote on 2012-03-05:

#14

Although audience was the example I used in my use case, I would like to add that we generally see these as location searches, and that location happens to be a subset of the larger location that is the library branch. If the Hitchhiker's Guide to the Galaxy is moved from the adult collection to the YA collection as part of the Summer Reading program, then we no longer would want to see that title appear in the search results for the adult collection. As Tom mentioned, with centralized cataloging used in our consortia, we do have cataloging staff at many libraries who do not have permission to edit the MARC record since their role is to do copy cataloging. Making those changes at the MARC record level would be complicated.

Overall, I see this as one piece of a larger goal to give libraries more flexibility in how they scope their collections. At a minimum, we need to be able to scope to the branches and to the entire consortium, and we are already doing this by relying on the hierarchy. Many systems are probably happy with these built-in scopes and may just want to continue with this approach, but others may find it to be too rigid. Allowing a system to group together several copy locations is one way to provide more flexibility. Allowing systems to more easily hide redundant org unit levels is another way to provide more flexibility, and ESI is currently working on a project to do so (the specs are available at http://www.esilibrary.com/esi/docs/?p=841 - Greater flexibility in library selector display.) I could see incorporating org unit lassos as another piece to giving consortia greater control over their scopes (not something we're working on, but I can see the benefit of such a project).

I agree that usability could be an issue if you went crazy with copy location groups, but I think each system should be able to decide which scopes work best for them.

As a side note, I also wanted to mention that I personally do not see this as a replacement for the copy location limiters that were available in jspac. When we first issued the RFP for this project, tpac was still in its infancy, and I didn't realize that the copy locations would be removed (actually, I think it's left as a "to do" item in the code.) I still see a use for those more granular limiters (e.g. I'm looking for a book on the solar system for my 3 year old and want to make sure I'm only searching the Picture Book location), but it is probably something more likely to be utilized by a power searcher and therefore belongs on the advanced search page.

Although audience was the example I used in my use case, I would like to add that we generally see these as location searches, and that location happens to be a subset of the larger location that is the library branch. If the Hitchhiker's Guide to the Galaxy is moved from the adult collection to the YA collection as part of the Summer Reading program, then we no longer would want to see that title appear in the search results for the adult collection. As Tom mentioned, with centralized cataloging used in our consortia, we do have cataloging staff at many libraries who do not have permission to edit the MARC record since their role is to  do copy cataloging. Making those changes at the MARC record level would be complicated.

Overall, I see this as one piece of a larger goal to give libraries more flexibility in how they scope their collections. At a minimum, we need to be able to scope to the branches and to the entire consortium, and we are already doing this by relying on the hierarchy. Many systems are probably happy with these built-in scopes and may just want to continue with this approach, but others may find it to be too rigid.  Allowing a system to group together several copy locations is one way to provide more flexibility.  Allowing systems to more easily hide redundant org unit levels is another way to provide more flexibility, and ESI is currently working on a project to do so (the specs are available at http://www.esilibrary.com/esi/docs/?p=841 - Greater flexibility in library selector display.) I could see incorporating org unit lassos as another piece to giving consortia greater control over their scopes (not something we're working on, but I can see the benefit of such a project).

I agree that usability could be an issue if you went crazy with copy location groups, but I think each system should be able to decide which scopes work best for them.