DACS Technical access field doesn't roundtrip (EAD export/import)
|Google Code Legacy ID:||Tested version:||2.2, 2.3|
Note: this issue has been updated from an ongoing catch-all about DACS roundtripping, to the one specific outstanding element, so the ticket can be available for reference (without being closed), but its current status is clear.
- Set DACS as default template
- Add "Foo" to Physical access field, and "Bar" to Technical access field
- Export as EAD
Resulting error: "Bar" is dropped. @type attributes are not used to support multiple <phystec> elements - DACS recommends that both fields map to phystech, so we'd need to use the type attribute to distinguish them on roundtrip. See comment 8 below.
The original issue description:
Step one: create DACS item-level description with digital image attached
Step two: view in AtoM (see BeforeExport.png)
Step three: export as EAD.XML (see flowers;ead.xml
Step four: delete item-level description with digital image attached
Step five: import flower.eax.xml file
Unexpected Result - view in AtoM (see AfterImport.png)
Expected Result - import file and have the same view as BeforeExport.png
#1 Updated by David Juhasz about 8 years ago
When exporting to EAD.xml the URL for the image in the current AtoM repository is used in the <dao> tag. If you delete the description (and the attache image presumably) from AtoM then the <dao> URL won't resolve. If I'm understanding the workflow properly, I think this is a case where round tripping an EAD file to/from the same instance of AtoM produces an unanticipated result which would not occur in real world usage.
The missing descriptive meta-data does look like a bug to me.
#2 Updated by José Raddaoui Marín almost 7 years ago
I've take a look into this and this is what I've found:
- Specialized note(s) are not being saved and editing the description that section is populated with other notes.
- After the escaping changes the extent field doesn't look good after the import, showing the definition list tags.
- Technical access is not exported in EAD and it doesn't roundtrip.
- The same happens with the related descriptions.
Everything else looks fine to me.
#4 Updated by Dan Gillean almost 7 years ago
Awesome to see that you are working on this issue!
For the Technical access
Both of these fields map to phystech. For us to be able to roundtrip them, I think we would need a DACS specific EAD profile - so we can add a @type to the <phystech> EAD element - something like this:
<phystech encodinganalog="4.2.5" type="physicalAccess"> and <phystech encodinganalog="4.3.5" type="techicalAccess">
Keep in mind, those @encodinganalog values are from DACS. By adding our own DACS EAD profile, we could re-align all the @encodinganalog attributes to use DACS numbers instead of ISAD one
It might be possible to add these @type elements just in the general EAD mappings - I'm pretty sure that every other template that is using this mapping is just mapping one field to it, so we are not using a @type. If you flip the template from DACS to ISAD, it is the physical access field in DACS that maps directly to the "Physical access and technical requirements" field in ISAD. So, the assumption could be, if @type="physicalAccess" OR no @type is included, map it to the current mapping. If @type="technicalAccess", map it to wherever we are storing the DACS-specific field for Technical access.
Would that work, as a way we could implement this now without having to make a whole separate DACS export profile?
Physical description / Extent
We are aware of this problem - the XSS escaping is affecting the display, but ultimately the current solution is a hacky workaround. We actually have a meeting to discuss how best to solve this for 2.2 next Wednesday. We will deal with that in a separate ticket as it affects all templates.
Again, this is affecting all templates at the moment, so we may want to deal with this on a separate ticket - but for now, I will add notes here; we can always move them if we want.
We ARE capturing the free-text field, "Related archival materials," using the following:
<relatedmaterial encodinganalog="3.5.3"> <p>Related archival materials, DACS 6.3.5</p> </relatedmaterial>
Ultimately, it looks to me like this data would map to the same <relatedmaterial> element in EAD.Looking at the description in the tag library, it seems as if we could use it to good effect with a nested <archref> - see:
- <relatedmaterial> - http://www.loc.gov/ead/tglib/elements/relatedmaterial.html
- <archref> - http://www.loc.gov/ead/tglib/elements/archref.html
Ideally, we could capture the <unittitle> of the related resource, and the URL to it via an @href attribute in the <archref>.
Since users can describe whatever they want in the free-text field, but only link to related descriptions held in AtoM, we shouldn't assume they will be related - so this should likely go in a second <relatedmaterial> element. So I'm imagining the ideal solution as something like this:
<relatedmaterial encodinganalog="3.5.3"> <p>Related archival materials, DACS 6.3.5</p> </relatedmaterial> <relatedmaterial encodinganalog="3.5.3"> <archref href="http://your-atom.example.com/your-resource-1"> <unittitle>Your first related description title</unittitle> </archref> <archref href="http://your-atom.example.com/your-resource-2"> <unittitle>Your second related description title</unittitle> </archref> </relatedmaterial>
Let me know if, theoretically at least, based what you know of the EAD import/export, and based on the links I've provided to the EAD tag library, you think that would work.
It would be great to get these added to the EAD export/import. I can look into suggested mappings for them. Likely they would be either a <note> or an <odd> element with a set of specific @type names worked out for mapping, similiar to what we have done with RAD special note types, as I describe to Creighton in a related ticket here: https://projects.artefactual.com/issues/6141#note-1
#8 Updated by Dan Gillean over 6 years ago
- Subject changed from DACS / EAD doesn't roundtrip to DACS Technical access field doesn't roundtrip (EAD export/import)
- Description updated (diff)
- Tested version 2.2, 2.3 added
Updating the title and status of this issue to reflect current progress. Marking as new again instead of in progress, since this may require development support for us to be able to work on further. For more up-to-date testing notes and a sample EAD record, see this public user forum discussion:
From the thread:
The only field that did not successfully roundtrip was the Technical access field (DACS 4.3.5). This is likely because both Physical access (DACS 4.2.5) and Technical access should map to EAD's <phystech> element - and currently the Physical access field in DACS is crosswalked with the "Physical characteristics and technical requirements" field in ISAD - so Physical access is using the <phystech> EAD field on export, and Technical access currently lacks a mapping.
It should be possible to improve this behavior, by using the @type attribute to distinguish the two, and export each DACS field in a different <phystech> element, with the @type attributes clarifying which is which so they will re-import successfully on a roundtrip. This work has not yet been done, however, and may require community sponsorship for Artefactual to be able to take it on, as we'll have to confirm that any export schema changes work across all standards templates.