Deleting a Creator also deletes Creation Dates

[Damian Bauder]

I'm experiencing some inconsistent behaviour in AtoM 2.3 when deleting Creators from archival descriptions.

Scenario 1: An archival description has a Creator and Creation Date assigned during a CSV import (both elements being set in the same record)

When I edit an archival description, delete the Creator from the Context area, and then save the record, AtoM also deletes the Creation Date from the Identity area of the record.

Scenario 2: An archival description has a Creator and Creation Date assigned via the web interface

When I edit the description, delete the Creator, and then save the record, AtoM leaves the Creation Date on the record.

I would think that in both cases AtoM should leave the Creation Date on the record. Looking at the database, it seems that Scenario 2 creates two separate rows in the event table, while Scenario 1 creates a single row. Deleting a Creator seems to delete the row in which the Creator Actor appears, but perhaps it should just set the actor_id to NULL and keep the row?

Let me know if there is some other reasoning behind this behaviour, though.

Thanks!

[Damian Bauder]

I would think that in both cases AtoM should leave the Creation Date on the record. Looking at the database, it seems that Scenario 2 creates two separate rows in the event table, while Scenario 1 creates a single row. Deleting a Creator seems to delete the row in which the Creator Actor appears, but perhaps it should just set the actor_id to NULL and keep the row?

Just to clarify here, I mean to say that since deleting a Creator seems to delete the row in which the Creator Actor appears, in Scenario 1 the actor_id should be set to NULL without deleting the row, while in Scenario 2 it makes sense to delete the row, since the Creation Date is stored in a separate row. 

[Dan Gillean]

Hi Damian,

Interesting find!

Part of the reason for the strangeness in the Creator/Creation dates implementation was the need to make it work with both the ISAD template (where creators and dates are separate fields or data entry points - sections 3.1 and 3.2 of the standard) and the RAD template (where they are all part of section 1.4). It can make roundtripping difficult (especially across templates) and has led to some strange workarounds to implement what was needed, which can sometimes have unexpected results, as you've found. In any case, I agree with you that it would be far preferable to have the actor_id set to NULL than to have the whole row inadvertently removed.

I've reproduced and filed a ticket here: https://projects.artefactual.com/issues/10505

Note that there is a workaround available, in how you prep your data. In AtoM 2.3, you can use literal NULL values in the CSV template to properly separate elemements for events and actors - so you can technically use pipe separators to separate the date of creation from the creator, like so:


​

Thanks for letting us know about this!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

On Tue, Nov 1, 2016 at 2:20 PM, Damian Bauder <drba...@ucalgary.ca> wrote:

I would think that in both cases AtoM should leave the Creation Date on the record. Looking at the database, it seems that Scenario 2 creates two separate rows in the event table, while Scenario 1 creates a single row. Deleting a Creator seems to delete the row in which the Creator Actor appears, but perhaps it should just set the actor_id to NULL and keep the row?

Just to clarify here, I mean to say that since deleting a Creator seems to delete the row in which the Creator Actor appears, in Scenario 1 the actor_id should be set to NULL without deleting the row, while in Scenario 2 it makes sense to delete the row, since the Creation Date is stored in a separate row. 

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/9dd5845c-6958-4c8b-8b5f-7d8ad34118c5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Damian Bauder]

Hi Dan,

Thanks for the response. I hadn't considered that it might be a case of RAD vs. ISAD(G) behaviour conflicting.

I will pass on the workaround to our archivists!

Cheers,

Damian

On Tuesday, November 1, 2016 at 4:38:24 PM UTC-6, Dan Gillean wrote:

Hi Damian,

Interesting find!

Part of the reason for the strangeness in the Creator/Creation dates implementation was the need to make it work with both the ISAD template (where creators and dates are separate fields or data entry points - sections 3.1 and 3.2 of the standard) and the RAD template (where they are all part of section 1.4). It can make roundtripping difficult (especially across templates) and has led to some strange workarounds to implement what was needed, which can sometimes have unexpected results, as you've found. In any case, I agree with you that it would be far preferable to have the actor_id set to NULL than to have the whole row inadvertently removed.

I've reproduced and filed a ticket here: https://projects.artefactual.com/issues/10505

Note that there is a workaround available, in how you prep your data. In AtoM 2.3, you can use literal NULL values in the CSV template to properly separate elemements for events and actors - so you can technically use pipe separators to separate the date of creation from the creator, like so:


​

Thanks for letting us know about this!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

On Tue, Nov 1, 2016 at 2:20 PM, Damian Bauder <drba...@ucalgary.ca> wrote:

I would think that in both cases AtoM should leave the Creation Date on the record. Looking at the database, it seems that Scenario 2 creates two separate rows in the event table, while Scenario 1 creates a single row. Deleting a Creator seems to delete the row in which the Creator Actor appears, but perhaps it should just set the actor_id to NULL and keep the row?

Just to clarify here, I mean to say that since deleting a Creator seems to delete the row in which the Creator Actor appears, in Scenario 1 the actor_id should be set to NULL without deleting the row, while in Scenario 2 it makes sense to delete the row, since the Creation Date is stored in a separate row. 

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.