oai_xml driver not precise enough to handle mods data

[jacobthill]

The oai_xml driver is able to grab mods fields but it loses much of the context in the process. The oai_xml driver builds column names based on xml elements only, while mods captures much of the data in attributes. Without the attributes informing column names, all urls get named the same thing and appended to a list in a single column of the csv output. We cannot use this to map fields because we have to rely on the order of elements in the list, but some records may not have the same number of elements, which throws the order off.

For now, we may have to use the xml driver for mods records but we need to look into improving the oai_xml driver.

[aaron-collier]

Isn't this just a matter of using the proper xpath query in the configuration to get the specific field with attributes? Let's discuss.

[jacobthill]

We can use the xpath query for each field with either the xml driver or the oai_xml driver. If we use it with the xml driver, we don't have the wait option which we need to harvest qnl. If we do it with the oai_xml driver we can get all the fields we need but it will also harvest many things we don't need since it harvests many things by default. This makes mapping a bit messy since there will be many fields that don't get mapped in the metadata. I think if we are going to manually enter the xpath query for all of the fields, we really should be using the xml driver.

[edsu]

We could adjust the oai-pmh driver to only serialize fields that are defined in the catalog? If we need to capture attributes for context, like we do in the MARCXML driver, this might be possible too?