Question about Physical Storage Taxonomy and Archon Migration (EAD 1.0 to EAD 2.0)

[Dallas Suttles]

Hi everyone!

I am having trouble wrapping my head around the physical storage taxonomy. I am used to working with Archon (see sceenshots). How would I emulate this system in ICA-Atom 2.1? 

 

Right now, I'm confused on how to break down the locations hierarchically. I've tried adding Range, Section, and Shelf in a hierarchical fashion in both the Location and Container sections under the Physical Object taxonomy. But If I use "Box 1" as a location, how can I keep it from being grouped with every "box 1" in different locations? Is there any way to break things down so that there is a link to everything, from Range, to Section, to Shelf, to box in the sidebar? Or do I need to make a new container with a unique id for each item? Below is a screenshot of my effort so far, but I can't help but feel I'm missing something critical:

--------

My second question is: does anyone have experience cross walking Archon EADs (which are 1.0) with ICA-Atom. I have compared the xml file EAD outputs of two identical collections from Archon and ICA-Atom and the results are different enough that I wouldn't know where to start. I am assuming a CSV sheet would be the way to go, but I would like to know if anyone has done this successfully before. 

Thanks for your time!

[Dan Gillean]

Hi Dallas,

Thanks for posting this.

Unfortunately, I don't think you are missing anything about the AtoM Physical storage module. The problem is simply that at the moment, the module is rather flat, and is an area we at Artefactual having been hoping to develop further for some time now.

The default taxonomy in AtoM's physical storage looks like this:


​

While you can create further hierarchical containers and locations (they operate similar to how terms are managed in our taxonomies), the interface for managing them is rather flat - so unless you are using a unique name that will allow you to identify the differences at a glance, there is no easy way, when adding a description to an existing container, to distinguish between multiple "Box 1" entries:


​

The frustrating part is the disconnect between the taxonomy and the interface for managing physical storage. Locations created in the physical storage module are not stored as children of the "Location" node in the taxonomy - and new child locations created in the taxonomy do not appear in an auto-complete field when creating new containers. In fact, it seems that one is not able to reuse locations between containers - it is a flat string stored alongside the container in the database. You *can* create new container types in the taxonomy, and have those appear in the drop-down for container type in the physical storage module, but that is all the interaction currently transpiring between the physical storage module and its term taxonomy:


​

There's also no way to see the relationship between related (associative or hierarchical) locations or containers at the moment.

So, for the time being, I think you are taking the best approach you can. Give your containers unique names or identifiers at the box level to be able to differentiate between them easily. If you continue to manage the shelf information as a separate container, then any description held in a box linked to the same shelf will be visible when you click on that shelf in the physical storage module - but you won't have an easy way to see which boxes are on that shelf, beyond the descriptions the shelf is linked to. Does that make sense?

We would very much like to overhaul the physical storage module in AtoM. I think it needs to be managed like a taxonomy, where broad/narrow containers and locations can be managed, and associative relationships (like related terms) can also be added between both containers and locations. I would also like to see improved physical storage reporting, and the ability to add physical storage information in the accessions module. As you might know, Artefactual is a small company and AtoM is maintained entirely through community-driven development - meaning we hope to find an institution willing to sponsor these improvements so Artefactual can take them on and add them to a public release, or a developer with the resources to tackle this work willing to share the code back with the community.

I wish I had a better answer for you! Perhaps some of our other users might have creative workarounds that they use locally to manage physical storage in AtoM. Any tips for Dallas?

As to the second part of your question - we are undertaking a number of EAD improvements in the 2.2 release, which we hope will bring a few outstanding elements more in line with broader community practice - so this may help make the mapping seem less daunting. Which version of AtoM's EAD output have you been looking at? We have assisted with Archivist Toolkit migrations previously, but I'm not sure we've worked directly with Archon EAD - I'll have to check with our team. Have you tried importing an Archon EAD file into AtoM to see what the initial results are?

Cheers,

Dan Gillean, MAS, MLIS
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "ICA-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 http://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/5effbdf7-2662-4b03-abe2-dad6c5cc6316%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dallas Suttles]

 Thanks Dan, that was helpful. I'm glad to know you guys are planning to expand this feature so it is less "flat". I think I can manage for the time being with the current set up.  As far as importing directly from Archon, it says libxml error 522 on line 0 in input file: no DTD found!   

I am using the EAD 2002 for ICA Atom.  I haven't experimented passed this point yet, so adding the DTD declaration may allow some data to be imported. I will post back here, whatever the results. However, other projects have come up and my ICA-Atom testing has to go on the back burner for a bit.

I highly recommend the ICA-Atom team looking more into Archon for inspiration, as it was a truly great system and much better than AT, in our opinion.  The lack of support  is our number one reason for looking elsewhere as it doesn't work with newer PHP versions and isn't digital object friendly.  

I have also attached two xml files of the same collection in Archon and ICA-Atom 2.1  if you guys want to compare. 

[Dan Gillean]

Hi Dallas,

Well, I'm glad my response was helpful! Hopefully in the near future we can find a community partner willing to sponsor improvements to the Physical storage module.

Regarding the DTD error:

We actually discovered that this error you are encountering is a PHP-FPM configuration issue. If php_admin_value[allow_url_fopen] = on is not included in the PHP configuration file, then PHP will actually block the external URL call to the DTD and return the error. Our 2.1 installation docs now include this in the PHP configuration section:

• https://accesstomemory.org/docs/2.1/admin-manual/installation/linux/#php

Note that allowing external URL calls in your PHP configuration files *could* potentially be a security risk, depending on the other security protocols you have in place. In the future, we hope to validate XML files internally against a local XSD, rather than making an external call. Some work has already been undertaken on this, and a feature proposal ticket filed in AtoM's early days has recently been updated to reflect this:

• https://projects.artefactual.com/issues/2787

The inclusion of this feature in the 2.2 release is still tentative, as the development project proceeds and we figure out how much complexity will be involved. It's definitely something we want to include in a future release, however.

In the meantime, you might try reviewing/editing your PHP configuration files, as outlined in the first link above, to see if this will resolve the DTD error. 

Thanks for sharing the Archon example file! When I have a bit more time, I'll take a closer look, and try importing it into AtoM to see what the results are.

Cheers,

Dan Gillean, MAS, MLIS
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--

You received this message because you are subscribed to the Google Groups "ICA-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 http://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/75363d62-2678-42ef-b126-cb0b584ce8fb%40googlegroups.com.

[Creighton Barrett]

Hi Dallas,

I'm not familiar with Archon, but we have been successfully importing EAD from the Archivists' Toolkit into AtoM for a little while now. Our developer prepared an XSLT stylesheet that does a number of things, such as replacing the Schema declaration with a DTD declaration. We run the transformation in Oxygen and command line import the batch of EAD files. We also did a few things in the backend of the Toolkit to prepare for the export/import scenario.

The differences are not just limited to the DTD header. In particular, I suggest you examine the <physdesc> elements and any nested elements (i.e.., <extent>, <physfacet> or <dimensions>).  AtoM has gone through a number of updates and improvements to the EAD import, so I'm not sure where everything stands at the moment, but we experienced data loss with repeating <physdesc> notes and certain, more obscure, EAD elements. So the stylesheet concatenates all of these complex physical description notes, inserts the proper punctuation from our descriptive standard, and wraps them in a single <physdesc> tag.

Physical storage information from the Toolkit is not importing as part of this routine and we are looking at our options. We would love to see the kind of functionality you're talking about, and I know of at least one other institution interested in the development of this module. I would be happy to chat about this off-list if you're interested in potentially sponsoring development. We'll certainly miss the functionality in the Toolkit and are considering exporting the data as a flat file spreadsheet as an interim measure.

Hope that helps!

Creighton Barrett

Dalhousie University Archives

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZK4L7YruKVyf88yDiAXcz0i1n48eH-6uvU6Xqjxvbeu_w%40mail.gmail.com.