Powered by OPF
OPF WIKI STATIC ARCHIVE
2,681 pages · 153 spaces · 776 tags · 4,025 history records · 96.2% of the original wiki recovered
Archived copy. This page was recovered from the Internet Archive snapshot of /display/SP/Preservation Component Profiles taken on 2016-03-30. The original wiki at wiki.opf-labs.org is being decommissioned.

Preservation Component Profiles

Created by Markus Plangg on Jun 18, 2012 · last edited by Markus Plangg · on Oct 07, 2013 (view history) · 53 versions
Specification, for current work on components check https://github.com/openplanets/scape-component-profiles.

During the PC meeting of 2013-06-18 (Paris) new component profiles have been defined, commented and agreed upon by the CC, AS and QA WP leads. The new definition of profiles contains active contributions from Donal, Carl, Miguel and Hélder. 

Further information on this topic will be uploaded soon. A small report is being devised at the moment.

Motivation

The PC subproject develops and packages a variety of tools for preservation actions, characterisation and quality assurance. Additionally it packages existing tools to ensure that all services are compliant with and can be deployed in the SCAPE platform. Existing tools usually come in the form of command line programs that provide a variety of output formats. To guarantee interoperability between services and enable automation of preservation processes, PC creates preservation components that provided a standardised interface. These preservation components are based on Taverna workflows as a common language. They either wrap command line tools with necessary post-processing, are directly implemented as workflows or are composed of other components.

To allow discoverability (e.g. for preservation planning, watch or other users), the components must be annotated with relevant information using a common vocabulary. Standardised interfaces add the possibility of automating parts of a preservation process. Additionally, dependencies allow the execution platform to run the components. All these aspects are defined as preservation component profiles.
Using Taverna workflows allows domain experts from the testbed as well as the wider community to engage in the development of preservation components. The Taverna workbench will implement a mechanism to easily validate workflows against profiles.

Component usage

Migration and QA example

To increase the level of automation and thus scalability in preservation planning, the planning component queries the component repository (myexperiment.org) for migration components based on the migration paths and other criteria specified in the policy of the organisation (e.g. by license). The preservation planner the selects fitting alternatives and all representative samples are migrated to the respective target format. Based on the objective tree for this plan, a template of a QA workflow is generated that contains input ports for the path to the files as well as output ports for measurable properties for this file. A preservation planner can then open this template in Taverna and add characterisation and quality assurance components from myexperiment.org that provided the needed properties. The QA components are then used to evaluate the possible alternatives. The preservation planner can select the best alternative and a executable plan (example) is generated by combining the migration component with quality assurance.

How to read this document

The profile has four different areas to check:

  1. Input ports: Input ports of the workflow.
  2. Output ports: Output ports of the workflow.
  3. Taverna activities: Taverna activities that have to be present in the workflow.
  4. Annotations: Annotations on the level of the workflow.

Notation

Port (Datatype, Depth, Example) [Cardinality]
Description

A port is specified by a denomination, the expected datatype, the port depth and an example for an expected value. Additionally it contains the cardinality and a short description.

Taverna activity [Cardinality]
Description

The taverna activity specification contains the Taverna activity and cardinality as well as a short description.

@Annotation name (Datatype, Example) [Cardinality]
Description

A generic annotation contains a specific name, the datatype of the annotation value and an example. Additionally it contains the cardinality and a short description.

@Annotation name (Fixed value) [Cardinality]
Description

A fixed annotation contains the annotation name and a fixed value the annotation must have. Additionally it contains the cardinality and a short description.

The cardinality denotes how often the element can occur, default cardinality is [1, 1].

Please note that the provided URLs are not final and will be specified in a separate vocabulary.

Profiles

Common for all components

These ports and annotations are common for all components, and help to identify them, the profile they adhere to, dependencies and other information used for discovery, assembly and execution.

Input ports

No requirements.

Output ports

Taverna activities

Annotations

Migration action component

Input ports

Output ports

No requirements.

Taverna activities

No requirements.

Annotations

Characterisation component

Input ports

Output ports

Taverna activities

No requirements.

Annotations

Quality assurance object comparison component

Input ports

Output ports

Taverna activities

No requirements.

Annotations

Quality assurance property comparison component

Input ports

Output ports

Taverna activities

No requirements.

Annotations

Validation component

Input ports

Output ports

Taverna activities

No requirements.

Annotations

Migration Executable Plan

Input ports

Output ports

Services

Attributes