Archival description with item-level digital objects don't Roundtrip EAD
|Assignee:||José Raddaoui Marín||% Done:|
|Target version:||Release 1.4.0|
|Google Code Legacy ID:||Tested version:|
1. create archival description fonds level with series and items
2. attach digital objects to all items
3. export fonds level description EAD (file attached)
4. delete entire description
5. import EAD
6. fonds and series only, no items, no digital objects imported
everything imports successfully
#2 Updated by David Juhasz over 8 years ago
The desired functionality here is that the export file includes a <dao> element that links to the digital object in the source system. On import into the destination AtoM system, the digital object should be remotely linked to the digital file in the source system, the digital object should not be imported into the destination system.
This may cause some confusion if you are testing import/export using the same instance of AtoM as the source and destination.
#3 Updated by José Raddaoui Marín over 8 years ago
- Status changed from New to QA/Review
- % Done changed from 0 to 100
Hi Jessica an David,
That was the issue, we were throwing an exception when there is a problem fetching an external digital object (deleted all in the point 4). This was breaking the import from that point so the remaining items were ignored. And, as I said in ^^ those errors weren't visible.
Doesn't seem like a good idea breaking the whole process for that, so I've catched the exception and showed it as a warning after the import process has finished.
Hope that's okay.
#5 Updated by Dan Gillean over 8 years ago
- File fivers-collection-of-bunnies;ead.xml added
- File error-import.png added
- Status changed from QA/Review to Feedback
I'm not sure that this is yet a solution.
I've created a test collection, "Fiver's collection of bunnies. It has 2 series: Real bunnies (photographs) and Fake bunnies (images, cartoons, etc.). All real bunny series items were linked to external digital objects on the web. All Fake bunny series items were linked to uploaded images.
First, the error message referenced above appears, but there is no indication that the collection was imported anyway, and no way to view the results (no view archival description button). Because it says error with no option to view, most users will assume the file did not upload. One must search AtoM to find out if the files actually imported (they did... mostly). I don't think this ambiguity is something that we should maintain. See attached screenshot.
Examining the results
the "Real bunnies" series imported correctly - all item-level records appeared, including even their digital objects - so AtoM has no problem fetching external digital objects on the web and linking them with an import
The "Fake bunnies" series did not import any item-level descriptions. It makes sense to me that AtoM cannot fetch copies of the digital objects if they are not available in AtoM or online - but it seems to me that the item-level files should import without the digital objects linked, and the error message about fetching them delivered (with a clear indication that something was imported, and a link to view the description).
As such, the disappearance of the item-level descriptions still seems like a major problem to me.
Interestingly, while I created and exported the file from 2.x, when I tried to import it into 1.x, I got a blank white screen. Even using the debug toolbar I couldn't get an error message.
#7 Updated by José Raddaoui Marín over 8 years ago
- File import_result.png added
- File imported_descriptions.png added
- Status changed from Feedback to QA/Review
That's exactly what I did David, I had to pass the errors array as a reference to the information object class, where the fetching is made, to get those erros in the importSuccess (I've changed all calls to that method too, like in the METS import).
I think we're confusing branches, this fix is merged in the 1.x branch and still not cherry-picked to 2.x. I've imported fiver rabits (hehehe) using 1.x and the result looks good to me (although it takes too much trying to fetch the non existing resources). See attached screenshots.
We may want to discuss the error with the "onRequest" value and maybe truncate those long file names. But I think the rest is fine.