RDA fields for icons, search, and facets

Bug #1125621 reported by James Fournie on 2013-02-14
This bug affects 14 people
Affects Status Importance Assigned to Milestone

Bug Description

This is a bug to discuss support in Evergreen for RDA 336/337/338 fields. These are similar format fields based on non-finalized controlled vocabularies.




It seems to me that these might make sense as entries in config.record_attr_definition table for the index.

It's not clear to me if the codes or terms should be used. In Sitka's production database there is already a mix of useage. For Sitka, the desire is to be able to ingest any RDA record and have it just work, so ideally codes or terms should be possible, but I don't know how this could be accomodated given the current setup of record_attr.

It's not clear to me where a logical place for displaying this information or if it's worth displaying at all, but it may be useful for moving format icons away from the leader among other things.

Ben Shum (bshum) on 2013-02-14
tags: added: rda
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Mary Llewellyn (mllewell) wrote :

I would like to see more specific icons in the OPAC, possibly based on the CMC of the 33x tags (content, media, carrier). It would be more helpful to our patrons to display symbols for a DVD or VHS instead of the generic icon for all videorecordings, to take one example. Tag 007 is one way to identify a specific format, but the new 33x tags offer another avenue.

Revision history for this message
Kathy Lussier (klussier) wrote :

We gave some thought to the use of 33x tags for icons too, but the one concern I had is that any icons based on 33x tags would only display for newer records, not for the thousands of older non-RDA records in our systems. Unless, of course, there is a way we could somehow use both for the display of icons.

Revision history for this message
Dan Scott (denials) wrote :

Coding icons (and user-friendly text labels) based on 33x first, with a fallback to 007, shouldn't be too difficult, actually.

The 33x fields won't be fun to deal with, as they are all repeatable, and their subfields are repeatable as well, but assuming we can handle that, the pseudo-code would look like:

# Try and set the format icon and label by RDA fields
my %format = set_format_by_rda($record);

# Fall back to 007 if we did not get anything back from RDA
if (!exists($format->{label}) {
    %format = set_format_by_007($record);

Of course all of the fun happens in the to-be-defined set_format_by_rda() function :)

Things are complex enough that I think it would make sense for this mapping to occur in the Perl layer rather than as a TT2 macro, but that's getting well ahead of myself...

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

We're soon going to have Backstage Library Works "RDA-ize" our bib records, so the split between new and old records shouldn't be a factor. I am concerned about cases like blu-rays that have the same 33x values as the regular DVDs. We'd definitely need to be able to incorporate the 007 in cases like that.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

It would be useful to add the RDA 347 field, Encoding Format, as well.

I understand that NOBLE has implemented this locally. I'm going to see if I can get them to submit what they've done as an enhancement on this bug.

summary: - RDA 336, 337 338 fields
+ RDA fields for icons, search, and facets
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

copied over from Jennifer Weston's post for bug 1892038 so as to not lose it

Cataloging Working Group would like to investigate ways to create new record attributes using rda fields (example: the 347 field does not currently have an rda definition which could be used for MP3 Audiobooks with item_form=i AND 347$b=MP3)

This will require continued CWG discussion from bug #1835736
From Elaine's wording - This may be a good place to begin a CWG discussion on how to integrate the MARC fields designed for RDA and that drill down specifically and granularly in an items attributes that might be important to user discovery -- anything from fields that define format to those that provide contributor characteristics.

tags: added: cataloging marc
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

After looking at another use case where this functionality would be REALLY useful, Jennifer Weston has agreed to look at documenting the mappings where the RDA fields have controlled vocabularies to put a few more resources at the fingertips of anyone who wants to work on this.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers