Generated Finding Aid PDFs only shows physical storage location field

[Sandra Yates]

Hello,

We’ve noticed an issue with the generated finding aids since the last major update to 2.6. See example links below.

Currently, the PDFs only provide the data from the Physical Storage Location field. Our use of that field is very general, mostly linking containers to collections. Can the finding aids list the Physical Storage Name field, so Physical Storage Name field (such as Box and Folder numbers) is visible like in previous versions? Is this a known issue? I didn't notice it listed under Finding Aid Issues or mentioned previously in the forum.

Generated Finding Aid, 2.5.3 (has container column): https://archives.library.tmc.edu/downloads/ms-002.pdf

Generated Finding Aid, 2.6.4 (only has Physical Location): https://archives.library.tmc.edu/downloads/ms-243.pdf 

Thank you for all your help!

Sandra

Sandra E. Yates, MSIS, CA, DAS (she/her) Head of McGovern Historical Center Texas Medical Center Library

[Dan Gillean]

Hi Sandra, 

Good catch, and thank you for bringing this to our attention for consideration. 

There were definitely some finding aid layout changes introduced between 2.5 and 2.6, captured in this issue ticket: 

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

This work started as a community pull request that turned into a sponsored development project for Artefactual to finalize the implementation. While replacing the container information with physical description information in the table rows of the inventory summary layout was discussed (and moving the storage information to below the table), I don't recall us intending to change the *type* of storage information included - this may be a bug or intended outcome of the changes. 

I have reached out to the original sponsor of the changes to ask if there was a rationale for such a change that I no longer recall, or whether this was accidental. AtoM does already have a method for users to exclude physical storage information from finding aid (basically: hide storage info via Admin > Visible elements; set finding aids to Generate as public user in Admin > Settings > Finding aid - and then no storage information should appear), so I personally don't think adding this information back in poses any increased privacy or security risk, but I wanted to make sure there isn't some reason I am failing to consider / remember from the original development project. 

From the response I've received back, it sounds like this was a local convention based on how the sponsoring institution uses the storage module and the description identifiers, and was something in the original community pull request that our team at Artefactual didn't catch, rather than a purposeful change we implemented as part of the finding aid layout improvements. 

Correspondingly, I have filed an issue ticket for this, so we can track it: 

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

Any development work related to this bug fix is not currently sponsored, so I can't guarantee any related change will be included in a future release, most notably 2.7 since we are slowly trying to wrap that up and prepare it for public release. That said, we do try to tackle as many bug fixes as we can before a major public release, so hopefully we can address it in the future. Otherwise, I will update the thread if I hear back from the original sponsor as to any rationale. 

In the meantime, I'm not personally very familiar with working with XSLTs, but if you have someone on staff who is, you might be able to compare the 2.5 finding aid XSLT and the 2.6 ones, and make some local changes to your XSLT file to re-add the container info using this. 

The AtoM EAD 2002 XML export of an archival unit (e.g. fonds, collection, etc) is used to generate finding aids - it is transformed into a PDF via our XSLT files: 

• 2.5 XSLT files: https://github.com/artefactual/atom/tree/stable/2.5.x/lib/task/pdf
• 2.6 XSLT files: https://github.com/artefactual/atom/tree/stable/2.6.x/lib/task/pdf
• Basic instructions for changing XSLTs in AtoM: https://wiki.accesstomemory.org/Community/Community_resources/Customization#Instructions_on_swapping_XSLT_files

You can always perform an EAD export yourself to see how AtoM structures the storage information, but here's an example from our demo site: 

<physloc id="physloc0004">Processing Room B</physloc>
<container type="shelf" parent="physloc0004">DD-10/11/12/13</container>

The EAD <physloc> element captures location information, while the <container> element has the actual container info. We use attributes in each element to keep them related - a unique incrementing @ID attribute in the physloc element, with a @parent attribute using the same ID in the <container> element. 

Hopefully by looking at how the container info was added in 2.5 you can make some local adjustments to your current XSLT until we can address this in a public release. 

Regards ,

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/9b9dcbb2-f701-4367-806a-a112947d6c97n%40googlegroups.com.

[Sandra Yates]

Hi Dan,

Thank you for your response. The links you shared were very helpful. I compared the ead-pdf-inventory-summary.xsl file in 2.5 and 2.6. The big difference related to ead:physloc and ead:container seems to be in some new coding in 2.6 XSLT around lines 1599 and 1667 where mode="itemDsc".

I have a very simplistic approach to XSLT. My first thought is to just add the ead:container after ead:physloc.

~line 1599  add <xsl:apply-templates select="ead:container" mode="itemDsc"/>

~line 1667 add <xsl:template match="ead:origination | ead:scopecontent | ead:materialspec
        | ead:physloc | ead:container | ead:note | ead:userestrict" mode="itemDsc">...

I'm not able to test on our local AtoM server at this time, but I will let you know if I have any luck. Our public site is hosted by Artefactual, so we would have to wait for a future update or sponsor the change.

Thanks,

Sandra

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/FDA7NvozMFc/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAC1FhZKiRQ2yTHtfp4v0K9VFOFoExyvf658F_w5fGOV09Gv6BA%40mail.gmail.com.