Thanks for the feedback everyone! We certainly can tackle the call number / volume issue on the survey, though I suspect I know where the votes will fall on that question.
>From Dan: As we do so, we should also keep in mind how these labels overlap and > interact. Otherwise, we might paint ourselves into a corner if by deciding > to replace every X with Y, when some of the X was really Xa or Xb. Yes, I agree that this could be a problem. As I was creating the branch, I tried to be cognizant of context as I changed the labels. If we decide to go with a preferred term, I think it would beneficial if a few people gave the branch additional scrutiny to see if there are places where there is a valid reason for not changing the term. >From Jennifer: If we stick with item (which implies copy, call number, and barcode), that > keeps it very simple. Copies has the implication of multiple copies of > a title of a book, whereas we mean more than that in most systems because > we will have different kinds of physical things attached to one MARC > record. Using the term ‘items’ keeps it most generic. I disagree with the idea that item implies copy, call number and barcode. IMO, we are choosing the best term to describe what lives in the asset.copy table, which certainly could be a physical thing rather than a copy of a book, but is not the same thing as a call number, which can contain multiple items/copies, or a barcode, which is an identifier for that item/copy. We need to be very precise in what we call these entities in the client. When we are referring to a call number, we should say call number (or volume). I like Dan's approach of using 'holdings' when we need some way to refer to a group that can contain items/copies and/or call numbers. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org On Wed, Aug 8, 2018 at 12:07 PM, Walz, Jennifer <jlw...@asbury.edu> wrote: > All – > > > > I would prefer the ITEM and ITEM LOCATION designators – and consistency > across all functions / buttons / screens / views etc would be very welcome. > > > > As Dan and Lynn point out below, there have been VAST inconsistencies and > also problems with function. If we stick with item (which implies copy, > call number, and barcode), that keeps it very simple. Copies has the > implication of multiple copies of a title of a book, whereas we mean more > than that in most systems because we will have different kinds of physical > things attached to one MARC record. Using the term ‘items’ keeps it most > generic. > > > > Thanks! > > > > Jennifer > > > > *From:* Open-ils-general [mailto:open-ils-general-bounc > e...@list.georgialibraries.org] *On Behalf Of *Daniel Wells > *Sent:* Tuesday, August 07, 2018 6:52 PM > *To:* Evergreen Discussion Group > *Subject:* Re: [OPEN-ILS-GENERAL] Towards more consistent terminology in > the web client > > > > > > As for the "Add Volumes" vs "Add Copies", the problem there was that the > omnibus branch created an "Add Volume" menu entry within the holdings view > which did exactly that, add an empty "volume" (call number) with no copy. > It felt like bad design to have this menu entry for "Add Volume" which only > added the call number while also having an "Add Volumes" button which added > both the call number and the copy. An early revision, for maximum clarity, > relabeled the record-level button to "Add Volumes and Copies", but a long > button label such as that brings its own challenges. It was then reasoned > that "Add Copies" in some sense implicitly means (at the record level) "Add > (Volumes and) Copies", since you can't have the second without the first. > And thus the current label was born. > > > > Sincerely, > > Dan > > > > On Tue, Aug 7, 2018 at 5:40 PM, Lynn Floyd <lfl...@andersonlibrary.org> > wrote: > > I came up with another terminology that should be looked at Call Number > vs. Volume. There are lots of places where these terms are used > interchangeably. > > > > Lynn Floyd > > lfl...@andersonlibrary.org > > Anderson County Library > > Anderson, SC > > > > >
