Open awead opened 8 years ago
For my part, I think of this gem like ActiveFedora- mashing it up with Hydra::Works should probably be a downstream concern. That said, there are some things that will probably be required by PCDM migrations that make sense here.
I would vote for leaving this gem handling scenario 1 as it currently does and create separate gems for the other two scenarios.
Since the source data for scenarios 1 and 2 is totally different (Fedora 3 vs Fedora 4) I doubt there would be a significant amount of common functionality to justify a single gem, despite the fact that the output (Fedora 4 PCDM) would be the same for scenarios 2 and 3.
For the ScholarSphere migration from Sufia 6 to Sufia 7 I have been tinkering with exporting theGenericFile
metadata to JSON files from a Sufia 6 instance and importing those files into Sufia 7 GenericWork
, FileSet
, and File
. You can see here the proto-type for the export process here: https://github.com/psu-stewardship/scholarsphere/pull/272 and the one for the import process here https://github.com/projecthydra/sufia/blob/import_s6/lib/sufia/import/import_service.rb
Yeah, I'm inclined to agree, @hectorcorrea. The other point is that most people will probably want to go from Sufia 5 to 7, and not stay on 6 forever. So I can see a migration path using a suite of tools such as this gem, with additional modifications as @barmintor points out, then another gem that does the PCDM lifting based on what you're working on.
:+1: to @hectorcorrea
This question was brought up in projecthydra-labs/curation_concerns#716
The scenarios are:
The original intention of the gem was just the first scenario. Whether or not it would hold up with the other two is unknown. We could build a new gem just for PCDM migrations, which would leave this gem only responsible for migrating Sufia from 5 to 6, then the new gem does 6 to 7.
Ping: @mjgiarlo @barmintor @hectorcorrea, who's currently working on some PCDM migration tools for Penn State.