That is not correct. Works. Selections is still valid. What has changed from AACR2 is that Selections can no longer appear alone.
Just a note here: Works. Selections is no longer valid, right?
On Friday, December 6, 2019, Jessica Janecki <[log in to unmask]> wrote:
The important point is that Works. Selections (or Poems. Selections) needs a qualifier at the WORK level. There are multiple selections, and each selection, per RDA is its own aggregate work. Further disambiguation at the expression level might not be needed. It helps to imagine the selecting happening *before* the translation (even if that’s not how it actually happened in real life). For example, there was likely only 1 expression of this particular selection. But, if the exact same selection of content was translated by two different translators, then yes, you would have to add a $s for translator (or something else like date if you didn’t know the translator). There is probably nothing wrong with adding extra expression elements once you’re already at the expression level, but the point is that you don’t have to if there is no conflict at the expression level.
From: Program for Cooperative Cataloging <[log in to unmask]> On Behalf Of Gene Fieg
Sent: Friday, December 6, 2019 2:14 PM
To: [log in to unmask]
Subject: Re: [PCCLIST] [External] Re: [PCCLIST] Qualifiers for "Selections"
Steve, in the second to last citation is Echevarria the translator, publisher?
In a translation wouldn't we still use $l [language] $s [version]?
On Fri, Dec 6, 2019 at 7:03 AM McDonald, Stephen <[log in to unmask]> wrote:
RDA 126.96.36.199 says, “Include additional elements in authorized access points if needed to distinguish the access point for a work.” It does not explicitly prohibit qualifiers if there is no current conflict. It can be argued whether the prohibition is implied. It is LC-PCC PS which explicitly states, “Do not predict a conflict.” This is in keeping with legacy practice.
The Beta Toolkit says something a bit different:
Additional elements and designations in access points for work
Include values for other elements or designations in an access point if required:
· to distinguish the access point from a value of an access point for another entity
· to assist in the identification of the entity
· to conform to a string encoding scheme
So under the Beta Toolkit, LC-PCC would definitely be free to have a policy which requires a qualifier for all work AAPs of conventional collective titles.
Unlike for names, RDA’s general instructions for work access points (6.27.1) lack an Optional Addition that allows for qualifiers in cases where no conflict exists. Compare to, say, RDA 188.8.131.52’s Optional Addition on attaching a fuller form of name to a base heading for identification purposes, not for conflict. (My thanks to Adam Schiff for pointing this out a few years ago.)
Not that this has prevented catalogers from building work access points with extra bells and whistles. There are plenty of 130s in bib records for films where “(Motion picture)” is tethered to very unique titles, some of these also established in the NAF. RDA 2020 for its part is open to such discretionary additions: “Include values for other elements or designations in an access point if required … to assist in the identification of the entity”:
Mark K. Ehlert Alma: NA02
Cataloging and Metadata Librarian Primo: MT NA01
O'Shaughnessy-Frey Library, University of St. Thomas
"Experience is by industry achieved // And perfected by
the swift course of time"--Shakespeare, "Two Gentlemen of
Verona," Act I, Scene iii