Bug #4972

Physical location and containers will not export from lower levels of description

Added by Dan Gillean about 9 years ago. Updated almost 9 years ago.

Status:VerifiedStart date:04/22/2013
Priority:MediumDue date:
Assignee:José Raddaoui Marín% Done:

0%

Category:EAD
Target version:Release 1.4.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

To reproduce this issue
1) Create an archival description with children (a series with some files)
2) Add physical location links to different levels, top and lower
3) Export from the top level description (fonds): Physical location and container information appears for all levels
4) Navigate to one of the child records that is linked to physical location. Export from that level and compare EAD

Resulting Error
When exporting from a lower level of description, <physloc> and <container> are missing from the EAD.

Example
Compare the results of exporting from the Demo Site at different levels:
Here is a top-level description, in which all information for the children is included: http://demo.ica-atom.org/subject-files-including-council-supporting-documents;ead?sf_format=xml

This description is one of the above description's children, linked to a physical storage location, but the export is not showing these details.
http://demo.ica-atom.org/standing-committee-on-planning-and-development-downtown-transportation;ead?sf_format=xml

Expected Result
EAD should include <physloc> and <container> in the export, regardless of level

History

#1 Updated by José Raddaoui Marín about 9 years ago

I'm trying to reproduce this problem, but I can't.

It may be solved with the fix for visibility of physical storage?

#3 Updated by Dan Gillean about 9 years ago

  • Status changed from QA/Review to Feedback

Hi Radda,

This is coming along well! I have managed to successfully roundtrip physical location information at multiple levels (fonds, series, file) with no information lost. HOWEVER: an warning is generated on import. This is because, looking at the EAD, the id that you have used is not in fact unique in each instance - all levels of physical location (fonds, series, file) had the same @id of "physloc0001." In XML, as I know you've pointed out to me on other issue tickets, we need to ensure that each @id used is unique. My hope for implementing @ID to keep each physloc separate was that they could auto-increment - so we would start with "physloc0001" and progressively go up as physical locations are added, not just at the same level, but throughout the EAD output.

The id is doing a good job of keeping the container and the physloc associated, and if we add multiple physical locations to one level of description then they auto-increment correctly as so:

   <physloc id="physloc0001">Box 2</physloc>
            <container type="folder" parent="physloc0001">
                  folder 6              </container>
                          <physloc id="physloc0002">Box 2</physloc>
            <container type="folder" parent="physloc0002">
                  folder 7              </container>

But now we have a warning when roundtripping because the IDs are not unique in different levels of description (they will start again at 0001).

Can you see if there is a way to autoincrement throughout the entire EAD XML output?

Note that this will also impact issue #3850, which has been marked as verified, but should have addressed this fact: https://projects.artefactual.com/issues/3850#note-34

It was missed perhaps because it was not tested in conjunction with this issue ticket and roundtripped.

Thanks.

#4 Updated by Jesús García Crespo almost 9 years ago

  • Status changed from Feedback to QA/Review

#5 Updated by Jessica Bushey almost 9 years ago

  • Status changed from QA/Review to Verified

Also available in: Atom PDF