Context-Specific Identifier Masks

[Paul Ritchie]

Hello All!

This is a newbie question, so hear me out. I've checked the forum history and couldn't find an answer.

I'm handling the migration from our legacy system to AtoM. Expected cutover is November.

As I understand it, the Identifier Mask is 'one size fits all'. Anywhere it would be used (in our case, it could be fond / series / file / item), it just uses the prefix and the next identifier counter.

What we would like is counters which reset to 1 within their parent level and have their own prefix, such as this:

  CH2025/012 (fond)
      S001 (series)
          F001 (file)
          F002 (file)
          ... etc ...
      S002 (series)
          F001 (file)

          ... etc ...

Which would result in reference codes like CA U5122-CH2025/012-S001-F001, CA U5122-CH2025/012-S002-F001

This does not fit the Identifier Mask usage. However, I have seen AtoM sites which do it like my example. How is this done? Manually, or perhaps it is coded locally?

Perhaps the answer is 'don't do like that', but our legacy system is a mess and one thing we want to do right going forward is have decent identifiers. In case our concept is wrong, other suggestions are welcome.

Many thanks
Paul Ritchie

[Paul Ritchie]

The answer is "Inherit Reference Codes", found in Settings > Identifiers.

We have not decided if this will be done in our installation. It seems a nice-to-have. Given that there are already unique identifiers, the additional utility of having the entire hierarchy in a reference code is marginal.

[Stuart Bligh]

Hi - in my experience, it is (or has been) pretty standard archival practice to have ref codes that show the whole hierarchy. I haven't used one for a long time but cataloguing systems like CALM used to create whole hierarchy ref codes automatically as you catalogued and built the collection hierarchy. There wasn't therefore a need to have a function that allowed ref codes to be inherited or not.

I've found that to be a slight issue with CALM when people using it create a hierarchy then if by accident/chance the inherit ref code gets turned on they end up with long duplicated and complicated ref codes. Easy to resolve but I do wonder whether having an inherit ref code function sometimes complicates things? 

Anyway it's a long time since I was properly involved in cataloguing etc so perhaps it's different now!

Stuart  

Stuart Bligh

Archive Advisor

Mob: 07949377526

Tel: 020 8309 5445

Please note that I work part time usually on Tuesdays and Wednesdays

Max Communications Ltd.
2-3, Gunnery Terrace
Cornwallis Road
London SE18 6SW

www.maxcommunications.co.uk

www.royalwarrant.org/company/max-communications-ltd

 

 

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/e7becdf4-1756-4d3c-87fe-4dd994834aa4n%40googlegroups.com.

[Paul Ritchie]

Point well taken, thanks Stuart.

I have added this to my to-do list. Our current system was created 26 years ago, by amalgamating 17 different data sources, many of them spreadsheets, each with their own idiosyncrasies. I am unwinding that with (you guessed it) 17 different data extract / conversion programs. I am coding number seven right now.

On the upside, I have found AtoM's archival description import to be well behaved, once you get the hang of it.

Paul Ritchie

Archivist

Calgary Highlanders Museum and Archives