In regard to things such as related subject APs in personal/corporate name authority records: I would hope that, in the spirit of cooperation and fostering of experimental usage of data, that the policies for NACO authority records can be based on the perceived current and potential value of RDA- and MARC-defined elements, and not on the workflows and workloads of Library of Congress staff. If there are elements that LC does not want to deal with because their system(s) cannot take advantage of them or because their staff don't have time to add them, that is not at all a good reason for PCC policy to exclude them; it's a COOPERATIVE database. However, if LC's system(s) cannot technically support an element (meaning, the system cannot import, store, and/or export the element) that would be the only reason I could understand for not allowing it in a NACO authority record.
Just my two cents...
Kevin M. Randall
Principal Serials Cataloger
Northwestern University Libraries
Northwestern University
www.library.northwestern.edu<http://www.library.northwestern.edu>
[log in to unmask]<mailto:[log in to unmask]>
847.491.2939
Proudly wearing the sensible shoes since 1978!
From: Program for Cooperative Cataloging <[log in to unmask]> On Behalf Of Stephen Hearn
Sent: Wednesday, September 16, 2020 1:45 PM
To: [log in to unmask]
Subject: Re: [PCCLIST] CB merges
I guess my ;point is that RDA gives us more metadata and more type-specified metadata about non-resource entities than we used to have, and that new functionality could be built on it. I'd like to see more experimentation in that direction. The presence of an "Entity attributes":search type in OCLC is a little bit of that, and I've occasionally been able to make practical use of it; but a lot more will be needed to make the case.
For a long time MARC's fixed field data was mostly ignored. Then some bits (e.g., bib 008/35-37, Language) got traction as search result filters and got more attention. Something similar could happen with authority 046 and 3XX and 670 data. For those of us who can't run experiments ourselves, I counsel for advocacy and patience. We're not done yet.
Stephen
On Wed, Sep 16, 2020 at 1:08 PM Young, William C <[log in to unmask]<mailto:[log in to unmask]>> wrote:
My apologies Stephen, but I don’t see your point.
My point was that the idea behind RDA was “Build it and they will come”. I assure you that I am aware of how much extra work RDA authorities creates, as I have created many. But if we don’t have the data, it will not be built. It may not be built anyway, but that has not stopped RDA, which currently has very few practical applications at all.
- Hank
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Stephen Hearn
Sent: Wednesday, September 16, 2020 12:54 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] CB merges
[External Email]
My understanding has been that the exclusion of subject terms from LC name authorities derives more from the "division of the world" at LC between units devoted to descriptive access (and LCNAF) and units devoted to subject access (and LCSH). The appearance of 550 terms in name authorities used to be standard in certain cases, but as subject-term maintenance lagged on the descriptive unit's work, the practice was eventually discontinued to avoid erroneous forms of access in LC authorities, all long before RDA.
As for presidents, we can get a list in OCLC by browse searching the corporate name "United States. President ..." All are included, sorted by the dates of each president's time in office.
One could hope to get a similar result by searching "Occupation term: presidents" filtered by "Associated country: United States", but the proximate result of such a search in OCLC (using "Entity attributes") leaves a lot to be desired (e.g., hits on interlopers based on "374 College presidents"; misses for John Adams, James Buchanan, et alii which lack a 374).
Stephen
On Wed, Sep 16, 2020 at 11:21 AM Young, William C <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Gentle colleagues,
Forgive me if I am mistaken, but I thought the original intent of RDA (when it followed the FRBR model instead of the inane model new RDA advocates) was to provide rich data that “modern” systems could support. For instance, if all the authority records for each of the US Presidents had a subject of Presidents--United states, then someone performing a search for that subject would be able to find resources on individuals who held that office, even if that functionality did not yet exist.
We have spent a LOT of time adding fields to records for individuals tracing things like their date of birth and death as well as the location of these events. We have recorded what Corporate Bodies these people were associated with and their professions. All in the hopes that someday soon we will be able to use that data. So why is this any different? If we are reaching for a system that can use all types of rich data, don’t we need that data to exist? We have already spent a lot of resources doing this with individuals, why the heck would we not do it for corporate bodies? And what if the information was not used by patrons? Is it not useful for the catalogers who come after us?? Are we not users too?
With all due respect, the argument that we should not include these facets sounds to my ear a lot like my least favorite argument “We have always done it this way”.
- Hank
William C. (Hank) Young
Serials Coordinator
George A. Smathers Libraries
University of Florida
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Prochazka, David
Sent: Wednesday, September 16, 2020 11:31 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] CB merges
[External Email]
I quite agree, Bob. I tried getting folks at my institution interested in adding authority records to our keyword indexes, but couldn’t get any traction. Their value isn’t limited to browsing indexes.
David—
David Procházka | Music/Special Materials Cataloger | The University of Akron | Bierce Library 261C | Akron, Ohio 44325-1712 | 330-972-6260 | [log in to unmask]<mailto:[log in to unmask]> | https://works.bepress.com/david-prochazka/<https://urldefense.proofpoint.com/v2/url?u=https-3A__works.bepress.com_david-2Dprochazka_&d=DwMGaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=qq1vy-mEc5dWF5oSJzeo_N2qFHuzTpiDcfOvKM6jWiA&m=DtpX_hnbH4g8-JI8s4U2pvnUhpaZqdr93V8XQbt5Tsc&s=p60r6nMUw6fIu5ZMwpLsQhWfbfrhdvOJj0Akpe7yPg0&e=>
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Robert Maxwell
Sent: Wednesday, September 16, 2020 11:20 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] CB merges
CAUTION: This email originated from outside of The University of Akron.
No one is advocating resurrecting buggy whips, but it has always seemed to me that keyword indexes could be designed to take advantage of the very rich data found in our authority records. As it is most that I know of don’t pay attention to authority records at all. Our keyword searches could very helpfully implement “did you mean?” (based on authority 4XX) or “you might also be interested in” (based on authority 5XX) results if only they would pay attention to the authority records. I’m a browse fan, but it isn’t only about browsing.
This to say nothing of all the other very rich data we’re now adding to authority records (occupations, related locations, related bodies, time periods, etc.) that could hugely enhance the user experience if only it were not ignored by searches. But maybe we could start with integrating 4XX and 5XX into keyword searching.
Bob
Robert L. Maxwell
Ancient Languages and Special Collections Librarian
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Stephen Hearn
Sent: Wednesday, September 16, 2020 9:08 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: CB merges
No, our Alma/Primo public catalog does not display 5XX fields in the browse index (or anywhere else). When 5XX indexing was enabled by Ex Libris, we were not happy with the result of our testing and did not turn it on. But I'm old enough to remember the good sense that 5XX references made in our browsable card catalogs. (For a while at UT Austin my job included typing up the SEE ALSO reference cards.)
The fact that most of our catalogs default to a keyword search rather than browse already calls into question the way our MARC authority format and AACR2/RDA practices are grounded in AAPs and VAPs intended for alphabetically ordered heading lists. To borrow another metaphor, we're making fine buggy whips for traffic that no longer relies on horses.
My memory of our long-ago NOTIS system was that it did manage the trick of turning "110 Later name / 510 $w a $a Earlier name" into "Earlier name SEE ALSO LATER NAME Later name", so I'm convinced it's still possible. But hopefully trying to revive the horse-and-buggy trade is not our best option at this point. We should be looking for ways to index human-friendly labels for searching in coordination with machine-managed links between identifiers to offer expanded and when appropriate, relationally differentiated sets of human-friendly search targets for users of our catalogs.
Stephen
On Wed, Sep 16, 2020 at 8:57 AM Hostage, John <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Our public catalog dances neither in high heels nor backwards. In fact, it doesn’t display 5XX references at all; only 4XX references. For the tiny fraction of users who use the browse indexes.
Stephen, does your system really do all that? It seems like an awful lot of special programming, but it became necessary when we started using 5XX fields for something for which they weren’t intended, in fact for nearly the opposite purpose.
John
From: Program for Cooperative Cataloging [mailto:[log in to unmask]<mailto:[log in to unmask]>] On Behalf Of Stephen Hearn
Sent: Wednesday, September 16, 2020 09:33
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] CB merges
And remember, if our 5XXs get displayed as "see also" references in a public catalog browse index, they use the inverse of the authority record's relationship designator or predicate. To avoid blind references, the use of a term as a 1XX prompts the indexing of the 5XX term as an access point. So, borrowing Adam's first example:
110 2 University of Washington. ǂb Department of Laboratory Medicine
510 2 ǂw r ǂi Mergee: ǂa University of Washington. ǂb Department of Pathology
510 2 ǂw r ǂi Product of merger: ǂa University of Washington. ǂb Department of Laboratory Medicine and Pathology (A)
110 2 University of Washington. ǂb Department of Pathology
510 2 ǂw r ǂi Mergee: ǂa University of Washington. ǂb Department of Laboratory Medicine
510 2 ǂw r ǂi Product of merger: ǂa University of Washington. ǂb Department of Laboratory Medicine and Pathology (B)
110 2 University of Washington. ǂb Department of Laboratory Medicine and Pathology
510 2 ǂw r ǂi Component of merger: ǂa University of Washington. ǂb Department of Laboratory Medicine (C)
510 2 ǂw r ǂi Component of merger: ǂa University of Washington. ǂb Department of Pathology (D)
becomes
University of Washington. Department of Laboratory Medicine
SEE ALSO MERGEE
University of Washington. Department of Pathology
SEE ALSO PRODUCT OF MERGER
University of Washington. Department of Laboratory Medicine and Pathology (derived from C)
University of Washington. Department of Laboratory Medicine and Pathology
SEE ALSO COMPONENT OF MERGER
University of Washington. Department of Laboratory Medicine (derived from A)
University of Washington. Department of Pathology (derived from B)
University of Washington, Department of Pathology
SEE ALSO MERGEE
University of Washington. Department of Laboratory Medicine
SEE ALSO PRODUCT OF MERGER
University of Washington. Department of Laboratory Medicine and Pathology (derived from D)
Like Ginger Rogers, dancing the same dance in high heels and backwards.
Stephen
On Wed, Sep 16, 2020 at 6:41 AM Young, William C <[log in to unmask]<mailto:[log in to unmask]>> wrote:
I may not have recorded the relationship between corporate bodies that have merged, but I have always recorded the names of both of the previous bodies and included the relationship between the two with a note in the 670 field.
Our Authorities Librarian said she could always tell when a serials cataloger created an authority record, because this was something that monograph catalogers never thought of.
- Hank
William C. (Hank) Young
CONSER Coordinator
George A. Smathers Libraries
University of Florida
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Hostage, John
Sent: Tuesday, September 15, 2020 5:01 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] CB merges
[External Email]
Unlike with serials, we have never formally recorded relationships between two bodies that merged (nor two bodies that resulted from a split). Is there any reason to start now?
------------------------------------------
John Hostage
Senior Continuing Resources Cataloger
Harvard Library--Information and Technical Services
Langdell Hall 194
Harvard Law School Library
Cambridge, MA 02138
[log in to unmask]<mailto:[log in to unmask]>
+(1)(617) 495-3974 (voice)
+(1)(617) 496-4409 (fax)
ISNI 0000 0000 4028 0917
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Adam L Schiff
Sent: Tuesday, September 15, 2020 16:53
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] CB merges
Bob,
Here's a real life example that I have been working on: the University of Washington Department of Laboratory Medicine and the Department of Pathology merged on July 1, 2020 to form the Department of Laboratory Medicine and Pathology.
110 2 University of Washington. ǂb Department of Laboratory Medicine
510 2 ǂw r ǂi Mergee: ǂa University of Washington. ǂb Department of Pathology
510 2 ǂw r ǂi Product of merger: ǂa University of Washington. ǂb Department of Laboratory Medicine and Pathology
110 2 University of Washington. ǂb Department of Pathology
510 2 ǂw r ǂi Mergee: ǂa University of Washington. ǂb Department of Laboratory Medicine
510 2 ǂw r ǂi Product of merger: ǂa University of Washington. ǂb Department of Laboratory Medicine and Pathology
110 2 University of Washington. ǂb Department of Laboratory Medicine and Pathology
510 2 ǂw r ǂi Component of merger: ǂa University of Washington. ǂb Department of Laboratory Medicine
510 2 ǂw r ǂi Component of merger: ǂa University of Washington. ǂb Department of Pathology
Splits also present complications and, interestingly, there is no relationship designator to relate the two resulting bodies to each other. There are only designators to relate the earlier name to each of the resulting names and the resulting name to the two earlier names:
The University of Washington Department of Periodontics and Endodontics split into the Department of Endodontics and the Department of Periodontics:
110 2 University of Washington. ǂb Department of Periodontics and Endodontics
510 2 ǂw r ǂi Product of split: ǂa University of Washington. ǂb Department of Endodontics
510 2 ǂw r ǂi Product of split: ǂa University of Washington. ǂb Department of Periodontics
110 2 University of Washington. ǂb Department of Endodontics
510 2 University of Washington. ǂb Department of Periodontics
510 2 ǂw r ǂi Predecessor of split: ǂa University of Washington. ǂb Department of Periodontics and Endodontics
110 2 University of Washington. ǂb Department of Periodontics
510 2 University of Washington. ǂb Department of Endodontics
510 2 ǂw r ǂi Predecessor of split: ǂa University of Washington. ǂb Department of Periodontics and Endodontics
--Adam
Adam Schiff
University of Washington Libraries
________________________________
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> on behalf of Robert Maxwell <[log in to unmask]<mailto:[log in to unmask]>>
Sent: Tuesday, September 15, 2020 12:49 PM
To: [log in to unmask]<mailto:[log in to unmask]> <[log in to unmask]<mailto:[log in to unmask]>>
Subject: Re: CB merges
Some clear examples of real situations in the documentation would be helpful. Adam, do you have a real example in mind and could you show what the designators would be on the authority records (presumably three records in a simple situation, one for each of the two original bodies and one for the resulting merged body)?
Bob
Robert L. Maxwell
Ancient Languages and Special Collections Librarian
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Adam L Schiff
Sent: Tuesday, September 15, 2020 1:33 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: CB merges
Ben,
The way I explain this to people is that the relationship designator always spells out the relationship between the body in the 1XX and the body in the 5XX. It is not used to relate two 5XXs.
So the relationship between the two bodies that merge is reciprocal and "Mergee" is used. The relationship between each of the earlier names to the merged result is "Product of merger" in one direction and "Component of merger" in the other.
Adam Schiff
University of Washington Libraries
________________________________
From: Program for Cooperative Cataloging <[log in to unmask]<mailto:[log in to unmask]>> on behalf of Benjamin A Abrahamse <[log in to unmask]<mailto:[log in to unmask]>>
Sent: Tuesday, September 15, 2020 11:57 AM
To: [log in to unmask]<mailto:[log in to unmask]> <[log in to unmask]<mailto:[log in to unmask]>>
Subject: CB merges
So for all it’s worth I did look at the PCC-List archives because I remembered this coming up before, but the discussion does not seem to have concluded in a definitive way.
I’m trying to figure out how best to handle the merging of two corporate bodies to form a new one. In this case the evidence from the sources is extremely clear (literally a press release saying, “Body A and Body B have merged to form Body C”) so I’m just a little puzzled how to handle the RDA relationship designators.
In Appendix K we have a relationship designator, “Mergee” (reciprocal form: “Mergee”) as well as “Product of merger” (reciprocal form: “Component of merger”). Because it’s not clearly spelled out in the appendix, is the intention here that we should use the first term to relate the two merging bodies to each other, and the second to relate the merging bodies to the new body?
E.g.
Body A
Mergee: Body B
Product of merger: Body C
Body B
Mergee: Body A
Product of merger: Body C
Body C
Component of merger: Body A
Component of merger: Body B
In viewing the archives I found an interesting mention from 2014 that SCT suggested we don’t use “merge” language and instead rely on just “Predecessor” and “Successor”. That was in reference to the PCC Guidelines for the Application of Relationship Designators in NACO Records” but that language no longer seems to appear in the document (as of the 2019 version.)
--Ben
Ben Abrahamse
Metadata Librarian
MIT Libraries
[log in to unmask]<mailto:[log in to unmask]>
--
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
170A Wilson Library (office)
160 Wilson Library (mail)
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID: 0000-0002-3590-1242
--
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
170A Wilson Library (office)
160 Wilson Library (mail)
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID: 0000-0002-3590-1242
--
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
170A Wilson Library (office)
160 Wilson Library (mail)
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID: 0000-0002-3590-1242
--
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
170A Wilson Library (office)
160 Wilson Library (mail)
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID: 0000-0002-3590-1242
