Feature #2593

Add <physloc> support to EAD import

Added by Peter Van Garderen over 12 years ago. Updated about 5 years ago.

Status:NewStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:EADEstimated time:24.00 hours
Target version:Release 1.4.0
Google Code Legacy ID:atom-643 Tested version:
Sponsored:No Requires documentation:

Description

if <physloc> is given without a <container> element, set a note with type
'location'.

Otherwise, use the <physloc> content to set the container's location
element value

[g] Legacy categories: Import/Export, EAD

History

#1 Updated by Peter Van Garderen almost 12 years ago

[g] Labels added: Component-EAD

#2 Updated by Anonymous almost 11 years ago

  • Priority set to Low

[g] Labels added: Priority-Low

#3 Updated by Evelyn McLellan over 10 years ago

  • Target version set to Release 1.2

Moved to 1.2.

[g] Labels added: Milestone-Release-1.2

#4 Updated by Anonymous over 10 years ago

- Missing comment -

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

container:
XPath: "did/container"
Method: setPhysicalObjectByName
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.

#8 Updated by Tim Hutchinson about 10 years ago

See also /p/qubit-toolkit/issues/detail?id=1966 re importing <container>

#9 Updated by MJ Suhonos about 10 years ago

[g] New owner: MJ Suhonos

#10 Updated by David Juhasz over 9 years ago

  • Target version set to Release 1.3

Roll over to Release 1.3

[g] Labels added: Milestone-Release-1.3

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

[g] New owner: David Juhasz

#13 Updated by David Juhasz about 9 years ago

Reassign to David's new account.

[g] New owner: David Juhasz

#14 Updated by Jessica Bushey over 8 years ago

  • Target version changed from Release 1.3 to Release 2.1.0

[g] Labels added: Milestone-Release-2.0
[g] Labels removed: Milestone-Release-1.3

#15 Updated by Jesús García Crespo over 8 years ago

  • Subject changed from add <physloc> support to EAD import to Add <physloc> support to EAD import
  • Sponsored set to No

#16 Updated by David Juhasz over 8 years ago

  • Target version changed from Release 2.1.0 to Release 1.4.0

#17 Updated by José Raddaoui Marín almost 8 years ago

What should we do about this after #3850 and #4972 fixes?

#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

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:
  1. What do we do for existing users? Update their data to match the new model via migration script, or leave it alone?
  2. How can the user manage these hierarchical arrangements in the AtoM?
  3. We currently hide the "location" data from public users - how do we control public visibility with this new model?

#20 Updated by Jesús García Crespo almost 8 years ago

Is this maybe something that we want to address in future releases o do you want Radda to tackle this as part of 1.4?

#21 Updated by David Juhasz almost 8 years ago

I think we shoul make the change for Release 1.4.

#22 Updated by David Juhasz almost 8 years ago

  • Category set to EAD

#23 Updated by José Raddaoui Marín almost 8 years ago

  • Estimated time set to 24.00

David, please let me know if you have any more details on how you want me to implement this, e.g. migration, management of the elements, wireframes, etc...

#24 Updated by David Juhasz about 5 years ago

  • Assignee deleted (David Juhasz)

Also available in: Atom PDF