The Workflow Fragment Description Ontology

Table of Contents

• 1. Introduction
• 1.1 Namespace declarations
• 1.2 Terminology
2. Wf-fd Overview
• 3. Wf-fd Description
• 4. Cross reference for Wf-fd classes, properties and dataproperties
• 4.1 Classes
• 4.2 Object Properties
• 4.3 Data Properties
• 5. References
• 6. Acknowledgements

1. Introduction back to ToC

A scientific workflow can be seen as a digital instrument that allows scientists to encode a scientific experiment in the form of a set of computational or data manipulation steps. Scientific workflows play an important role in the reproducibility and replicability of scientific experiments, as well as in repurposing and reusing results from previous experiments [Goderis et. al.].

Given their importance in the research lifecycle, scientific workflows are beginning to be included in scientific publications, together with datasets and other elements used in the context of an experiment. At the same time, repositories of workflows like myExperiment, Crowdlabs or Galaxy facilitate workflow publication, exchange and reuse. These repositories currently store thousands of workflows (referred to as workflow templates), which have been uploaded by scientists in many different domains (ranging from life sciences to text analytics or astronomy).

These workflow templates and the provenance associated to their executions are used for different purposes: detection of the source of an error in a particular execution, determining workflow similarity among workflows, automatic workflow mining for helping in workflow design or detection of common workflow fragments among the workflow dataset.

The Workflow Fragment Description ontology (Wf-fd) aims to model workflow fragments by connecting them to the different workflows to which they correspond. The objective of the ontology is twofold:

1. Model the workflow fragments and how they overlap with each other independently of their connection to template.
2. Model how the workflow fragments can be found within workflow templates.

The Wf-fd ontology complements the work described in [Garijo et. al.], where an approach for detecting common workflow fragments is described. Some of the descriptions and motivation used in this document are extracted from that publication.

2. Wf-fd Overview back to ToC

Wf-fd extends the Ontology for provenance and plans (P-plan) to link workflow fragments to the workflow templates where they can be found. The next tables summarize the classes and properties that have been used to extend or complement P-plan to adapt it to our particular domain. No dataproperties are included, because Wf-fd doesn't define any:

4.1 Classes

• wffd:TiedResultWorkflowFragment
• wffd:DetectedResultWorkflowFragment
• wffd:WorkflowFragment

4.2 Properties

• wffd:foundAs
• wffd:foundIn
• wffd:isPartOfWorkflowFragment

4.3 Data Properties

• wffd:detectedByAlgorithm

3. Wf-fd Description back to ToC

As stated, the Wf-fd ontology aims to link workflow fragments to their occurrences in workflow templates. A wffd:WorkflowFragment extends p-plan:Plan, since a fragment of a workflow is a workflow itself (which is also a type of p-plan:Plan). A workflow fragment has steps (p-plan:Step) which represent the individual data manipulation steps of a particular fragment.

There are two types of wffd:WorkflowFragments: wffd:DetectedResultWorkflowFragment and wffd:TiedWorkflowFragment. The former refers to those workflow fragments found as a result of applying graph mining techniques among a workflow collection (i.e., the results of the algorithms). The latter is used to represent how a particular result workflow fragment is bound to a part of a workflow template. This separation is necessary to properly point to the different parts of a workflow where a fragment appears. For instance, if we find that a fragment appears twice in a workflow, then we need two wffd:TiedWorkflowFragments to group the workflow steps belonging to each fragment. For this we use the relationship wffd:foundAs, which links a wffd:DetectedResultWorkflowFragment to the wffd:TiedWorkflowFragment which represents it in the workflow.

Workflow fragments may be included in other workflow fragments. In order to capture this overlap among the detected result workflow fragments, we use the relationship wffd:isPartOfWorkflowFragment. This facilitates querying the results, being able to retrieve efficiently the fragments related to each other.

Another function to facilitate relating fragments is wffd:foundIn. This function connects a wffd:DetectedResultWorkflowFragment to the Workflow (p-plan:Plan) where it was found (i.e., where one or more wffd:TiedWorkflowFragments have been wffd:foundAs).

Workflow fragments are composed by steps (p-plan:Step). Since we are interested in representing the ordering of the steps in the result fragment, we use the property p-plan:isPrecededBy between detected result fragment steps. The ordering of other workflow fragment steps, such as the ones belonging to a tied workflow fragment, is out of the scope of Wf-fd.

The Wf-fd complete diagram can be seen in Figure 1 below.

Figure 1. Wf-fd as an extension of p-plan: Workflow fragments are represented as plans with steps. The extension is represented in blue, while in orange the original classes are shown.

An example of usage of the Wf-fd ontology can be seen in Figure 2. Three workflows are represented on the top of the figure (Workflow 1, Workflow 2 and Workflow 3) with their steps coloured in orange. Each step has its URI represented on the top (e.g., :step1W1), while their type is represented in angle brackets. In order to avoid adding complexity to the figure, only the relevant type of the step for detecting the fragments is shown (e.g., <A>, <B>, etc).

On the bottom of the figure the two detected result workflow fragments are shown. As depicted in Figure 1, each workflow fragment step belongs to a workflow fragment. The detected result workflow fragments (shown in yellow) are linked to their tied workflow fragment (parts of the original workflows where they appear, shown in green) with the wffd:foundAs relationship. Each fragment is also directly connected to the original workflow with the property wffd:foundIn.

Figure 2. Wf-fd: example of usage. On the top side of the figure some workflows of the workflow collection are represented. The names of their staps are different, but some of their types are common. On the bottom part of the figures we can see the fragments detected (yellow plus orange). With the help pf wf-fd, all the fragments are properly represented anb bound to their corresponding fragments in the workflow templates.

4. Cross reference for Wf-fd classes and properties