[Archivesspace_Users_Group] ArchivesSpace v. 3 and Agents module redesign inquiry

[Hadewijch Dekker]

Hi everyone,

With the update to ASpace v.3 the Agents module has had a complete redesign that does not seem to match the records that have been entered in earlier versions. I have been testing with the new version and have some concerns. I would like to know how others deal with these issues (if at all).

Background:
We have invested a lot of time over the last 18 months to convert all our Agent records to LCNAF-records. Our old Agent records were either local or were derived from the Dutch Authority File. We used the LCNAF plugin to import the LCNAF-records and merge them with the existing records.
Our cataloguers doing this job could easily check to see what records were still waiting to be handled and which ones were already made from LCNAF-records, because they could filter by source when browsing the Agents.

[cid:image001.png at 01D7A0AE.8B2488E0]

In the new module there are changes that makes that the LCNAF importer won't match the records made in the older versions. If a NACO-record is reimported a new record is created.
Q: How do people deal with this?
I also understand updates to records are something on the roadmap. I would like to take advantage of this. Should we somehow convert the old records to the newer version? Any ideas on how to do this?

Because of the new structure the records are also not recognized as being from the NACO Authority File and the Authority ID misses when looking at the search results and they are missing from the Source filters.
[cid:image002.png at 01D7A0AE.8B2488E0]

This last bit puzzles me because in the record the Record ID for the NACO-file is labelled as being the primary label.
[cid:image003.png at 01D7A0AE.8B2488E0]
Q: Why is there a primary label there, if the system does not take it into account? Do other people also find this to be a problem?


On a related issue, when exporting to MARC21 the ID was added to $0 of the 1XX, 7XX, 6XX fields. I know it is not customary to have $0 added for LCNAF, but for our Alma instance it is necessary to do the bibliographic record linking (to authority records) by ID, because we have more than  one personal name authority file in Alma.

Kind regards,

Hadewijch

_____
University of Amsterdam
University Library | Acquisition and Metadata Services
Hadewijch Dekker
Metadata Librarian
P.O. Box 19185 | 1000 GD Amsterdam
Singel 425 | 1012 WP Amsterdam | The Netherlands
T  +31 20 525 2407
www.uva.nl<http://www.uva.nl/>
Available on
Mon | Tues | Wed morning (every other week) | Thur | Fri morning


Hadewijch Dekker
Metadataspecialist
_____

Universiteit van Amsterdam | Hogeschool van Amsterdam

Bibliotheek UvA/HvA
Acquisitie en Metadatadiensten
Postbus 19185 / 1000 GD Amsterdam
Singel 425 / 1012 WP Amsterdam
T 020 525 2407
www.uba.uva.nl<http://www.uba.uva.nl/>
aanwezig op:
maandag | dinsdag | woensdagochtend (om de week) | donderdag | vrijdagochtend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210903/fc9ce7c4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 25898 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210903/fc9ce7c4/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 40177 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210903/fc9ce7c4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 10566 bytes
Desc: image003.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210903/fc9ce7c4/attachment-0002.png>