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:

Important

This page contains the historical development documentation for the accession module in ICA-AtoM and AtoM, which was originally added to an earlier development wiki (Qubit Toolkit). The content was last updated July 26, 2013.

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

Select option to add new accession record or to edit an existing accession record.
Record accession unique identifier.
Record date of acquisition of accession.
Record source of acquisition.
Record location.
Save accession record.

Optional Accessions Workflow

Select option to add new accession record or to edit an existing accession record.
Record accession unique identifier.
Record date of acquisition of accession.
Record location.
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
Add or link additional information to accession record:
- Extent Information
- Location Information
- Rights Information
- Deaccession Information
Link accession record to one or more:
- Archival Descriptive records
- Name access points
- Subject access points
Save Accession record

Deaccessioning Workflow

All Fields are Mandatory

Create Deaccession Record
Record Deaccession Scope (Whole or Part)
Record Deaccession Date
Record Deaccession Description
Save Deaccession Record

Optional Deaccessioning Workflow

Create Deaccession Record
Record Deaccession Scope (Whole or Part)
Record Deaccession Date
Record Deaccession Description
Record Deaccession Extent
Record Deaccession Reason
Record Deaccession Disposition
Indicate Deaccession Notification
Save Deaccession Record
Cancel Deaccession Record
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

Field	Values	Definition	Validation	Status	Review
Accession record edit area
Accession number	Unique identifier	Accession number should be a combination of values recorded in the field and should be a unique accession number for the repository	Required
Acquisition date	day/month/year	Accession date represents the date of receipt of the materials and is added during the donation process.	Required
Source of acquisition		Identify immediate source of acquisition or transfer, and date and method of acquisition IF the information is NOT confidential	Required
Location information		A description of the physical location in the repository where the accession can be found. Free text field.	Required
Donor / Transferring body area
Dialog?
Field	Values	Definition	Validation	Status	Review
Name		This is the legal entity field and provides the contact information for the person(s) or the institution that donated or transferred the materials. It has the option of multiple instances and provides the option of creating more than one contact record using the same form.
Contact information		Mailing address, phone and email of the donor, the transferring body and/or the contact person(s).
Administrative area
Field	Values	Definition	Validation	Status	Review
Acquisition type	Deposit Gift Purchase Transfer	Term describing the type of accession transaction and referring to the way in which the accession was acquired.
Type of resource of accession	Public transfer Private transfer	Select the type of resource represented in the accession, either public or private.
Title		The title of the accession, usually the creator name and term describing the format of the accession materials.
Creator / Department		The name of the creator of the accession or the name of the department that created the accession
Custodial / Archival history		Information on the history of the accession. When the the accession is acquired directly from the creator, do not record an archival history but record the information as the Immediate Source of Acquisition
Scope and content		A description of the intellectual content and document types represented in the accession
Physical condition		A description of the physical condition of the accession and if any preservation or special handling is required
Received extent units		The number of units as a whole number and the measurement of the received volume of records in the accession
Processing priority	High Medium Low	Indicates the priority the repository assigns to completing the processing of the accession
Processing status	Complete Incomplete In-Progress	An indicator of the accessioning process.
Processing notes		Notes about the processing plan, describing what needs to be done for the accession to be processed completely.

Optional fields under consideration
Field	Values	Definition	Validation	Status	Review
Expected completion date		Include day/month/year that accession process should be completed			Not needed by CVA. Not to be included in accession module.
Retention Schedule					Not needed by CVA. Not to be included in accessions module.
Inventory				Not added to MockUps yet	Under review
Notes
Linked subjects	terms
Linked names	authority records (actors)
Linked resources	archival descriptions

De-accession

Field	Values	Definition	Validation
Deaccession area
Deaccession scope	Whole Part	Identify if the whole accession is being deaccessioned or if only a part of the accession is being deaccessioned	Required
Date		Date of deaccession	Required
Description		Identify what materials are being deaccessioned	Required
Extent		The number of units as a whole number and the measurement of the records to be deaccessioned
Reason		Provide a reason why the records are being deaccessioned

Rights

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

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

Field	RAD	ISAD	DC	MODS
Title (title)	Title	Title	Title	Title
Creator (QubitRelation)	QubitEvent	QubitEvent	QubitEvent	QubitEvent
Physical condition (physical_characteristics)	Physical condition	Physical characteristics and technical requirements	There is not any correspondence	There is not any correspondence
Scope and content (scope_and_content)	Scope and content	Scope and content	Description	There is not any correspondence
Archival history (archival_history)	Archival history	Custodial history	There is not any correspondence	There is not any correspondence

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

Edit Accession record template has new "Information object area" added (in production version ICA-AtoM 1.3 the language for this area will be changed to "Archival description area"). This new area provides a data entry field with autocomplete widget to select new archival descriptions, and allows the authenticated user to link and view existing archival descriptions to a new accession record. There is still the option to create a new accession record, save it, and then generate an archival description using the create archival description button in the button block at the bottom of the edit page. (All screengrabs are from 1.3 trunk version and use the generic Qubit language of information object instead of archival description).

Create new accession record

Here is an example of the new "Information object area" in an accession record that is linked to an existing archival description.

Edit accession record with linked archival description

If an authenticated user wants to create an accrual for an existing accession record that is already linked to an archival description, they will select the original accession record and in the View accession record page they click on the new "Add accrual" button in the button block on the bottom of the page.

Add accrual

ICA-AtoM presents a notice at the top of the edit accession record page "You are creating an accrual of the accession YYY-NN-DD/#."

Edit accrual

When the authenticated user views the new accession record (for the accrual) a new data field "Accrued to" is listed in the Administrative area.Note: "Accrued to" will be changed into "Accrual to", see Issue 2375.

Accrual to

When the authenticated user views the original accession record a new data field "Accruals" is listed in the Administrative area.

New accruals field

When DELETING an accession record, a warning is shown if there are accruals linked to the accession record. An authenticated user may deaccession the records with no warnings.

Delete accession record warning

NOTE: In the View accession record page, if the accession record is an accrual, the "Add accrual" button is not available in the button block. In the View accession record page, if the accession record is an original, the "Add accrual" button is available in the button block.

Accession module: Historical development documentation

Contents