Levels in hierarchy/treeview without reference codes

[Rebecca Hughes]

Hello all,

I've looked through the documentation and user group and couldn't see anything on this; apologies if I'm repeating something which has been covered before.

Several of our older catalogues only have two levels below fonds level: a class or section level and then an item level. Any further divisions are not reflected in reference numbers. This was fine in printed catalogues, where descriptions can be divided by headings, but does not work well in AtoM as we can end up with 'flat' structures with hundreds of item descriptions at the same level. For an example see our catalogue of the papers of J. J. Thomson, where the 'Family and personal papers' section includes over 700 items which fall into multiple sub-divisions. I've tried to indicate sub-divisions by use of colons etc, but it's still hard for the eye to cope with.

https://archives.trin.cam.ac.uk/index.php/section-b-family-and-personal

If we create child levels with no reference number, it's possible to add child-levels to those with reference numbers and construct divisions that way. So using the J. J. Thomson papers as an example, a child level with no number could be created in 'Family and personal; papers' with the description "1-679: Correspondence". The reference of a child of this level would be THMJ II/B/1. Further sub-divisions could be created in the same way.

We wanted to know whether this work-around was likely to cause any problems at the moment and especially with future iterations of AtoM, and whether anyone else had used a similar approach. We realise that exporting data with these sub-divisions would require particular care, - it's not something we want to use often, but a few of our older collections really would benefit from it.

All best,

Rebecca Hughes

Assistant Archivist

Trinity College, Cambridge

[Dan Gillean]

Hi Rebecca, 

I'm not sure I fully understand your exact use case, but: even with reference code inheritance turned on, the quick tests I performed did not cause any issues when intermediary levels had no identifiers. 

One interesting thing I did note during my test, however: 

I first created my test description in the public demo site. I created a collection with an identifier, a series with no identifier, and then a file with one. With reference code inheritance on and the default dash character used as a separator, I ended up with my file level descriptions having identifiers with two dashes in them (indicating where the missing series identifier would be in the inherited full reference code), like this: 

CA REPOCODE COLLECTIONID--FILEID

However, I then exported that hierarchy as a CSV, and imported it into my local Vagrant test box. The import worked fine and all records displayed properly. However, once imported, the empty placeholder dash was gone, so the full reference code was just: 

CA REPOCODE COLLECTIONID-FILEID

This was maintained even when I changed the default separator in the Inherit reference code settings. 

Anyway, at no point in my tests, admittedly quick, did excluding an identifier at the series level cause an error or bug for me. A couple of considerations however: 

First, I did not experiment with including spaces in a single description's identifier and seeing how that might affect reference code inheritance. I suspect it will be fine but might be worth experimenting with a bit. 

Next, please note that while it's definitely viable, using slashes  either directly in identifiers or as the default separator in the inherited reference codes can have impacts on the search functionality when trying to find records by reference code. This is because the slash is a reserved character in Elasticsearch, the search index that AtoM uses. Not escaping it when searching can cause search errors. 

You can work around this by adding the slash as a character to be automatically escaped in searches in the settings - see: 

• https://www.accesstomemory.org/docs/latest/user-manual/administer/settings/#escape-special-characters-from-searches
  

However, this workaround is not perfect either. To learn more, please be sure to read the "Important" admonition text box in the docs section linked above. 

Ultimately, the best way to make sure the behavior will work as expected is to run some tests of your own. If you don't want to make test descriptions in your production environment, consider setting up a local Vagrant test environment to play around in: 

• https://www.accesstomemory.org/docs/latest/dev-manual/env/vagrant/
  
• https://www.slideshare.net/accesstomemory/atom-and-vagrant-installing-and-configuring-the-atom-vagrant-box-for-local-testing-and-development
  
• See also: https://www.slideshare.net/accesstomemory/creating-your-own-atom-demo-data-set-for-reuse-with-vagrant

Cheers, 

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

@accesstomemory

he / him

--
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 on the web visit https://groups.google.com/d/msgid/ica-atom-users/a737239d-868a-47c4-b00c-f45512c94589n%40googlegroups.com.