Versions Compared

Old Version 3

changes.mady.by.user Michael Durbin

Saved on

compared with

New Version 4

changes.mady.by.user Michael Durbin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • migration of data that's not in the repository (like configuration, global xacml policies, etc.) will require special handling
  • ability to write and use plugins (special configurations) for mapping complex metadata or fedora 3 constructs into fedora 4 must be made as easy as possible since most institutions will need to write their own or adapt existing ones

 

Pluggable

The main framework will take as its source FOXML from a fedora repository.  This may be just pointing to the fedora data store directory or pointing it to a running repository and fetching each record through the export API call.  What happens during the processing of each object must be highly configurable.  For the purpose of this proposal, consider the term "processing plugin" to refer to a bit of code or algorithm to handle a part of a fedora object.

Identifier plugins

A place that represents the implementation of your institutional pid migration strategy.  This could be as simple as "Store the PID as a DC identifier and mint a new fedora 4 id for this item" to something more complex like "escape the existing pid into a fedora 4 path".

Datastream plugins

I envision lots of datastream plugins whose applicability is based on characteristics of the datastream such as control group, mime type, dsid or even based on the content model that defines it.  Presedence for such rules should be simple and well-defined. 

You should be able to express strategies like some of the following examples:

  • the DC datastream should be translated into RDF assertions
  • datastreams called descMetadata should be translated to RDF assertions using a given template
  • the content datastream on objects with the cmodel:images content model should be handled X
Access Control plugins
  • POLICY datastreams should be mapped as follows
Reporting plugins

In addition to processing plugins, the framework allows for no-op plugins that instead of migrating data, performs some sort of check, gathers some statistics or otherwise generates a report that may be useful in developing and planning migration.