Bug #4509

Place added in Event dialog not importing RAD template

Added by Jessica Bushey over 9 years ago. Updated almost 9 years ago.

Status:In progressStart date:01/07/2013
Priority:MediumDue date:
Assignee:José Raddaoui Marín% Done:


Category:EADEstimated time:4.00 hours
Target version:Release 1.4.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:


Create information object.
Add creation event in dialog and assign a place.
Save information object.
Event details appear in information object view page.
Delete Record.

Imported record has date of creation but no place in the "Dates of Creation Area" of the information object view page. RAD TEMPLATE

Expected behaviour:
To have all information entered into the event dialog appear in the Dates of Creation Area after export and import.

before.png (50.9 KB) José Raddaoui Marín, 04/25/2013 07:12 PM

test-creation-event-place.xml Magnifier (3.51 KB) José Raddaoui Marín, 04/25/2013 07:12 PM

after.png (54.4 KB) José Raddaoui Marín, 04/25/2013 07:12 PM

Related issues

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


#1 Updated by Dan Gillean about 9 years ago

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

Recommendation from the current Qubit Toolkit Crosswalk:

<unittitle><imprint><geoname role="publication">

#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:

  <name role="Publisher">pedroooooo</name>
  <name role="Creator">test_corp_body</name>
  <name role="Creator">a_test_creator</name>


  <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>

Only creation events are ALSO exported inside of bioghist (here is all the event's data together, except LOCATION):

<bioghist id=";isaar" encodinganalog="3.2.2">
      <date type="creation" normal="20120000/20120000">2012</date>
          <note type="eventNote">
          <origination encodinganalog="3.2.1">

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.

So finally:

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.

#5 Updated by Jesús García Crespo about 9 years ago

Thanks for clarifying that, Radda! It seems possible after all, it's just a matter of updating the code. Let's wait for Jessica and Dan. Thanks again.

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

  • Estimated time set to 4.00

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

  • Status changed from New to In progress

Also available in: Atom PDF