Accession record mapping

Here’s what we have done and where we are with mapping our Beast accessions information to ArchivesSpace accession records:

  1. Play around in ArchivesSpace. Create new accession records with example data. See how these records interact with agent and subject records. Explore how spawning records into resource records work. Figure out how event records work (new to Aspace). And so forth.
  2. Analyze the Accession CSV Map and Accession CSV Template available on the ArchivesSpace Data Import and Export Map page. Ask questions about the mapping as the map contains a few errors (see below).
  3. Begin matching fields from the Beast database to the ArchivesSpace accession fields. Start parsing out our fields to their destination fields in the CSV template, including doing some data clean up by hand. This step helped to start identifying data clean up issues
  4. Do some test imports of populated CSV template. A good reminder that ArchivesSpace is still very much in active development. (ex: importing of agents had been turned off in the version 1.0.4 as in previous versions the importer was duplicating agent entries.  Sadly, I did not realize this and spent a good 30 minutes trying to make my import take the names!)
  5. Adjust and continue refining map as you get into the details of your legacy data.

I added information about our database fields to the CSV map and sharing here:


A few things to note:

  • There are five fields which are included in the CSV map, but do not currently import. I highlighted them in red with a note.
    • We do not really have this data in our current records, so no worries for now.
  • There are ten fields which the map states are collection management records in Aspace, but they are really event records. I highlighted these fields in yellow with a note that they create event records.
    • On first glance collection management makes sense as it describes the activity these fields perform. I’ll confess I spent more time than I should have looking for them in that section of Aspace, before someone alerted me they are event records, which even if connected to a particular accession you don’t see when viewing that accession record (that will change in an upcoming release.)
  • Our data is messy. So messy. Information from the archdescid:abstract field might show up in 23 Aspace accession record fields. 23!
    • To be fair, this represents 11 different types of information as fields are more narrow in Aspace. (ex: A date range in the abstract doesn’t just move to a “date” field, but will move to 5-6 date fields based on the content.)
    • 11 is still a lot of different types of information crammed into one field.

Next we will start diving into the questions our data is pushing.


2 thoughts on “Accession record mapping

  1. Hi Cassie,

    In your spreadsheet, I didn’t see any data that looked like location information- only a few references to location information from the Beast. Are you importing any accession records with their associated location information into ASpace?

    We’re in the beginning stages of mapping FileMaker Pro (FMP) database fields to ASpace fields. I’m trying to figure out if ASpace has the capability to import accession records with associated location information. Since our data is presently in FMP, our import will be done via csv.

    I looked at the locations spec and for imports it says “none are supported independent of an Archon, AT, ArchivesSpace migration,” which we will not be doing since we use FMP (but I wasn’t sure if this only meant importing locations separately from a resource/accession). When I reviewed the ASpace Accession Template for importing, I didn’t see any columns for location information. I also couldn’t find any details in the ASpace Pivotal bug/feature tracker, and haven’t gotten a response in the Google group yet.

    My worry is that we will need to manually link each record to its physical location(s)? All of our current accession records have associated locations, so the thought of reentering this data manual makes me really, really sad (think crying kittens sad). I’m hoping I’m missing/misread something. Any information would be great.

    And to all the authors of this blog- thanks! I stumbled here today in the midst of a desperate Google search, and the information is great, as is knowing that we’re not going at this alone.


  2. Short answer is you’re right in that currently ArchivesSpace doesn’t give you an easy way to import locations. Assigning locations in ArchivesSpace is very similar to assigning locations in Archivists’ Toolkit. In order to assign a location you need an instance within the accession or resource record (in AT you needed an instance for resources, but not for accessions.) Now that I’m facing this in again migrating our data out of our Access database I haven’t quite decided on the best plan of attack since we’re in the same boat as you.

    At UO when implementing AT a few years ago we did a non-elegant workaround. For accessions, we imported our locations to one of the user defined fields. Then, over time, we (students) searched for records that had a value in that field, opened each one, assigned the location in AT, then removed the value from the user defined field.

    Resources we imported came in with instances, usually made by us in our data clean up phase at the aggregate level. A resource with a full container EAD might have imported an instance for each of the 50 boxes, but we then created “collection level” resources to assist in assigning locations. So, an instance for Mixed materials, Boxes 1-50 if all shelved in the same place or multiple instances if shelved in different places, eg Boxes 1-32 and another instance of Boxes 33-50, etc…) Again the import process doesn’t link the instance to the location, so our work around was to add the location to the instance value: Boxes 1-50 [location code]. Over time, locations were assigned to these instances and the location information removed from the instance information. I probably have screenshots around somewhere…..

    So, is there some other better workaround to not importing location information? Probably, but at least in the way we approached it we were able to have the information in AT with the import and it really didn’t take that long to assign the locations and get everything in its place.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s