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.
1. Introduction back to ToC
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:
- The plan can provide a higher-level, more abstract description of what was executed
which improves understandability and facilitates reuse in future situations
- The plan can describe the expectations for the execution,
which can then be contrasted with the provenance to detect deviations and correct abnormalities.
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.
1.1. Namespace declarations back to ToC
Table 2: Namespaces used in the document
| p-plan | <http://purl.org/net/p-plan#> |
| owl | <http://www.w3.org/2002/07/owl#> |
| rdfs | <http://www.w3.org/2000/01/rdf-schema#> |
| prov | <http://www.w3.org/ns/prov#> |
3. P-Plan Description back to ToC
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: prov:wasGeneratedBy
(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
grouped in 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:Bundle, p-plan:Entity and 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 prov:Plan. 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
between p-plan:Steps are captured with the p-plan:isPrecededBy relationship.
p-plan:Variables represent the inputs of the steps and can have proper-ties (i.e., type, restrictions, metadata, etc.).
p-plan:Steps have p-plan:Variables as input and p-plan:Variables are output of
p-plan:Steps. Both of them are associated to
a p-plan:Plan. The relation of the plan with agents and activities is not specified P-PLAN, since it can be modeled with PROV
(with the prov:hadPlan property).
Note that prov:Plan is a prov:Entity, so its provenance can be modeled with PROV.
3.1 Subplan representation
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.
A p-plan:Entity is a subclass of prov:Entity that represents the input of an executed p-plan:Activity. The p-plan:Entity corresponds to a p-plan:Variable in the overall p-plan:Plan.
Example: