Attach RDF Properties Directly to Parent Container

[daniel-dgi]

See https://github.com/daniel-dgi/migration-utils/blob/camel-service/migration-service/src/main/java/org/fcrepo/migration/service/routes/DatastreamIngesterRoute.java#L31

You should make another route to handle this to try and keep things clean.

The parent container's path is accessible as a property on the exchange, although it has already been set as a header that will be utilized by the fcrepo camel component. See: https://github.com/daniel-dgi/migration-utils/blob/camel-service/migration-service/src/main/java/org/fcrepo/migration/service/routes/DatastreamIngesterRoute.java#L23

[whikloj]

Soooo, I'm new to camel, but I am guessing you want to transform the RDF to be compatible with a POST/PUT or PATCH.
Do you want to iterate through all the contents of the rdf:Description element or try and convert it all at once using an XSLT?

[whikloj]

Are we attempting to maintain "collections", etc? That requires maintaining our existing PIDs, which is not necessarily to our benefit.
So we could set the old PID as a property, then we will need to iterate through the RDF properties and for things like

<fedora:isMemberOfCollection rdf:resource="info:fedora/test:collectionPid"/>

Get the new UUID from fedora 4 based on the old PID property to re-associate them. This requires things going in from top to bottom.
Or am I off-track?

[ruebot]

Nope. Not off track. The migration plan that we've sketched out between the two of us is staged, and goes like this:

1. Grab all collection objects
2. Grab all audio, image, large image, book (containers), compound (container), etc
3. Grab all children of containers (book, compound, newspaper).

[whikloj]

Last question (for now). Did you discuss how to do the linking between old PIDs and new? I asked @acoburn about searching a triplestore during the route and he suggested that a simple SQL DB would be easiest.
But then I wondered if the plan was to migrate everything first then do the "re-linking" as a second pass.

[ruebot]

Oh. That's a really good question... and @daniel-dgi and I didn't discuss that before he went on vacation this week 😢

[acoburn]

Sorry to barge in -- are you all planning to maintain this mapping of fcr3 pids to fcr4 paths beyond the migration itself? So that when a browser visits an old fcr3 URL the response is a 303 to the fcr4 path? (At least that's what I'm planning to do -- which is why a simple database seems easiest)

[ruebot]

No worries for barging in! You're always welcome here Aaron 😄

We hadn't really thought that out completely yet. But, the plan in my head for that was to use the Drupal Pathauto module in conjunction with the Islandora Pathauto module to take care of all the redirects. Basically create a little sub-module that redirects everything.

[whikloj]

Hi Aaron. I had not grasped the long view of your suggestion but now it leads me to wonder.
I think a db it makes sense, and your point about persistence is also valid.

Perhaps we can create a custom field in our Drupal content type to store the old PID. Then have it populated by the camel migration. Lastly, we could create this module of Nick's by querying the data already in Drupal and either generating a new table or using what is there.

[daniel-dgi]

Irrelevant and closed. All work has been rolled into https://github.com/fcrepo4-labs/migration-utils