Add <physloc> support to EAD import
|Category:||EAD||Estimated time:||24.00 hours|
|Target version:||Release 1.4.0|
|Google Code Legacy ID:||atom-643||Tested version:|
if <physloc> is given without a <container> element, set a note with type
Otherwise, use the <physloc> content to set the container's location
[g] Legacy categories: Import/Export, EAD
#5 Updated by Tim Hutchinson about 10 years ago
The following change to the ead.yml file allows <physloc> to be imported along with <container>
Parameters: [$nodeValue, "$options = array('type' => $importDOM->xpath->query('@type', $domNode2)->item(0)->nodeValue, 'location' => $importDOM->xpath->query('//*/did/physloc', $domNode2)->item(0)->nodeValue)"]
I.e. added location parameter. However, tweaking of the xpath will likely be required to ensure that this works at all levels e.g. c/c/did/physdesc. This has only been tested with archdesc/did/physloc
#6 Updated by Tim Hutchinson about 10 years ago
So to be clear, this will only work if <container> is populated.
Also, this may be at best a workaround for fonds-level records. For multi-level descriptions, we would need a way to make sure that the <physloc> at the same level as the main XPath is being selected. As currently written, I think a lower level <container> could be linked to the <physloc> at the top level of the description (since presumably the xpath->query call would just match the first occurrence. Is there a way to select the argument for xpath->query() so that it's relative to the main XPath?
#7 Updated by Anonymous about 10 years ago
As we are using multi-level descriptions, we needed a way to import this data for every record. After attempting the solution described in comment #5 without success, our programmer devised the following workaround, which unfortunately, required that we move our <physloc> data inside of our <container> tags for import.
We separated these two sets of data using a special sequence of characters (that is, a sequence that must not appear in any of the two fields ever); in our case the special sequence was '---' (eg - <container>Box 4---<physloc>Archive Repository 4/4</physloc></container>).
Then following import, our programmer used a sql instruction to move/modify the data to the proper field for location data, the MySQL table physical_object_i18n in the ICA-Atom database. He chose to use Microsoft Access as a front end to create the sql script, linking the database using the official MySQL ODBC driver. (He said he chose Access for its simplicity. He noted that the script can be created directly using the native MySQL connection and its sql syntax.)
The resulting sql script is this:
UPDATE physical_object_i18n SET physical_object_i18n.name = Left([name],InStr(1,[name],"---")-1), physical_object_i18n.location = Right([name],Len([name])-(InStr(1,[name],"---")+2));
Note that the various substring functions and syntax used are Access-specific.
Basically it does just two things:
- Replaces the 'name' field with what comes before the '---' sequence in its value
- Moves to the 'location' field what comes after the '---' sequence in the 'name' field value
The end result is that our location data displays in the appropriate place in the container record, as well as immediately following the text of the container text under "Physical Storage" on the archival description record (but not on the container record). Interestingly, this text is still hidden to the public but not to authenticated users, so we do lose some control over access to this data.
#11 Updated by Tim Hutchinson over 9 years ago
See also related user group thread:
#18 Updated by David Juhasz almost 8 years ago
We are looking at implementing <physloc> in ICA-AtoM 1.4 and AtoM 2.0, so I've been catching up on the discussion around the issue.
It looks to me like MJ Suhonos suggested a workable XPath for importing <physloc> with or without a corresponding <container> tag:
physloc_with_container: XPath: "did/physloc[boolean(../container)]" Method: setPhysicalObjectByName Parameters: [%../container, "$options = array('type' => $importDOM->xpath->query('@type', $domNode2)->item(0)->nodeValue, 'location' => $importDOM->xpath->query('.', $domNode2)->item(0)->nodeValue)"] physloc_without_container: XPath: "did/physloc[not(../container)]" Method: importEadNote Parameters: ["$options = array('note' => $nodeValue, 'noteTypeId' => QubitTerm::LOCATION_NOTE_ID)"]
However, this doesn't address the third condition of <container> without <physloc>. If we retain the current <container> logic, the physloc_with_container rule will duplicate the container.
#19 Updated by David Juhasz almost 8 years ago
In my opinion the ideal solution is to remove "location" as a property of a physical storage entity and make location an first order entity in the database. e.g. Instead of having a physical storage location like "name: box 12345, type: hollinger box, location: building 1, aisle 12, shelf 104" there would be a hierarchical arrangement like:
- building 1, type: location
- aisle 12, type: location
- shelf 104, type: location
- box 12345, type: hollinger box
- shelf 104, type: location
- aisle 12, type: location
This would allow a great deal of flexibility when specifying locations and containers, with various hierarchial arrangements (flat, location->container, location->*location->container).This does have some implications:
- What do we do for existing users? Update their data to match the new model via migration script, or leave it alone?
- How can the user manage these hierarchical arrangements in the AtoM?
- We currently hide the "location" data from public users - how do we control public visibility with this new model?