[Archivesspace_Users_Group] Collection management - processing status disappeared...
Kate Dundon
dundon at ucsc.edu
Thu Feb 11 20:13:21 EST 2016
UCSC Special Collections & Archives also supports AS-76. We are
experiencing a scenario similar to Harvard's.
Kate Dundon
Archivist, Special Collections & Archives
University Library
University of California, Santa Cruz
831-502-7587
On Tue, Feb 9, 2016 at 3:41 PM, Cyndi Shein <cyndi.shein at unlv.edu> wrote:
> UNLV University Libraries supports AS-76 as well.
>
> Cyndi Shein
> Head, Special Collections Technical Services
> University Libraries, University of Nevada, Las Vegas
> cyndi.shein at unlv.edu (702) 895-2223
>
> unlvspecialcollections <https://www.facebook.com/unlvspecialcollections>
>
>
> On Tue, Feb 9, 2016 at 10:02 AM, Dougherty, Laurel <l1dougherty at ucsd.edu>
> wrote:
>
>> UC San Diego concurs. The experience (and resulting complications with
>> managing data effectively) that Anne describes below are identical to UC
>> San Diego’s, and we too support AS-76.
>>
>>
>>
>> *Laurel McPhee Dougherty*
>>
>> Supervisory Archivist, Special Collections & Archives Program
>>
>> UC San Diego Library | ( 858-534-5619 | * l1dougherty at ucsd.edu
>>
>>
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Engelhart,
>> Anne
>> *Sent:* Tuesday, February 09, 2016 8:58 AM
>> *To:* Archivesspace Users Group <
>> archivesspace_users_group at lyralists.lyrasis.org>
>> *Cc:* Sniffin-Marinoff, Megan <megan_sniffin-marinoff at harvard.edu>
>> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>> I’ve been asked by the Harvard ArchivesSpace Interim Steering Group to
>> post Harvard University’s position on AS-76. I also posted it on JIRA,
>> AS-76. (Here it is below.)
>>
>>
>>
>> Anne Engelhart
>>
>> Head, Collection Services
>>
>> Schlesinger Library, Radcliffe Institute
>>
>> 10 Garden St.
>>
>> Cambridge, MA 02138
>>
>> 617.495.8521
>>
>>
>>
>> *Restoration of processing status to collection management records in
>> ArchivesSpace*
>>
>> *Summary *
>>
>> Sometime during the past year, ArchivesSpace made a major change to its
>> functionality.
>>
>> · It eliminated the processing status from collection management
>> records.
>>
>> · The processing status and associated date were converted to
>> “event” records.
>>
>> This has created several problems for archivists at Harvard who rely on
>> this information for workflow and reporting purposes including:
>>
>> · The “processing status” in all accessions migrated from the
>> Archivists’ Toolkit (AT) for which processing statuses were assigned now
>> displays as “Not specified” (see Screenshot 1).
>>
>> · The conversion of processing status from a condition (or type)
>> to an event overcomplicates what was previously a fairly straightforward
>> piece of collection management information.
>>
>> *Detailed discussion of issues*
>>
>> There are three troubling issues associated with this change in
>> functionality.
>>
>> 1. The first should be important to all archives: by converting
>> the processing status to an event, the ArchivesSpace developers have
>> changed the nature of the data. A status is not equivalent to an event,
>> although they can be related. There is one and only one “status” at any
>> one time, but there can be multiple events. Events can lead to status
>> changes. For example, two “partially processed” events may or may not
>> lead to a status of “processed,” because it is entirely possible that three
>> or more processing events might be needed to conclude that the status of
>> the collection is “processed.” In addition, some statuses may have no
>> relation to an event. For example “Unknown” is a possible processing
>> status. Finally, how does an archivist identify “unprocessed” accessions
>> in this scenario? This is another “non-event”. Are ArchivesSpace users
>> expected to run a report on all accessions and look for those for which
>> there is no “processing” event? Since there are many possible event types,
>> this seems counter-productive and unnecessarily complex.
>>
>>
>>
>> 2. The second issue is perhaps unique to Harvard albeit no less
>> critical. The Harvard AT-to-AS migration did not create event records based
>> on processing status. Instead, while our back-end data has processing
>> status in it, these statuses are, troublingly, not visible to staff.
>> Instead the processing status displays as “not specified” (Screenshot
>> 1). The same record in AT displays a processing status. (Screenshot 2)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Screenshot 1*
>>
>> *Screenshot 2*
>>
>>
>>
>> 3. Processing status is a critical piece of information that
>> should be available to archivists for reporting on their accessions. In
>> Harvard's current ArchivesSpace environment is that it is not possible to
>> understand the scope and nature of our backlogs. The staff member who
>> discovered this issue previously used the AT to readily determine the
>> number of unprocessed accessions. While attempting to gather the same
>> information from ArchivesSpace, the staff member found that it was not
>> possible to achieve the same results with existing ArchivesSpace
>> functionality.
>>
>>
>>
>> It is essential to the Harvard University ArchivesSpace user community
>> that processing status be restored to its original functionality. The
>> restoration of processing status to collection management records would:
>>
>> · Allow archivists to report out on backlog and processing
>> statistics;
>>
>> · Assist archivists in resource allocation planning for grant
>> proposals and yearly projects; and
>>
>> · Make this data currently in the back-end of ArchivesSpace
>> easily available to archivists
>>
>> As such, Harvard University ArchivesSpace user community supports the
>> JIRA ticket (AS-76) submitted by Matt Francis of Penn State Libraries.
>>
>>
>>
>>
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
>> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
>> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf Of
>> *MATTHEW R FRANCIS
>> *Sent:* Monday, January 04, 2016 12:56 PM
>> *To:* Archivesspace Users Group
>> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>> Quick FYI update for anyone interested in this thread. After a couple of
>> off-list discussions I decided to go ahead an create a new "feature
>> request" ticket in JIRA requesting that the "Processing Status" field be
>> restored to the Collection Management sub-record. The ticket can be viewed
>> at: https://archivesspace.atlassian.net/browse/AS-76 (my apologies for
>> forgetting to submit in the form of a user story!).
>>
>>
>>
>> If there are any questions, concerns, or clarifications that I can help
>> with related to the request please let me know.
>>
>>
>>
>> -Matt
>>
>>
>>
>> *Matt** Francis*
>>
>> Archivist for Collection Management
>>
>> Special Collections Library
>> Penn State University
>>
>>
>> ------------------------------
>>
>> *From: *"MATTHEW R FRANCIS" <mrf22 at psu.edu>
>> *To: *"Archivesspace Users Group" <
>> archivesspace_users_group at lyralists.lyrasis.org>
>> *Sent: *Wednesday, November 25, 2015 4:50:24 PM
>> *Subject: *Re:
>> [Archivesspace_Users_Group] Collection management - processing status
>> disappeared...
>>
>>
>>
>> Thank you Brad for your explanation for why the change occurred with the
>> processing status field, and thank you Kate, Noah, and Carolyn for your
>> additional thoughts and feedback.
>>
>>
>>
>> Based on all of the provided feedback I asked some of our staff to
>> work/test the new functionality while trying to consider the intent behind
>> the changes, our existing local workflows and collections metadata, and the
>> abstract "what do we consider processing status to mean". Based on this
>> examination of the new functionality we would like to provide the following
>> feedback (many of which have already been stated in this email thread):
>>
>> - In regards to "an event record allows much more information to be
>> associated with the event", it has been our local practice and belief that
>> more nuanced processing information that would help researchers and staff
>> better understand a finding aid/the physical collection should be recorded
>> in a corresponding "Processing Information" note (which is informed by our
>> interpretation of DACS 7.1.8). That said, we do appreciate that the event
>> record allows for the capturing of some metadata that would be less
>> relevant to researchers, and consequently a place where additional metadata
>> could be recorded outside of the aforementioned note field.
>> - After examining our "processing status" data and discussing the
>> new functionality, we agree with Kate's observation that "events and
>> processing statuses are not logical equivalents." Additionally, we also
>> agree with Noah's comment "that a resource or accession will always have
>> only one current status."
>> - Additionally, based on our examination, we do not believe that is
>> ideal or logical to separate "processing status" from collection management
>> records that still include: "processing priority", "processing plan", and
>> "processors".
>> - Our local workflows appear to be at a high level similar to what
>> Carolyn has reported, and along with the data we had already created to
>> take advantage of the previous functionality, we also preferred the
>> simplicity of the processing status being a simple drop-down selection in
>> the collection management records.
>> - Based on our local use the processing status field, along with the
>> current status of the ASpace tool, we found it much easier to report on
>> collection status and to locate appropriate collections projects for our
>> workers with the previous functionality over the current.
>> - Finally, we also echo Kate's sentiment in that we do not understand
>> why the new event features requires the removal of the processing status
>> from the collection management records and consequently wonder if there is
>> any reason not to have both?
>>
>> Due to the above points we are of the opinion that if the new event
>> features cannot be appropriately maintained while also having the
>> processing status functionality reside in the collection management
>> records, we would be in favor of a return to the previous functionality, or
>> a new approach that is more similar to the previous functionality. With
>> that said, we understand that our rationale for this request is largely
>> based on our local understanding of the role of the processing status
>> field, our local workflows, and and our existing data. Because of this we
>> recognize that not all ASpace members might share our perspective, and
>> consequently we welcome continued discussion on this subject as appropriate.
>>
>>
>>
>> Thank you again to everyone who have already participated in the
>> conversation, and we hope that as a community we can reach a consensus on
>> the best direction for us to proceed in the near future.
>>
>>
>>
>> Hope all of you have a wonderful Thanksgiving.
>>
>>
>>
>> -Matt
>>
>>
>>
>> *Matt** Francis*
>>
>> Archivist for Collection Management
>>
>> Special Collections Library
>> Penn State University
>>
>>
>> ------------------------------
>>
>> *From: *"Runyon, Carolyn" <Carolyn-Runyon at utc.edu>
>> *To: *"Archivesspace Users Group" <
>> archivesspace_users_group at lyralists.lyrasis.org>
>> *Sent: *Tuesday, November 24, 2015 2:12:09 PM
>> *Subject: *Re:
>> [Archivesspace_Users_Group] Collection management - processing status
>> disappeared...
>>
>>
>>
>> We used the Processing Status field in the Collection Management module
>> to track processing of our all our Resource records. It’s a little less
>> complex than the data needed to populate an Event. I preferred the basic
>> dropdown menu offered in Collection Management because it doesn’t require
>> and Event Date/Time or a link it to an Agent. With legacy data, I won’t
>> able to link an accurate Agent or Date to my processing events, which means
>> I’ll have to devise some sort of input workaround for undated and anonymous
>> Events.
>>
>>
>>
>> One last note, when Processing Status became and Event, Event Date/Time
>> and Agent Links were populated, but they’re not accurate. They appear to
>> reflect the Agent who selected the Processing Status and the Timestamp of
>> when the Agent made the Processing Status selection. This means that if I
>> want accurate data, I’ll need to clean up this legacy data.
>>
>>
>>
>> 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, (423) 425-4503
>> Dept. 6456, LIB 439D
>>
>>
>>
>> On Nov 19, 2015, at 9:57 AM, Noah Huffman <noah.huffman at duke.edu> wrote:
>>
>> I tend to agree with Kate here. It seems useful to allow a resource or
>> accession to have lots of processing events associated with it (who did
>> what, when), but it also seems that a resource or accession will always
>> have only one current status (processed, not processed, partially
>> processed, etc.).
>>
>>
>>
>> Also, associated events do not display in “edit” mode for resources or
>> accessions (collection management sub-records do). As a result, it’s a bit
>> complicated to figure out what the processing status is if you have to sort
>> through a long list of associated events in “view” mode.
>>
>>
>>
>> -Noah
>>
>>
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
>> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
>> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf
>> Of *Bowers, Kate A.
>> *Sent:* Thursday, November 19, 2015 9:40 AM
>> *To:* Archivesspace Users Group <
>> archivesspace_users_group at lyralists.lyrasis.org>
>> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>>
>> Brad,
>>
>> Thanks for your very thorough reply!
>>
>> I think you presented this as an either/or choice. However, because
>> events and processing status are not logical equivalents (they may be
>> associated in that the status may be the result of an event, but it does
>> not have to be), I do not understand why adding features to the events
>> record requires removal of the status. I short, is there any reason not to
>> have both?
>>
>> Thanks again,
>>
>> Kate
>>
>> Kate Bowers
>> Collections Services Archivist for Metadata, Systems, and Standards
>> Harvard University Archives
>> Cambridge, Massachusetts, USA
>> voice: (617) 384-7787
>> fax: (617) 495-8011
>> kate_bowers at harvard.edu
>> ------------------------------
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
>> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
>> Brad Westbrook <brad.westbrook at lyrasis.org>
>> *Sent:* Wednesday, November 18, 2015 6:04:27 PM
>> *To:* Archivesspace Users Group
>> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>> Hi.
>>
>>
>>
>> Certainly it is possible and reasonable to have a discussion of how to
>> adjust this change in functionality to make it more satisfying and less
>> confusing, including reverting back to the functionality first included in
>> ArchivesSpace.
>>
>>
>>
>> As I recall that functionality, it consisted of the ability to link a
>> single collection management record to a material description record
>> (accession, resource, or digital object but not components for resources
>> and digital objects) and, further, to indicate in that collection
>> management record the processing status of the material being described.
>> Default terms were “completed”, “in_progress”, and “new”, but the
>> controlled value list was completely configurable. So institutions could
>> add any terms they wanted to that list but they could only ever apply one
>> status term to the material being described at a given time.
>>
>>
>>
>> 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. We envisioned several benefits to
>> this change:
>>
>>
>>
>> 1) As before, an organization has complete liberty to decide what
>> terms it wants to use for expressing processing events and changes in
>> processing status, as well as for any other events an institution chooses
>> to track. The “Event Event Type” list is completely configurable.
>>
>>
>>
>> 2) An event record allows much more information to be associated
>> with the event, including a descriptive note about the event, when the
>> event occurred, and who was responsible for the event. It struck us that
>> knowing that processing of a collection was completed on a certain date and
>> by a certain individual could be more useful information that know
>> processing was simply completed.
>>
>>
>>
>> 3) Multiple event records can be associated to the same material
>> description record. For instance, using event records it would be possible
>> to indicate when processing of material started in one event record and
>> when it was completed in another.
>>
>>
>>
>> 4) Multiple event records can be linked to component records.
>> Thus for processing projects split into parallel parts, it would be
>> possible to track, say, the processing progress of series.
>>
>>
>>
>> In short, our belief is that the collection management record in
>> conjunction with event records provides a more comprehensive and flexible
>> way for organizations to record collection management information. In that
>> relationship, the collection management record is the location for
>> planning—indicating processing priority, estimating processing time,
>> indicating processing plan(s) and processor(s), but also noting funding
>> source and whether rights are determined (it’s questionable whether or not
>> these last two should be included in the collection management
>> record)—while the event record is for recording completion (or not) of
>> processing / administrative tasks associated with the materials—acquiring a
>> purchase agreement, starting processing, completing processing, etc.
>>
>>
>>
>> There are requisites for this, of course:
>>
>>
>>
>> 1) Institutional policies regarding what events are to be tracked
>> and what event vocabulary is to be used.
>>
>>
>>
>> 2) A process for creating and sharing reports that relate material
>> descriptions, collection management, and events in meaningful ways. A
>> segment of the ArchivesSpace community has been working to develop a
>> reporting process, but the trajectory being taken will place the burden on
>> institutions to define reports (You can, btw, see a record of this effort at
>> https://archivesspace.atlassian.net/wiki/display/AC/2015-16+Reports
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_2015-2D16-26-2343-3BReports&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=8UVzAZgZUYCTKzwFwtZ-ItCHeuR_vGn6ZXiJbokIYsc&e=>
>> (current work) and
>> https://archivesspace.atlassian.net/wiki/display/AC/Reports+Sub-team
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_AC_Reports-26-2343-3BSub-2Dteam&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=gR2KAeUPGvIhxYIWoXd34WpOx_Fv8C2o6k7-biJ_1S0&e=>
>> (past work). It was also noted in the ArchivesSpace developers meeting
>> last week, that information of this type would be very suitable for
>> displaying in a dashboard widget. Of course, institutions can already
>> build their own reporting and define their own reports by using report
>> software to extract and format data from the ArchivesSpace MySQL database.
>>
>>
>>
>> But these would be requisites for any collection management information,
>> supplemented or not by event information. They would be requisites for a
>> reversion for a return to the previous data model.
>>
>>
>>
>> Let me close with two observations to other parts of this thread:
>>
>>
>>
>> 1) The display problem that Noah noted in his comment yesterday is
>> a remnant of moving collection status to events. There is a bug report
>> requesting its correction at AR-1324
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1324&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=pyfDl0NLRM2Jvhgo4nw49RzEuLIWLzobJtqOMHw8wZY&s=_4rsWhuS5vR89lgPot1DeY3XwBuDLb5wp_nbHwCIMZI&e=>
>> .
>>
>>
>>
>> 2) The presence of the “Collection Management Processing Status” in
>> the list of controlled values is also remnant of that change. It should be
>> removed , unless there is a collective decision to revert. Thanks for
>> pointing that out, Kelly.
>>
>>
>>
>> So it would be great to hear others weigh in on this. Collection
>> management and event information have, as far as I know, no prevailing
>> models or standards that we can simply follow. The closest to such is the
>> de facto collection management sub-record created for accessions in the
>> Archivists’ Toolkit, which was generalized for all top-level material
>> descriptions in ArchivesSpace and supplemented by the inclusion of events.
>> The ArchivesSpace event module is itself an extension of the PREMIS events.
>>
>>
>>
>> Best,
>>
>>
>>
>> Brad W.
>>
>>
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
>> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
>> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf
>> Of *MATTHEW R FRANCIS
>> *Sent:* Wednesday, November 18, 2015 4:49 PM
>> *To:* Archivesspace Users Group
>> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>> For the reasons outlined by Kate, and seconded by Glynn, we have also
>> found this change rather confusing, and unfortunately it has hampered our
>> ability to identify and report on various issues related to processing
>> status, including the previously mentioned backlog issue.
>>
>>
>>
>> I do not know if this is an issue that others would like revisited, but
>> from our perspective we would welcome a conversation on if there is better
>> alternative moving forward (including possibly reverting back to the
>> pre-v1.3 set-up).
>>
>>
>>
>> -Matt
>>
>>
>>
>> *Matt* *Francis*
>>
>> Archivist for Collection Management
>>
>> Special Collections Library
>> Penn State University
>>
>>
>> ------------------------------
>>
>> *From: *"Glynn Edwards" <gedwards at stanford.edu>
>> *To: *"Archivesspace Users Group" <
>> archivesspace_users_group at lyralists.lyrasis.org>
>> *Sent: *Wednesday, November 18, 2015 11:13:44 AM
>> *Subject: *Re: [Archivesspace_Users_Group]
>> Collection management - processing status
>> disappeared...
>>
>>
>>
>> Hi Kate,
>>
>> We're on the same page...I too find this rather confusing. It is not
>> straightforward enough for tracking status of collections across holdings
>> easily.
>>
>> Cheers,
>>
>> Glynn
>>
>>
>>
>> Glynn Edwards
>> Head, Technical Services
>> Director, ePADD project
>> Special Collections
>> Stanford University Libraries
>> Stanford, CA 94305-6064
>> (650) 521-2255 | gedwards at stanford.edu
>>
>>
>> ------------------------------
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
>> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
>> Bowers, Kate A. <kate_bowers at harvard.edu>
>> *Sent:* Tuesday, November 17, 2015 1:08 PM
>> *To:* Archivesspace Users Group
>> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>> I am very confused. Can you explain how this is would work? How is an
>> archivist supposed to understand an accession’s status from one or more
>> associated “events” rather than from a straightforward status? I can also
>> see how this would make reporting out backlogs really difficult.
>>
>>
>>
>> The reason I ask is that I can see how an event can lead to a status, but
>> it is entirely possible that a status may have no associated event.
>> Furthermore, the same type of event may lead to different statuses.
>>
>>
>>
>> In brief, status is not the same as “event”. I can think of a couple of
>> examples to illustrate this:
>>
>> · “Unknown” can be a status, but it has no associated event
>>
>> · “Partially processed” can be both a status an event. However,
>> if one “partially processes” an accession once, then the accession remains
>> partially processed. If one “partially processes” again, it could be that
>> the processing has been completed and the accession’s status is now
>> “processed” or it could be that the accession is still only “partially
>> processed” and that additional processing events will be necessary to reach
>> a “processed” status.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kate
>>
>>
>>
>>
>>
>> *Kate Bowers*
>>
>> Collections Services Archivist for Metadata, Systems, and Standards
>>
>> Harvard University Archives
>>
>> kate_bowers at harvard.edu <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
>> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf
>> Of *Noah Huffman
>> *Sent:* Tuesday, November 17, 2015 3:01 PM
>> *To:* Archivesspace Users Group
>> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>> Hi Kelly,
>>
>>
>>
>> During a previous release (v1.3), I think Processing Status was moved
>> from the collection management subrecord to an Event record. Here is a
>> JIRA issue describing this change:
>> https://archivesspace.atlassian.net/browse/AR-827
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D827&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=AZTgid9lXUTh7glUns7pyqqX7w28sAhx7rK3QIIMb8o&e=>
>>
>>
>>
>> Here are some specifics:
>>
>> Remove “Processing Status” Collection Management sub-record
>>
>> If data is present, migrate to Event record with these settings and
>> linked to same record collection management sub-record is linked to:
>>
>>
>>
>> Type = “Processing [Value in Collection Management Record for Processing
>> Status]”
>>
>>
>>
>> Date/Time Specifier = “Time stamp for last modification of Collection
>> Management record”
>>
>>
>>
>> Label= Agent relationship
>>
>>
>>
>> Type=Single
>>
>>
>>
>> Role=Implementer
>>
>>
>>
>> Agent=ID of agent last modifying the collection management sub-record
>>
>>
>>
>>
>>
>> So, if you previously had processing status in a collection management
>> subrecord, you might try browsing your event records to see if you can
>> locate that data.
>>
>>
>>
>> Hope this helps,
>>
>>
>>
>> -Noah
>>
>>
>>
>> ================
>>
>> Noah Huffman
>>
>> Archivist for Metadata, Systems, and Digital Records
>>
>> David M. Rubenstein Rare Book & Manuscript Library
>>
>> Duke University | 919-660-5982
>>
>> http://library.duke.edu/rubenstein/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__library.duke.edu_rubenstein_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=_GXkqn82Z-IInAOMJ80LH9QqQ2QNs6vZ496YUW6DDdw&e=>
>>
>>
>>
>>
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [
>> mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org
>> <archivesspace_users_group-bounces at lyralists.lyrasis.org>] *On Behalf
>> Of *Kelly Spring
>> *Sent:* Tuesday, November 17, 2015 2:40 PM
>> *To:* archivesspace_users_group at lyralists.lyrasis.org
>> *Subject:* [Archivesspace_Users_Group] Collection management -
>> processing status disappeared...
>>
>>
>>
>> Hello!
>>
>>
>>
>> Our Processing Status field is visible when using the Manage Controlled
>> Value Lists feature; but is not present when actually working within a
>> collection management sub-record in an accession or resource. Any tips or
>> advice out there?
>>
>>
>>
>> Thank you and have a great day!
>>
>> *Kelly
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Kelly Spring
>>
>> Archivist for Special Collections
>>
>> University of California, Irvine Libraries
>>
>> (949) 824-6573
>>
>> http://special.lib.uci.edu
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=zFl3APrxF-DYAdjHiyHfabcKKA8Exkt6l-SzojCi4hA&e=>
>>
>>
>>
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=>
>>
>>
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.uci.edu_about_zot-2Dsmarter.html&d=CwMFAg&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=KjdPV61xIn7OR7Ks9cg6HRC91WufUrZNTXFAT4skW8w&s=Ts5rSOVYPjSmSaxnBfWRYPYHSdVkhu9yZ4MoUwdLS-g&e=>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=QRZODf9XXD3bgxGHWgBXsAvw7uhg6gGfVUJ1KmSajT8&m=0Ck_7IMJVnx6wohz4qKGlbGyhudg134OSblcthSYEpo&s=Hy6Jm25S5RX5J4co3hzouZaE-u_g-orFLrA1i0aglwU&e=>
>>
>>
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 11771 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 49510 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 38864 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160211/3fe11e47/attachment-0001.png>
More information about the Archivesspace_Users_Group
mailing list