Tom,

I know the transitory locations like Display is important to some of our
libraries and you make a very good point.  There essentially is a lot of
information stored in shelf locations that I would not want to carry over
into a MARC record for the sake of creating a search index.

Tim

On Mon, Mar 5, 2012 at 7:02 AM, Thomas Berezansky <<email address hidden>
> wrote:

> I am not going to claim to know everything about what this development
> aims to accomplish, but I see multiple potential issues with the MARC
> Record approach compared to the approach Dan brought up. Anyone who does
> know more can chime in and tell me I am wrong.
>
> One of those is loss of data if someone isn't doing a good job editing
> the MARC Record, via merging, overlaying, or manual editing. Perhaps
> even intentional edits along the lines of "No WAY this is supposed to be
> in that category!" regardless of whether or not there is a "who put this
> here" subfield.
>
> A second is transitory locations that people may want to search, like
> "Display" locations, or perhaps "New" or "Popular" locations. Editing
> the MARC every time you move something in or out of these locations
> would be annoying at best, and wouldn't happen at worst. Add to that the
> detail that the staff moving things in and out of these locations may
> not be catalogers, and thus may not have enough knowledge or permissions
> to edit the MARC itself. Furthermore, if two libraries put something on
> Display at the same time, one may wipe out the Display tag when the
> other is still using it, causing the MARC to no longer reflect reality
> in one of the libraries at that point.
>
> A third is that I suspect this is partially intended to replace the
> missing Copy Location limiter from JSPac, which ignored MARC
> designations and showed you what is in that specific location. That
> limiter was built based on scoping rules that don't work in TPac, and
> thus doesn't currently exist in TPac. I don't see MARC information as
> being a suitable substitute for that functionality, personally.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> https://bugs.launchpad.net/bugs/939570
>
> Title:
>  Copy Location Search Groups
>
> Status in Evergreen - Open ILS:
>  New
>
> Bug description:
>  From the included release notes:
>
>  This feature allows staff to create and name sets of copy locations to
>  use as a search filter in the catalog.  OPAC-visible groups will
>  display within the library selector in the template toolkit OPAC.
>  When a user selects a group and performs a search, the set of results
>  will be limited to records that have copies in one of the copy
>  locations within the group.  Groups can live at any level of the
>  library hierarchy and may include copy locations from any parent org
>  unit or child org unit.
>
>  For advanced users, this change includes a new Query Parser filter called
>  location_groups().
>
>  ==
>
>  As it stands currently, copy location groups for a given org unit are
> visible in the TPac org unit selector under the following conditions:
>  - The org is the current search org unit
>  - The org is the current physical location org unit
>  - The org is the logged in patron's home org unit
>  - The org is a parent or child of any of these.
>
>  For example, if you are searching globally, you will see all copy
>  location groups.  If you are searching your home library from within
>  your home library, you will see copy location groups for your home
>  library and any parent org units (and any sub-library org units).
>
>  http://git.evergreen-
>  ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick
>  /copy-location-search-groups
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/939570/+subscriptions
>



-- 

Tim Spindler

Manager of Library Applications

<email address hidden>

508-755-3323 x20


C/W MARS, Inc.

67 Millbrook St, Suite 201

Worcester, MA 01606
http://www.cwmars.org



*P**   Go Green - **Save a tree! Please don't print this e-mail unless it's
really necessary.*