Country code in Identifier field

68 views
Skip to first unread message

m.gor...@gmail.com

unread,
Dec 12, 2018, 5:25:20 PM12/12/18
to AtoM Users
We are testing AtoM as a successor to Archon.  When I'm making a new archival description and attach our repository to the Identity Elements section, it auto generates a US at the beginning of the Reference Code field.  We don't want the US to display publicly, or at all, because I assume this field is for the a collection ID number.

And why is it called Reference Code in non-editing mode and Identifier in editing mode?  Why not be consistent?

And for some reason I get a server error when I try to attach or insert screen shots.

Thanks,
Matt
SIU Carbondale


Gomes Silva

unread,
Dec 13, 2018, 9:26:41 AM12/13/18
to AtoM Users
Hello,

In the contact area of your Archival Institution, If you delete the country name then the country code will disappear on all descriptions.
I believe have the possibility to fix some translations using Transifex.

Hope this helps

Dan Gillean

unread,
Dec 13, 2018, 10:48:48 AM12/13/18
to ICA-AtoM Users
Hi Matt, 

In AtoM, an identifier and a full reference code are not exactly the same thing, and the behavior you are seeing with the "US" prefix results from a setting to enable reference code inheritance, which can be turned off if desired. 

In AtoM, an identifier is a unique code for a particular description. By contrast, a reference code follows the recommendations and definition drawn from ISAD(G) 3.1.1: 

Purpose:
To identify uniquely the unit of description and to provide a link to the description that represents it.

Rule:
Record, as necessary for unique identification, the following elements:
— the country code in accordance with the latest version of ISO 3166 Codes for the representation of names of countries;
— the repository code in accordance with the national repository code standard or other unique location identifier;
— a specific local reference code, control number, or other unique identifier.

All three elements must be present for the purpose of information exchange at the international level.

Examples:
CA OTY F0453 (Fonds)
Canada, York University Archives

CA OONAD R610-134-2-E (Fonds)
National Archives of Canada

US MnHi P2141 (Fonds)
U.S., Minnesota Historical Society


To aid archivists in the creation of these unique codes and prevent the necessity of entering the same data multiple times, AtoM has a setting called "Inherit reference code" in Admin > Settings > Global, that when turned on, will construct a full reference code by combining identifiers and other elements recommended in the ISAD(G) definition.  This unique string is built using the archival description identifier plus the identifier of all its ancestors (parent records), as well as the related repository identifier and country code if they have been entered on the associated repository's edit page. The string will appear in this order with the applicable elements:
  • Country code (derived from the country code of the country entered into the contact information of the related archival institution)
  • Repository identifier (derived from the identifier field on the related archival institution)
  • Fonds/Collection level identifier
  • Series identifier
  • Subseries identifier
  • File identifier
  • Item identifier 
  • etc



You can also configure what separator character is used between description identifier elements - by default, a dash character is used: 
As such, when the reference code setting is turned on, then the view page of an archival description will display the term "Reference code." However, when you enter edit mode, you are not actually editing the full reference code (which is being inherited from parent descriptions and the related repository record) - you are editing the identifier for that particular record. This is why the labels are different. 

You have a couple options on how to proceed. 

First, if you want to make use of reference code inheritance, but don't want the country code to display then, as Gomes has suggested, you can remove the Country name from the address field of your related repository record, in the Contact area. Similarly, if you wanted to use reference code inheritance but not include the repository identifier as a prefix as ISAD(G) recommends, then currently your best option is to leave the repository's identifier field blank. 

The other option is to turn off reference code inheritance, and enter the full reference code exactly as you want it displayed at all levels of description. There are many institutions who choose to do this - it means a bit more manual data entry but ultimately gives you more control over exactly how the reference code displays. 

We have had interest from our community in expanding the functionality of the reference code inheritance and separator settings, so users can configure more elements, such as whether or not to include the country code and repository identifier, and how exactly each element should be displayed. We even have a proposal idea captured in a Wishlist development ticket that would use a model similar to AtoM's accession and identifier mask options, to allow a variety of different implementation options - see: 
To be able to implement such functionality, the AtoM project depends on the support of its user community. As you may know, Artefactual develops and maintains AtoM, releasing everything related to the project under open licenses. We also collect community feedback about bugs and invest our own time in fixing as many as we can in each release - the recent 2.4.1 release for example addressed over 55 bugs, many of them first reported via this forum. However, as a small company who basically gives away most of our core work for free, we depend on community support for feature development and enhancements, either via paid development support, or community code contributions. Any time an institution sponsors an enhancement in AtoM, we will design it in such a way so that it meets the specific needs of the sponsoring institution, but is also generalized enough in its implementation to conform to any relevant standards and best practices, and can be useful to the broader community of users as well. The sponsoring institution gets access to the sponsored feature immediately, and the new functionality is then also included in the next major public release, so that the entire community benefits. This is how we've maintained and developed AtoM for 10 years now - everything you seen in AtoM has been sponsored and refined by dozens and dozens of institutions over the course of the project. To learn more, see: 
If your institution is considering AtoM but would like to see the current reference code behavior enhanced, and you might be interested in sponsoring ticket #12365 or similar improvements, please feel free to contact me off-list, and Artefactual can prepare a development estimate for you. 


As a final point, I will say that overall you will find a number of differences between AtoM and Archon, and a successful migration will depend on understanding how the systems are different. One of the key differences to keep in mind is the distinction between physical and intellectual arrangements. 

Archon was first developed primarily as an EAD authoring tool, and seems to make no distinction between the physical arrangement of materials (i.e. items in folders in boxes on shelves) and the intellectual arrangement of your holdings (i.e. items in files in series in record groups, collections, or fonds - where an intellectual unit of "file" might actually represent multiple fonders in the phsysical storage of the materials). The ability to use Archon as your public-facing web-based catalog came later in the project - the tools purpose was focused on arrangement and description. 

AtoM, in contrast, began with a focus on web-based access as one of its core tenets from the beginning, in addition to arrangement and description. Additionally, in AtoM each record, down to the item (or even sub-item, if you are including parts or views or components as separate descriptions) can be arranged, described, and given its own full edit template, and the intellectual arrangement (based on core archival concepts such as respect de fonds and original order) is thought of as distinct from the physical arrangement, which may change as materials are accessioned, processed, and re-housed for long-term storage and future access. Physical storage information is part of a different module that can be linked to descriptions via many-to-many relationsihps. 

Admittedly, AtoM's physical storage module is currently quite limited, and there has been a lot of interest in our community in developing this further, but this separation is important to understand if you are coming from Archon - "Box" is not a default level of description in AtoM, since it generally denotes physical arrangement, not intellectual, and while you can create a "Box" level of description (all levels of description in AtoM are customizable terms maintained in a taxonomy that administrators can edit), you could equally just link a number of file-level descriptions in an intellectual series to a box in the physical storage module. 

Many users we've migrated from Archon do in fact choose the former approach and create a "Box" level of description - AtoM is flexible enough that you can use it in a manner more similar to how Archon was organized, and if you export your Archon records in EAD XML right now, boxes are treated as <c> levels in the resulting XML, rather than using the <physloc> and <container> components exclusively. As such, this is generally the path of least resistance when moving from Archon to AtoM - but your migration will go smoother overall if you are at least aware of this difference going in, and can make choices around your migration with these distinctions in mind. 

Let us know if you have more questions! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory


--
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 post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a3538909-6638-4b83-918c-82300f0dcc9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

m.gor...@gmail.com

unread,
Dec 14, 2018, 11:02:42 AM12/14/18
to AtoM Users
Thanks Dan!  Lots to digest here.  I'm continuing to play with AtoM and will post more questions as they arise.

Matt

m.gor...@gmail.com

unread,
Jan 11, 2019, 4:27:16 PM1/11/19
to AtoM Users
I learned that by checking "no" in the

Dan Gillean

unread,
Jan 11, 2019, 5:04:03 PM1/11/19
to ICA-AtoM Users
Glad to hear it, Matt!

Yes, that was my second suggestion - though I understand I sent you a lot of text; it might have gotten lost in there!

The other option is to turn off reference code inheritance, and enter the full reference code exactly as you want it displayed at all levels of description. There are many institutions who choose to do this - it means a bit more manual data entry but ultimately gives you more control over exactly how the reference code displays. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

Reply all
Reply to author
Forward
0 new messages