[Archivesspace_Users_Group] Collection management - processing status disappeared...
Jason Loeffler
j at minorscience.com
Mon Feb 15 14:29:33 EST 2016
A pull request is a request to make changes to the source code of a web
application or other technology project. They are issued by developers to a
version control system like GitHub. More here
<https://help.github.com/articles/using-pull-requests/>. Any proposed
changes made by contributing developer are reviewed and either merged or
rejected by the code maintainer (in this case Lyrasis). Since ArchivesSpace
is a community-drive, open-source project, pull requests afford an
opportunity for developers from both within and outside of the
ArchivesSpace community to develop and submit enhancements to the project.
Hope that clarifies.
Jason Loeffler
Technology Consultant
The American Academy in Rome
Minor Science | Application Development & Metadata Strategy
Brooklyn, New York
jason at minorscience.com
(347) 405-0826
minorscience (Skype)
On Mon, Feb 15, 2016 at 11:35 AM, Bowers, Kate A. <kate_bowers at harvard.edu>
wrote:
>
>
> What is a "pull request" who is authorized to "send one in" and how do
> they do that?
>
>
> Once you tell me these things, I will personally sit next to anyone who
> can execute a "pull request" and hurl $20 bills at them until the task is
> completed.*
>
>
>
>
>
>
>
> *offer not available in all areas, subject to change, but I will
> definitely buy you a beer/coffee
>
> 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
> Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org>
> *Sent:* Monday, February 15, 2016 3:49 AM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> Hi All,
>
>
>
> 1. Also, just to mention if someone wants to send in a pull request to
> look at for this, it would really increase the chances of it being included
> in an upcoming release.
>
>
> best, chris.
>
>
> Chris Fitzpatrick | Developer, ArchivesSpace
> Skype: chrisfitzpat | Phone: 918.236.6048
> http://archivesspace.org/
>
>
> ------------------------------
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Kelly Spring <kspring at uci.edu>
> *Sent:* Saturday, February 13, 2016 12:25 AM
> *To:* Archivesspace Users Group
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
> UCI also supports AS-76.
>
>
>
>
>
> 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=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=>
> Special Collections
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__special.lib.uci.edu_&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=MYm-DioZW5HaoMQZMtCGUG5pTsMKhDCDT3hqSYL6tOg&e=>
> special.lib.uci.edu
> Special Collections and Archives houses the UC Irvine Libraries'
> collections of rare books, manuscripts, archives, photographs, and other
> rare and special materials.
>
>
>
>
>
>
>
> *From:* Cyndi Shein [mailto:cyndi.shein at unlv.edu]
> *Sent:* Tuesday, February 09, 2016 3:42 PM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Collection management -
> processing status disappeared...
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_unlvspecialcollections&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=buzU5ikgX54NwC2hx6ovTVRyB07kBgt9fAnh-mkK944&e=>
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AS-2D76&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=QUpHD5feOr8PKWUU0jLrJOPTvrvpsMIrier1jCOIkvc&e=> (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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=eRudWwn124T8IwjvAFm1mTkcF8pWMMeZguGtn-SX8Q8&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=CwMF-g&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=V9bJcpgKwxXu8ho-KacYaLOG5Pkx1qxmRAKXisFoD1E&s=eRudWwn124T8IwjvAFm1mTkcF8pWMMeZguGtn-SX8Q8&e=>
>
>
>
> _______________________________________________
> 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/20160215/0063dc71/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 38864 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/0063dc71/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 49510 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/0063dc71/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 2366 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160215/0063dc71/attachment.jpg>
More information about the Archivesspace_Users_Group
mailing list