Revision as of 13:31, 15 May 2015

Main Page > Development > Development/Accession module > Development/Accession module/Historical

On this page you'll find an overview of the some of the early development considerations and analysis undertaken when designing the accession module for ICA-AtoM, enhancements introduced in ICA-AtoM 1.3, and user feedback and development suggestions received at that time.

For newer development documentation about the accession module, please see the other pages in this section of the wiki:

• Development/Accession module/2.x development
• Development/Accession module/Future development

Introduction

The Accession Module is designed to establish basic intellectual and physical control over a new accession at the time it is received by the repository. By creating an accession record, information is recorded about the accession transaction, the contents of the accession and management events related to the accession. The accession record is not aimed at end-user description, such as a finding aid for the repository's archival resources.

Resources

Research into creating an Accession Module led us to the following websites and specific documents:

• Archivists' Toolkit and the User Manual v.1.5/1.9.
• Archon and the User Manual v.2.2
• ArchivesSpace and their Accession Specification and their Deaccession Specification

Minimum Accessions Workflow

• All fields are mandatory

1. Select option to add new accession record or to edit an existing accession record.
2. Record accession unique identifier.
3. Record date of acquisition of accession.
4. Record source of acquisition.
5. Record location.
6. Save accession record.

Optional Accessions Workflow

1. Select option to add new accession record or to edit an existing accession record.
2. Record accession unique identifier.
3. Record date of acquisition of accession.
4. Record location.
5. Record additional administrative information:
   • Donor information
   • Type of accession (e.g., Deposit, Gift, Purchase, Transfer)
   • Source of Acquisition
   • Record title of accession.
   • Custodial/Archival History
   • Physical content of accession
   • Physical condition of accession
   • Physical Inventory of accession (e.g., box list)
   • Processing Note
6. Add or link additional information to accession record:
   • Extent Information
   • Location Information
   • Rights Information
   • Deaccession Information
7. Link accession record to one or more:
   • Archival Descriptive records
   • Name access points
   • Subject access points
8. Save Accession record

Deaccessioning Workflow

• All Fields are Mandatory

1. Create Deaccession Record
2. Record Deaccession Scope (Whole or Part)
3. Record Deaccession Date
4. Record Deaccession Description
5. Save Deaccession Record

Optional Deaccessioning Workflow

1. Create Deaccession Record
2. Record Deaccession Scope (Whole or Part)
3. Record Deaccession Date
4. Record Deaccession Description
5. Record Deaccession Extent
6. Record Deaccession Reason
7. Record Deaccession Disposition
8. Indicate Deaccession Notification
9. Save Deaccession Record
10. Cancel Deaccession Record
11. Modify existing Deaccession Record

Functional Requirements

• The software must manage accession workflow from creation to deaccession.

• The software must allow the option to create a new accession record or edit an existing accession record.

• Every accession must be documented by one and only one accession record. An accession may be comprised of a single item or an aggregation of materials.

• The software requires a unique accession identifier. The system will automatically generate an Identifier based on Administrator template.

• The software requires a date of acquisition of accession for each record. Note: The date of the acquisition of accession materials is the date of receipt that is added during the donation process. A timestamp should be generated by the system when the accession record is started.

• The software should capture the type of resource represented by the accession. (e.g., Public Record Transfer or Private Records)

• The software must provide the option to indicate if the record is public enabled. This item is under review. Why would the Accession Record need to be made available to the Public? Artefactual team has decided that the Accessioning Record will not be made public, and the feature of enabling will not be included in the module.

• The software should capture donor restrictions. If possible, FOIPPA restrictions should be captured for individual record and sets of records. Could this be captured in the Accession Record Rights area and be linked to the Descriptive Record? This requirement was requested by City of Vancouver Archives as a High Priority.

• The software should capture Copyright Holder and Copyright Status. This information is captured in descriptive, but once the records become Public Domain it is erased from descriptive record. Could this be dealt with in the Accession Record? This requirement was requested by City of Vancouver Archives as a High Priority.

• The software must link accession records to descriptive records (and vice versa). Each accession record may be linked to zero or more resources.

• The software should list the accession records linked to an archival description and should include all accession records linked to lower levels of description in the same descriptive hierarchy. (optional)

• The software must allow navigation between accession records and descriptive records.

• The software should provide the option to restrict public access to records according to rights restrictions (e.g., copyright or FOIPPA).

• The software must save the accession record.

• The software must enable pre-populated descriptive record with accessions record information.

• The software must enable deaccessioning. The linked descriptions would require manual deletion by the Administrator to remove from public view.

• The software must provide customizable reports (eg., Accession or Donor Form.) This requirement was requested by City of Vancouver Archives as a High Priority.

Metadata Requirements

Accession record

• schema definition

De-accession

Rights

Like an Accession Record, Rights are their own individual entity in the Qubit data model.

Rights entities can be linked to accession records, information object (intellectual entity) records, and digital object (manifestations) records.

When the 'Create Archival Description' option is selected, a copy of each of the rights records linked to the accession record are made for the new archival description, i.e. rights may be revised over course of archival description but original rights records remained versioned against the accession record.

Record Linking/ Data Relationships

• Accession Records to Archival Description (Many to Many)
• Accession Records to Donor Name (Many to Many)
• Accession Records to Authority Records (Many to Many)

• Accession Records to Deaccession Record (One to Many)
• Accession Record to Extent subrecords (One to Many)
• Accession Record to Date subrecords (One to Many)
• Accession Record to Rights subrecords (One to Many)
• Accession Record to Location subrecords (One to Many)

Copying fields from accession records to information objects

UI Design

• 

  Add Accession Record

• 

  Accession Record Edit Area

• 

  Donor/Transferring Body Area

• 

  Administrative Area

• 

  Rights Area

• 

  View Accession Record

• 

  Deaccession PopUp

• 

  ISAD(G) Descriptive Record with Accessions links

• 

  RAD Descriptive Record with Accessions links

User Feedback for enhancing Accession feature

The Accession module was introduced into ICA-AtoM release 1.2 in November 2011. Following release a number of questions were asked on the ICA-AtoM user forum and over the support forum regarding the functionality of the new accession feature and suggestions were made in response to use cases. The purpose of this section is to document accession-related discussions and issues in order to provide a platform for future development, when funding can be obtained.

LINKING

• Link accessions to existing fonds.
• Link existing fonds to existing accession records. (This relates specifically to legacy data).

• Link to physical storage interface that is available for archival descriptions should be available for accessions. Relationship needs to be one to many (one accession to one or many boxes or physical objects). (The current ICA-AtoM accession template offers "location information" field, but this does not allow for printing a box location list report). See Redmine Issue 4540

SEARCHING

• The current Accessions search interface only allows searching by accession identifier. A new feature suggestion is to allow searching within the accession records, provided through the search box accessible from the Browse Accession screen. SFU has suggested an advanced search screen, which would give access to individual fields and their drop-down values.

ACCRUALS

• Accruals is a data entry field in Archival description template (ISAD and RAD); however, accruals is not a data entry field in the accession template. Add a dedicated field (Accrual status) with a customizable value list, suggested by SFU.
• What is the relationship between an accession record and accruals? See User Forum string: Adding Accruals
• Provide accrual workflow examples in User Manual.
• See comment below suggesting Unit of description field.

RIGHTS

• Suggestion made by SFU that current rights module in accession template is too granular. Donors cannot typically transfer copyright to ALL items in accession (third-party copyright); cannot limit to series/file/item level until material is arranged and described; and typically only make detailed determination of copyright as needed (i.e., on receiving request for reproduction).

SUGGESTED ADDITIONAL DATA ENTRY FIELDS

• Legal transfer date field: ICA-AtoM does not distinguish transfer of physical custody only from transfer of both custody and control (legal ownership). (Current ICA-AtoM accession data entry template provides Acquisition date only.)
  • Use case: donor wants to transfer material and also wants tax receipt; monetary evaluation must be done in same year as transfer,but typically only after arrangement and description complete; but may not be able to process within same year. Need ability to take material in, capture some descriptive info, and bring under physical control in the storage system; but treat as "pending accessioning", i.e. ownership remains with donor until Archives is ready to process and sign off formal paperwork. Add dedicated field Accession date. Alternatively, allow repeating set of Action/Date fields: Action (Transfer of custody, Transfer of ownership, Processed), Date, Staff name.
    • An alternative to the Action/Date fields, would be to create two new fields "Processed date" and "Processed by".
• Staff acquisition field: Needed for accountability, could include drop-down value list with staff names. (Current ICA-AtoM accession data entry template has a Processing Notes field - free text, which could be used for this purpose).

• Control area field: Track database record creation and revision with "Date record created, Last modified date, Last modified by"

• Appraisal, destruction and scheduling field: Could be mapped to ISAD in generated information object, but not mapped to RAD (since field does not exist in RAD).
  • Disposal authority field: Could be included in "Appraisal, destruction and scheduling field" or be a dedicated field with a link to a url of schedules if these are available online. SFU suggests it would be useful for scheduling transfers of university records, as well as Agreements to Transfer with private organizations that stipulate regular accessions.

• Creator copyright transfer field: yes/no toggle (see discussion above regarding granular rights)
• Conditions governing reproduction field: free-text
• Conditions governing access field: free-text

• Unit of description field: This field would link accession to fonds or series (highest level). Could allow multiple values for cases in which accession contains records from multiple fonds.

• Date range, Start and End fields: Populate start and end number fields automatically from Date range text field. needed for management and access purposes. SFU e.g., backlog reduction grants require date range information; occasionally we may provide access to unprocessed holdings.

• Forms of material field: Customizable value list; allow multiple values. This would be useful for flagging materials that may have special storage/processing requirements, and for occasions when we provide access to unprocessed holdings; easier to search if there is a dedicated field using controlled terms (e.g., RAD GMD terms).

• Language of material field: value list for individual languages; allow multiple values.

SUGGESTED ADDITIONAL TEMPLATE

• Create separate Appraisal Table: linking an appraisal action (appraisal for acquisition, appraisal for selection, monetary appraisal and deaccession) to an accession or a unit of description or both.
  • Use Case provided by SFU: Monetary appraisals typically done after processing and may map to more than one accession; probably best handled separately from both the Accession and Description record.

DEACCESSION FEEDBACK LINKING

• Currently one deaccession maps to one accession; but typically a single deaccession may map to 0, 1 or many accessions (e.g., deaccessioning material that was never formally accessioned).Need to de-couple Accession and Deaccession records. Suggestion - add "Accession field" and allow multiple values. See note above regarding Appraisal table: If deaccessions were de-coupled from accessions, could be re-configured as an appraisal entity; deaccessions would be only one type of Appraisal. Appraisal record could be linked to 0,1, or many Accessions, descriptions and boxes.
• Link to boxes: Should be able to select individual boxes if they already are registered in the system.

DEACCESSION FEEDBACK ADDITIONAL FIELDS

• Unit of description field: with interface for searching/ navigating to/ selecting unit: allow multiple values. Should be able to select the descriptive unit to which the deaccessioned material belongs if it has already been arranged and described. (In current ICA-AtoM this can be added to the "description" field in the deaccession record).

• Unique deaccession ID field: sound auto-generate a unique ID (Current deaccession number in ICA-AtoM template is a text field and is user generated not auto-entered).
• Deaccession by field: customizable value list for staff. This is needed to support accountability requirements for some institutions. (This info could be included in the Description field in current ICa-AtoM template).

ACCESSIONS USER INTERFACE

• Structure accession fields into areas. Proposed areas: Summary, Donor/transferring body, Actions/dates, Terms of transfer, Description, Appraisal and processing, Control
• Add Context menu that provides links to: Donor, Creator, Fonds, and Physical storage

ACCESSIONS NEW FEATURES

• Support import of accession records
  • Use case: accession records are currently automated using another database. There should be a method for exporting accession records as text or xml files to be uploaded in ICA-AtoM.
• Support export of accession records
  • Use case: export accessions data for statistical analysis in other programs (e.g., Excel, Filemaker)
• Print accession form needs improvement (current report is not attractive or user-friendly)
• Generate statistical reports (currently not supported by ICA-AtoM). E.g., how many accessions, how many meters of materials, how many MB of materials, totals broken down by: creator, fonds, acquisition type, disposal authority etc.

User submitted mock-ups for enhancement

• The following mock-ups were submitted by Simon Fraser University's Richard Dancy and Paul Hebbard.
• 
• 

</div>

1.3 Release Accessions Enhancements Introduced