Move to Islandora Kit's output CSV is completely under our control

[mjordan]

@seth-shaw-unlv I'm sorry if I didn't clarify how MIK might be used in conjuction with Migrate Plus. I see you have provided a patch for Migrate Plus because

The Move to Islandora Kit sample metadata, however, combines [subject fields of different types] into a single column. This requires us to perform a single lookup across multiple content types, something the existing migrate_plus module doesn't support.

What I didn't explain in Islandora/documentation#452 was that the sample CSV you were looking at is input to MIK, whereas what we want to do here is to use MIK to output a CSV that we can then hand off to Migrate Plus.

The structure and content of sample CSV that I have provided in Islandora/documentation#452 (comment) and that my work in MarcusBarnes/mik#463 is completely under our control. Some hacking I did late last week added functionality to MIK to generate a CSV (and accompanying images) from an existing Islandora 7.x collection via an OAI harvest. I am happy to additional work on this MIK "toolchain" required to avoid patching anything.

The initial work I did used the metadata from DC XML harvested via OAI. We could harvest MODS, parse it, and lay values down in a CSV files as well. I started with DC since I didn't want to get tangled up in MODS->CSV mappings before I demonstrated to myself that MIK could be made to output a CSV file. @dannylamb and I have discussed doing things like spitting out some Xpath expressions from Form Builder configurations to use as ways of mapping MODS structures to CSV columns.

[seth-shaw-unlv]

Well, at least my updated example matches what other inputs MIK users are used to seeing.

I should note that the Migrate API actually works quite well with an XML or JSON feed by matching the destination fields to the appropriate source records' XPath (e.g. my overly-simplified MADS import), so we could do a migrate that pulls straight from either the DC XML or the MODS to populate the nodes, no CSV intermediary required. @Natkeeran demonstrates this approach on this ticket.

[seth-shaw-unlv]

@mjordan I think source CSV files that combine subjects and agents are going to be a common example, so even if split people subjects and topic subjects apart again in this example, I should leave a note about the issue with having them in the same field and the patch to make it work.

[mjordan]

Totally agree that if we can skip the CSV we're ahead. It would be easy to modify a couple of MIK classes to fetch the MODS instead.