The Ontology for Provenance and Plans (P-Plan) is an extension of the PROV-O ontology [PROV-O] created to represent the plans that guided the execution of scientific processes. P-Plan describes how the plans are composed and their correspondence to provenance records that describe the execution itself.
The latest OWL encoding of the P-Plan Ontology can be found here
P-Plan is an OWL2 ontology developed to describe abstract scientific workflows as plans and link them to their past executions.
P-Plan extends the W3C PROV-O Ontology [PROV-O], which encodes the W3C PROV
data model [PROV-DM]. PROV-DM describes the provenance
of objects (
prov:Entities) as a record of assertions about the steps (
prov:Activities) that generated them and the entities used in those steps.
Provenance describes past execution, but does not offer a vocabulary to express the plan that the execution was supposed to follow.
As an example, provenance vocabularies are appropriate for describing assays once they are executed, but are not designed to describe protocols. Therefore, in addition to the provenance record, it is often desirable to publish the plan that was followed during the execution. This would allow the provenance record to include what was envisioned would happen prior to the execution.
Publishing the plan has several benefits:
Acknowledging this need, PROV includes the term “
prov:Plan”. However, it does not elaborate any further how plans can be described or
related to other provenance elements of the execution, which is precisely the scope of the P-Plan ontology.
This document specifies the classes and properties of the P-Plan ontology.
P-Plan extends PROV to link the provenance traces to their plan descriptions. The next tables summarize the classes and properties that have been used to extend or complement the PROV-O Starting Point Terms to our domain. No dataproperties are included, because P-Plan doesn't define any:
P-plan uses PROV to represent the provenance of the execution and extends it to link it to the different parts of the plan.
PROV describes the usage and generation of entities through two main properties:
(an Entity wasGeneratedBy an Activity) and
prov:used (an Activity used an Entity for the execution).
The agents responsible for the execution are linked to the activity as
prov:Agent with the property
prov:wasAssociatedWith. All properties can be qualified with
prov:Roles. Provenance assertions can be
prov:Bundles, so that provenance can be asserted for the bundle.
In PROV plans are defined as entities associated with an agent and an activity. PROV does not specify anything further about plans and how they correspond to parts of the execution, as it is considered out of the scope of the model for provenance.
Figure 1 shows an overview of P-PLAN and how it relates to PROV concepts,
showing plans at the top and plan executions at the bottom.
The provenance of the execution is entirely captured with PROV. Entity, activity and bundle concepts are subclasses
of PROV classes (
p-plan:Activity) to be able
to represent their relationship with the parts of the plan (p-plan:correspondsToStep property for activities,
p-plan:correspondsToVariable property for entities and
prov:wasDerivedFrom to connect
the bundle representing the execution to the plan).
p-plan:Plan is a subclass of
p-plan:Steps represent the planned execution
activities. Plan steps may be bound to a specific executable step 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. In addition, a step may not have a corresponding activity, for example if there is an execution failure. Dependencies
p-plan:Steps are captured with the
p-plan:Variables represent the inputs of the steps and can have proper-ties (i.e., type, restrictions, metadata, etc.).
p-plan:Variables as input and
p-plan:Variables are output of
p-plan:Steps. Both of them are associated to
p-plan:Plan. The relation of the plan with agents and activities is not specified P-PLAN, since it can be modeled with PROV
a prov:Entity, so its provenance can be modeled with PROV.
Plans may be included as part of other plans, and they can be represented in P-PLAN. However, if a plan A is directly included as a step of plan B, we may find inconsistencies when retrieving the steps that Preceded A (specifically if A is included in other plans appart from B). Therefore if a
p-plan:Step represents a
p-plan:Plan, it becomes a
p-plan:MultiStep, and links to its correspondent
p-plan:Plan with the
p-plan:isDecomposedAsPlan relationship. This way the plan specification is separated from the plan composition.
An example can be seen in Figure 2. The plan P2 (which has 2 steps: Step1P2, Step2P2) is included in plan P1 (which has 3 steps: Step1p1, Step2p1, and Step3p1) as the third step (Step3p1). Therefore, Step3p1 is a
p-plan:MultiStep, linked with P2 via the
p-plan:isDecomposedAsPlan relationship. P2 is also linked to P1 with the
p-plan:isSubPlanOf, which states the inclusion between the two plans explicitly. Every representation of P2 in a plan should be a
p-plan:MultiStep, and linked back to P2.
We would like thank Varun Ratnakar and Raul Alcazar for his help and his technical support and Silvio Peroni for developing LODE, tool used to create part of the cross-reference sections of this document.