PROV OWL ontology component examples

From Provenance WG Wiki
Revision as of 20:04, 20 February 2012 by Gklyne (Talk | contribs)

Jump to: navigation, search

Author: Tim Lebo

This page provides an overview of the ontology component examples available in the mercurial repository at:

For an introduction to the purpose and use of components, see PROV OWL ontology components.

For artificial examples, see Artificial PROV OWL ontology component examples.

Don't forget PROV-XG's scenarios (disease outbreak).

ComplementarityUseCases was created 2011 Dec 01 to accumulate uses cases for the highly controversial complementarity construct in PROV-DM.

Purchasing a car


Writing an article about crime

This is the example described in PROV-DM and PROV OWL

Adopting the Ordnance Survey Ontology


Adopting the Ordnance Survey Ontology - citing controller


Appending a file to itself


Adding contents to a file using parts of two files from the web

This example is discussed in Using named graphs to model Accounts


Ordering from a restaurant


Issuing a traffic ticket

This example emphasizes the "evidence gathering" activities during an event. The traffic officer is gathering information and recording it. This is also used to illustrate how human-readable identifiers are needed to associate Entities found in different sets of assertions.


Handgun sale and crime scene evidence

Shop owner creates different URIs for the same handgun than the URIs created by the crime scene investigators. Both reference the same handgun serial number. Is the gun sold the same as the gun found?

Performing an owl:imports closure

  1. prov.ttl cites other RDF files that should be aggregated to produce a full OWL ontology (using owl:imports). prov.owl.prov.ttl cites the URLs of files that were included in the result, prov.owl.
  2. While prov.ttl only included one file, prov-variant-1.ttl cites many. Its provenance cites the URLs of all files that were included in the result.



Discussed in Using named graphs to model Accounts.

Tim was at MIT on 2011-10-12 (was described in RDF, which was referenced in foaf)

Who is the author of a document

Paul Groth wanted to model a quote in a read web page. 2011 Oct 20 telecon

Self portrait

Stian's self-portrait example

Two Online Accounts held by the same Person

Tim has a twitter account "timrdf" and a W3C PROV wiki account of "Tlebo":


asserting the wasComplementOf between the two Entities should let me assert:

problem: prov-o doesn't let me associate an entity to what it is talking about (me). This is modeled as :x in the example.

Quoting some text in an email archived on the web

Tim quoted something Luc said in an email. The email was archived on the web.

The example is version controlled at:

The follow PROV-O components were added to support this example:

Some questions from this example:

  • Would the prov-wg accept using rdf:value for the string that is quoted?
    • PG: I think we don't say. It's not clear how you identify the quoted string. You could quote something else. [1]
    • SSR: Agreed - it's just an attribute characterizing the entity. A very good characterization in this case - but not if we were worried about formatting, coffee stains, etc. [2]
  • Would "wasQuotedFrom" be more intuitive than "wasQuoteOf"?
    • PG: Seems a reasonable change to me [3]
  • Isn't this just a special kind of derivation? Shouldn't be handled with the core constructs with appropriate roles, etc?
@prefix rdf:     <> .
@prefix owl:     <> .
@prefix rdfs:    <> .
@prefix time:    <> .
@prefix dcterms: <> .
@prefix prov:    <> .
@prefix :        <#> .

   a prov:Entity;
"""Remember that an entity is a perspective on a thing.
So, here, we can have multiple perspectives:

e1 Luc
e2 Luc at age=5
e3 Luc at age=10

e3 and e2 have a same attribute name age, but different values. So they 
must be different entities,i.e. perspectives, over human being e1.""";
   prov:wasQuoteOf <>;
   prov:qualifiedQuotation [
      a prov:Quotation;
      prov:hadQualifiedEntity <>;
      prov:hadQuoter          <>;
      prov:hadQuotee          <>;

Two ages of the same person

Concrete example at

Required addition of PROV-O component:

@prefix rdf:     <> .
@prefix owl:     <> .
@prefix rdfs:    <> .
@prefix time:    <> .
@prefix dcterms: <> .
@prefix foaf:    <> .
@prefix prov:    <> .
@prefix :        <#> .

   rdfs:seeAlso <>,
"""Remember that an entity is a perspective on a thing.
So, here, we can have multiple perspectives:

e1 Luc
e2 Luc at age=5
e3 Luc at age=10

e3 and e2 have a same attribute name age, but different values. So they 
must be different entities,i.e. perspectives, over human being e1.""";
   a prov:Entity, foaf:Person;
   foaf:firstName "Luc";

   a prov:Entity, foaf:Person;
   foaf:firstName "Luc";
   :age 5;
   rdfs:comment "e2 is a perspective on e1";
   prov:viewOf          :e1;

:e2 owl:differentFrom :e3 .

   a prov:Entity, foaf:Person;
   foaf:firstName "Luc";
   :age 10;
   rdfs:comment "e3 is a perspective on e1";
   prov:viewOf          :e1;

Building a statue example

Example by Satya, augmented by Luc [4], encoded by Tim.

Quoting a blog

Paul's example "blogpost wasDerivedFrom Report at 10am Thursday"

Quality Control supervisor

""For example, a quality control inspector "qci1" on a factory floor is "involved" in production (PE instance "prod1") of "honda civic car" by observing the prod1 PE and taking notes. But qci1 is not linked to prod1 by "used" or "wasControlledBy" or "wasComplementOf" properties, but qci1 is a participant in prod1.""

Multiple in; multiple out


   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;

  prov:generated :output;
  prov:qualifiedGeneration [
     a prov:Generation;
     prov:qualifiedEntity   :output;
     prov:hadRole         io:output;

  prov:generated :metadata;
  prov:qualifiedGeneration [
     a prov:Generation;
     prov:qualifiedEntity   :metadata;
     prov:hadRole         io:metadata;

Programmer and Researcher

Yolanda: "a programmer and a researcher could both be associated with running a workflow, but it may not matter what programmer clicked the button to start the workflow while it would matter a lot what researcher told the programmer to do so."

Student posting Department info

Yolanda: "a student publishing a web page describing an academic department could result in both the student and the department being agents associated with the activity, and it may not matter what student published a web page but it matters a lot that the department told the student to put up the web page. "

the student acted on behalf of his supervisor, who acted on behalf of the department chair, who acts on behalf of the university, and all those agents are responsible in some way for the activity to take place but we don't say explicitly who bears responsibility and to what degree. 

Mail app run by person

"So in the example of someone running a mail program, the program is an agent of that activity and the person is also an agent of the activity, but we would also add that the mail software agent is running on the person's behalf. "

LibC upgrade affecting program execution

Stian: "The C program prov:uses some text files and a connection to a web server. On a lower granularity perhaps, /lib/ (the C standard library) is prov:associatedWith with the programme. The asserter does not feel that *his* C program is *using* libc - that is merely an side-effect of the compiler and operating system. It is not an agent, it is not like a Python interpreter responsible for running a script, it is just there for those boring system calls. However the asserter wants to link this stronger than just as some custom attribute on the plan-entity for the C-program-activity."

"The reason is that a concurrent system upgrade overwrites the /lib/ file (and this is captured by provenance) , and causes the C programme to crash. "

"I did not specify any prov:SoftwareAgent up here, because agents are currently disjoint from activities, and so the active :exec can't be an agent - while the dormant entity :myProgramme can."

The MonaLisa portrait is dated to circa 1503–1519

 On 02/16/2012 05:04 PM, Luc Moreau wrote:
 >On 16/02/12 21:36, Satya Sahoo wrote:
 >>Also, I believe the DM supports representation of a simple provenance
 >>assertion such as, "The MonaLisa portrait is dated to circa 1503–1519"
 >>(MonaLisa portrait is an Entity).
 >How would you do it? I don't know.

Time is instantaneous, so you couldn't specify it as a generation time, but could you just define a domain specific attribute for the generation?

 wasGeneratedBy(ex:MonaLisa, [ex:creationEstimate="1503-1519"]);

Is it ok to leave out both activity and time in order to specify generation attributes? DM would seem to allow it since everything but entity is optional.

How would such a thing get mapped to RDF?

 ex:MonaLisa a prov:Entity .
 _:a a prov:Activity .
 _:g a prov:Generation .
 ex:MonaLisa prov:wasGeneratedBy _:a .
 _:a prov:hadQualifiedGeneration _:g .
 _:g a prov:QualifiedInvolvement .
 _:g prov:hadQualifiedEntity ex:MonaLisa .
 _:g ex:creationEstimate "1503-1519" .

Probably easier to just express this outside PROV:

 ex:MonaLisa ex:creationEstimate "1503-1519" .

GK comment: this topic (uncertain times) has been discussed in the context of CIDOC CRM, and the discussion was quite involved. I think we need to avoid getting into the rathole of creating ontologies for uncertain time intervals, but provide something to which such work can be attached. In this case, the prov:Activity provides the placeholder, and we can duck the actual problem of how to represent the uncertain time interval. I think this is what the final example above is suggesting.