Bug #6317

EAD <repository> will not import properly if it is not nested in a <corpname> element

Added by Dan Gillean over 6 years ago. Updated 8 months ago.

Status:VerifiedStart date:02/13/2014
Priority:MediumDue date:
Assignee:-% Done:

0%

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

Description

To reproduce
Import an EAD file with the archival institution name wrapped in <repository>, but not nested in <corpname>

Resulting error
Though the use of <corpname> is optional within the <repository> element, AtoM expects it because that is what AtoM outputs. Consequently, EAD imports that do not use <corpname> nested inside of <repository> will drop the repository name, and fail to link the archival description to an archival institution on import.

Here is a valid example from the EAD Tag library description of the <repository> element:


<archdesc level="otherlevel" otherlevel="Lettercode">
            <did>
                <unitid>EW</unitid>
                <unittitle>Records of the Department of Economic Affairs</unittitle>
                <origination><corpname>Department of Economic Affairs</corpname></origination>
                <unitdate>1945-1979</unitdate>
                <physdesc><extent>28 </extent>
                    <genreform>classes</genreform>
                </physdesc>
                <repository>Public Record Office, Kew</repository>
            </did>
        </archdesc>

The above example would fail to link the imported description to an archival institution record for the Public Record Office, Kew.

See: http://www.loc.gov/ead/tglib/elements/repository.html

Expected result

EAD imports properly, and is connected to an archival institution record, regardless of whether or not the <corpname> element is used.

This issue was first reported in our user forum - see: https://groups.google.com/d/msg/ica-atom-users/B0g4dRbywyk/v2JaG6sO23MJ

Tentatively assigning to 2.0.2.

History

#1 Updated by Dan Gillean over 6 years ago

  • Priority changed from Medium to High

Bumping this issue to high, as not including the <corpname> element will break key functionality in AtoM, even though it is valid EAD not to do so - namely, the repository will not inherit properly, nor will publication status. See this thread in the user forum for more information:

https://groups.google.com/d/msgid/ica-atom-users/4ae683ae-e531-47b9-8733-0c5f8a848008%40googlegroups.com

#2 Updated by Dan Gillean about 6 years ago

  • Assignee changed from José Raddaoui Marín to Jesús García Crespo
  • Priority changed from High to Critical
  • Target version changed from Release 2.0.2 to Release 2.1.0
  • Tested version 2.0.1 added

Bumping this to critical - as it should be an easy fix, one we have hoped to include in the 2.1 release, and will improve the fidelity of our EAD import.

#3 Updated by Jesús García Crespo about 6 years ago

  • Assignee changed from Jesús García Crespo to Mike Gale

MikeG, this is for you :)

#4 Updated by Jesús García Crespo about 6 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Mike Gale to Dan Gillean

#5 Updated by Dan Gillean about 6 years ago

  • Status changed from QA/Review to Feedback
  • Assignee changed from Dan Gillean to Mike Gale
  • Priority changed from Critical to Medium

Downgrading status because as it is, it covers the most common use cases.

Right now, import will work with the current setup, e.g. something like this:

<repository>
  <corpname>Dundas Museum and Archives</corpname>
  <address>
    <addressline>139 Park Street West</addressline>
    <addressline>Dundas</addressline>
    <addressline>Ontario</addressline>
    <addressline>Canada</addressline>
    <addressline>L9H 1X8</addressline>
    <addressline>Telephone: 905-627-7412</addressline>
    <addressline>Fax: 905-627-4872</addressline>
    <addressline>Email: skiemele@dundasmuseum.ca</addressline>
    <addressline>www.dundasmuseum.ca</addressline>
  </address>
</repository>

... and it will work with:

<repository>New Wesminster Museum and Archives</repository>

It will not work, however, if the repo name is not in a <name> or <corpname> element (but just PCDATA instead, and there are nested <address> elements as well, like this:

<repository>
  Dundas Museum and Archives
  <address>
    <addressline>139 Park Street West</addressline>
    <addressline>Dundas</addressline>
    <addressline>Ontario</addressline>
    <addressline>Canada</addressline>
    <addressline>L9H 1X8</addressline>
    <addressline>Telephone: 905-627-7412</addressline>
    <addressline>Fax: 905-627-4872</addressline>
    <addressline>Email: skiemele@dundasmuseum.ca</addressline>
    <addressline>www.dundasmuseum.ca</addressline>
  </address>
</repository>

I think this third scenario is far less likely - but ideally we could accommodate it as well, because it's technically allowed, and you just never know. If it proves inordinately complex, I think this fix is acceptable as is, and will cover about 95% of actual use cases.

#6 Updated by Jesús García Crespo about 6 years ago

  • Target version changed from Release 2.1.0 to Release 2.1.1

#7 Updated by Jesús García Crespo almost 6 years ago

  • Target version changed from Release 2.1.1 to Release 2.2.0

#8 Updated by Dan Gillean over 5 years ago

  • Target version deleted (Release 2.2.0)

#9 Updated by Mike Cantelon 10 months ago

  • Status changed from Feedback to Code Review
  • Assignee deleted (Mike Gale)

PR: https://github.com/artefactual/atom/pull/1019

Here are the EAD import scenarios I tested:

1. Repo name directly in repository element with no emph tag formatting and with a child address element
2. Repo name directly in repository element with no emph tag formatting and no child address element
3. Repo name directly in repository element with emph tag formatting and with a child address element
4. Repo name directly in repository element with emph tag formatting and no child address element
5. Repo name specified in corpname element
6. Repo name specified in name element

I ran into some weirdness during testing that I think was a result of the AtoM worker running outmoded code so could be a good idea to, after updating your AtoM code, via git pull --rebase or whatever, restart your AtoM VM.

#10 Updated by Mike Cantelon 9 months ago

  • Status changed from Code Review to QA/Review

Merged into qa/2.6.x.

#11 Updated by Dan Gillean 8 months ago

  • Status changed from QA/Review to Verified
  • Target version set to Release 2.6.0
  • Requires documentation set to No

Also available in: Atom PDF