Warning:
This wiki has been archived and is now read-only.
Qualifed Involvements in PROV-O
This writeup was created by Tim Lebo on Sunday (2011-11-06) to follow up on Friday's (2011-11-04) telecon with Satya, Daniel, and Stephan.
This outlines the "new design" proposed on Monday's (2011-10-31) telecon to replace EntityInRole with a hybrid "direct and/or indirect" modeling of Qualified Involvements (Usage, Control, Participation, and Generation).
Contents
Materials
The following materials were used to support this proposal.
- PROV-DM public working draft: defines the provenance terminology and how they relate.
- PROV-O components and examples: provides version-controlled portions of OWL axioms with accompanying examples that exercise the axioms. About 60 files were created or modified while preparing this Qualifed Involvements in PROV-O proposal. The examples from PROV-DM were encoded in PROV-O:
- components/Agent/prov-dm-e1.ttl
- components/Agent/prov-dm-e2.ttl
- components/Annotation/prov-dm-ann1.ttl
- components/Entity/prov-dm-e0.ttl
- components/ProcessExecution/prov-dm-pe1.ttl
- components/hadParticipant/prov-dm-constraint-participation.ttl
- components/hasAnnotation/prov-dm-annotation-association.ttl
- components/used/prov-dm-pe1-used-e1-e2.ttl
- components/wasAttributedTo/prov-dm-attribution.ttl
- components/wasComplementOf/prov-dm-rs.ttl
- components/wasControlledBy/prov-dm-pe3-wasControlledBy-a4.ttl
- components/wasControlledBy/prov-dm-qualified-wasControlledBy.ttl
- components/wasDerivedFrom/prov-dm-e5-wasDerivedFrom-e3.ttl
- components/wasEventuallyDerivedFrom/prov-dm-wasEventuallyDerivedFrom.ttl
- components/wasGeneratedBy/prov-dm-e1-e2-wasGeneratedBy-pe1.ttl
- components/wasInformedBy/prov-dm-constraint-wasInformedBy.ttl
- components/wasQuoteOf/prov-dm-quotation.ttl
- components/wasRevisionOf/prov-dm-constraint-wasRevision.ttl
- components/wasRevisionOf/prov-dm-wasRevisionOf.ttl
- components/wasScheduledAfter/prov-dm-wasScheduledAfter.ttl
- component list that aggregates the OWL axioms related to this proposal.
- a titanpad developed by Stephan, Daniel, and Tim. The OWL axioms in here should be reconciled with PROV OWL ontology components
An informal sketch of PROV-DM
The following diagram informally sketches out the different constructs described by PROV-DM public working draft. This is NOT a diagram of an OWL ontology. It is intended to illustrate the extent of the topics addressed by PROV-DM. Each shape represents an instance of a particular class; each edge is a binary relationship that can be represented with an RDF triple. Classes and predicates without namespaces are in the prov namespace; namespace prefixes use the prefix.cc conventions.
Unqualified Involvements
Unqualified involvements are asserted with individual triples. The following example shows a single Activity that exercises each involvement relation twice:
:a
a prov:Activity;
prov:used :input,
:parameters;
prov:hadParticipant :bystander,
:peanut_gallery;
prov:wasControlledBy :drAnderson,
:drJones;
prov:generated :output;
:metdata;
.
:input a prov:Entity .
:parameters a prov:Entity .
:bystander a prov:Entity .
:peanut_gallery a prov:Entity .
:drAnderson a prov:Entity .
:drJones a prov:Entity .
:output a prov:Entity .
:metadata a prov:Entity .
Generated Entities can also refer back to the Activity that generated them. This suits the convention that relations should point backwards in time, allowing one to trace where something came from. The prov:generated predicate shown above is the inverse of prov:wasGeneratedBy below, so if either is seen the other can be "filled in". Generally, we avoid defining the inverses for any property in PROV-O, but prov:generated is included to allow Activity-centric descriptions without needing to "stop" and start describing the Entity. A second reason will be shown below, when prov:generated is needed to accompany its qualified generation.
:output
a prov:Entity;
prov:wasGeneratedBy :a;
.
:metadata
a prov:Entity;
prov:wasGeneratedBy :a;
.
Qualified Involvements
- Qualifiers can be associated to relations, namely use and wasGeneratedBy, in order to further characterize their nature. Role is a pre-defined qualifier.
- - PROV-DM
A QualifiedInvolvement provides additional information about an unqualified involvement. QualifiedInvolvements are subordinate to instances of the primary Activity or Entity classes. A QualifiedInvolvement cannot stand on its own; it can only exist as referenced by a Activity (or, in the case of Revision, an Entity).
The OWL axioms for a QualifiedInvolvement are pretty simple. First, it should have a prov:qualifiedEntity predicate that points to the Entity whose involvement is being qualified. prov:qualifiedEntity can only be used on QualifiedInvolvements and can only point to Entities.
The next four sections apply the QualifiedInvolvement pattern to qualify Usage, Participation, Control, and Generation.
Qualified Usage
Activities can be annotated with a prov:Usage class to qualify how the Activity prov:used an Entity.
So, instead of the direct, minimal information involvements:
:a
a prov:Activity;
prov:used :input,
:parameters;
.
Qualified Usage with Roles
We can qualify how :a prov:used the :input and :parameters Entities, by indicating that one was an input and the other was parameters. Note that you can put ANY application-specific triples you want on the prov:Usage -- that's what it is there for.
:a
a prov:Activity;
prov:used :input;
prov:qualifiedUsage [
a prov:Usage;
prov:qualifiedEntity :input;
prov:hadRole io:input;
];
prov:used :parameters;
prov:qualifiedUsage [
a prov:Usage;
prov:qualifiedEntity :parameters;
prov:hadRole io:parameters;
];
.
The following diagram illustrates the general pattern for how to qualify the unqualified prov:used triple:
Qualified Usage with Time
Qualified Usage with Arbitrary Qualifiers
Qualified Participation
Activities can be annotated with a prov:Participation class to qualify how the participating Entities participated.
So, instead of the direct, minimal information involvements:
:a
a prov:Activity;
prov:hadParticipant :bystander,
:peanut_gallery;
.
Qualified Participation with Roles
We can qualify how the :bystander and :peanut_gallery [1] Entities participated in :a, by indicating that one was the target of a practical joke and the other was the heckler. Note that you can put ANY application-specific triples you want on the prov:Participation -- that's what it is there for.
:a
a prov:Activity;
prov:hadParticpant :bystander;
prov:qualifiedParticipation [
a prov:Participation;
prov:qualifiedEntity :bystander;
prov:hadRole part:practical-joke-target;
];
prov:hadParticipant :peanut_gallery;
prov:qualifiedParticipation [
a prov:Participation;
prov:qualifiedEntity :peanut_gallery;
prov:hadRole part:heckler;
];
.
The following diagram illustrates the general pattern for how to qualify the unqualified prov:hadParticipant triple:
Qualified Participation with Time
Qualified Participation with Arbitrary Qualifiers
Qualified Control
Activities can be annotated with a prov:Control class to qualify how the controlling Agents controlled.
So, instead of the direct, minimal information involvements:
:a
a prov:Activity;
prov:wasControlledBy :drAnderson,
:drJones;
.
Qualified Control with Roles
We can qualify how the :drAnderson and :drJones Entities participated in :a, by indicating that one was the main surgeon and the other was the assisting surgeon. Note that you can put ANY application-specific triples you want on the prov:Control -- that's what it is there for.
:a
a prov:Activity;
prov:wasControlledBy :drAnderson;
prov:qualifiedControl [
a prov:Control;
prov:qualifiedEntity :drAnderson;
prov:hadRole medical:main-surgeon;
];
prov:wasControlledBy :drJones;
prov:qualifiedControl [
a prov:Control;
prov:qualifiedEntity :drJones;
prov:hadRole medical:surgeon-assist;
];
.
The following diagram illustrates the general pattern for how to qualify the unqualified prov:wasControlledBy triple:
Qualified Control with Time
Qualified Control with Arbitrary Qualifiers
Qualified Generation
Activities can be annotated with a prov:Generation class to qualify how the generated Entities were generated.
So, instead of the direct, minimal information involvements:
:a
a prov:Activity;
prov:generated :output;
:metdata;
.
Activities are inherently part of an Entity's qualified generation
If an Entity wants to qualify how it was made, it is inherently bringing the Activity into discussion. Because of this -- and to maintain the regularity simplicity of the pattern we've applied for Usage, Participation, and Control -- an Entity MAY NOT directly cite the QualifiedInvolvement class; it must do so by referencing the PE that generated it (with the usual prov:wasGeneratedBy), and annotating the Activity with the prov:Generation qualifier.
Qualified Generation with Roles
We can qualify how the :output and :metadata Entities were created in :a, by indicating that one was the output (that would correspond to the input) and the other was the metadata (e.g., log) for the output. Note that you can put ANY application-specific triples you want on the prov:Generation -- that's what it is there for.
:output
a prov:Entity;
prov:wasGeneratedBy :a;
.
:metadata
a prov:Entity;
prov:wasGeneratedBy :a;
.
:a
a prov:Activity;
prov:generated :output;
prov:qualifiedGeneration [
a prov:Generation;
prov:qualifiedEntity :output;
prov:hadRole workflow:output;
];
prov:generated :metadata;
prov:qualifiedGeneration [
a prov:Generation;
prov:qualifiedEntity :metadata;
prov:hadRole workflow:metadata-of-output-with-log;
];
.
The following diagram illustrates the general pattern for how to qualify the unqualified prov:wasGeneratedBy and prov:generated triples:
Qualified Generation with Time
Qualified Generation with Arbitrary Qualifiers
Inferring Unqualified Involvements from the assertion of Qualified Involvements
Unqualified involvements can be inferred from Qualified involvements. For example, from:
:a
a prov:Activity;
prov:qualifiedUsage [
a prov:Usage;
prov:qualifiedEntity :input;
prov:hadRole io:input;
];
.
we can infer:
:a
prov:used :input;
.
and thus do not need to assert it directly (though, we can).
The rules would look something like:
# At the superproperty level: ?pe prov:qualifiedInvolvement [ prov:qualifiedEntity ?entity ] ==> ?pe prov:involved ?entity . # For the subproperties of qualifiedInvolvement: ?pe prov:qualifiedUsage [ prov:qualifiedEntity ?entity ] ==> ?pe prov:used ?entity . ?pe prov:qualifiedParticipation [ prov:qualifiedEntity ?entity ] ==> ?pe prov:hadParticipant ?entity . ?pe prov:qualifiedControl [ prov:qualifiedEntity ?entity ] ==> ?pe prov:wasControlledBy ?entity . ?pe prov:qualifiedGeneration [ prov:qualifiedEntity ?entity ] ==> ?pe prov:generated ?entity .
OWL 2 property chains:
prov:used owl:propertyChainAxiom ( prov:qualifiedUsage prov:qualifiedEntity ) . prov:used owl:propertyChainAxiom ( prov:qualifiedParticipation prov:qualifiedEntity ) . prov:used owl:propertyChainAxiom ( prov:qualifiedControl prov:qualifiedEntity ) . prov:used owl:propertyChainAxiom ( prov:qualifiedGeneration prov:qualifiedEntity ) .
Overview
The following table shows the PROV-O predicates to use to assert unqualified involvements (prov:used, prov:hadParticipant, etc), its corresponding qualified predicate, and the subclass of QualifiedInvolvement that the qualified predicate should reference. The blue QualifiedInvolvements indicate that they suit the "point to the past" convention, while the red Generation indicates that its qualification is done by "pointing to the future". The "extra" cell for prov:wasGeneratedBy indicates that a generated Entity can only be qualified via the Activity that did the qualifying. prov:wasGeneratedBy and prov:generated are inverses, and the QualifiedInvolvement qualifies prov:generated just like Usage, Participation, and Control.
- TODO: the statement that Generation is a "pointing to the future" qualification may be something of a lightening rod, especially since this is a provenance model where we only intend to describe things that have actually happened. I get what you are trying to say, but I wonder if there is not a better term we can use here?
- Perhaps "result" ?
- Generation describes a "result" of a process execution whereas Usage, Participation, and Control describe "drivers" on a process execution? Or things that "affect" a process execution?
- affect vs result? -Stephan
- prov:Usage, prov:Participation, prov:Control, and prov:Generation
- are subclasses of prov:QualifiedInvolvement .
- prov:qualifiedUsage, prov:qualifiedParticipation, prov:qualifiedControl, and prov:qualifiedGeneration
- are qualified parallels of prov:used, prov:hadParticipant, prov:wasControlledBy, and prov:generated properties, respectively.
- prov:qualifiedUsage, prov:qualifiedParticipation, prov:qualifiedControl, and prov:qualifiedGeneration
- are subproperties of prov:qualifiedInvolvement .
