You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Location data needs to be migrated at a more granular level to reflect local practice and needs. For UA and ALA instances of Archon, specific locations are coded as specific buildings/public display names for the interface. However, the migrator assumes that whatever is in the "location" field should be migrated to the "building" field in ASpace. There is a mapping available in a config file for the two relevant Archon instances that would provide the relevant building information. However, there are many fields available to describe location in ASpace, and it might be better to take advantage of these and parse out the location text even further.
For accuracy, we would not want the migrator to parse the text, but instead look up the location id value to find what we decided it should map to.
An initial start might be to migrate the public display name to the "building" field and the private display name to the "room" field.
It looks like implementing a fix would affect a couple different functions.
Location data needs to be migrated at a more granular level to reflect local practice and needs. For UA and ALA instances of Archon, specific locations are coded as specific buildings/public display names for the interface. However, the migrator assumes that whatever is in the "location" field should be migrated to the "building" field in ASpace. There is a mapping available in a config file for the two relevant Archon instances that would provide the relevant building information. However, there are many fields available to describe location in ASpace, and it might be better to take advantage of these and parse out the location text even further.
For accuracy, we would not want the migrator to parse the text, but instead look up the location id value to find what we decided it should map to.
An initial start might be to migrate the public display name to the "building" field and the private display name to the "room" field.
It looks like implementing a fix would affect a couple different functions.
addLocationInfo(JSONObject containerJS, JSONObject location)
https://github.com/archivesspace/archon-migration/blob/5ab5bc4aed3607a71923ec91e0a515680c361f7b/src/org/nyu/edu/dlts/utils/ASpaceCopyUtil.java#L2176
This calls getLocationURI(building, coordinate1, coordinate2, coordinate3)
This function won't work if we strip the building field down to simply be the building.
Here is that function:
getLocationURI(String building, String coordinate1, String coordinate2, String coordinate3)
https://github.com/archivesspace/archon-migration/blob/5ab5bc4aed3607a71923ec91e0a515680c361f7b/src/org/nyu/edu/dlts/utils/ASpaceCopyUtil.java#L2653
This function forms a "key" to the locationURIMap that simply concatenates the text of the building and the coordinates.
Maybe we want to write some custom UIUC versions of these instead?
The text was updated successfully, but these errors were encountered: