webclient: Consistency for terminology in cataloging

[Kathy Lussier]

Starting this bug to track areas where we need a little more consistency in terminology in the sprint 2 (cataloging) interfaces.

Specifically, I was hoping we could get some consensus over copies vs. items, but others may have other terminology they want to add to this bug. Once the latest sprint 2 fixes are merged, we can create a branch to change some of the labels.

The Holdings View Actions menu includes the following actions:

- Add Items to Bucket
- Request Items
- Item Status (list)
- Item Status (detail)
- Item Holds
- Mark Item as Damaged
- Mark Item as MIssing
- Mark Volume as Item Transfer Destination
- Add Copies
- Add Volumes and Copies
- Edit Copies
- Edit Volumes and Copies
- Delete Copies
- Delete Volumes and Copies
- Transfer Copies to Previously Marked Library
- Transfer Items to Previously Marked Volumes

Can we come to a consensus on whether copies or items should be used? Or is there a fine distinction between when copies should be used and when items should be used? For example, a colleague told me today that she uses the word "item" when referring to a unit that combines the volume and copy, but uses "copy" when speaking specifically of a single, barcoded copy without that volume level.

What do you all think?

[Don Butterworth (don-butterworth)]

Personally I prefer the term "Item" for item/copy records. For some reason I tend to think "books" when using the word copy. "Item record" just seems more generic to me for all of the different media types it describes. My 2 cents. -- Don.

[Mary Llewellyn (mllewell)]

I prefer Item as well. This inconsistency has existed in the current client forever and has always bugged me. This is a good moment to course correct.

[Kathy Lussier (klussier)]

I'm going to put forth two arguments in favor of copies:

* Labeling it "copies" in the UI would make it consistent with the name of the asset.copy database table. However, there are other cases where the interface doesn't match the database table (volumes / asset.call_number), so I don't think it's a strong argument.

* Serials has an entity called "items" that are similar to copies, but are not quite the same thing. Using distinct terms for these two entities might be a good thing.

[Rogan Hamby (rogan-hamby)]

I, personally, prefer the term copy as I think it's less ambiguous but,
honestly, I would be perfectly happy with either term being used
consistently.

On Thu, Jan 28, 2016 at 10:33 AM, Kathy Lussier <email address hidden>
wrote:

> I'm going to put forth two arguments in favor of copies:
>
> * Labeling it "copies" in the UI would make it consistent with the name
> of the asset.copy database table. However, there are other cases where
> the interface doesn't match the database table (volumes /
> asset.call_number), so I don't think it's a strong argument.
>
> * Serials has an entity called "items" that are similar to copies, but
> are not quite the same thing. Using distinct terms for these two
> entities might be a good thing.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1538691
>
> Title:
> webclient: Consistency for terminology in cataloging
>
> Status in Evergreen:
> New
>
> Bug description:
> Starting this bug to track areas where we need a little more
> consistency in terminology in the sprint 2 (cataloging) interfaces.
>
> Specifically, I was hoping we could get some consensus over copies vs.
> items, but others may have other terminology they want to add to this
> bug. Once the latest sprint 2 fixes are merged, we can create a branch
> to change some of the labels.
>
> The Holdings View Actions menu includes the following actions:
>
> - Add Items to Bucket
> - Request Items
> - Item Status (list)
> - Item Status (detail)
> - Item Holds
> - Mark Item as Damaged
> - Mark Item as MIssing
> - Mark Volume as Item Transfer Destination
> - Add Copies
> - Add Volumes and Copies
> - Edit Copies
> - Edit Volumes and Copies
> - Delete Copies
> - Delete Volumes and Copies
> - Transfer Copies to Previously Marked Library
> - Transfer Items to Previously Marked Volumes
>
> Can we come to a consensus on whether copies or items should be used?
> Or is there a fine distinction between when copies should be used and
> when items should be used? For example, a colleague told me today that
> she uses the word "item" when referring to a unit that combines the
> volume and copy, but uses "copy" when speaking specifically of a
> single, barcoded copy without that volume level.
>
> What do you all think?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1538691/+subscriptions
>

[Terran McCanna (tmccanna)]

I think about it from a Circ perspective and not a Cataloging perspective, and I think Copy is more intuitive.

But, like Rogan, I'll be happy if it's consistent either way.

[Sarah Childs (sarahc)]

I would be very content with either term, consistently used.

[Jim Keenan (jkeenan)]

I asked our catalogers for their thoughts and this is what they said:

"I prefer the use of *items* instead of copies in all the menu options listed below.

I also prefer the use of *call number* over "volume". I realize that wasn't part of the question and the term 'volume' is an EG standard, however the term 'volume' in general library speak means a book. The call number is what is assigned to a cataloged item and what is printed on a spine label."

Jim

Jim Keenan
Library Applications Supervisor
<email address hidden>
508-755-3323 x23

C/W MARS
67 Millbrook St., Suite 201
Worcester, MA 01606

   Save a tree! Please don't print this e-mail unless it's really necessary.
Currently reading Swansong 1945  by Walter Kempowski.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Sarah Childs
Sent: Monday, February 01, 2016 11:37 AM
To: James Keenan
Subject: [Bug 1538691] Re: webclient: Consistency for terminology in cataloging

I would be very content with either term, consistently used.

--
You received this bug notification because you are subscribed to Evergreen.
Matching subscriptions: EG Launchpad, Launchpad Evergreen
https://bugs.launchpad.net/bugs/1538691

Title:
  webclient: Consistency for terminology in cataloging

Status in Evergreen:
  New

Bug description:
  Starting this bug to track areas where we need a little more
  consistency in terminology in the sprint 2 (cataloging) interfaces.

  Specifically, I was hoping we could get some consensus over copies vs.
  items, but others may have other terminology they want to add to this
  bug. Once the latest sprint 2 fixes are merged, we can create a branch
  to change some of the labels.

  The Holdings View Actions menu includes the following actions:

  - Add Items to Bucket
  - Request Items
  - Item Status (list)
  - Item Status (detail)
  - Item Holds
  - Mark Item as Damaged
  - Mark Item as MIssing
  - Mark Volume as Item Transfer Destination
  - Add Copies
  - Add Volumes and Copies
  - Edit Copies
  - Edit Volumes and Copies
  - Delete Copies
  - Delete Volumes and Copies
  - Transfer Copies to Previously Marked Library
  - Transfer Items to Previously Marked Volumes

  Can we come to a consensus on whether copies or items should be used?
  Or is there a fine distinction between when copies should be used and
  when items should be used? For example, a colleague told me today that
  she uses the word "item" when referring to a unit that combines the
  volume and copy, but uses "copy" when speaking specifically of a
  single, barcoded copy without that volume level.

  What do you all think?

To manage notifications about this bug go to:
https://bugs.launchpad.net/evergreen/+bug/1538691/+subscriptions

[Andrea Neiman (aneiman)]

"Item" is consistent with the FRBR concepts of Work/Expression/Manifestation/Item, and it's what I personally tend to use.

However, as others above, I would be happy with either item or copy as long as it's used consistently.

Also +1 to Jim's thoughts about volume vs. call number, labelling this "volume" has always struck me as something that may be confusing to an end user (though TBH I've had no specific complaints about it). I'm sure there's logic behind calling it "volume" that I haven't thought of.

[Jennifer Pringle (jpringle-u)]

At Sitka (BC Libraries Cooperative) we're +1 for consistency whether it's items or copies.

Adding to Kathy's arguments for copies, acquisitions has line items which are different from items. Acq also uses the term copies to refer to actual copies/items.

[Elaine Hardy (ehardy)]

While I slightly prefer items over copies, it doesn't matter which term as long as it is consistently applied across all menus in Evergreen. Item is used in other menus and places -- the circ menu uses item and never copy, the Actions for Selected Items menu in Item status uses item rather than copy (even referring to item bucket rather than copy bucket), patron records have an Items out tab and an Actions for Selected Items menu. Then we have copy buckets, copy id, copy location, and copy number. I probably have missed some since I didn't do an exhaustive search.

Which ever term is picked, all labels in all visible menus referring to copy/item should use the same term.

Another inconsistent usage is Document/Database ID. At one point, it was also called record ID but I don't see that usage anywhere. I actually prefer the record ID term since it seems more consistent with naming for other IDs -- patron, copy, circulation, hold, etc.

There is a slight distinction between Call number and volume -- probably dating back to the time when we entered the volume designations in separate subfields from the |a class and |b item number (the call number) in 050 and 090. In this context, the call number is 814.5 Web and volume would be 814.5 Web V.1, pt. 5, sect. 6. I see them as separate, but similar concepts.

[Dan Wells (dbw2)]

I mostly agree with Don, et al.

I think "Copy" is somewhat more natural for describing media (i.e. 95%+ of what we circ), but falls pretty flat for the other 5%. You wouldn't often talk about "copies" of puppets, e-readers, rooms, etc. (or at least I wouldn't). I think there might also be a subtle distinction for multi-piece works, such that (in general vernacular) a three volume set might be one "copy" but three "items".

On the other hand, "Item" is somewhat less natural for typical media, but generally much better for the rest.

Overall, I slightly prefer Item, particularly for the staff interfaces. The patron UI may need a more subtle approach to find the best wording case-by-case.

-Dan

P.S. I wouldn't worry too much about conflicting with serial items. Nobody has ever particularly liked that name, and if it became a problem, I'd rather change *that* name than have it affect this decision. :)

[Josh Stompro (u-launchpad-stompro-org)]

I prefer "items" but that is just because it is what our staff are used to from our previous system. It bugs me that it won't be consistent with asset.copy, but most people won't have to deal with that so it probably isn't a big deal. <joke>Or we can just rename that table, no big deal, right?</joke> Would this extend to changing copy level holds to item level holds.. and would that include changing "C" to "I" for the hold type code?

So to summarize what others have written so far. I think everyone is for consistency one way or the other.

- Copy vs Item -

Dan Wells - Item
Elaine Hardy - Item
Jennifer Pringle - Copy
Andrea Neiman - Item
Jim Keenan - Item
Terran McCanna - Copy
Rogan Hamby - Copy
Kathy Lussier - Copy
Mary Llewellyn - Item
Don Butterworth - Item
Josh Stompro - Item

+7 for Item
+4 for Copy

Do we need to ask for more input on the general list for this, or is this enough votes?

Do we want to try and identify the other terms that should be standardized also and just ask for input once, or make each one its own ticket?

Others that were mentioned are
Volume vs Call Number
Record ID vs Database ID for the BRE.id number.

Also, there should be a standard for pluralization. If the menu is named "Actions for Selected Items" then the menu options should all be pluralized. Right now I see a mix of "Mark Item Damaged" vs "Renew Items" for example. Although maybe it is redundant to say Item/Items. Just say "Mark Damaged" "Renew" "Mark Lost" "Request/Place Hold" "Check-in".

Josh

[Mike Rylander (mrylander)]

I'm all for making the UI labels consistent, but please leave hold type codes alone. While they do leak out today, the really should not. The fix for those is to provide a label, either as a separate table in the database /a la/ hold cancel causes, or just in the UI via translation strings or the like.

The first and most obvious problem with changing hold type C to hold type I is that hold type I already exists, for issuance holds.

[Jennifer Pringle (jpringle-u)]

The terms item and copy both continue to be used in 3.1.

Example:

Holdings View
Actions -> Add -> Copies
Actions -> Add -> Volumes and Copies
Actions -> Edit -> Copies
Actions -> Edit -> Volumes and Copies
Actions -> Delete -> Copies
Actions -> Delete -> Volumes and Copies

Item Status
Actions -> Add -> Items
Actions -> Add -> Volumes and Items
Actions -> Edit -> Items
Actions -> Edit -> Volumes and Items
Actions -> Delete Items

[Kathy Lussier (klussier)]

I have a working branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1538691-items-not-copies that attempts to change most instances of copies to items since that seemed to be the majority opinion on this bug.

With this branch, we now have item buckets, item tags, item notes, item alerts, etc. I avoided changing the terminology when it was used for 'copy locations.' I think the copy location vs. shelving location (vs. item location?) discussion should be part of another bug.

I loaded the branch on the VM at https://mlnc2.noblenet.org/eg/staff. The login is admin / evergreen123.

I also started work on a similar branch that does the opposite. My general impression is that, currently, we tend to use 'copy' more than 'item' in the client, and changing everything over to item would be a larger change than if we changed everything to copy.

I wonder if we should put a survey out to the community on this terminology rather than relying on the input we received on the bug.

The first question could be whether users believe this terminology should be consistent. Perhaps a majority of people are okay with making these two terms interchangeable. We could then ask folks which term they prefer.

[Kathy Lussier (klussier)]

I also have a git branch that does the opposite, changing everything over to copies. http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1538691-copies-not-items

The branch is loaded on the VM at https://mlnc3.noblenet.org/eg/staff/. Admin login is admin / evergreen123.

In the latest branch, I did not change the instances of 'item' used in serials or acq because, if I remember correctly, an item in serials is a little different from a copy. In acq, most instances of 'item' were referring to lineitems. I also kept the term 'item type' as is as well as in cases where we seem to be referring to a grid 'item' (i.e. row), rather than a copy.

As was the case with the last branch, there were some cases where the change seemed a little strange, such as with the 'Copies Out' tab in the patron record. However, I guess we would eventually get used to these new names once the changes are in place.

I'm sending an email to the general list to share ideas for a plan to come to a consensus on these terms.

[Kathy Lussier (klussier)]

Adding a note that in this e-mail thread - https://markmail.org/message/4c2lxtisv2w37lj3 - there was a general consensus that the term 'holdings' should be used when referring to something that might include a combination of items/copies and volumes/call numbers.

As an example, "Add Holdings" from the record page, which is used to add copies and volumes.

[Kathy Lussier (klussier)]

Adding a link to the results of the community survey at https://docs.google.com/document/d/1QJvFO3aSlMOIzf5JsONddis8SwwbNPFp3WQLQJ2FYGs/edit

The overwhelming consensus was that we consistently use one term to describe items/copies and shelving locations/copy locations. Although not as overwhelming, a significant majority also indicated that we should consistently use the same term for call number/volume.

I have created a collab branch as a first attempt at updating these terms:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/kmlussier/lp1538691-more-consistent-terminology-in-staff-client

I have also loaded the branch on a test server at https://mlnc1.noblenet.org/eg/staff/
Login is admin / evergreen123.

I'm sure there are places where I an update may not have been needed or places where I missed a replacement. In particular, there were some places where I struggled with the use of call number of holding.

I tried to use holding whenever we referred to copies and volumes, such as the 'Add Holdings' actions on the record page. However, there are places, such as the holdings view, where we have actions that look like this:

- Add
  - Items
  - Call Numbers
  - Call Numbers and Items

In this case, where there are add items and add call numbers options immediately preceding the next option, I thought it was more clear to the user to call it 'Call Numbers and Items" rather than Holdings. In this respect, we continue to have some inconsistency, since we use 'Add Holdings' in interfaces where this is the only action available for adding items/call numbers to a record.

In the volume/copy editor (now called holdings editor), we used to have Hide Volume/Copy Details button that hides the area with call number details, barcodes and parts. I renamed it Hide Holdings Details, but this feels wrong since we are still showing item-specific information.

Anyway, I welcome any feedback to the current implementation or updates to the collab branch.

[Beth Willis (willis-a)]

Thanks for listing the options in a consistent order on the Actions menu(!):

Call Numbers
Items
Call Numbers and Items

[Kathy Lussier (klussier)]

Adding a note to myself that I missed replacing 'volume hold' on the catalog record page.

[Dan Wells (dbw2)]

This looks good on an first pass through, going to keep poking around a bit, but plan to push this in for the RC (pending approval from Bill).

[Dan Wells (dbw2)]

Things still look good to me after a rebase to master and reinstall.

So, after a few communication foibles due to my inability to understand Freenode's new security, I finally heard back from Bill, who gave the green light on this. Now, we recognize that this may cause some consternation to translators, and I am doing what I can to communicate this change and offer any help I can, but we didn't feel there would be a better time to push forward on this (other than 3 weeks ago, of course). Also, since we do ongoing translation updates for releases now, this isn't *as* big of a deal as it has been in the past.

Nonetheless, if there is a lot of pushback, Bill also mentioned he's willing to delay the RC a bit to compensate.

In any case, thank you Kathy! Pushed to master.

[Christine Burns (christine-burns)]

New reference to "Volume" added in Evergreen 3.3

Admin -> Server Admin -> Call Number Prefixes -> Call Number/Volume Prefix Configuration

Button = New Call Number/Volume Prefix

Volume should be removed.

Should I report this as a new bug / regression?

[Jane Sandberg (sandbergja)]

Good catch, Christine! I think a new bug would be great.