Standards

W3C PROV

A family of specifications for representing provenance of entities, activities, and agents.

Kind: Data models
Steward: World Wide Web Consortium (W3C)
Official source: https://www.w3.org/TR/prov-overview/

What it describes

W3C PROV provides a common model for describing how an entity came to be, including its association with activities and agents. PROV-O expresses the model as an ontology, while related specifications define other representations and constraints. This gives independent systems a shared language for provenance relationships rather than requiring them to agree on one application-specific database design.

A provenance graph is only as complete and trustworthy as the observations recorded in it. PROV can say that an activity used a source entity, but it does not verify the source's truth or the activity's legitimacy. Keep source locators, timestamps, identity information, and retained evidence where appropriate. A missing edge may mean unknown provenance, not proof that no dependency existed.

Structure

Core concepts include entity, activity, agent, and relations such as wasGeneratedBy and used.

Useful for

Exchange lineage relationships.
Trace derived records to inputs.
Compare provenance across systems.

Limits

Does not establish truth of a source.
Incomplete graphs remain possible.
A relation needs evidence and temporal context.

How it is used in practice

PROV describes provenance with three core kinds of thing. An entity is something with fixed aspects, such as a document, a dataset or a version of a record. An activity is something that happens over time and acts on entities, such as an extraction, a review or a merge. An agent is something that bears responsibility for an activity, such as a person, an organization or a piece of software. Relations connect them: an entity was generated by an activity, an activity used an entity, one entity was derived from another, and an entity was attributed to an agent.

The family of W3C Recommendations includes a data model, an ontology that expresses it in RDF, a notation for human reading, an XML schema, constraints that say what makes a provenance description consistent, and a note on how to find and retrieve provenance. Organizations use the model to publish lineage for datasets, to record how a document was produced, and to exchange provenance between systems that otherwise have little in common.

A worked example

A fictional record states that Halden Therapeutics AG (fictional) completed an acquisition on a given date. In PROV terms, the statement is an entity, derived from a source document, which is also an entity. The reading of the document is an activity that used the document and generated the statement. The reader is an agent associated with the activity, and a time attached to the activity says when it happened.

A later correction creates a second statement, derived from the first and from a new source, generated by a new activity with its own agent and time. The first statement is not deleted. It may be marked as invalidated at a given time by the correction activity. A reviewer can then follow the chain in either direction: from the statement to its sources, or from a source to every statement that depends on it. That second direction is what makes impact analysis possible when a source is found to be wrong.

Evaluating a claim that rests on provenance

Provenance statements are claims, and the first question is who made them. A provenance graph written by the system that produced the data records what the system says it did. An independent graph, reconstructed from logs and retained copies, is stronger. The model includes a way to say that a provenance description is itself an entity with its own provenance, which supports the distinction.

The second question is completeness. A gap in a graph can mean that an input was not recorded, not that there was no input. The constraints specification gives rules for consistency, such as that an entity cannot be generated after it was used, and a validator can catch contradictions. It cannot reveal what was left out. Record explicitly where lineage stops, and why.

Confusions to avoid

PROV is a model of provenance, not a mechanism for trust. It does not sign, verify or protect a graph. Cryptographic integrity, if needed, is a separate layer. A well-formed PROV graph can be wrong, forged or incomplete.

It is also not the same as a domain schema. It says how things came to be, not what they are about. A system of record that uses PROV still needs its own vocabulary for the facts, and a rule for which PROV relations it will record for each class of fact. Finally, PROV's time properties record when something started or ended or was generated, which is not the same as the time a fact was valid in the world. Keep valid time and provenance time apart.

Questions a reviewer can ask

Who wrote the provenance statements, and are they independent of the system that produced the data? Does the graph pass the constraint checks? Where does the lineage stop, and is that declared? Are the times in the graph the times of activities, and are valid times held separately? Is the graph itself retained and dated? Can every derived statement be followed back to a retained source, and every source forward to its dependents?

Related terms

References

Found an error on this page? See corrections for what counts as one, how to report it and the dated log.

Enquiry

Which of your sources carry W3C PROV?

Tell us which sources carry it, which key the same entity some other way and who may read which. We reply with whether and how a first record would use this data model.

Open a structured enquiry Contact and what happens next

Or write to [email protected] in your own words.