The spreadsheet that was presented at the ASA Conference (click to open)

Back in October 2018, Piers presented to the 2018 ASA Conference with Bootstrapping small archives. One of the key artefacts from this was an Excel workbook that could be used to help describe your archival collection in line with the concepts that underpin the Australian Series System.

In my blog, I want to go a step deeper and look at the process describing the attributes you might want to keep at the item level.

As a TL;DR version of the workbook created for the conference, you have groupings of records (Series) which have timebound relationships (Relationships) to organisations or business units that may have created or administered the records (Agencies), which also have time bound relationships to what that Series represents or the Agency did (Functions) at that point in time. Inside a Series, you have lower level objects (Items), that you may wish to describe in a variety of ways, but represent the things within the archival holdings or collection.

It’s beyond the scope of this simple blog (and my knowledge) to look at the intellectual underpinnings of how you might define an item – such as whether you separate descriptions from the object, or treat Series as parent objects, or items with partials and child relationships. That is all for overall management strategy. Rather, this blog is just presenting some questions you want to ask yourself about what data you want to capture at the lowest level of description – however you’ve chosen to define it.

Perhaps with these thoughts you might wish to grab the Excel workbook, and change up some of the column headers in the ‘Item’ sheet to match the considerations below, or that match what data or information you are already capturing.

I’ve put these questions into some broad categories of the types of data you might want to capture, and some thoughts about how you might want to move forward once answering the questions.

• Naming – what identifiers do you want to use, and do you need to retain external / alternative identifiers? Do you want to inherit some related areas into the name to give a shorthand way of understanding the context – like the Series of current storage location? Do you want a human readable title as well? Depending on these questions you might be able to just use a system generated ID, or you might need additional fields for context.
• Dates – do you split Start Date and End Date or can you support Date Ranges? what date qualifiers do you want to use? How close can you get to ISO-8601 standards or extensions of the standard? Be careful with your qualifiers and try to use as few possible, maybe just something along the lines of circa, and be consistent. If you’ve got nice clean date data, a date range could be ideal, otherwise splitting start and end dates and keeping qualifiers in another field could be more useful, so it can exported and dealt with in another system.
• Relationships – what needs to be related, and what can be inferred? It’s nice to draw out what the relationships are, and if there are cases where there is always a consistent relationship, eliminate it from being explicitly expressed so it does not need to be maintained (e.g. if all items in a Series are related to an Agency, then you can infer the relationship between Agency and Item via the Series and you do not need to maintain that relationship). Often this is not possible, but worth considering.
• Description – what data needs to be captured at the item or record level vs what data you might want to consider holding at the Series level? Do you want a set of descriptions with each one having a specific meaning or context? Thinking about the data you want in this description layer/s may have implications for how you describe your items or how you might use controlled content fields for different parts of the description.
• Type – what is in the collection or holding and how is it classified? Do you need a controlled vocabulary (e.g. paper, maps, microfilm, digital files)? Do you need to describe partials (e.g. part of another item)? If the collection or holding is homogenous maybe a simple text description suffices, or maybe you might need relationships between items, or you might even need descriptive fields on the type (e.g. size, weight)
• Change history – how do you track changes? will a “last changed date” and “last changed by” suffice? If not, you might need some more comprehensive software that can track all log changes.
• Containers – where are the records held? Do you just need a reference to somewhere else? Or do you need track movements? If you need to track movements you may need to keep that as a separate description and link to it.
• Restrictions / preservation – should the data have any usage restrictions? Such as personal data, or preservation problems? If so, is it the metadata or the item? How long should it be restricted? If there’s preservation problems, when should you re-examine the record? If all of these are relevant considerations you may need to describe each, if none are relevant, you may not need to describe any.

All or some of these questions may be excessive for a small archive. Nevertheless, it’s not a bad idea to ask them, and think if the item data fields you have are capturing all the details you may need.

Hope it helps!  If you have any queries, then feel free to drop me an email, or start a conversation with us on Facebook, Twitter or LinkedIn,

Morgan