[Archivesspace_Users_Group] LCNAF plugin

Wed Apr 12 13:52:03 EDT 2017

Thanks Karen. My comments are below.

Francis

--

Karen Miller k-miller3 at northwestern.edu <mailto:archivesspace_users_group%40lyralists.lyrasis.org?Subject=Re%3A%20%5BArchivesspace_Users_Group%5D%20LCNAF%20plugin&In-Reply-To=%3C82e30afaa16f4ea2b07386fea46a98c4%40evcspmbx05.ads.northwestern.edu%3E>
Tue Apr 11 12:57:21 EDT 2017

Francis, this is great news and I'm very excited by the prospect of getting an updated plug-in! We're doing a lot of editing when using it now, and the changes you have planned will eliminate a lot of that work for us at Northwestern.

-          FL: Excellent! Yes, our goal is that authorities imported via the plugin will require no (or minimal) manipulation after import.

I only have two comments on the mappings.

1.       I'd rather see contents of the 100$d, 110$d, and 111$d go into the Dates of Existence sub-record instead of Name Forms\Date, since the latter is deprecated. I have mixed feelings about this, though - on the one hand, if there is a 046 present, it may include a more granular date than is in the $d, and it would be a shame to lose that. On the other hand, for many records there is no 046 and only a $d. In these cases, it might be possible to extract appropriate date fields from the $d; Gary Strawn (our former authorities librarian, but still at NUL working archival processing), has written some code that was used to create 046 fields from $d when Library of Congress started automatically converting selected records from AACR2 into RDA. He mentioned that he'd be happy to share it, if it's of interest.

-          FL: There is an implicit suggestion in this mapping that deprecation of Name-Forms\Date isn't the correct approach. Here's our thinking: The components of an AS name form are all sub-parts of the access point. If an access point has dates, those dates need to appear in the name form section. Dates that appear in the name form (and part of the access point) aren't necessarily the same as those that represent dates of existence. We may sometimes want to record dates of existence even if dates are not included in the access point. So we need both data elements. This approach parallels what he have in LCNAF, where dates in 1xx $d exist in parallel to dates in 046 - because they mean different things. There is an argument for deriving dates of existence from the dates in the name form (upon import), but our Yale group has opted (so far at least) not to take that option.

2.       I'd also prefer not to strip the terminal periods from 100$, 110$c or 111$c. Although this is listed in your mapping spreadsheet, it does not appear to have been done in the example for the Brown (Family : 1910-1956 : Me.), where the $c is mapped to the Qualifier field as "Me." with the terminal period retained.

-          FL: Yeah, I see the arguments for not stripping those periods. Doing so causes problems with headings such as "$a Seuss, $c Dr." We'll review this.

Finally - and this is just a *thought*, not a suggestion! - at some point in time, it would be wonderful to see the ArchivesSpace Agent record model expanded to accommodate some of the fields that are now being added to name authority records under RDA, such as Fields of Activity, Occupations, Associated Places (including place of birth, place of death, country of residence, headquarters, etc.), Associated Groups, Gender, and Associated Languages. I know this is way, way out of scope for your project, but I thought it might be useful to get it out there and have people start thinking about it. I work in a NACO library where we add loads of information like this to authority record in hopes that it will be used by a discovery system at some point in our lifetimes!

-          FL: I agree! It's my understanding that the AS person model will be modified (before long?) to be compliant with EAC-CPF, providing a richer set of fields, such as those you mention.

FL: In my mind, AS might also benefit by reconsidering its treatment of preferred titles. I'd like to see an AS model that recognizes WEMI entities as a separate category of related entity. For the moment, preferred titles without an author can be mapped well enough to AS Subject, of type "preferred title" - though the AS subdivisions for subjects don't work particularly well for titles. For related works that do have an author, I'm not sure what to do. Smoosh them in to an AS subject too (preferred title)? Otherwise, when linking to a work (as subject), we are left to enter the name as a controlled entry in a resource description, with the title dangling as an uncontrolled subdivision (of type "preferred title")- by which practice we lose benefits of treating the whole name/title as a related entity/authority.

Best regards,

Karen

Karen D. Miller

Monographic Cataloger/Metadata Specialist

Northwestern University Libraries

Northwestern University

1970 Campus Drive

Evanston, IL 60208

www.library.northwestern.edu<http://www.library.northwestern.edu>

k-miller3 at northwestern.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>

874.467.3462

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>] On Behalf Of Lapka, Francis

Sent: Thursday, April 06, 2017 3:23 PM

To: archivesspace_users_group at lyralists.lyrasis.org<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>

Subject: [Archivesspace_Users_Group] LCNAF plugin

As part of a larger project concerning agent and subject records in ArchivesSpace, a group at Yale has drafted changes we'd like to see in the LCNAF plugin (to be coded by a vendor for use at Yale). The spec is outlined here:

https://drive.google.com/open?id=1_Jt0_5_9uuu-YexjfIdzTQEuJo2GjQ88no8WxHBXPlI<https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D1-5FJt0-5F5-5F9uuu-2DYexjfIdzTQEuJo2GjQ88no8WxHBXPlI&d=DwMFAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ&m=zS5homH5OTG72slKBPW59J87PR6_v4APDiUa9YxTyeU&s=JHEsLLF3jpBuJNnrqJ39FTpy_1fhcb0fXh0vcM9WOrU&e=<https://drive.google.com/open?id=1_Jt0_5_9uuu-YexjfIdzTQEuJo2GjQ88no8WxHBXPlI%3Chttps://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D1-5FJt0-5F5-5F9uuu-2DYexjfIdzTQEuJo2GjQ88no8WxHBXPlI&d=DwMFAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ&m=zS5homH5OTG72slKBPW59J87PR6_v4APDiUa9YxTyeU&s=JHEsLLF3jpBuJNnrqJ39FTpy_1fhcb0fXh0vcM9WOrU&e=>>

There are three tabs. Text in red indicates changes to existing performance of the plugin (except for the third tab - where we propose an entirely new mapping for lcgft).

Some of what we propose may not be universally desired (e.g., using the LC authority URI as AS AuthorityID). Other changes probably ought to be incorporated in the LCNAF plugin for all (e.g., don't create separate AS subject *records* for each variant form in an LCSH record).

We welcome your corrections, suggestions, or other thoughts.

Thanks,

Francis

Francis Lapka  *  Catalog Librarian

Dept. of Rare Books and Manuscripts

Yale Center for British Art

203.432.9672  *  francis.lapka at yale.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group><mailto:francis.lapka at yale.edu<http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>>

Francis Lapka  *  Catalog Librarian
Dept. of Rare Books and Manuscripts
Yale Center for British Art
203.432.9672  *  francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170412/5ff72d43/attachment.html>