Consider including ISBN in Copy/Item records

Bug #1203868 reported by Don Butterworth
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Wishlist
Unassigned

Bug Description

This may be pushing the envelope, especially since no other ILS that I know of does this, but it has always seemed like a good idea to me to include the ISBN, when it is available, in the copy/item record. Often there are multiple ISBNs on a bibliographic record; for hard copy, paperback, electronic, Volume number, Part number, etc. Including the ISBN would be a means of indicating the exact copy owned. (e.g. a hardback version of volume 4) Having this information could be helpful in establishing replacement costs. It might be used as part of the order process to tell a vendor exactly what format and volume number you wish to purchase. If indexed, it could be used run precise reports of the volumes/copies were owned by an Org Unit.

Revision history for this message
Ben Shum (bshum) wrote :

Not sure I entirely understand what's being wished for here. I always thought ISBN was specific to the record and all related copies attached and not different per copy...

Marking incomplete wishlist pending further discussion by catalogers who can help explain this procedure and wishlist item.

tags: added: cataloging
Changed in evergreen:
status: New → Incomplete
importance: Undecided → Wishlist
Revision history for this message
Don Butterworth (don-butterworth) wrote : Re: [Bug 1203868] Re: Consider including ISBN in Copy/Item records
Download full text (4.0 KiB)

Hi Ben,

Let me give a bit more detail to the issue.

In United States cataloging land it is standard practice to create a single
MARC record that describes a multi-volume "set". For example: *The handbook
of family psychology and therapy* is a two volume set with just one MARC
record. On that MARC record there are two ISBNs: 9780256034875 (v. 1) and
9780256034882 (v. 2) that identify the individual volumes and which could
be directly related to the Evergreen Copy/Item Records. Volume 1 costs $50
and volume 2 costs $65.

Now in this example there are only 2 volumes and the ISBNs for all of the
volumes in the set are accounted for on the MARC record, but there are
other titles where volumes never get all of their ISBNs added. This is
particularly true in the case of a Serial/Periodical title that has an ISSN
that describes the set, but also includes an ISBN on each new issue
published.

Also it is standard practice for a single MARC bibliographic record to
describe a monograph that includes both a hardback and a paperback edition.
Example: *Your defiant teen* 9781593855833 (pbk. : alk. paper)
9781593855840 (hardcover : alk. paper) In this example our library has both
the hardback and the paperback but nothing on the Copy/Item record
indicates that fact.

"So what", you say ;-)

There are two issues. The first has to do with acquisitions. When a MARC
record has an ISBN for a "set", we can easily order from a vendor using
that ISBN and get all of the volumes. However when the MARC record only
lists ISBNs for each individual volume, it creates a problem. It is not
uncommon for us to receive multiple copies of Volume 1 of a set because
currently what gets ordered is derived from the first ISBN listed on the
MARC record. If ISBN numbers could be attached to each item record, and
those numbers used to create the order record, the problem would be solved.

Second, in the case of hardback/paperback, lets say a copy of *Your defiant
teen* is lost by a patron. We want to charge them for a replacement copy,
but have no way of knowing if we should charge them a hardback price or a
paperback price.

I hope that all makes sense. Please feel free to contact me for even more
details.

Blessings,

Don

On Wed, Nov 6, 2013 at 2:55 PM, Ben Shum <email address hidden> wrote:

> Not sure I entirely understand what's being wished for here. I always
> thought ISBN was specific to the record and all related copies attached
> and not different per copy...
>
> Marking incomplete wishlist pending further discussion by catalogers who
> can help explain this procedure and wishlist item.
>
> ** Tags added: cataloging
>
> ** Changed in: evergreen
> Status: New => Incomplete
>
> ** Changed in: evergreen
> Importance: Undecided => Wishlist
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1203868
>
> Title:
> Consider including ISBN in Copy/Item records
>
> Status in Evergreen - Open ILS:
> Incomplete
>
> Bug description:
> This may be pushing the envelope, especially since no other ILS that I
> know of does this, but it has always seemed like a good idea to me to
> include the...

Read more...

Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

I'm going to say that I disagree with this. ISBNs should be on the bibliographic level, not item. If items with separate ISBNs need to be connected as peer bibs.

Revision history for this message
Don Butterworth (don-butterworth) wrote :

Rogan,

I am not suggesting that ISBNs be excluded from the Bib record. Perish the
thought. They are need there to find the right Bib record. The problem is
insuring that the right volume is ordered. It is my contention that orders
for a specific volume need to be done at the copy/item level not at the Bib
level.

   - It is a not an uncommon occurrence to order volume 1 twice (when you
   really want volume 2), because the bib record has the ISBN for volume 1
   listed first on the bib record, which is then picked up by acquisitions.
   - It is not an uncommon occurrence to order a hardback twice (when you
   really want the paperback), because the bib record has the ISBN for
   hardback as the first entry listed, which is then picked up by acquisitions.

This could all be avoided if acquisitions was pulling from the copy record
data when ordering a specific copy.

Don

On Wed, Nov 8, 2017 at 10:50 AM, Rogan Hamby <email address hidden> wrote:

> I'm going to say that I disagree with this. ISBNs should be on the
> bibliographic level, not item. If items with separate ISBNs need to be
> connected as peer bibs.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1203868
>
> Title:
> Consider including ISBN in Copy/Item records
>
> Status in Evergreen:
> Incomplete
>
> Bug description:
> This may be pushing the envelope, especially since no other ILS that I
> know of does this, but it has always seemed like a good idea to me to
> include the ISBN, when it is available, in the copy/item record. Often
> there are multiple ISBNs on a bibliographic record; for hard copy,
> paperback, electronic, Volume number, Part number, etc. Including the
> ISBN would be a means of indicating the exact copy owned. (e.g. a
> hardback version of volume 4) Having this information could be helpful
> in establishing replacement costs. It might be used as part of the
> order process to tell a vendor exactly what format and volume number
> you wish to purchase. If indexed, it could be used run precise reports
> of the volumes/copies were owned by an Org Unit.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1203868/+subscriptions
>

--
Don Butterworth
Collection Management Librarian /
Faculty Associate
B.L. Fisher Library
Asbury Theological Seminary
<email address hidden>
(859) 858-2227

Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

The original request seems to have been based on combining multiple formats on single record then wanting to distinguish format on the copy level. Given that this would be a feature request and it has been four years since the last update and is still incomplete with no clear functionality request I am going to mark it as won't fix. I would recommend that if this is re-filed it be done with a more complete functionality request including how this would impact things like searching by format and how that would be tracked to a copy level.

Changed in evergreen:
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.