<dams:initiator> recorded in <dams:event> metadata leads to a 404

[arwenhutt]

Descriptive summary

The record for with ark bb4782910t leads to a 404

404Object does not exist2020-01-31T10:35:56-0800/objects/bb4782910t/exportERROR

The examples we have found so far were ingested or edited by @abbypenn93

Examples:

• https://library.ucsd.edu/dc/object/bb24282657
• https://library.ucsd.edu/dc/collection/bb30062003

[lsitu]

@mcritchlow I've added PR https://github.com/ucsdlib/damsmanager/pull/398 to ensure that the curator id is passed to the damsrepo backend for events creation as the fist step for the fix. The PR is ready for review now. We'll see whether there are other issues or not. Thanks.

[arwenhutt]

@lsitu events initiated by @abbypenn93 still have incorrect initiator metadata. I'm attaching a zip with an object edited by @abbypenn93 and for comparison objects edited by @remerjohnson and myself. Also the records for each of us ah_initiator.zip

[lsitu]

@arwenhutt I just took a look at record object_ah_2020_02_12_bd3708188f.xml in ah_initiator.zip and I see the new events are correct. Would you point me to the newly created events that are correct? Thanks.

[arwenhutt]

@lsitu the problem is with events initiated by Abby, in the files I provided the examples with abby's name or initials are the ones that show problems:

• object_ap_2020_02_12_bb6930466p.xml
• initiator_abby.xml

All of the other files are objects which show how Ryan and my names are recorded, and are provided for comparison.

[lsitu]

@arwenhutt Yep, I see the problem regarding why Arbby's name record (bb42367382) doesn't show up in the full RDF/XML now. It is a bb ark that was created on prod in the events triplestore: see apennington. I think this is what we'd implemented from the very beginning to have all event data stored in the events triplestore. However, we treat those curator name records as authority records and look them up from the dams triplestore while exporting full RDF/XML records, so it doesn't shown up while Arbby testing it. The reason that you and Ryan see it because both of your name records have a copy stored in the dams triplestore somehow.

To avoid the problem, I think we can create/lookup curator name records in the dams triplestore instead of the events triplestore. Or we can simply import Abby's name record to the dams triplestore. What do you think?

[arwenhutt]

@lsitu I think either sounds fine, so whichever you think is best!

[lsitu]

@arwenhutt I recalled that we may have talked about the topic with creating those curator name records first. How about just import @abbypenn93 's name record to the dams triplestore now to move the deployment forward, and if you want to change the way of creating/looking up those name records, we'll work on another ticket?

[arwenhutt]

@lsitu sounds good

[lsitu]

@arwenhutt I've imported @abbypenn93 's name record to staging. Here is the full RDF/XML for record bb6930466p that Abby tested earlier: http://lib-hydratail-staging.ucsd.edu:8080/dams/api/objects/bb6930466p/export. Could you take a look?

[arwenhutt]

@lsitu it's showing up for me now 👍

[arwenhutt]

@lsitu - @abbypenn93 verified this on production ✔️