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
|Assignee:||Sara Allain||% Done:|
|Category:||Import/Export||Estimated 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|
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.
Moved from a comment added to Issue 4256, which has been broken into smaller separate issues and closed.
#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.
#5 Updated by Dan Gillean about 9 years ago
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.
#7 Updated by Dan Gillean about 9 years ago
- Status changed from QA/Review to Feedback
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.
<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
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 statement <unittitle><edition> 1.2B1
Statement of resp relating to edition 1.2C
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
Standard number <unitid type=”standard”> 1.9B1
Conservation: <odd type=“conservation”> 1.8B9b
Accompanying material 1.5E
Alpha numeric designations 1.8B11
Physical description 1.8B9
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.
#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:
<title>title of publisher sereis</title>
<title type="parallel">parallel title</title>
#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.
#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).
#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
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. ¯\_(ツ)_/¯