[Archivesspace_Users_Group] LCNAF mapping -- AuthorityID & Sort Name
Cyndi Shein
cyndi.shein at unlv.edu
Tue Jan 9 15:10:38 EST 2018
Hi Francis and all,
We're delighted to have direction for these agent fields. Thank you to all
who have been thinking about this and moving things forward. After some
discussion, UNLV would like to voice support for the suggested changes to
the sort field and the Authority ID, advocating for their addition to the
core code.
At UNLV we have been entering the full string (actionable link) for URIs.
We made this decision three years ago when no one on the listserv or at
ASpace was able to provide direction. At the time, it occurred to us that
we could enter just the ID and let the drop-down for the source of the ID
(NACO, AAT, ULAN, etc) trigger automated generation of that source's prefix
for an actionable link. We opted to go with the full string, knowing we
can do a global find and replace behind the scenes in the event that a
source body changes its prefix.
Brian's point is, however, something to consider. Times change. Sample
EAC records (from 2010) on EAC's official website
<http://eac.staatsbibliothek-berlin.de/examples-for-the-eac-cpf-schema-2010/>
point to http://lccn.loc.gov/ rather than to http://id.loc.gov/authorities/
names/
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0>
Again, updates of this type could be made behind the scenes with a global
find and replace.
Will John's suggestion to have two fields for IDs (one truncated and one
full/actionable) align with EAC-CPF's future direction? The simple ID
number and the full string are both included and tagged separately in some
(ancient) sample EAC records. It is a little more work to enter the data
twice...
As the options for sources of Authority ID URIs expand the options in
ArchivesSpace's future (thinking of SNAC and other (as yet undreamed of)
specialized sources that may develop in the world of linked data) is there
potential for the IDs across different sources to be duplicates?
For example, in ULAN, the full string for Ansel Adams is
http://vocab.getty.edu/ulan/500026108
. Obviously, that number alone is not a unique identifier outside the ULAN
system. I realize LC name IDs are preceded by an "n" and that the number of
digits in LC and ULAN IDs differ, etc... but potential duplication is
something to be wary of.
By including the URI's full string, we stand a better chance of getting a
truly unique ID as more sources
for LD authorities become available.
Finally, at UNLV we do map the dates in the Names Form field directly to
the LC/NACO heading (even if the LC date is incorrect). We also use the
Dates of Existence field, where we enter more complete dates when known.
Both date fields are very useful for different reasons. We are in favor of
retaining both.
Cyndi Shein
Head, Special Collections and Archives Technical Services.
On Mon, Jan 8, 2018 at 1:11 PM, Rees, John (NIH/NLM) [E] <
reesj at mail.nlm.nih.gov> wrote:
> How about adding to the core a separate URI field for the full string?
>
>
>
>
>
> John P. Rees
>
> Archivist and Digital Resources Manager
>
> History of Medicine Division
>
> National Library of Medicine
>
> 301-827-4510 <(301)%20827-4510>
>
>
>
>
>
>
>
> *From:* Brian Thomas [mailto:bthomas at tsl.texas.gov]
> *Sent:* Monday, January 08, 2018 1:02 PM
> *To:* 'Archivesspace Users Group' <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID &
> Sort Name
>
>
>
> Thank you for your continued work with this plug-in. I like the sort name
> idea.
>
>
>
> But…I am concerned about directly embedding a URI when we have the
> authority number as the UUID. I doubt the authority id will change, but it
> is always possible that the URI information preceding or trailing the
> authority ID will be modified for some reason. I used to think URIs were
> persistent, but lately I’ve come across systematic changes with websites
> that invalidate good urls and require manual intervention to get working.
>
>
>
> My thought process is that: if we just key off the authority UUID, with
> the appropriate source specified from the drop-down menu, the underlying
> code can compile and potentially create the authority URL from the latest
> known URI structure for synchronization/ead export. That way, if a change
> becomes necessary, one part of the application gets changed instead having
> to batch alter potentially thousands of cells in a database.
>
>
>
> Just my two cents.
>
>
>
> Brian Thomas
>
> Electronic Records Specialist
>
> Texas State Library and Archives Commission
>
> 1201 Brazos Street
>
> Austin, TX 78701
>
> PH: (512) 475-3374
>
> e-mail: bthomas at tsl.texas.gov
>
> tsl.texas.gov
>
> [image: cid:image001.jpg at 01D029A2.37194C70]
>
>
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Lapka,
> Francis
> *Sent:* Monday, January 8, 2018 10:30 AM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] LCNAF mapping -- AuthorityID &
> Sort Name
>
>
>
> In April 2017, I asked for thoughts on changes that Yale would like to see
> in the AS LCNAF plugin (see below).
>
>
>
> We are now working with Lyrasis to implement some of these changes. Where
> appropriate, some changes may be made in the AS core code for MARC mapping
> (e.g., in mapping dates of existence). Other changes that Yale would like
> to see may be implemented in a local variation of the LCNAF plugin.
>
>
>
> For two of Yale’s desired changes, it’s unclear whether the modification
> should be made to the core code or as a local modification of the plugin.
>
>
>
> 1. *AuthorityID*: For imports from LC, Yale would like to populate the
> AuthorityID field with the URI for the entity rather than the MARC 010
> value. For example, http://id.loc.gov/authorities/names/n79060712
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fn79060712&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=5%2BTrWSz%2B%2B8JceUh7XeSFRiGJFvxFmTU%2BLjkfdAS0ocg%3D&reserved=0>
> instead of *n79060712*. We assume the URI will be more useful, lending
> itself to LD applications *and* enabling the synchronization feature
> that is envisioned in the specification for the AS expanded agent model.
>
>
>
> 1. *Sort Name*: For imports from LC, *do not* automatically generate a
> sort name. Instead, map to Sort Name by taking the authorized form exactly
> as it appears in the MARC 1xx field, minus the MARC subfield syntax. We
> think this is the most straight-forward way to always get the exact LC
> authorized form, properly ordered and properly punctuated (auto generate
> has trouble with order/punctuation in some of the more complex headings,
> e.g.: http://id.loc.gov/authorities/names/no2013064755.html
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fauthorities%2Fnames%2Fno2013064755.html&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=skTEFgQb%2BPh4XDKkl4e68YGMMbS3WCwfeBEZJcK0iXE%3D&reserved=0>
> )
>
>
>
> I’d appreciate your thoughts on these two issues.
>
>
>
>
>
> Thanks,
>
> Francis
>
> (on behalf of a Yale working group)
>
>
>
>
>
>
>
> Francis Lapka · Catalog Librarian
>
> Dept. of Rare Books and Manuscripts
>
> Yale Center for British Art
>
> 203.432.9672 <(203)%20432-9672> · francis.lapka at yale.edu
>
>
>
>
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Christine
> Di Bella
> *Sent:* Wednesday, April 12, 2017 3:31 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] LCNAF plugin
>
>
>
> This is really wonderful work and discussion. Thank you all for these
> efforts!
>
>
>
> I wanted to mention a few things related to ongoing ArchivesSpace
> development and a few of the points in the discussion.
>
>
>
> - There are several related JIRA issues related to the Dates/Dates of
> Existence issue specifically: https://archivesspace.
> atlassian.net/browse/AR-1322
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1322%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DeLenPqaNOmyv-Ci_ujGLdGYiGv1GTOBwiTmo7ikbtCQ%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=g9E0asqNYTbFU3sMCLx9yMDDU2g8ZSPesXrCaaiHTa0%3D&reserved=0>,
> https://archivesspace.atlassian.net/browse/AR-1339
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1339%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DhgWDYWqcc2mIwnGPkAiXTiFFsNbomuHwlCQR5vUb-Xo%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=DcFJ3kNa%2F5NMvtWszm7E4vRXo7UCVDSElhmnZK%2FrLBY%3D&reserved=0>,
> and https://archivesspace.atlassian.net/browse/AR-1344
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__archivesspace.atlassian.net_browse_AR-2D1344%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DD823vM9JV2KVvBtIyhFkIAiIDIV8VJ-YooJY-n-lMLA%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=Gl8ZJvBoNQn6UqoCw5mUaniZfqrbKdkoJ%2B6eS0tN3Dk%3D&reserved=0>
> .
> - The Dates field is the Agent record is no longer deprecated. This
> decision was made awhile back, but the tooltip and documentation are just
> catching up with the 2.0.0 version. The short version of why this is the
> case is that in the current application, the Dates field is needed for
> alignment with MARC while the Dates of Existence fields align better with
> EAC-CPF and allow for more precise use of dates. Currently what is in the
> Dates field is also what is put into the display string for an Agent, on
> both the staff interface and the public interface. While it is certainly
> not the most satisfying answer, the current solution is to either use both
> sets of dates, or to choose the one that most reflects your intended output.
> - As Francis suggests, a more robust Agents module is in the planning
> stages. Cory Nimer and Brad Westbrook have been working on specification
> for a substantial reworking of the Agents module, along with fuller support
> for EAC-CPF. I believe this specification will be ready for wider community
> review soon. In addition to providing the potential for recording
> additional types of information about people, families, and corporate
> bodies, reworking the Agents module could potentially come up with a
> solution for this date redundancy problem, though from this discussion it
> sounds like there are use cases for maintaining both ways to record dates.
>
>
>
> Christine
>
>
>
> Christine Di Bella
>
> ArchivesSpace Program Manager
>
> christine.dibella at lyrasis.org
>
> 800.999.8558 x2905 <(800)%20999-8558>
>
> 678-235-2905 <(678)%20235-2905>
>
> cdibella13 (Skype)
>
>
>
> [image: ASpaceOrgHomeMedium]
>
>
>
>
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of *Cyndi
> Shein
> *Sent:* Wednesday, April 12, 2017 2:12 PM
> *To:* Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] LCNAF plugin
>
>
>
> Hello all,
>
> Just to weigh in on this conversation, local practice here at UNLV
> supports Francis' statement:
> 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.
>
>
> We find that the dates of existence field permits us to include
> information absent from the authorized heading... not all headings have
> dates, and death dates are not often added in a timely manner.
>
>
>
> We're excited about all the developments!
>
>
> Cyndi Shein
>
> Head, Special Collections Technical Services
>
> University Libraries, University of Nevada, Las Vegas
>
> cyndi.shein at unlv.edu (702) 895-2223
>
>
>
> On Wed, Apr 12, 2017 at 10:52 AM, Lapka, Francis <francis.lapka at yale.edu>
> wrote:
>
> Thanks Karen. My comments are below.
>
>
>
> Francis
>
>
>
>
>
> *--*
>
>
>
> *Karen Miller* k-miller3 at northwestern.edu
> <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 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.library.northwestern.edu%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3Dxq6EdWeZJMtoTYrqj3Xpi9FONLWyFncQqI1nmaQurdI%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=FWKc1KosVLA%2FahElAqAlH%2BrbyhlbI%2FfkDqiB%2FJUm06M%3D&reserved=0>
>
> k-miller3 at northwestern.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>
>
> 874.467.3462
>
>
>
>
>
>
>
>
>
> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>] On Behalf Of Lapka, Francis
>
> Sent: Thursday, April 06, 2017 3:23 PM
>
> To: archivesspace_users_group at lyralists.lyrasis.org <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>
>
> 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://docs.google.com/spreadsheets/d/1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA/edit#gid=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1JRKcx7W0Os09NIgLckCtoTZxLeqTqUQVXlLLL_joWbA%2Fedit%23gid%3D0&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=7PV4BHcWcacj8jRf%2BoPDJldC6%2FR5IaP1RVXwhGDaw9U%3D&reserved=0>
>
>
>
> 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 <%28203%29%20432-9672> * francis.lapka at yale.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0><mailto:francis.lapka at yale.edu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>>
>
>
>
>
>
> Francis Lapka · Catalog Librarian
>
> Dept. of Rare Books and Manuscripts
>
> Yale Center for British Art
>
> 203.432.9672 <%28203%29%20432-9672> · francis.lapka at yale.edu
>
>
>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup%26d%3DDwMGaQ%26c%3D-dg2m7zWuuDZ0MUcV7Sdqw%26r%3DgQGQofGdaGM0cHFpVYJ0c97q2nvrx1llOMu-5gZnWGg%26m%3DVE7vahQV409oFeyMJzrm8qL-EAABs1a2EeqCYbbA0kE%26s%3DlAXcHM1BDjQuDu_S4suuqwrJDlJ1mwQdvARy_y0ZYk4%26e%3D&data=02%7C01%7Cbthomas%40tsl.texas.gov%7Cb84af399b80144a8bfa408d556bf780a%7Ca4597bff9f384145a0334a2168399a5e%7C0%7C0%7C636510302741242703&sdata=sjfFUfK8wBgEFymqXFeFX0fO6vUAGHtUlQTlTQMCBcA%3D&reserved=0>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
--
Cyndi Shein
Head, Special Collections & Archives Technical Services
University Libraries, University of Nevada, Las Vegas
cyndi.shein at unlv.edu (702) 895-2223
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 5314 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 4144 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 1497 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 11771 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/4e9350c5/attachment.jpe>
More information about the Archivesspace_Users_Group
mailing list