Print

Print


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]>
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]> *On
> Behalf Of *Stephen Hearn
> *Sent:* Wednesday, September 16, 2020 12:54 PM
> *To:* [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]>
> 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]> *On
> Behalf Of *Prochazka, David
> *Sent:* Wednesday, September 16, 2020 11:31 AM
> *To:* [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] | 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]> *On
> Behalf Of *Robert Maxwell
> *Sent:* Wednesday, September 16, 2020 11:20 AM
> *To:* [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]> *On
> Behalf Of *Stephen Hearn
> *Sent:* Wednesday, September 16, 2020 9:08 AM
> *To:* [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]>
> 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]] *On Behalf Of *Stephen Hearn
> *Sent:* Wednesday, September 16, 2020 09:33
> *To:* [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]>
> 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]> *On
> Behalf Of *Hostage, John
> *Sent:* Tuesday, September 15, 2020 5:01 PM
> *To:* [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]
>
> +(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] <[log in to unmask]>] *On Behalf Of
> *Adam L Schiff
> *Sent:* Tuesday, September 15, 2020 16:53
> *To:* [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]> on
> behalf of Robert Maxwell <[log in to unmask]>
> *Sent:* Tuesday, September 15, 2020 12:49 PM
> *To:* [log in to unmask] <[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]> *On
> Behalf Of *Adam L Schiff
> *Sent:* Tuesday, September 15, 2020 1:33 PM
> *To:* [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]> on
> behalf of Benjamin A Abrahamse <[log in to unmask]>
> *Sent:* Tuesday, September 15, 2020 11:57 AM
> *To:* [log in to unmask] <[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]
>
>
>
>
>
>
> --
>
> 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