Bug #3792

EAC round-trip export/import results in name fields being combined

Added by Evelyn McLellan over 11 years ago. Updated about 9 years ago.

Status:VerifiedStart date:
Priority:MediumDue date:
Assignee:José Raddaoui Marín% Done:

100%

Category:Import/Export
Target version:Release 1.4.0
Google Code Legacy ID:atom-1843 Tested version:
Sponsored:No Requires documentation:

Description

To reproduce this error: ========================
1)Import the attached file, which is an EAC export from Qubit
2)View imported object

Resulting error: ================
Parallel form(s) of name (la famille Eglise) and Standardized form(s) of name (Church family) have been combined into one field with Other form(s) of name (Synagogue family)

Expected result: ================
Should be separate fields.

[g] Legacy categories: Import/Export

church-family (4.73 KB) Evelyn McLellan, 12/01/2012 03:57 AM

History

#1 Updated by David Juhasz almost 11 years ago

  • Priority set to Medium

[g] Labels added: Priority-Medium

#2 Updated by David Juhasz over 10 years ago

  • Target version set to Release 1.3

Roll over to Release 1.3

[g] Labels added: Milestone-Release-1.3

#3 Updated by David Juhasz almost 10 years ago

Reassign to new account.

[g] New owner: David Juhasz

#4 Updated by Jessica Bushey over 9 years ago

  • Target version changed from Release 1.3 to Release 2.1.0

These are imported as part of “other forms of name”. It's because the attribute is the same for all of them <alternativeForm>.

[g] Labels added: Milestone-Release-2.0
[g] Labels removed: Milestone-Release-1.3

#5 Updated by David Juhasz over 9 years ago

  • Target version changed from Release 2.1.0 to Release 1.4.0

#6 Updated by Dan Gillean over 9 years ago

  • Assignee changed from David Juhasz to José Raddaoui Marín

#7 Updated by Jesús García Crespo over 9 years ago

  • Sponsored set to No

I merged Radda's commit commit:7eb7498 but it's WIP (work in progress). He needs some clarification on how to export standardized (otherNames).

Is the following example correct?

<nameEntry xml:lang="" scriptCode="">
  <part><?php echo esc_specialchars($item->name) ?></part>
  <authorizedForm>conventionDeclaration</authorizedForm>
</nameEntry>

#8 Updated by José Raddaoui Marín over 9 years ago

  • Status changed from New to QA/Review

#9 Updated by Jessica Bushey over 9 years ago

  • Status changed from QA/Review to Feedback

Created authority record with all data fields in the Identity area completed.
Saved and exported EAD.
Reviewed EAD and noticed the Standardized form of name is missing.

I looked through EAD standard and I'm not sure, can you do:

  <nameEntry>
    <part>XXXX</part>
    <standardizedForm>conventionDeclaration</standardizedForm>
  </nameEntry>

Not sure if this is legit.

#10 Updated by Jesús García Crespo over 9 years ago

  • Category set to Import/Export

There is no <standardizedForm> tag as far as I know in EAC.

#11 Updated by Jesús García Crespo over 9 years ago

Jessica, can we use the @localType attribute to differentiate the standardized form of name with the authorized form of name?

Just to clarify:

  • 1) Authorized form of name:
  <nameEntry>
    <part>...</part>
    <authorizedForm>...</authorizedForm>
  </nameEntry>
  • 2) Parallel form of name:
  <nameEntryParallel>
    <nameEntry>
      <part>...</part>
      <authorizedForm>...</authorizedForm>
    </nameEntry>
  </nameEntryParallel>
  • 3) Standardized form of name:
  <nameEntry>
    <part>...</part>
    <authorizedForm>...</authorizedForm>
  </nameEntry>
  • 4) Other forms of name:
  <nameEntry>
    <part>...</part>
    <alternativeForm>...</alternativeForm>
  </nameEntry>

Please, notice the collision between 1) and 3).
Could @localType be used to differentiate them? Something like this:

  <nameEntry localType="standardized">
    <part>...</part>
    <authorizedForm>...</authorizedForm>
  </nameEntry>

#12 Updated by Jesús García Crespo over 9 years ago

  • Status changed from Feedback to In progress

#13 Updated by Jessica Bushey over 9 years ago

Radda,

yes, that looks right.

Jessica

#14 Updated by Jessica Bushey over 9 years ago

Please change EAC-CPF for Parallel Entry to:

<nameEntryParallel>
    <nameEntry>
      <part>...</part>
        <preferredForm>… (rules here)</preferredForm>
    </nameEntry>
    <nameEntry>
      <part>...</part>
    </nameEntry>
<authorizedForm>...</authorizedForm>
  </nameEntryParallel>

The reason for this is in the ISAAR rule 5.1.3 Parallel forms of name:
To indicate the various forms in which the Authorized form of name occurs in other languages or script form(s).Record the parallel form(s) of name in accordance with any relevant national or international conventions or rules applied by the agency that created the authority record,including any necessary sub elements and/or qualifiers required by those conventions or rules. Specify in the Rules and/or conventions element (5.4.3) which rules have been applied.

Please change EAC-CPF for Standardized form of name to:

  <nameEntry localType="standardized">
    <part>...</part>
    <alternativeForm>...</alternativeForm>
  </nameEntry>

We don't really need the localType, but I think it adds clarity. Archivists should use the authorized form of name first.
The ISAAR rule 5.1.4: To indicate standardized forms of name for the corporate body, person or family that have been constructed according to rules other than those used to construct the authorised form of name. This can facilitate the sharing of authority records between different professional communities.

#15 Updated by José Raddaoui Marín over 9 years ago

Sorry for asking again Jessica. Could you confirm EAC-CPF for Parallel Entry:

<nameEntryParallel>
  <nameEntry>
    <part>[user parallel form of name data]</part>
    <preferredForm>conventionDeclaration</preferredForm>
  </nameEntry>
  <nameEntry>
    <part>[user parallel form of name data]</part>
  </nameEntry>
  <authorizedForm>conventionDeclaration</authorizedForm>
</nameEntryParallel>

Should I use the same data on both <part>?

One last thing. Notice that in any form of name (<authorizedForm>,<alternativeForm>, etc) AtoM puts "conventionDeclaration", I guess because user can not set this data when adding a new form of name. This is not a problem for roundtripping, but I don't know if it's the right way.

Thanks for all!

#16 Updated by Dan Gillean about 9 years ago

hi Radda,

I am coming in late on this issue, so I am not sure I understand your question, but:

The purpose of a Parallel form of name is to offer different versions of the same name as it exists in in different languages. For example, Belgium National Archives [eng] = Les Archives Nationale de Belge [fre]. (this is probably a bad translation - just an example!) This means that the data should not be the exact same in each <part> - it should be the name as entered in a different culture.

Here is the example included on the EAC-CPF site for the <nameEntryParallel> element's use:

<nameEntryParallel>
<nameEntry xml:lang="fre" scriptCode="Latn">
<part>Institut international des droits de l'homme</part>
<preferredForm>AFNOR_Z44-060</preferredForm>
</nameEntry>
<nameEntry xml:lang="eng" scriptCode="Latn">International institute of human rights</nameEntry>
<nameEntry xml:lang="spa" scriptCode="Latn">
<part>Instituto internacional de derechos humanos</part>
</nameEntry>
<authorizedForm>AFNOR_Z44-060</authorizedForm>
</nameEntryParallel>

This suggests that for the name entry to be useful when working with Parallel Names, each <nameEntry> should have a language and script code associated with it. The problem again is that since we have only a free-text field for users to enter data, we have no way of knowing the other language/script used for the parallel name. For now, I suggest adding the language/script code to the original <nameEntry>, based on the the language of the user interface - ie, if they are working with the English AtoM user interface to enter data, then the name entry would be <nameEntry xml:lang="eng" scriptCode="Latn">.

Ideally, if the user enters a translation of a name in a different culture user interface, we could capture that information here as a parallel form of name ( <nameEntryParallel> ). If this is not possible, then we should at least enter the lang and scriptCode attributes for the original language, and capture whatever data the user enters in the Parallel Form of name in its own <nameEntry> tag, nested in the <nameEntryParallel> tag.

Meanwhile, here is some information that might be of help from the description of the <authorizedForm> element:

The eac-cpf schema offers two possibilities:
1. <authorizedForm> is used within <nameEntry> only when <nameEntry> is not included within <nameEntryParallel>. In this case, it qualifies the form of the name recorded within the precise <nameEntry> element as an authorized access point.
2. <authorizedForm> may be used within <nameEntryParallel> to indicate that the set of parallel names recorded in separate <nameEntry> elements within <nameEntryParallel> are deemed as authorized access points.

The content of the element is an abbreviation selected from a constrained set of values, each of which represents a set of national, international or other rules that govern the construction of EAC-CPF names in those environments. The abbreviations expressed in <authorizedForm> must be declared within the <conventionDeclaration> element in <control>. 

Note that point #2 is what applies in this case. Based on this, the <authorizedForm> data should not actually say "conventionDeclaration" - instead, it should list the abbreviated form of whatever standard is used to come up with the authorized form. These abbreviations are then listed in the <conventionDeclaration> tag in the control area ( <control> ).

Here's the description of the <conventionDeclaration> element:

"An optional element of <control> for declaring references in the <citation> element to any rules and conventions, including authorized controlled vocabularies or thesauri, applied in the construction of the description. For example, <conventionDeclaration> should be used to identify any controlled vocabularies appearing in the @vocabularySource attribute for <term>, <placeEntry>, and <placeRole> elements. Any notes relating to how these rules or conventions have been used may be given within a <descriptiveNote> element. The <abbreviation> element may be used to identify the standard or controlled vocabulary in a coded structure."

And an example:

<conventionDeclaration>
<abbreviation>AACR2</abbreviation>
<citation>Anglo-American Cataloging Rules, Revised</citation>
</conventionDeclaration>

In this case, if Anglo-American Cataloging Rules were used to define/determine the authorized form of name, then the EAC would look like this:

<nameEntryParallel>
<nameEntry xml:lang="fre" scriptCode="Latn">
<part>Monsieur Fiver Watson</part>
<preferredForm>AACR2</preferredForm>
</nameEntry>
<nameEntry xml:lang="eng" scriptCode="Latn">Mister Fiver Watson</nameEntry>
<nameEntry xml:lang="spa" scriptCode="Latn">
<part>Senor Fiver Watson</part>
</nameEntry>
<authorizedForm>AACR2</authorizedForm>
</nameEntryParallel>

The problem, as I understand it, is that our use of the <conventionDeclaration> tag is tied to the "Rules or Conventions Used" field in the ISAAR template, in the control area - only this is a free-text field, meaning the user can never enter an abbreviation for the standard used. Similarly, if two or more standards are entered here, they cannot be separated. Currently, the output of the abbreviation for any data entered in the "Rules or Conventions Used" field is just "conventionDeclaration", like this:

<conventionDeclaration>
   <abbreviation>conventionDeclaration</abbreviation>
   <citation>this is rules and conventions used in ISAAR in the Control Area</citation></conventionDeclaration>

So... for now, there is no way for you to change this, unless we change the way that data is entered into the field in future versions of AtoM. I will consult further with Jessica and the developers about this, but I think that yes, for now you can leave it as is.

#17 Updated by Dan Gillean about 9 years ago

Radda, here is another example, which was recently posted to the EAD List-serv: http://listserv.loc.gov/cgi-bin/wa?A2=ind1303&L=ead&T=0&P=613

<nameEntryParallel>
        <nameEntry xml:lang="eng" scriptCode="Latn">
        <part>Der Nersessian, Sirarpie</part>
        <preferredForm>ICFA</preferredForm>
        </nameEntry>
    <nameEntry xml:lang="arm" scriptCode="Latn" transliteration="alalcRomanization">
         <part>Ter-Nersesian, Sirarp'i Veronik'</part>
        </nameEntry>
    <authorizedForm>Virtual International Authority File</authorizedForm>
    </nameEntryParallel>
    <nameEntry>
          <part>Nersessian, Sirarpie der</part>
          <alternativeForm>Virtual International Authority File</alternativeForm>
    </nameEntry>

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

I have sent another fix to Jesús.

A couple of things. The export for each parallel form of name look like this:

<nameEntryParallel>
  <nameEntry xml:lang="eng" scriptCode="Latn">
    <part>parallel_form_of_name_2</part>
    <preferredForm>conventionDeclaration</preferredForm>
  </nameEntry>
  <nameEntry xml:lang="spa" scriptCode="Latn">
    <part>parallel_form_of_name_2_es</part>
  </nameEntry>       
  .
  .
  [other cultures]
  .
  .         
  <authorizedForm>conventionDeclaration</authorizedForm>
</nameEntryParallel>

The first nameEntry (with the preferredForm tag inside) will be the culture that match with the user culture. Doesn't matter in the import.

The script attribute is always set to 'Latn'. Doesn't matter in the import.

I hope everything is ok.

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

  • Status changed from In progress to QA/Review
  • % Done changed from 0 to 100

Applied in changeset atom|commit:96c020ef435e1986cd9e5b4dd25e088a4b728b2c.

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

Applied in changeset atom|commit:96c020ef435e1986cd9e5b4dd25e088a4b728b2c.

#21 Updated by Jessica Bushey about 9 years ago

  • Status changed from QA/Review to Verified

Created parallel names in other languages and they exported in the EAD with the correct corresponding language. And imported correctly.

Also available in: Atom PDF