[Archivesspace_Users_Group] Collection management - processing status disappeared...

[Emma Jolley]

Dear all

Thanks for such a thorough discussion on this issue. We were very dismayed when the processing status field initially disappeared (not having been notified that this was going to happen in the first place). But when it did we adapted our workflows to use Events to track our various Accessioning and Processing stages and have done significant work to correct that problems associated with the movement of information from the Processing Status field to an Event.

As such we agree with Kate's and Laurel's approach - we would not want to see the Events that we now use to track processing status disappear and would want to retain them. We are happy if the processing status is re-instated in Collection Management (we can always ignore the field if we don't want to use i) but would not want to see all of the information now in Events affected.

Best wishes

Emma
National Library of Australia


Emma Jolley| Curator of Digital Archives, Pictures and Manuscripts Branch|National Library of Australia Canberra ACT 2600
e: emma.jolley at nla.gov.au<mailto:emma.jolley at nla.gov.au>|t: 02 6262 1456| www.nla.gov.au/ms<http://www.nla.gov.au/ms>
http://www.nla.gov.au/support-us/make-a-collection-offer-pictures-and-manuscripts



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Dougherty, Laurel
Sent: Thursday, 18 February 2016 6:34 AM
To: 'Archivesspace Users Group'
Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared...

I think Kate's approach sounds good. If the processing_status_id / cataloged fields and their related dates that are currently showing as Events can simply be made to reappear (populated with the data they contain) in the Collection Management subrecord (and Kate implies it's actually already there in the tables), then we're not necessarily proposing a sweeping deletion of folks' data or a change to the data model-just a restoration of functionality that has been the focus of this conversation.

Perhaps this could happen in a sequence of events like this:

1)      Following a pull request and prioritization/acceptance, a future version of ASpace is released with processing and cataloged status options (pull-down menus) and the other requisite fields that go along with them back in the Collection Management subrecord. Updating to this version doesn't cause anyone to lose data-it just reappears as it was originally migrated.

2)      The migration tool is re-configured, for those who aren't in production yet, to have their AT processing status data mapped to the Collections Management subrecord

3)      Institutions that want to wipe out their processing-related events can do so; if a plug-in is required to transfer data added to the Events module (post-migration), that is developed as a final step

It's easy to configure the events by adding and deleting fields to fit your needs. So I wouldn't propose a reverse migration that wipes out processing events for everyone-after all, while re-reading Brad's post on this topic from November, this change was done with good intentions and was a deliberate extension of the PREMIS events model. I quote Brad here:

"We removed this field from the collection management field with the understanding such data would be better handled as event information and with the understanding that a change in status is first an event accomplished at a time and by an agent."

Some repositories may very well want to continue adding processing actions as events (i.e. "partially processed" by [agent] on [date]) to allow for granular reports on these types of events and agents in the future.  But it seems, in addition, institutions simply want an option via Collection Management to say: is this stuff processed, or not? Because an event is not necessarily the same as a status.  As others have pointed out, a status is just easier for querying and on-the-ground collection management. A one-time version change that exposes those relevant fields that were moved to Events and plops them back into the Collection Management subrecord might be a suitable minimum "do no harm" approach. Plug-ins to migrate data between the Events and Collections Management subrecords might be a slightly different issue.

Respectfully,
Laurel

Laurel McPhee Dougherty
Supervisory Archivist, Special Collections & Archives Program
UC San Diego Library | * 858-534-5619 | * l1dougherty at ucsd.edu<mailto:l1dougherty at ucsd.edu>




From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A.
Sent: Wednesday, February 17, 2016 8:30 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared...

I'm not sure that incorporating "reverse migration" for all into re-establishing the disappeared functionality would be wise.  Rather a one-time "reversion helper" plug-in, that can be optionally executed by an ArchivesSpace repository, is better.

Here's my thinking



1) Less work means more likelihood of getting the basic, vital functionality of "processing status" back into collection management records more quickly.  By this I mean: the table is still there with the data in it (at least for AT migrations).  Just put it back into the interface and for users and admins.

2) Status does not equal event.  Status *may* be inferred from *some* events.

3) Individual implementers have control over their drop-down lists, thus, each type of event would have to be evaluated for its real-world meaning vis-a-vis processing status. Automated monkeying might obfuscate the actual processing status. There is no way to know what can be automated across the board. Ergo, individual repositories have to govern these changes.

4) Individual implementers may not need "reverse migration" and the labor might be in excess of the work needed to simply apply processing statuses to accessions by hand.  Questions to evaluate the need include: a) How much work would be involved in creating "reverse migration"? b) As far as I can tell, processing statuses that migrated from AT are still there. For many repositories, changing processing status may not be that labor-intensive-it could be that not many accessions have been processed between migration and implementation.  c)   Did Archon have processing status?  If so, were they also retained? d) How many repositories changed the default drop-downs for event records?



Kate



Kate Bowers
Collections Services Archivist for Metadata, Systems, and Standards
Harvard University Archives
kate_bowers at harvard.edu<mailto:megan_sniffin-marinoff at harvard.edu>
617.496.2713
voice: (617) 384-7787
fax: (617) 495-8011
web: http://nrs.harvard.edu/urn-3:hul.eresource:archives
Twitter: @k8_bowers


From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Runyon, Carolyn
Sent: Tuesday, February 16, 2016 4:18 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Collection management - processing status disappeared...

Chris, I'm going to answer two of the questions you posed in yesterday's email according to UTC's preference.


  *   Yes, we would like to see processing event records migrated back to their original collection_management records and then removed.
  *   Yes, we like to see processing tracked in collection_management only and have it removed as an option in events.

Cheers,
Carolyn

Carolyn Runyon
Assistant Head of Collection Services and Director of Special Collections
University of Tennessee at Chattanooga Library
615 McCallie Ave., Chattanooga, TN  37403
Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503
Dept. 6456, LIB 439D

On Feb 15, 2016, at 1:15 PM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org<mailto:Chris.Fitzpatrick at lyrasis.org>> wrote:

One thing I am curious about is are people wanting to have this processing_status_id field added to the collection_management table, but are you wanting to have these event records migrated back to collection_management records and then removed ( the migration to make this change moved the data from the collection_management table into events) ? Are you wanting to do away with the processing status in events completely?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160217/6d40c5f9/attachment.html>