Bug #4505

RELATEDENCODING In RAD Template still points to ISAD Element Numbers during EAD export - develop a separate RAD EAD profile for import/export from RAD template

Added by Dan Gillean over 9 years ago. Updated about 6 years ago.

Status:VerifiedStart date:01/07/2013
Priority:MediumDue date:
Assignee:Sara Allain% Done:

100%

Category:Import/ExportEstimated time:20.00 hours
Target version:Release 2.2.0
Google Code Legacy ID: Tested version:1.3.1, 2.0.0, 2.0.1
Sponsored:No Requires documentation:Yes

Description

EAD recommends using the RELATEDENCODING attribute in the <eadheader> and <archdesc> tags to indicate the source descriptive standard; and the ENCODINGANALOG attribute in the various EAD tags to map those tags to elements in the standard named in RELATEDENCODING.

ICA-AtoM implements this by using ISAD as the RELATEDENCODING standard for <archdesc>, and uses the specific ISAD element numbers as the ENCODINGANALOG of the various tags in the <archdesc> section. This however is unchanged when a user changes the default template to RAD - when exporting in EAD, the RELATEDENCODING still employs the ISAD element numbers.

It would be preferable for ICA-AtoM to use RAD as the RELATEDENCODING standard and RAD rule numbers as the ENCODINGANALOG for EADs that were exported from the RAD template. This might also help ICA-AtoM manage the import / export of RAD elements that have no ISAD equivalents.

Notes:
Moved from a comment added to Issue 4256, which has been broken into smaller separate issues and closed.


Related issues

Blocked by Access to Memory (AtoM) - Bug #5094: RAD EAD Dates improperly encoded when not Dates of creation Verified 05/16/2013

History

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

  • Target version changed from Release 2.1.0 to Release 1.4.0

#2 Updated by Mike Cantelon over 9 years ago

  • Assignee changed from Mike Cantelon to José Raddaoui Marín

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

Here is a list with all the encodinganalog attributes (and the relatedencoding attribute) that are in EAD export, the ISAD value for the attributes and the RAD values I could find.

  Element                           ISAD encodinganalog               RAD encodinganalog
------------------------------------------------------------------------------------------
  relatedencoding                   ISAD(G)v2                         
  eadid                             identifier                        identifier
  titleproper                       title                             title
  author                            creator                           creator
  publisher                         publisher                         publisher
  date                              date                              date
  language                          language                          language
  language of description           languageOfDescription             languageOfDescription
  script                            script                            script
  script of description             scriptOfDescription               scriptOfDescription
  descrules                         3.7.2                             
  scopecontent                      3.3.1                             1.7D 
  arrangement                       3.3.4                             1.8B13
  phystech                          3.4.3                             1.8B14
  appraisal                         3.3.2                             
  acqinfo                           3.2.4                             1.8B12
  accruals                          3.3.3                             1.8B19
  custodhist                        3.2.3                             1.7C 
  originalsloc                      3.5.1                             1.8B15a
  altformavail                      3.5.2                             1.8B15b
  relatedmaterial                   3.5.3                             1.8B18
  accessrestrict                    3.4.1                             1.8B16a
  userestrict                       3.4.2                             1.8B16c
  otherfindaid                      3.4.5                             1.8B17
  bibliography                      3.5.4                             
  unittitle                         3.1.2                             1.1B
  unitid                            3.1.1                             
  unitdate                          3.1.3                             1.4B2
  extent                            3.1.5                             1.5B1
  langmaterial                      3.4.3                             1.8B9a
  note                              3.6.1                             
  bioghist                          3.2.2                             
  origination                       3.2.1                             

Please, let me know if those are ok, and help me to fill the blanks.

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

  • Status changed from New to In progress

#5 Updated by Dan Gillean about 9 years ago

Hi Radda,

What you have looks good. Remember, these standards are not 1:1, so unfortunately there will not always be equivalents. I can suppplement a few with certainty however:

  Element                           ISAD encodinganalog               RAD encodinganalog
------------------------------------------------------------------------------------------
  note                              3.6.1                             1.8B21 (General Note)
  bioghist                          3.2.2                             1.7B (Admin history/Bio sketch)
  origination                       3.2.1                             1.7C (Custodial History)

As for the rest:

If it is easier to have an encoding, I would suggest:

For unitid 3.1.1 - we could use 1.8B11 "Other Alphanumeric Designation," since RAD strangely does not include a place for a REFERENCE CODE! But it is another number associated. The thing with this is that it implies that it's a number associated with the original resource, NOT its description... so the match is imperfect.

Add them to those you have - if the import/export is not dependent on their presence and they are merely informational, then we will continue to import/export all available information, but will not add an encodinganalog where there is no equivalent RAD field.

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

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

Applied in changeset atom|commit:87eeee132c9d9713d3edfb468b34d0eb001a2e25.

#7 Updated by Dan Gillean about 9 years ago

  • Status changed from QA/Review to Feedback

Hi Radda,
So, my apologies – there is more to do on this ticket. I had not remembered to supply you a list of all the RAD fields that DON’T map to ISAD at all – and there are quite a few. As well, I found a few small issues to be fixed before verifying this ticket.

TO FIX:
<phystech> should be: 1.8B9a
<note type="General note" encodinganalog="3.6.1"> = remove this ISAD encoding analog
<unitdate> still had the ISAD encoding - change to 1.4B2

Please do a general check as well to ensure that any other encoding values from ISAD are removed.

RAD has a lot of fields that don’t appear in ISAD. I’ve gone back through the standard and supplied the missing ones below. Unfortunately, something about how you have handled one of your commits is interfering with my EAD export (Jesus is looking into this and will show you; it is an AtoM particularity and not a general coding problem), so unfortunately I can’t point you to all the appropriate EAD elements and attributes used for each field. Where possible based on earlier testing, I have provided examples – they will likely point you to the rest, as they will often be similar but with different attribute names.

If it helps, I can give you a sample EAD file that you can fill out for the missing fields and export to look at the EAD.

Note that if you need to look at the RAD standard at all, it is available here: http://www.cdncouncilarchives.ca/rad/radcomplete_july2008.pdf

TERM ENCODING VALUE

TITLE AND STATEMENT OF RESP AREA
General Material Designation <genreform> 1.1C
Parallel Title <unittitle type=”parallel”> 1.1D
Other title info <untititle type=“otherinfo”> 1.1E
Statement of responsibility @type=”statrep” 1.1F

TITLE NOTES
Source of title proper <odd type=”titlesource”> 1.8B2
Variations in title 1.8B1
Parallel titles and other title info 1.8B3
Continuation of title 1.8B4
Statement(s) of responsibility 1.8B5
Attributions and conjectures 1.8B6

EDITION AREA
Edition statement <unittitle><edition> 1.2B1
Statement of resp relating to edition 1.2C
<unittitle type="statrep"><edition>

CLASS OF MATERIALS SPECIFIC AREA
Statement of scale cartographic 5.3B1
Statement of projection cartographic 5.3C1
Statement of coordinates (cartographic) 5.3D
Statement of scale (architectural) 6.3B
Issuing jurisdiction and denom 12.3B1

PUBLISHER’s SERIES AREA
Title proper of publisher series 1.6B1

<unittitle>
      <bibseries>
        <title>XXXX</title>
      </bibseries>
 </unittitle>

Parallel Title pub series 1.6C1
Other title information pub series 1.6D1
Statement of responsibility pub series 1.6E1
Numbering within pub series 1.6F
Note on publisher’s series 1.8B10
<odd type=’bibseries’>

Standard number <unitid type=”standard”> 1.9B1

OTHER NOTES:
Conservation: <odd type=“conservation”> 1.8B9b
Accompanying material 1.5E
Alpha numeric designations 1.8B11
Edition 1.8B7
Physical description 1.8B9
Rights 1.8B16b
General Note 1.8B21

As well, for the names and dates in events, there are also particular rules that guide the encoding of different names and dates, depending on if they are associated with creation, publication or distribution, or manufacture. Wherever there is the possibility of including the following encodings, please do:

NAMES AND DATES
Dates of pub, distro, etc. (other dates)    1.4F            
Name of publisher, distributor            1.4D
Place of publication, distribution        1.4C
Place of manufacture                1.4G
Date of manufacture                1.4G
Name of manufacturer                1.4G

At some point, it would be good for us to apply the same camelCase attribute naming conventions to the RAD EAD as we intend to apply to the ISAD EAD, in issue 4463 (https://projects.artefactual.com/issues/4463).

As a final note, I have through this process encountered some strangeness related to how we are encoding information for the editions, the publisher’s series, and others. I need to do some further testing and consultation of the standards, but I may be filing new issues around how these are handled. Just a heads up.

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

  • Status changed from Feedback to QA/Review

#9 Updated by Jessica Bushey almost 9 years ago

  • Status changed from QA/Review to Feedback

This is looking good, but Publisher's Series area has no RAD numbers. See, Dan's comments #7 above.

This is from the export:
unittitle>
<bibseries>
<title>title of publisher sereis</title>
<title type="parallel">parallel title</title>
</bibseries>
</unittitle>

#10 Updated by José Raddaoui Marín almost 9 years ago

  • Status changed from Feedback to QA/Review

Applied in changeset atom|commit:9d1a0e917f80f8e22530b5127144e1535346417f.

#11 Updated by José Raddaoui Marín almost 9 years ago

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

#12 Updated by José Raddaoui Marín almost 9 years ago

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

Applied in changeset atom|commit:04964c4d09aa3cc98c848cdc344fcec3580d61da

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

  • Estimated time set to 20.00

#14 Updated by Dan Gillean almost 9 years ago

  • Status changed from QA/Review to Feedback

We are so close!

A couple small things:

1) The note on the publisher's series is being captured like this:

<odd type="bibSeries"><p>note on pub series</p></odd>

The @ENCODINGANALOG on this <odd> should be: 1.8B10

2) If possible, the different dates available in the RAD template should use different encoding, as outlined in note 7 above. Currently all dates seem to receive 1.4B2, date of creation, by default.

NAMES AND DATES
Dates of pub, distro, etc. 1.4F
Name of publisher, distributor 1.4D
Place of publication, distribution 1.4C
Place of manufacture 1.4G
Date of manufacture 1.4G
Name of manufacturer 1.4G

@ENCODINGANALOG is available on <name>s as well, so the names AND places associated with publishing, distributing, broadcasting, manufacturing, captured in <controlaccess><*name role=" "> or <geogname> should have the above @ENCODINGANALOG added where applicable.

Thanks!

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

It's almost done, only <geoname> and <*name>s elements are waiting. I think it's better to wait until #5094 is fixed.

#16 Updated by Tim Hutchinson over 7 years ago

I just noticed that in the command line export, the relatedencoding is still ISAD even if RAD is the default template.

#17 Updated by Dan Gillean over 7 years ago

  • Target version changed from Release 1.4.0 to Release 2.1.1
  • Tested version 1.3.1, 2.0.0, 2.0.1 added

Tentatively assigning to 2.1.1 - we're working on #5094 and related EAD mapping issues now for the 2.1.1 release, so hopefully once the dust settles on those, we can work on these encodings. Same thing should be done for the DACS EAD export.

#18 Updated by Tim Hutchinson over 7 years ago

I thought I'd throw this in here - with a fairly recent version of qa/2.2.x (including the MODS dev branch), relatedencoding seems to be "DC" when the description template is set to either RAD or ISAD (the encodinganalog values seem to be using the correct standard).

#19 Updated by Tim Hutchinson over 7 years ago

Please ignore my earlier comment. I just realized that the relatedencoding for DC only applies to the <eadheader>; it's correct at the <archdesc> level.

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

  • Target version changed from Release 2.1.1 to Release 2.2.0

#21 Updated by José Raddaoui Marín about 7 years ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from José Raddaoui Marín to Dan Gillean

#22 Updated by Dan Gillean about 7 years ago

  • Status changed from QA/Review to In progress
  • Assignee changed from Dan Gillean to José Raddaoui Marín

Ok Radda!

I've reviewed where we are at with this now that #5094 is cleared up.

First, there are a few <odd> elements missing @encodinganalogs:

odd type="titleVariation"             encodinganalog="1.8B1" 
odd type="titleAttributions"          encodinganalog="1.8B6" 
odd type="titleContinuation"          encodinganalog="1.8B4" 
odd type="titleStatRep"               encodinganalog="1.8B5" 
odd type="titleParallel"              encodinganalog="1.8B3" 
odd type="titleSource"                encodinganalog="1.8B2" 
odd type="physDesc"                   encodinganalog="1.8B9" 
odd type="alphanumericDesignation"    encodinganalog="1.8B11" 
odd type="bibSeries"                  encodinganalog="1.8B10" 

Now, there is the dates/names/places, as described comment 14, above. Here they are broken down:

Dates: <unitdate>

IF @datechar=""               encodinganalog="" 
-----------------------------------------------
publication                           1.4F
distribution                          1.4F
manufacturing                         1.4G

Names: (in <controlaccess>, could be persname, famname, corpname, or just name)

IF @role=""                   encodinganalog="" 
-----------------------------------------------
Publisher                             1.4D
Distributer                           1.4D
Manufacturer                          1.4G

Geognames: <geogname>

IF @role=""                   encodinganalog="" 
-----------------------------------------------
Publisher                             1.4C
Distributer                           1.4C
Manufacturer                          1.4G

That's all I could find with certainty in the maze of the RAD standard. Otherwise, I think we're good.

#23 Updated by José Raddaoui Marín about 7 years ago

Hi Dan, I've added those changes, but I'm wondering about other @role types in <controlaccess>, e.g. Creator, Contributor, etc.

Also, in the top level description, we are not exporting the creators inside <controlaccess><*name>. I guess this was done to avoid the creation event duplication, but it's not done for the descendant descriptions. Is that okay or should it be the same for all levels?

#24 Updated by Dan Gillean about 7 years ago

Wow.... I knew RAD was ridiculous, but this has surprised even me. Because RAD is derived directly out of the library cataloguing AACR2 standard, there is apparently no formally appropriate place to include a CREATOR'S NAME IN THE STANDARD... sigh...

The two best options are to use the Statement of responsibility (1.1F), or just lean on the "etc" of 1.4D Name of publisher, distributor, etc. Because 1.1F clarifies it is meant for item-level descriptions (because the source AACR2 is describing publications), and because 1.1F1 states this information is derived from those explicitly appearing "in conjunction with a formal title proper in or on the chief source of information" (again, publication), this seems to be a bad fit. The only other viable option then is to use 1.4D.

Radda, let's use 1.4D for all currently unassigned name types (creator, contributor, etc).

I wanted to check how we were previously encoding the creator name in the <origination> element and I found an error there - turns out we are accidentally using 1.7C (Custodial history). So for <origination> let's change the @encodinganalog to 1.4D as well.

Not a perfect solution, but hey, that's RAD. ¯\_(ツ)_/¯

#25 Updated by José Raddaoui Marín about 7 years ago

  • Status changed from In progress to Code Review
  • Assignee changed from José Raddaoui Marín to Mike Gale

Created PR 137

#26 Updated by Mike Gale about 7 years ago

  • Assignee changed from Mike Gale to José Raddaoui Marín

#27 Updated by José Raddaoui Marín about 7 years ago

  • Status changed from Code Review to QA/Review
  • Assignee changed from José Raddaoui Marín to Dan Gillean

#28 Updated by Dan Gillean about 7 years ago

  • Status changed from QA/Review to Verified
  • Requires documentation set to Yes

Looks good.

Will involve updates to the current RAD template documentation in Data entry section of user manual.

#29 Updated by Dan Gillean about 6 years ago

  • Assignee changed from Dan Gillean to Sara Allain

Something to check on if you are updating the data-entry template docs, Sara!

Also available in: Atom PDF