Qualifed Involvements in PROV-O

From Provenance WG Wiki
Jump to: navigation, search

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).

Materials

The following materials were used to support this proposal.

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.

Dm-sketch.png

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:

Dm-sketch-used.png

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:

Dm-sketch-participation.png

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:

Dm-sketch-controlled.png

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:

Dm-sketch-generation.png

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 .

Dm-sketch-table.png