View Source

From the point of view of PW components include migration actions, characterization and quality assurance as well as a combination of components. Components must provide a common interface and must be available on the component catalogue. An Overview of goals and requirements can be found in the document [^GoalsandrequirementsforPTfromtheperspectiveofPW.pdf].

[Component interfaces|SP:Preservation Component Profiles] and lookup were discussed at the [Registry Workshop at AIT|SP:Preservation Components, Workflows, Planning and Platform integration].

h2. Specific Feature Requirements 

These requirements were refined in [^GoalsandrequirementsforPTfromtheperspectiveofPW.pdf] and further discussed at the [Registry Workshop at AIT|SP:Preservation Components, Workflows, Planning and Platform integration]


h3. List of all components

Retrieve a list of all available components.

h3. Search for components based on metadata

* name
* category
* source formats *
* target formats \*, \*\*
* cost 
* software license 
* \[tbd\]

\* use of wildcard should be possible, e.g. search for image migration components image/\*

\*\* not relevant for Characterization, QA

(cost, software license, .. could also be of interest for QA tools, when used in executable plan.)

h3. Describe component

Retrieve a machine readable description of a component (based on component id).
* name
* version
* tool category (Migration, Characterization, Quality Assurance, ...)
* output specification (e.g. for QA Tools: measured criteria)
* (config parameters?)
* information to invoke the component
* \[tbd\]

h3. Execution of component  

* Invoke component directly (e.g. as WS)
* Use component in a Taverna workflow

h2. Use Cases

PW uses services provided by the Platform for different tasks.

h3. During Planning

h4. Define Alternatives

The user has defined the organizational policies, and representative sample objects of a certain format.

The Platform is queried for suitable migration actions according to format , ..., information about all found migration actions is displayed to the user, who can select a subset of these actions for evaluation.

h4. Evaluate Alternatives

The Platform is queried for suitable characterization and QA components.

An experimental Taverna workflow is created, using the selected migration actions and characterization and QA components.

This experimental Taverna workflow is executed on \[tbd\] (for PW it is not relevant, where the workflow is executed, as long as there are all components available. However, if it is not executed on the Platform, information about performance cannot be gathered from this experiment - at least they are not comparable)

Results have to be retrieved from the Platform/datastore, this includes migrated objects as well as characterization results, runtime information, ...

h3. Executable Plan

Based on collection profile and selected migration action.

It includes migration components, and may also include QA workflows/components

The user can decide to install the plan in the repository using the [Plan Manager|SP:Plan Management Mock-Up].

This plan is executed on the Platform