<Physloc> fix in 1.2 upgrade
Anne-Marie
If the problem with <physloc> data not importing is fixed in 1.2, will
the location data we have already imported with the rest of our XML
then display correctly or would we need to reimport?
We are trying to decide if we can continue with implementation or if
this is going to hang up the project.
Anne-Marie Viola
Archival Consultant
International Centre for the Study of the Preservation and Restoration
of Cultural Property (ICCROM)
Rome, Italy
http://www.iccrom.org
Evelyn McLellan
Sorry for the delay in our response. I have asked one of the
developers to look into this and get back to you as soon as possible.
Evelyn McLellan
Anne-Marie
the Qubit-dev discussion group here,
http://code.google.com/p/qubit-toolkit/issues/detail?id=643
It is not without disadvantages so I remain eager to hear what the
developers have to say.
Anne-Marie Viola
Archival Consultant
International Centre for the Study of the Preservation and Restoration
of Cultural Property (ICCROM)
Rome, Italy
http://www.iccrom.org
MJ Suhonos
My apologies for not responding to this issue more quickly. I was not familiar with the issue and so didn't quite understand what was being proposed, and how it should be addressed.
Anne-Marie, the workaround you describe on issue #643 seems reasonable enough, and I will just comment to say that, in general, all data-related issues would have to be done similarly (ie. in-place using SQL) if you wish to avoid re-importing descriptions. In the vast majority of cases, normalizing or otherwise modifying existing data within ICA-AtoM code is not a good idea since data can vary significantly between institutions. Your fix is a good example of a graceful solution.
To be sure that I understand the issue before I commit a fix for #643, please let me clarify:
- Tim's mapping on the issues page does only work for a top-level did/physloc node, and is only triggered from within a did/container.
- A physloc element can only appear within any did or archref element (based on the EAD DTD)
Is the behaviour described originally by Peter still desired? If so, both cases would be triggered by the did/physloc element, and we would have two mapping rules like so:
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)"]
Please note that I haven't tested these expressions, and they're just off the top of my head. If someone can confirm this is the desired behaviour, that's what I'll test to.
Also note the use of the % prefix for designating an XPath relative to the current node -- in this case did/physloc -- which is currently underused in mappings due to the way method options are passed an array. Given the complexity of recent mapping changes by Tim and others, we may want to extend this behaviour for the 1.2 release.
Hope this helps, and please let me know if this will address everyone's requirements.
MJ
> --
> You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
> To post to this group, send email to ica-ato...@googlegroups.com.
> To unsubscribe from this group, send email to ica-atom-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ica-atom-users?hl=en.
>
Tim Hutchinson
From my perspective, I think that's still the desired behaviour. I just
want to add a couple points which add complications to this issue:
- it's not clear to me what a "note with type location" refers to, and
it appears that other changes to the application (beyond adding this
type to the notes taxonomy) would be required. See my exchange with
Jes�s on the qubit-dev list:
http://groups.google.com/group/qubit-dev/browse_frm/thread/3846016433164fe7
- I filed issue 1966, "Importing EAD <container> element merges physical
location information when name is identical". As detailed there,
depending on how <container> is populated, importing that data may not
occur as expected, resulting in loss of data in the case where the name
is the same but the type is different. It is also not obvious how the
import should occur. E.g. map cabinet B is probably unique across an
institution; Box 1 not so much - and then throw in multi-institution
issues to make this even more complicated...
I'm glad to learn of some additional XPath syntax - I have really only
been able to copy the existing examples!
Tim
--
Tim Hutchinson
University of Saskatchewan Archives
301 Main Library, 3 Campus Drive
Saskatoon, SK S7N 5A4
tel: (306) 966-6028
fax: (306) 966-6040
e-mail: tim.hut...@usask.ca
web: http://www.usask.ca/archives/
MJ Suhonos
> - it's not clear to me what a "note with type location" refers to, and it appears that other changes to the application (beyond adding this type to the notes taxonomy) would be required. See my exchange with Jesús on the qubit-dev list:
> http://groups.google.com/group/qubit-dev/browse_frm/thread/3846016433164fe7
It's not clear to me what that refers to either, so I'll ask Peter for clarification. You're absolutely right that the impact of adding a new note type for this would be the same as you and Jesús have discussed. From my perspective the question is whether this is critical functionality for people eg. Anne-Marie.
> - I filed issue 1966, "Importing EAD <container> element merges physical location information when name is identical". As detailed there, depending on how <container> is populated, importing that data may not occur as expected, resulting in loss of data in the case where the name is the same but the type is different. It is also not obvious how the import should occur. E.g. map cabinet B is probably unique across an institution; Box 1 not so much - and then throw in multi-institution issues to make this even more complicated...
Yes, I've had a look at that issue as well, but wanted to be sure to keep them as separate as possible. There are some strangely-defined aspects in EAD like this which make importing more challenging. So, issue 1966 is on the radar, but I have a few priorities that I'd like to address first. We're also missing David for a couple of weeks while he cares for his newborn son, so I'm learning in areas that he would normally be able to address much more quickly.
> I'm glad to learn of some additional XPath syntax - I have really only been able to copy the existing examples!
Glad to hear it -- most people are (rightly) scared off by XPath syntax, and the mapping design makes it even more cumbersome. I tried to sprinkle some convenience aspects in where possible, but unfortunately very few people have ventured in far enough to explore everything it can (and can't) do.
In case you hadn't seen it before, there is some documentation: http://qubit-toolkit.org/wiki/index.php?title=XML_import/export#Import
MJ