AtoM 2.3 Accession CSV template not consistent with how columns used in 2.3 Information objects templates
|Google Code Legacy ID:||Tested version:||2.3|
In the updated 2.3 accessions template, there is still a separate creators column - attaching here for reference. In the archival description csv templates, we managed to do away with this awkwardness - all events and actors, creation or otherwise, can be added to the same columns: eventActors, eventActorHistories, eventStartDates eventDates, eventTypes, eventEndDates, etc.
In the 2.3 accessions template it's a bit confusing:
- creators must have the creator names (e.g. creator1|creator2)
- eventActors must have NULL values (e.g. NULL|NULL)
Trying to add a 3rd actor, who is an accumulator, gets a bit weird. If you add a 3rd, piped, NULL value in the creators column this gets imported as a literal - you'll end up with a creator named NULL. So you would have to pipe all the other values, but NOT the creators column. Hardly intuitive.
- creators column is removed - values are added to eventActors instead
I tried importing one like this, and my creators were not imported. Right now, AtoM is only looking for creators in the creators column. Other event types are less of a priority, since their creators will not display (as AtoM add other event actors as name access points, and there are no name access points on accession records - and they do not appear magically when an archival description is generated from an accession). Still, for clarity and consistency, I think we should use the same columns as we are now using the information_objects csv templates - and you should not need another column with NULL values for imports.
#2 Updated by Dan Gillean about 6 years ago
- Status changed from New to Code Review
I sent the CSV example to Sara to test in her VM. Can you take a look at the changes and make sure all seems well, Mike? Got a funny message during my commit about line endings and want to make sure I haven't inadvertently made a mess of things. Thanks!
#3 Updated by Dan Gillean about 6 years ago
Note: this is really more of a workaround than a solution for this issue. If the PR is approved, I would still like to keep this issue open. I think we should still fix it - but in the meantime I've done what I can to remove unnecessarily confusing columns from the example.
#6 Updated by Dan Gillean about 6 years ago
- Status changed from Verified to New
- Assignee deleted (
Thanks! I am going to leave this ticket as new, because my PR does not actually solve the issue as identified in the description - it merely reduces end user confusion by removing confusing rows that are unnecessary for import. I still think we should harmonize how events/actors works with how it does for IOs, so there is consistency in the application.