Ability to display notes in public facing OPAC by specific library

Bug #1297838 reported by Elaine Hardy
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Triaged
Wishlist
Unassigned

Bug Description

Wishlist item from the Cataloging Interest Group meeting Evergreen 2014.

In library consortia, local notes (e.g. 590s) specific to an individual library’s copy/item is not generally allowed. We would like the ability to make local notes in the MARC bibliographic record display in OPAC searches scoped to the specific library. We envision this to be similar to the |9 in 856 fields whereby coding within the field creates local notes that would then display only to the system or branch indicated in the field. This would also be valuable to other note fields as well. For example, where different libraries have different use and reproduction rights that could be indicated in a 540 note scoped for an individual library. These notes would be repeatable with in the MARC bibliographic record.

Tags: cat-marc
Revision history for this message
Galen Charlton (gmc) wrote :

MARC21 defines a subfield $5 for various 5XX fields (e.g., the 500, the 540, and others) that specifies the institution to which the note applies. Technically the list is drawn from http://www.loc.gov/marc/organizations/orgshome.html, although it wouldn't be a big stretch to use Evergreen OU shortnames instead.

Any opinion on using the $5 rather than the $9?

Revision history for this message
Yamil (ysuarez) wrote :

I was at this meeting. If I recall correctly, the person that mentioned this wishlist wanted to denote, for example, that their local library copy of a book was signed by the author. There are some other ways to denote this, like using copy notes, but this is still a valid wishlist item.

Revision history for this message
Galen Charlton (gmc) wrote :

Another option would be to not store such notes in the MARC record. Doing this would simplify overlaying bib records, for example, by meaning that you wouldn't have to care about not removing or scribbling over 5XX fields that have a $5 or $9.

There is an existing biblio.record_note table that perhaps could be adapted for this purpose, though it would require work:

[1] It needs a UI to set notes
[2] It needs some sort of type (e.g., 'general note', 'usage note') to be associated with it
[3] It would need to be taught the concept of an owning library.

Revision history for this message
Elaine Hardy (ehardy) wrote :

I am a little hesitant to use the subfield 5 for this since it is for the MARC codes. If changes in MARC format elevates or makes substantial changes to the subfield for some reason, I wouldn't want there to be repercussions we would need to then handle.

I did mention the use of copy notes; however, the consensus of the group were that they were inadequate. Particularly given the break in workflow adding copy notes cause. The interface for adding them is not user friendly. They wonted to be able to retain the note functionality within the MARC record to streamline the process. Which would also be my concern with storing the notes out side the MARC record in any other way as well. It breaks workflow and could make the process more cumbersome.

Catalogers at any library using the proposed functionality would need to be aware that overlaying records would have to take in consideration the notes.

Revision history for this message
Sarah Childs (sarahc) wrote :

I'd vote for improving the copy note function so that it is less cumbersome to use, personally. I have a ton of ideas for that as an alternative. I should probably open up a separate wishlist bug for that, rather than hijacking this one.

Revision history for this message
Sarah Childs (sarahc) wrote :

OK, here's a copy note features wishlist bug. It's a bit of a catchall for copy note improvements.
https://bugs.launchpad.net/evergreen/+bug/1297909

Revision history for this message
Mary Llewellyn (mllewell) wrote :

I know our libraries prefer the local note to be in the bib record itself so that donation notes mentioning civic bodies can be found with a keyword search. Copy notes don't allow this.

Revision history for this message
Laura Horgan (horganl) wrote :

I agree that having the ability to bring information such as local authors up in a search in the catalog is of interest and has been discussed in meetings that I have attended. If the information is added to the bib record can it be protected for that library.
This is the type of information that might not be added to the master record in OCLC and could be lost.

Revision history for this message
Elaine Hardy (ehardy) wrote :

Laura,

You should be able to add 690s to your records for local authors, etc. It is an indexed field or can be added to your indexed fields (although I did just discover our 690s are only retrieving in keyword search but are indexed as subject).

Kathy Lussier (klussier)
Changed in evergreen:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

We have some half-completed code for scoping display of MARC local notes (specifically fields 506, 540, 590, and 690). I am hoping to complete this work and share it upstream in the next few months. The intention is to use subfield $5 as the basis for scoping, although I know that Elaine has expressed concerns about this.

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

I'm planning to have this available for inclusion in 2.10.

Changed in evergreen:
assignee: nobody → Jeff Davis (jdavis-sitka)
Changed in evergreen:
milestone: none → 2.10-beta
Changed in evergreen:
milestone: 2.10-beta → 2.next
Elaine Hardy (ehardy)
tags: added: cat-marc
removed: cataloging editing local marc notes
Changed in evergreen:
assignee: Jeff Davis (jdavis-sitka) → nobody
Changed in evergreen:
milestone: 3.next → none
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.