3. OPMW Description back to ToC
The Open Provenance Model offers several core concepts and relationships to represent provenance. It models the resources (datasets) as artifacts (immutable pieces of state), processes (action or series of actions performed on artifacts), and agents (controllers of processes). Their relationships are modeled in a provenance graph with five causal edges: used (a process used some artifact), wasControlledBy (an agent controlled some process), wasGeneratedBy (a process generated an artifact), wasDerivedFrom (an artifact was derived from another artifact) and wasTriggeredBy (a process was triggered by another process). It also introduces the concept of roles to assign the type of activity that artifacts, processes or agents played when interacting with each other, and the notion of accounts and provenance graphs to group sets of OPM assertions into different subgraphs. An account represents a particular view on the provenance of an artifact based on what was executed.
The PROV model is heavily influenced by OPM. PROV models the resources as entities (which can be mutable or immutable), the steps using and generating entities as activities, and the individuals responsible for those activities as agents. The relationships are also modeled in a provenance graph with seven types of edges: used (an activity used some entity), wasAssociatedWith (an agent participated in some activity), wasGeneratedBy (an activity generated an entity), wasDerivedFrom (an entity was derived from another entity), wasAttributedTo (an entity was attributed to an agent), actedOnBehalfOf(an agent acted on behalf of another agent) and wasInformedBy (an activity used the entity produced by another activity). PROV also keeps the notion of roles to describe how entities, activities and agents behaved in a particular event (usage, generation, etc.); and provides the means to qualify each of the aforementioned relationships using an n-ary pattern. PROV allows to state the plan associated to a certain activity, although the plan definition itself is out of the scope of the model (since it is not something that necessarily happened). PROV statements can be grouped in named sets called bundles, which are entities themselves (allowing for their provenance to be described).
P-plan is a PROV extension for representing scientific processes (ranging from a laboratory protocol to an invocation of a specific script). In particular, P-plan indicates how plans should be specified. A p-plan:Plan is a subclass of prov:Plan. The p-plan:Steps represent the planned execution activities. Plan steps may be bound to a specific executable step (p-plan:correspondsToStep) or refer to a class of steps, providing an abstraction layer over the execution. As a result, a plan step could be carried out in different ways in different executions of the same plan. A step may not have a corresponding activity, (as in an execution failure). A p-plan:Variable represents the inputs of the a steps and can have properties (i.e., type, restrictions, metadata, etc.). p-plan:Steps may be preceded by other p-plan:Steps (p-plan:isPrecededBy), and have p-plan:Variables as input. p-plan:Variables are output of p-plan:Steps. Both steps and variables are associated to a p-plan: Plan (p-plan:isStepOfPlan and p-plan:isVariableOfPlan respectively). The relation of the plan with agents is not specified P-plan, since it can be modeled with PROV. The following figure summarizes P-plan as an extension of PROV:
Figure 1: P-Plan as an extension of PROV.
OPMW extends PROV, OPM and P-Plan in order to capture the execution traces of a workflow template (process view provenance). The workflow template itself is captured by extending the P-plan ontology (which is also aligned with PROV. The following figure summarizes how OPMW extends OPM, PROV and P-plan:
Figure 2: OPMW as an extension of OPM, PROV and P-plan.
OPMW also represents another important aspect of the workflows: the metadata of the template and execution itself (attribution provenance). The next sections describe in detail the OPMW extension as it represents the process view provenance and the attribution view provenance.
3.1 Process view provenance back to ToC
OPMW describes the traces of the execution of a workflow along with the abstract workflow (template) used for its design. The trace is described by extending opmv:Artifact and prov:Entity with opmw:WorkflowExecutionArtifact; opmv:Process and prov:Activity with WorkflowExecutionProcess; and reusing OPM and PROV relationships to link them (opmv:used, opmv:wasControlledBy, opmv:wasGeneratedBy and prov:used, prov:wasControlledBy and prov:wasAssociatedWith respectively). All the assertions from an execution are grouped in a opmw:WorkflowExecutionAccount, a subclass of opmo:Account and prov:Bundle that represents the view of the system on the execution.
Workflow templates are defined extending P-plan, in a similar way to the traces. Templates extend the p-plan:Variables with opmw:WorkflowTemplateArtifacts (which can be either opmw:DataVariables or opmw:ParameterVariables) and the p-plan:Steps with opmw:WorkflowTemplateProcesses, which represent an abstraction of the method that is being executed.
The opmw:WorkflowTemplateArtifacts are connected to opmw:WorkflowTemplateProcesses by opmw:uses (subproperty of p-plan:hasInput) and opmw:isGeneratedBy (subproperty of p-plan:isOutpuytvaROf) properties. These properties define which type of opmw:WorkflowTemplateArtifact is used by each opmw:WorkflowTemplateProcess and the type of the expected result. The next figure shows a brief example.
Figure 3: An example of process view workflow provenance.
Figure 3 shows a process view high level diagram of the OPM and OPMW representation of an abstract workflow on the left (a type of workflow template) and a workflow execution on the right. The example workflow shown here has one step (executionNode1), which runs the workflow component (specComp1) that has one input (execInput1) and one output (executionOutput1).
3.2 Attribution provenance back to ToC
Attribution is key for scientists who publish the workflow. Thus, OPMW was designed to include metadata from the specification as well as from the execution itself. Figure 4 shows an attribution view on the provenance of the same workflow of Figure 3.
Figure 4: An example of attribution provenance
The workflow template contains information of the authors of the original article, the contributors of the workflow, the version, the date of creation and documentation of the workflow (that may include a pointer to the publication). OPMW reuses terms from the Dublin Core (DC) Metadata Terms Vocabulary . The executed workflow links to the workflow systems used to create and execute it, the license, date of start and end of the run and the final status (succeeded or failed execution).
A Data variable is a workflow template artifact that represents a variable in the workflow specification.
Example: