Place added in Event dialog not importing RAD template
|Status:||In progress||Start date:||01/07/2013|
|Assignee:||José Raddaoui Marín||% Done:|
|Category:||EAD||Estimated time:||4.00 hours|
|Target version:||Release 1.4.0|
|Google Code Legacy ID:||Tested version:|
Create information object.
Add creation event in dialog and assign a place.
Save information object.
Event details appear in information object view page.
Imported record has date of creation but no place in the "Dates of Creation Area" of the information object view page. RAD TEMPLATE
To have all information entered into the event dialog appear in the Dates of Creation Area after export and import.
#2 Updated by José Raddaoui Marín about 9 years ago
Where should I place this element?
Right now AtoM is exporting creation events inside off:
The recommendation looks like is inside the <did> tag, wich will make it difficult to create the events on the import.
#3 Updated by Dan Gillean about 9 years ago
Radda, the date associated with the creation is captured in <unitdate>, not within an <event> similarly, the name of the creator is captured in <origination>. The information in the <event> elements is used for the ISAAR record. therefore all information that you should need is already within the <did>. There shouldn't be a problem.
Looking at the original suggestion I posted above, which came from Richard Dancy's 2008 crosswalk for AtoM (https://www.qubit-toolkit.org/wiki/Crosswalks#Older_RAD-RAD2-ISAD.28G.29-EAD-Marc21-Dublin_Core-MODS-CDWA_Crosswalk), the <imprint> element should only be used if the type of event is "publication." Unfortunately, AtoM's interface makes the "place" available in the even dialogue for any kind of date event (creation, distribution, manufacture, broadcast, etc...). I don't like the idea of putting this in <unittitle> either, but I can't find a solution that is better. We can't put it inside <unitdate>, or <origination>. If we create a separate <event> just to capture this information we are using <event> improperly, because an <event> is meant to be paired with a <date>, and we already have the date captured in <unitdate>.
The real problem is that many of RAD's elements don't crosswalk easily to EAD - you can see the Canadian Council on Archives' RAD/EAD crosswalk here ([http://www.cdncouncilarchives.ca/CrosswalkEN_Nov03.pdf PDF]), but notice 2 things:
1) They have left many examples empty, where they could not crosswalk
2) Much of the crosswalking uses EAD elements improperly, or is poorly considered.
SO: Given our limitations, I think the best option would be
1) If the date event type !== "publication" --> <unittitle><geogname role=""> where @role is whatever event type the user has selected (creation, distribution, broadcast, etc.)
2) If the date event type == "publication" --> <unittitle><imprint><geogname role="publication">
This relies on one thing: the <geogname> information should NOT appear in the unit title when someone imports it. i.e., we don't want to see someone enter a fonds called "Fonds X" and give a creation event with place "Y", and when they save the record they get a title that reads "Fonds X Y".
Jesus has looked at the AtoM code in relation to this question and does not think that getting this information in the <did> or anywhere else should be a problem. If you have technical questions about implementation, you can direct them to him.
#4 Updated by José Raddaoui Marín about 9 years ago
Ok, let me explain the whole process, because I took a better look, and we are dealing here with a bigger problem than only the location.
First of all, we have various types of event: creation, publication, distribution, etc. All events are exported in two pieces:
Role and actor:
<controlaccess> <name role="Publisher">pedroooooo</name> <name role="Creator">test_corp_body</name> <name role="Creator">a_test_creator</name> </controlaccess>
<did> <unittitle encodinganalog="3.1.2">test_creation_event_place</unittitle> <unitdate datechar="publication" normal="2013/2013" encodinganalog="3.1.3">2013</unitdate> <unitdate normal="2012/2012" encodinganalog="3.1.3">2012</unitdate> <unitdate normal="2011/2011" encodinganalog="3.1.3">2011</unitdate> </did>
Only creation events are ALSO exported inside of bioghist (here is all the event's data together, except LOCATION):
<bioghist id="http://192.168.244.129/atom/qubit_dev.php/test-corp-body;isaar" encodinganalog="3.2.2"> <chronlist> <chronitem> <date type="creation" normal="20120000/20120000">2012</date> <eventgrp> <event> <note type="eventNote"> <p>note</p> </note> <origination encodinganalog="3.2.1"> <name>test_corp_body</name> </origination> </event> </eventgrp> </chronitem> </chronlist> </bioghist>
Second, when importing:
- Unitdate elements creates an event with ONLY the dates and the type.
- Controlaccess data is loosed (there is no publisher,etc after the import, only the dates in the event).
- Creation events inside bioghist creates a full event with all the data (except LOCATION, of course).
- This dual export/import for creation events creates the issue we are talking about in #4845.
As I said earlier, putting the location inside the <did> tag will make difficult to associate it with all the other data for the event in the import, at least for creation events (which are exported/imported completly inside bioghist).
But if we are going to join the other events that are separated in two pieces(I think this is the mainly question) we can use the same logic to add the location to the event.
I'm adding two screenshots, before and after export/import and the xml generated.