Abstract

The PROV Ontology (PROV-O) expresses the PROV Data Model [PROV-DM] using the OWL2 Web Ontology Language (OWL2) [OWL2-OVERVIEW]. It provides a set of classes, properties, and restrictions that can be used to represent and interchange provenance information generated in different systems and under different contexts.
It can also be specialized to create new classes and properties to model provenance information for different applications and domains.
The PROV Document Overview describes the overall state of PROV, and should be read before other PROV documents.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

PROV Family of Documents

This document is part of the PROV family of documents, a set of documents defining various aspects that are necessary to achieve the vision of inter-operable
interchange of provenance information in heterogeneous environments such as the Web. These documents are listed below. Please consult the [PROV-OVERVIEW] for a guide to reading these documents.

W3C Members Please Review By 09 April 2013

The W3C Director seeks review and feedback from W3C Advisory Committee representatives by 09 April 2013. This will allow the Director to assess consensus and determine whether to issue this document as a W3C Recommendation.

Publication as a Proposed Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

1. Introduction

The PROV Ontology (PROV-O) defines the OWL2 Web Ontology Language encoding of the PROV Data Model [PROV-DM]. This document describes the set of classes, properties, and restrictions that constitute the PROV Ontology. This ontology specification provides the foundation to implement provenance applications in different domains that can represent, exchange, and integrate provenance information generated in different systems and under different contexts. Together with the PROV Access and Query [PROV-AQ] and PROV Data Model [PROV-DM], this document forms a framework for provenance information interchange in domain-specific Web-based applications.

PROV-O is a lightweight ontology that can be adopted in a wide range of applications.
With the exception of five axioms, PROV-O conforms to the OWL-RL profile [OWL2-PRIMER].
The PROV Ontology classes and properties are defined such that they can not only be used directly to represent provenance information,
but also can be specialized for modeling application-specific provenance details in a variety of domains.
Thus, the PROV Ontology is expected to be both directly usable in applications as well as serve as a reference model
for creating domain-specific provenance ontologies and thereby facilitates interoperable provenance modeling.
To demonstrate the use of PROV-O classes and properties, this document uses an example provenance scenario similar to the one introduced in the PROV-Primer [PROV-PRIMER].

The PROV Data Model [PROV-DM] introduces a set of concepts to represent provenance information in a variety of application domains. This document maps the PROV Data Model to PROV Ontology using the OWL2 ontology language [OWL2-OVERVIEW].

We briefly introduce some of the OWL2 modeling terms that will be used to describe the PROV Ontology.
An OWL2 instance is an individual object in a domain of discourse, for example a person named Alice or a car named KITT.
A set of individuals sharing common characteristics constitutes a class.
Person and Car are examples of classes representing the set of individual persons and cars respectively.
The OWL2 object properties are used to link individuals, classes, or create a property hierarchy.
For example, the object property "hasOwner" can be used to link car with person.
The OWL2 datatype properties are used to link individuals or classes to data values, including XML Schema datatypes [XMLSCHEMA11-2].

All other namespace prefixes are used in examples only.
In particular, IRIs starting with "http://example.com" represent some application-dependent IRI [IRI]

2. PROV-O at a glance

This section is non-normative.

PROV-O users may only need to use parts of the entire ontology, depending on their needs and according to how much detail they want to include in their provenance information. For this, the PROV-O terms (classes and properties) are grouped into three categories to provide an incremental introduction to the ontology: Starting Point terms, Expanded terms, and terms for Qualifying relationships.

Starting Point classes and properties provide the basis for the rest of the PROV Ontology and thus it is recommended that readers become comfortable with how to apply these terms before continuing to the remaining categories. These terms are used to create simple provenance descriptions that can be elaborated using terms from other categories. The classes and properties in this category are listed below and are discussed in Section 3.1.

Expanded classes and properties provide additional terms that can be used to relate classes in the Starting Point category. The terms in this category are applied in the same way as the terms in the Starting Point category. Many of the terms in this category are subclasses or subproperties of those in the Starting Point category. The classes and properties in this category are listed below and are discussed in Section 3.2.

Qualified classes and properties provide elaborated information about binary relations asserted using Starting Point and Expanded properties. The terms in this category are applied using a pattern that differs from those in the Starting Point and Expanded categories. While the relations from the previous two categories are applied as direct, binary assertions, the terms in this category are used to provide additional attributes of the binary relations. The pattern used in this category allows users to provide elaborate details that are not available using only Starting Point and Expanded terms. The classes and properties in this category are listed below and are discussed in Section 3.3.

3. The PROV-O Ontology Description

3.1 Starting Point Terms

The Starting Point category is a small set of classes and properties that can be used to create simple, initial provenance descriptions.
Three classes provide a basis for the rest of PROV-O:

An prov:Entity is a physical, digital, conceptual, or other kind of thing with some fixed aspects; entities may be real or imaginary.

An prov:Activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.

An prov:Agent is something that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent's activity.

The three primary classes relate to one another and to themselves using the properties shown in the following figure.

Activities start and end at particular points in time (described using properties
prov:startedAtTime and prov:endedAtTime, respectively)
and during their lifespan can use and generate a variety of Entities (described with
prov:used and prov:wasGeneratedBy, respectively).
For example, a blog writing activity may use a particular dataset and generate a bar chart.
By expressing usage and generation, one can construct provenance chains comprising both Activities and Entities.

In addition, we can say that an Activity prov:wasInformedBy
another Activity to provide some dependency information without explicitly providing the activities' start and end times.
A prov:wasInformedBy relation between Activities suggests that the informed Activity used an Entity that was generated by the informing
Activity, but the Entity itself is unknown or is not of interest.
So, the prov:wasInformedBy property allows the construction of provenance chains comprising only Activities.

Provenance chains comprising only Entities can be formed using the prov:wasDerivedFrom property.
A derivation is a transformation of one entity into another. For example, if the Activity that created the bar chart is not known or is not of interest,
then we can say that the bar chart prov:wasDerivedFrom the dataset.
Arbitrary RDF properties can be used to describe the fixed aspects of an Entity that are interesting within a particular application (for example,
the file size and format of the dataset, or the aspect ratio of the bar chart).

While the properties prov:used, prov:wasGeneratedBy,
prov:wasInformedBy, and prov:wasDerivedFrom can be used to construct provenance chains among
Activities and Entities, Agents may also be ascribed responsibility for any Activity or Entity within a provenance chain.
An Agent's responsibility for an Activity or Entity is described using the properties prov:wasAssociatedWith and
prov:wasAttributedTo, respectively.
Agents can also be responsible for other Agents' actions. In this case of delegation, the influencing Agent prov:actedOnBehalfOf
another Agent that also bears responsibility for the influenced Activity or Entity.

The properties rdf:type and rdfs:label are used to express prov:type
and prov:label, respectively.

Figure 1.
The three Starting Point classes and the properties that relate them.
The diagrams in this document depict Entities as yellow ovals,
Activities as blue rectangles, and Agents as orange pentagons.
The responsibility properties are shown in pink.

Example 1: The following PROV-O describes the resources involved when creating a chart about crime statistics. The example uses only Starting Point terms and serves as a basis for elaboration that will be described in subsequent sections. In the example, Derek performs an aggregation of some government crime data, grouping by national regions that are described in a separate dataset by a civil action group.

The example states that the agent :derek was associated with two
activities: :aggregationActivity and :illustrationActivity. The
activity :aggregationActivity used
the entities :crimeData (a crime statistics dataset) and :nationalRegionsList (a list of national regions), and
generated a new entity, :aggregatedByRegions that aggregates the statistics in
:crimeData according to the regions in :nationalRegionsList.
The :aggregatedByRegions entity was then used by the :illustrationActivity activity,
to generate a new entity :bar_chart that depicts the aggregated statistics.

The example also states that the activity :illustrationActivity was
informed by the activity :aggregationActivity. Indeed, the former used
the entity :aggregatedByRegions, which was generated by the latter.

Because the agent :derek was associated with the activities
:aggregationActivity and :illustrationActivity, the entities
generated by these activities, i.e., :aggregatedByRegions and :bar_chart, were also
attributed to him.

Finally, the example states that the agent :derek acted on behalf of the organization :national_newspaper_inc.

Figure 2.
A graphical illustration of the PROV-O in Example 1,
showing how the three Starting Point classes relate.
The diagrams in this document depict Entities as yellow ovals, Activities as blue rectangles,
and Agents as orange pentagons. The responsibility properties are shown in pink.

3.2 Expanded Terms

The terms introduced in this section provide additional ways to describe the provenance among Entities, Activities, and Agents.
The additional terms are illustrated in the following figure and can be separated into five different categories.

Figure 3.
The expanded terms build upon those in the Starting Points section.
The diagrams in this document depict Entities as yellow ovals, Activities as blue rectangles, and Agents as orange pentagons.
The domain of prov:atLocation (prov:Activity or prov:Entity or prov:Agent or prov:InstantaneousEvent) is not illustrated.

The first category extends the Starting Point terms with subclasses, subproperties, and a superproperty.

A prov:Collection is an Entity that provides a structure (e.g. set, list, etc.) to some constituents (which are themselves Entities).
The prov:Collection class can be used to express the provenance of the collection itself:
e.g. who maintained the collection, which members it contained as it evolved, and how it was assembled.
The prov:hadMember property is used to assert membership in a collection.

A prov:Bundle is a named set of provenance descriptions, which may itself have provenance.
The named set of provenance descriptions may be expressed as PROV-O or any other form.
The subclass of Bundle that names a set of PROV-O assertions is not provided by PROV-O, since it is more appropriate to do so using other recommendations,
standards, or technologies. In any case, a Bundle of PROV-O assertions is an abstract set of RDF triples, and adding or removing a triple creates a new distinct
Bundle of PROV-O assertions.

A prov:Plan is an entity that represents a set of actions or steps intended by one or more agents to achieve some goals.

More general and more specific properties are also provided by the expanded terms. More generally, the property
prov:wasInfluencedBy is a superproperty that relates any influenced Entity, Activity, or Agent to any other
influencing Entity, Activity, or Agent that had an effect on its characteristics.
Three subproperties of prov:wasDerivedFrom are also provided for certain kinds of derivation among Entities:
prov:wasQuotedFrom cites a potentially larger Entity (such as a book, blog, or image) from which a new Entity was created
by repeating some or all of the original,
prov:wasRevisionOf indicates that the derived Entity contains substantial content from the original Entity
(e.g., two editions of a book), and
prov:hadPrimarySource cites a preceding Entity produced by some agent with direct experience and
knowledge about the topic (such as a reading from a sensor, or a journal written during an historical event).

The second category of expanded terms relates Entities according to their levels of abstraction, where some Entities may present more specific aspects than their more general counterparts.
While prov:specializationOf links a more specific Entity to a more general one (e.g., today's BBC news home page versus BBC's news home page on any day), prov:alternateOf links Entities that present aspects of the same thing, but not necessarily the same aspects or at the same time (e.g., the serialization of a document in different formats or a backup copy of a computer file).

The third category of expanded terms allows further description of Entities. The property prov:value
provides a literal value that is a direct representation of an entity.
For example, the prov:value of a quote could be a string of the sentences stated, or the prov:value of an Entity involved in a numeric calculation could be the xsd:integer four.
The property prov:atLocation can be used to describe the prov:Location of any
Entity, Activity, Agent, or prov:InstantaneousEvent
(i.e., the starting or ending of an activity or the generation, usage, or invalidation of an entity).
The properties used to describe instances of prov:Location are outside the scope of PROV-O;
reuse of other existing vocabulary is encouraged.

The fourth category of expanded terms describes the lifetime of an Entity beyond being generated by an Activity and used by other Activities. For example, a painting could not have been displayed before it was painted, and it could not be sold after it was destroyed by fire.
Similar to how Activities have start and end times, an Entity may be bound by points in time for which it was generated or is no longer usable.
The properties prov:generatedAtTime and prov:invalidatedAtTime can be used to bound the starting and ending moments of an Entity's existence. The Activities that led to the generation or invalidation of an Entity can be provided using prov:wasGeneratedBy and prov:wasInvalidatedBy, respectively.
prov:generated and prov:invalidated are the inverses of prov:wasGeneratedBy and prov:wasInvalidatedBy, respectively, and are defined to facilitate Activity-as-subject as well as Entity-as-subject descriptions.
For more about inverses, see the Appendix B.

The fifth category of expanded terms describes the lifetime of an Activity beyond its start and end times and predecessor Activities.
Activities may also be started or ended by Entities, which are described using the properties prov:wasStartedBy
and prov:wasEndedBy, respectively. Since Entities may start or end Activities, and Agents may be Entities,
then Agents may also start or end Activities.

The following examples illustrate the expanded terms by elaborating the crime chart example from the previous section.
After aggregating the dataset and creating the chart, Derek published a post to exhibit his work.

Agent :derek, acting again on behalf of the :national_newspaper_inc organization,
used the :postEditor tool to publish a post about his recent data analysis :aggregatedByRegions.
The blog editing tool tracked Derek's actions as PROV-O assertions and published them as a Bundle (the current file <>).
The tool recorded that :derek started and ended the publishing activity (:publicationActivity1123)
that generated the post :post9821v1. The post
included a permanent link where the content of the latest version is available
(:more-crime-happens-in-cities) in addition to a textual snapshot of the current version (using prov:value).
Derek also included additional domain-specific descriptions of the post, such as its title.

Shortly after publishing the post, Derek noticed a typographical error in his narrative.
Because the fix would be minimal, he did not record the activity that led to the new version.
Instead, he related the new version (:post9821v2) as a revision of the previous (:post9821v1).
Since both versions of the blog are forms of the long-standing blog permalink :more-crime-happens-in-cities,
the revisions are alternates of one another and each is a prov:specializationOf of :more-crime-happens-in-cities.

Figure 4.
An illustration of the PROV-O assertions in Example 2, where Derek
published two versions of a blog for the National Newspaper, Inc.
The diagrams in this document depict Entities as yellow ovals, Activities as blue rectangles,
and Agents as orange pentagons. The responsibility properties are shown in pink.

Shortly after Derek published his blog post, Monica adapted the text for a wider audience in a new post (:post9822).
This rewrite is an alternate, abbreviated view of the same topic that Derek wrote about and was created from his original text.
Since the provenance produced by the activities of Derek and Monica corresponded to different user views, the system
automatically published it in a different prov:Bundle.
The tool also asserted provenance about the bundle that it produced (e.g., the date of creation, its creator, and the fact that it Derek's bundle was used).
Because a bundle is a kind of entity, all provenance assertions that can be made about entities can also be made about bundles.
The use of bundles enables the creation of provenance of provenance.

After some time, John wrote his own conclusions in his own post (:post19201) quoting the previous two posts.
Each quote that John makes (:quote_from_monica and :quote_from_derek) is a new entity derived from the
previous blogs and is annotated with the time that the quote was taken.
The provenance of John's blog notes that his post is the result of the quotes that he took from Derek and Monica.
The blog post is also derived from Derek's :aggregatedByRegions dataset because John inspected it and found a
concern that he discusses in his blog. All the provenance statements related to John's post are grouped in a new prov:Bundle.

Unfortunately, there was a problem in the servers where :post19201 was being stored, and all the data related to the post was lost permanently.
Thus, the system invalidated the entity automatically and notified John about the error.

3.3 Qualified Terms

The Qualified Terms category is the result of
applying the Qualification Pattern [LD-Patterns-QR] to the simple (unqualified)
relations available in the Starting Point and
Expanded categories.
The terms in this category are for users who wish to provide further details about the provenance-related influence among
Entities, Activities, and Agents.

The Qualification Pattern restates an unqualified influence
relation by using an intermediate class that represents the influence between two resources.
This new instance, in turn, can be annotated with additional descriptions of the influence that one resource had upon another.
The following two tables list the influence relations that can be qualified using the Qualification Pattern, along with the properties used to qualify them.
For example, the second row of the first table indicates that to elaborate how an prov:Activityprov:used a particular prov:Entity, one creates an instance of prov:Usage
that indicates the influencing entity with the prov:entity property.
Meanwhile, the influenced prov:Activity indicates the prov:Usage with the property
prov:qualifiedUsage.
The resulting structure that qualifies the an Activity's usage of an Entity is illustrated in Figure 4a below.

Seven Starting Point relations can be further described using the Qualification Pattern.
They are listed in the following normative table.

The qualification classes and properties shown in the previous two tables can also be found in the normative cross reference
in the next section of this document.
All influence classes (e.g. prov:Association, prov:Usage) are extensions of
prov:Influence and either
prov:EntityInfluence,
prov:ActivityInfluence, or
prov:AgentInfluence, which determine the property used to cite the influencing resource (either
prov:entity,
prov:activity, or
prov:agent, respectively).
Because prov:Influence is a broad relation, its most specific subclasses (e.g. prov:Communication,
prov:Delegation, prov:End, prov:Revision, etc.) should be used when applicable.

The asserter can thus attach additional properties to :e1Gen to describe the generation of :e1 by :a1.

As can be seen in this example, qualifying an influence relation provides a second form (e.g. :e1 prov:qualifiedGeneration :e1Gen) to express an equivalent influence relation
(e.g. :e1 prov:wasGeneratedBy :a1).
It is correct and acceptable for an implementer to use either qualified or unqualified forms as they choose (or both),
and a consuming application should be prepared to recognize either form.
Consuming applications should recognize both qualified and unqualified forms, and treat the qualified form as implying the unqualified form.
Because the qualification form is more verbose, the unqualified form should be favored in cases where additional properties are not provided.
When the qualified form is expressed, including the equivalent unqualified form can facilitate PROV-O consumption, and is thus encouraged.

In subfigure a the prov:qualifiedUsage property parallels the prov:used property and references an instance of
prov:Usage, which in turn provides attributes of the prov:used relation between the Activity and Entity.
The prov:entity property is used to cite the Entity that was used by the Activity.
In this case, the time that the Activity used the Entity is provided using the prov:atTime property and a literal
xsd:dateTime value. The prov:atTime property can be used to describe any
prov:InstantaneousEvent (including
prov:Start,
prov:Generation,
prov:Usage,
prov:Invalidation, and
prov:End).

Similarly in subfigure j, the prov:qualifiedAssociation property parallels the
prov:wasAssociatedWith property and references an instance of
prov:Association, which in turn provides attributes of the
prov:wasAssociatedWith relation between the Activity and Agent. The
prov:agent property is used to cite the Agent that influenced the Activity.
In this case, the plan of actions and steps that the Agent used to achieve its goals is provided using the
prov:hadPlan property and an instance of prov:Plan. Further, the
prov:hadRole property and prov:Role
class can be used to describe the function that the agent served with respect to the Activity.
Both prov:Plan and prov:Role are left to be extended by applications.

Figure 4:
Illustration of the properties and classes to use (in blue)
to qualify the
starting point and
expanded influence relations (dotted black).
The diagrams in this document depict Entities as ovals, Activities as rectangles, and Agents as pentagons.
Quotation, Revision, and PrimarySource
are omitted because they are special forms of Derivation and follow the same pattern as subfigure g.

The following two examples show the result of applying the Usage and Association patterns to the chart-making example from Section 3.1.

The prov:qualifiedUsage property parallels the prov:used property to provide an additional description to :illustrationActivity. The instance of prov:Usage cites the data used (:aggregatedByRegions) and the time the activity used it (2011-07-14T03:03:03Z).

The prov:qualifiedAssociation property parallels the
prov:wasAssociatedWith property to provide an additional description about the :illustrationActivity that Derek influenced.
The instance of prov:Association cites the influencing agent (:derek) that followed the instructions (:tutorial_blog).
Further, Derek served the role of :illustrationist during the activity.

The prov:qualifiedGeneration property parallels the prov:wasGeneratedBy property to provide an additional description to :bar_chart. The instance of prov:Generation cites the time (2011-07-14T15:52:14Z) that the activity (:illustrationActivity) generated the chart (:bar_chart).

The prov:qualifiedDerivation property parallels the prov:wasDerivedFrom
property to provide an additional description to :bar_chart. The instance of prov:Derivation
cites the activity (:illustrationActivity) and the Usages and Generations that the activity conduced to create the :bar_chart.

Each PROV-O term in this cross reference links to the corresponding PROV-DM concept. The PROV-DM's table
Cross-References to PROV-O and PROV-N
provides an overview of the correspondences between PROV-O and PROV-DM.

The qualification classes and properties shown in Table 2 and
Table 3 of the previous section can also be found in each entry of this cross reference.
If the property can be qualified, the can be qualified with
header indicates the qualifying property and influence class that should be used.
Conversely, the qualifies headers in the listings for qualification terms indicate the unqualified property that they qualify.
In the OWL file itself, the annotation properties prov:qualifiedForm and prov:unqualifiedForm
provide the same linkages between the unqualified properties and their qualifiying terms.

Most examples shown in this cross reference are encoded using the Turtle RDF serialization.
When it is convenient to do so (e.g., when an example describes a prov:Bundle), it may use the [TRIG] syntax.
Although this document does not specify how to encode Bundles in RDF, TriG's named graph construct is used only to illustrate the concept of
creating a named set of PROV assertions. Note that all examples are non-normative.

4.1 Starting Point Terms

The classes and properties that provide a basis for all other PROV-O terms are discussed in Section 3.1.

Start is when an activity is deemed to have been started by an entity, known as trigger. The activity did not exist before its start. Any usage, generation, or invalidation involving an activity follows the activity's start. A start may refer to a trigger entity that set off the activity, or to an activity, known as starter, that generated the trigger.

End is when an activity is deemed to have been ended by an entity, known as trigger. The activity no longer exists after its end. Any usage, generation, or invalidation involving an activity precedes the activity's end. An end may refer to a trigger entity that terminated the activity, or to an activity, known as ender that generated the trigger.

An activity association is an assignment of responsibility to an agent for an activity, indicating that the agent had a role in the activity. It further allows for a plan to be specified, which is the plan intended by the agent to achieve some goals in the context of this activity.

Delegation is the assignment of authority and responsibility to an agent (by itself or by another agent) to carry out a specific activity as a delegate or representative, while the agent it acts on behalf of retains some responsibility for the outcome of the delegated work.
For example, a student acted on behalf of his supervisor, who acted on behalf of the department chair, who acted on behalf of the university; all those agents are responsible in some way for the activity that took place but we do not say explicitly who bears responsibility and to what degree.

A location can be an identifiable geographic place (ISO 19112), but it can also be a non-geographic place such as a directory, row, or column. As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, and so forth.

An entity that is a specialization of another shares all aspects of the latter, and additionally presents more specific aspects of the same thing as the latter. In particular, the lifetime of the entity being specialized contains that of any specialization. Examples of aspects include a time period, an abstraction, and a context associated with the entity.

A primary source for a topic refers to something produced by some agent with direct experience and knowledge about the topic, at the time of the topic's study, without benefit from hindsight.
Because of the directness of primary sources, they 'speak for themselves' in ways that cannot be captured through the filter of secondary sources. As such, it is important for secondary sources to reference those primary sources from which they were derived, so that their reliability can be investigated.
A primary source relation is a particular case of derivation of secondary materials from their primary sources. It is recognized that the determination of primary sources can be up to interpretation, and should be done according to conventions accepted within the application's domain.

A quotation is the repeat of (some or all of) an entity, such as text or image, by someone who may or may not be its original author. Quotation is a particular case of derivation.

Example

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix : <http://example.com/> .
:bl-dagstuhl
a prov:Entity;
prov:value """During the workshop, it became clear to me that the consensus
based models (which are often graphical in nature) can not only be
formalized but also be directly connected to these database focused
formalizations. I just needed to get over the differences in syntax.
This could imply that we could have nice way to trace provenance across
systems and through databases and be able to understand the
mathematical properties of this interconnection.""";
prov:wasQuotedFrom <http://purl.org/twc/page/thoughts-from-the-dagstuhl-workshop>;
.
<http://purl.org/twc/page/thoughts-from-the-dagstuhl-workshop>
a prov:Entity;
.

An entity is derived from an original entity by copying, or 'quoting', some or all of it.

A revision is a derivation for which the resulting entity is a revised version of some original. The implication here is that the resulting entity contains substantial content from the original. Revision is a particular case of derivation.

Invalidation is the start of the destruction, cessation, or expiry of an existing entity by an activity. The entity is no longer available for use (or further invalidation) after invalidation. Any generation or usage of an entity precedes its invalidation.

Invalidation is the start of the destruction, cessation, or expiry of an existing entity by an activity. The entity is no longer available for use (or further invalidation) after invalidation. Any generation or usage of an entity precedes its invalidation.

Start is when an activity is deemed to have been started by an entity, known as trigger. The activity did not exist before its start. Any usage, generation, or invalidation involving an activity follows the activity's start. A start may refer to a trigger entity that set off the activity, or to an activity, known as starter, that generated the trigger.

End is when an activity is deemed to have been ended by an entity, known as trigger. The activity no longer exists after its end. Any usage, generation, or invalidation involving an activity precedes the activity's end. An end may refer to a trigger entity that terminated the activity, or to an activity, known as ender that generated the trigger.

Invalidation is the start of the destruction, cessation, or expiry of an existing entity by an activity. The entity is no longer available for use (or further invalidation) after invalidation. Any generation or usage of an entity precedes its invalidation.

Influence is the capacity of an entity, activity, or agent to have an effect on the character, development, or behavior of another by means of usage, start, end, generation, invalidation, communication, derivation, attribution, association, or delegation.

A location can be an identifiable geographic place (ISO 19112), but it can also be a non-geographic place such as a directory, row, or column. As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, and so forth.

Influence is the capacity of an entity, activity, or agent to have an effect on the character, development, or behavior of another by means of usage, start, end, generation, invalidation, communication, derivation, attribution, association, or delegation.

Example

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix my: <http://example.com/ontology#> .
@prefix : <http://example.com/> .
# Although a domain extension (e.g. ':wasConductedBy') is not defined by PROV-O,
# the relation between a surgery and an agent can still be qualified
# by reusing prov:Influence and one of its three subclasses
# (depending on the type of influencer):
# AgentInfluence, EntityInfluence, and ActivityInfluence.
my:wasConductedBy rdfs:subPropertyOf prov:wasAssociatedWith .
:conductingSurgery_1
a prov:Activity;
# This unqualified influence is unknown in PROV,
# but would be a subproperty of wasAssociatedWith.
my:wasConductedBy :bob;
# Even though PROV systems do not understand my:wasConductedBy,
prov:qualifiedAssociation [
# they can recognize that the unknown relation
# is being qualified with a prov:hadRole.
a prov:Association,
prov:AgentInfluence, # Inferred
prov:Influence; # Inferred
prov:agent :bob; # The object of my:wasConductedBy
prov:hadRole my:surgeon;
];
.
:bob a prov:Agent .
my:surgeon a prov:Role .

Because prov:Influence is a broad relation, its most specific subclasses (e.g. prov:Communication, prov:Delegation, prov:End, prov:Revision, etc.) should be used when applicable.

An instance of prov:Influence provides additional descriptions about the binary prov:wasInfluencedBy relation from some influenced Activity, Entity, or Agent to the influencing Activity, Entity, or Agent. For example, :stomach_ache prov:wasInfluencedBy :spoon; prov:qualifiedInfluence [ a prov:Influence; prov:entity :spoon; :foo :bar ] . Because prov:Influence is a broad relation, the more specific relations (Communication, Delegation, End, etc.) should be used when applicable.

EntityInfluence provides additional descriptions of an Entity's binary influence upon any other kind of resource. Instances of EntityInfluence use the prov:entity property to cite the influencing Entity.

It is not recommended that the type EntityInfluence be asserted without also asserting one of its more specific subclasses.

An instance of prov:Usage provides additional descriptions about the binary prov:used relation from some prov:Activity to an prov:Entity that it used. For example, :keynote prov:used :podium; prov:qualifiedUsage [ a prov:Usage; prov:entity :podium; :foo :bar ].

Start is when an activity is deemed to have been started by an entity, known as trigger. The activity did not exist before its start. Any usage, generation, or invalidation involving an activity follows the activity's start. A start may refer to a trigger entity that set off the activity, or to an activity, known as starter, that generated the trigger.

An instance of prov:Start provides additional descriptions about the binary prov:wasStartedBy relation from some started prov:Activity to an prov:Entity that started it. For example, :foot_race prov:wasStartedBy :bang; prov:qualifiedStart [ a prov:Start; prov:entity :bang; :foo :bar; prov:atTime '2012-03-09T08:05:08-05:00'^^xsd:dateTime ] .

End is when an activity is deemed to have been ended by an entity, known as trigger. The activity no longer exists after its end. Any usage, generation, or invalidation involving an activity precedes the activity's end. An end may refer to a trigger entity that terminated the activity, or to an activity, known as ender that generated the trigger.

A derivation is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-existing entity.

Example

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix : <http://example.com/> .
# The simplest (and least detailed) form of derivation.
:bar_chart
a prov:Entity;
prov:wasDerivedFrom :aggregatedByRegions;
.
# The simple form can be accompanied by a qualified form:
# which provides more details about how :bar_chart was
# derived from :aggregatedRegions.
:bar_chart
a prov:Entity;
prov:wasDerivedFrom :aggregatedByRegions;
prov:qualifiedDerivation [
a prov:Derivation;
prov:entity :aggregatedByRegions;
# Derivations can cite the influencing Activity in doing the derivation.
prov:hadActivity :create_the_chart;
# They can also cite the Usage and Generation that the Activity
# performed to generate :bar_chart.
prov:hadUsage :data_loading;
prov:hadGeneration :plot_the_chart;
];
.
### The process during which the chart was created, from loading the data to the software, to process the data and plot the chart.
### Additional metadata was recorded, like when it started (before the usage), ended (after the generation of the chart) and who was associated with it.
:create_the_chart
a prov:Activity;
prov:wasAssociatedWith :derek;
prov:startedAtTime "2012-04-03T00:00:00Z"^^xsd:dateTime;
prov:endedAtTime "2012-04-03T00:00:10Z"^^xsd:dateTime;
.
### The final chart was plotted
:plot_the_chart
a prov:Generation, prov:InstantaneousEvent;
prov:atTime "2012-04-03T00:00:01Z"^^xsd:dateTime;
.
### The data was getting used to create the chart
:data_loading
a prov:Usage;
prov:atTime "2012-04-03T00:00:00Z"^^xsd:dateTime;
.

The more specific forms of prov:Derivation (i.e., prov:Revision, prov:Quotation, prov:PrimarySource) should be asserted if they apply.

An instance of prov:Derivation provides additional descriptions about the binary prov:wasDerivedFrom relation from some derived prov:Entity to another prov:Entity from which it was derived. For example, :chewed_bubble_gum prov:wasDerivedFrom :unwrapped_bubble_gum; prov:qualifiedDerivation [ a prov:Derivation; prov:entity :unwrapped_bubble_gum; :foo :bar ].

A primary source for a topic refers to something produced by some agent with direct experience and knowledge about the topic, at the time of the topic's study, without benefit from hindsight.
Because of the directness of primary sources, they 'speak for themselves' in ways that cannot be captured through the filter of secondary sources. As such, it is important for secondary sources to reference those primary sources from which they were derived, so that their reliability can be investigated.
A primary source relation is a particular case of derivation of secondary materials from their primary sources. It is recognized that the determination of primary sources can be up to interpretation, and should be done according to conventions accepted within the application's domain.

A revision is a derivation for which the resulting entity is a revised version of some original. The implication here is that the resulting entity contains substantial content from the original. Revision is a particular case of derivation.

It is not recommended that the type ActivityInfluence be asserted without also asserting one of its more specific subclasses.

ActivityInfluence provides additional descriptions of an Activity's binary influence upon any other kind of resource. Instances of ActivityInfluence use the prov:activity property to cite the influencing Activity.

Invalidation is the start of the destruction, cessation, or expiry of an existing entity by an activity. The entity is no longer available for use (or further invalidation) after invalidation. Any generation or usage of an entity precedes its invalidation.

Attribution is the ascribing of an entity to an agent.
When an entity e is attributed to agent ag, entity e was generated by some unspecified activity that in turn was associated to agent ag. Thus, this relation is useful when the activity is not known, or irrelevant.

An instance of prov:Attribution provides additional descriptions about the binary prov:wasAttributedTo relation from an prov:Entity to some prov:Agent that had some responsible for it. For example, :cake prov:wasAttributedTo :baker; prov:qualifiedAttribution [ a prov:Attribution; prov:entity :baker; :foo :bar ].

An activity association is an assignment of responsibility to an agent for an activity, indicating that the agent had a role in the activity. It further allows for a plan to be specified, which is the plan intended by the agent to achieve some goals in the context of this activity.

An instance of prov:Association provides additional descriptions about the binary prov:wasAssociatedWith relation from an prov:Activity to some prov:Agent that had some responsiblity for it. For example, :baking prov:wasAssociatedWith :baker; prov:qualifiedAssociation [ a prov:Association; prov:agent :baker; :foo :bar ].

There exist no prescriptive requirement on the nature of plans, their representation, the actions or steps they consist of, or their intended goals. Since plans may evolve over time, it may become necessary to track their provenance, so plans themselves are entities. Representing the plan explicitly in the provenance can be useful for various tasks: for example, to validate the execution as represented in the provenance record, to manage expectation failures, or to provide explanations.

Delegation is the assignment of authority and responsibility to an agent (by itself or by another agent) to carry out a specific activity as a delegate or representative, while the agent it acts on behalf of retains some responsibility for the outcome of the delegated work.
For example, a student acted on behalf of his supervisor, who acted on behalf of the department chair, who acted on behalf of the university; all those agents are responsible in some way for the activity that took place but we do not say explicitly who bears responsibility and to what degree.

The PROV data model is implicitly based on a notion of instantaneous events (or just events), that mark transitions in the world. Events include generation, usage, or invalidation of entities, as well as starting or ending of activities. This notion of event is not first-class in the data model, but it is useful for explaining its other concepts and its semantics.

An instantaneous event, or event for short, happens in the world and marks a change in the world, in its activities and in its entities. The term 'event' is commonly used in process algebra with a similar meaning. Events represent communications or interactions; they are assumed to be atomic and instantaneous.

Influence is the capacity of an entity, activity, or agent to have an effect on the character, development, or behavior of another by means of usage, start, end, generation, invalidation, communication, derivation, attribution, association, or delegation.

Influence is the capacity of an entity, activity, or agent to have an effect on the character, development, or behavior of another by means of usage, start, end, generation, invalidation, communication, derivation, attribution, association, or delegation.

Example

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix my: <http://example.com/ontology#> .
@prefix : <http://example.com/> .
# Although domain extension 'my:wasConductedBy' is not defined by PROV-O,
# the relation between a surgery and an agent can still be qualified
# by reusing prov:Influence and one of its three subclasses:
# AgentInfluence, EntityInfluence, and ActivityInfluence
# (depending on the type of the influencing object).
:conductingSurgery_1
a prov:Activity;
# This unqualified influence is unknown in PROV;
# it would be a subproperty of prov:wasAssociatedWith.
my:wasConductedBy :bob;
prov:wasInfluencedBy :bob;
prov:qualifiedInfluence [
# Even though PROV systems do not understand my:wasConductedBy,
# they will at least understand that :bob influenced the
# surgery in some way.
a prov:Influence; # Inferred
prov:agent :bob; # The object of my:wasConductedBy
# Domain extension properties may be used to describe the
# influences that an Entity, Activity, or Agent
# have upon another Entity, Activity, or Agent.
my:degree .72;
];
.
:bob a prov:Agent .

Because prov:qualifiedInfluence is a broad relation, the more specific relations (qualifiedCommunication, qualifiedDelegation, qualifiedEnd, etc.) should be used when applicable.

A primary source for a topic refers to something produced by some agent with direct experience and knowledge about the topic, at the time of the topic's study, without benefit from hindsight.
Because of the directness of primary sources, they 'speak for themselves' in ways that cannot be captured through the filter of secondary sources. As such, it is important for secondary sources to reference those primary sources from which they were derived, so that their reliability can be investigated.
A primary source relation is a particular case of derivation of secondary materials from their primary sources. It is recognized that the determination of primary sources can be up to interpretation, and should be done according to conventions accepted within the application's domain.

A quotation is the repeat of (some or all of) an entity, such as text or image, by someone who may or may not be its original author. Quotation is a particular case of derivation.

Example

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix my: <http://example.com/vocab/my#> .
@prefix : <http://example.com/> .
:bl-dagstuhl
a prov:Entity;
prov:value """During the workshop, it became clear to me that the consensus
based models (which are often graphical in nature) can not only be
formalized but also be directly connected to these database focused
formalizations. I just needed to get over the differences in syntax.
This could imply that we could have nice way to trace provenance across
systems and through databases and be able to understand the
mathematical properties of this interconnection.""";
prov:wasQuotedFrom <http://purl.org/twc/page/thoughts-from-the-dagstuhl-workshop>;
prov:qualifiedQuotation [
a prov:Quotation;
prov:entity <http://purl.org/twc/page/thoughts-from-the-dagstuhl-workshop>;
my:fromSection 1;
];
.
<http://purl.org/twc/page/thoughts-from-the-dagstuhl-workshop>
a prov:Entity;
prov:wasAttributedTo <http://data.semanticweb.org/person/paul-groth>;
.
<http://data.semanticweb.org/person/luc-moreau> a prov:Person, prov:Agent .
<http://data.semanticweb.org/person/paul-groth> a prov:Person, prov:Agent .

If this Entity prov:wasQuotedFrom Entity :e, then it can qualify how using prov:qualifiedQuotation [ a prov:Quotation; prov:entity :e; :foo :bar ].

A revision is a derivation for which the resulting entity is a revised version of some original. The implication here is that the resulting entity contains substantial content from the original. Revision is a particular case of derivation.

Attribution is the ascribing of an entity to an agent.
When an entity e is attributed to agent ag, entity e was generated by some unspecified activity that in turn was associated to agent ag. Thus, this relation is useful when the activity is not known, or irrelevant.

Example

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix ex: <http://example.com/vocab#> .
@prefix : <http://example.com/> .
## When the role of the agent is not known or does not matter:
:nationalRegionsList
a prov:Entity;
prov:wasAttributedTo :civil_action_group;
.
:civil_action_group a prov:Agent .
## If we want to express the role of the agent:
:nationalRegionsList
a prov:Entity;
prov:qualifiedAttribution [
a prov:Attribution;
prov:agent :civil_action_group;
ex:hadRole :owner;
]
.

If this Entity prov:wasAttributedTo Agent :ag, then it can qualify how it was influenced using prov:qualifiedAttribution [ a prov:Attribution; prov:agent :ag; :foo :bar ].

Invalidation is the start of the destruction, cessation, or expiry of an existing entity by an activity. The entity is no longer available for use (or further invalidation) after invalidation. Any generation or usage of an entity precedes its invalidation.

Start is when an activity is deemed to have been started by an entity, known as trigger. The activity did not exist before its start. Any usage, generation, or invalidation involving an activity follows the activity's start. A start may refer to a trigger entity that set off the activity, or to an activity, known as starter, that generated the trigger.

An activity association is an assignment of responsibility to an agent for an activity, indicating that the agent had a role in the activity. It further allows for a plan to be specified, which is the plan intended by the agent to achieve some goals in the context of this activity.

End is when an activity is deemed to have been ended by an entity, known as trigger. The activity no longer exists after its end. Any usage, generation, or invalidation involving an activity precedes the activity's end. An end may refer to a trigger entity that terminated the activity, or to an activity, known as ender that generated the trigger.

Delegation is the assignment of authority and responsibility to an agent (by itself or by another agent) to carry out a specific activity as a delegate or representative, while the agent it acts on behalf of retains some responsibility for the outcome of the delegated work.
For example, a student acted on behalf of his supervisor, who acted on behalf of the department chair, who acted on behalf of the university; all those agents are responsible in some way for the activity that took place but we do not say explicitly who bears responsibility and to what degree.

This property is used as part of the qualified influence pattern. Subclasses of prov:Influence use these subproperties to reference the resource (Entity, Agent, or Activity) whose influence is being qualified.

Subproperties of prov:influencer are used to cite the object of an unqualified PROV-O triple whose predicate is a subproperty of prov:wasInfluencedBy (e.g. prov:used, prov:wasGeneratedBy). prov:influencer is used much like rdf:object is used.

The prov:entity property references an prov:Entity which influenced a resource. This property applies to an prov:EntityInfluence, which is given by a subproperty of prov:qualifiedInfluence from the influenced prov:Entity, prov:Activity or prov:Agent.

The prov:activity property references an prov:Activity which influenced a resource. This property applies to an prov:ActivityInfluence, which is given by a subproperty of prov:qualifiedInfluence from the influenced prov:Entity, prov:Activity or prov:Agent.

The prov:agent property references an prov:Agent which influenced a resource. This property applies to an prov:AgentInfluence, which is given by a subproperty of prov:qualifiedInfluence from the influenced prov:Entity, prov:Activity or prov:Agent.

The PROV data model is implicitly based on a notion of instantaneous events (or just events), that mark transitions in the world. Events include generation, usage, or invalidation of entities, as well as starting or ending of activities. This notion of event is not first-class in the data model, but it is useful for explaining its other concepts and its semantics.

The _optional_ Role that an Entity assumed in the context of an Activity. For example, :baking prov:used :spoon; prov:qualified [ a prov:Usage; prov:entity :spoon; prov:hadRole roles:mixing_implement ].

A. PROV-O OWL Profile

This section is non-normative.

To encourage widespread adoption, PROV-O's design is intentionally minimal and lightweight.
Because the OWL 2 RL profile is aimed at RDF applications that require scalable reasoning without sacrificing too much expressive power [OWL2-PRIMER],
it served as a baseline for all axioms included in PROV-O. The PROV-O axioms that do not suit the OWL 2 RL profile are listed in
Table 5.
All five use an anonymous class union for the domain or range of a property, while OWL 2 RL requires the classes to be explicitly named.
Although introducing "placeholder" classes would have suited the
OWL 2 RL profile, these additional "abstract" classes would have been irrelevant
to the modeling of provenance information, increased the size of PROV-O unnecessarily, and exposed a potential to confuse users.
All five axioms listed in the following table use a non-superclass expression in a position that requires a superclass expression
and do not conform to the OWL 2 RL Profile.

Table 5: All OWL Axioms in PROV-O that do not conform to the OWL-RL profile.

To provide guidance for OWL 2 RL environments that ignore the union domain axioms, some
property domains or ranges have also been defined with the closest
common superclass for the classes in the union, as shown in the following table.

Multiple RDFS domains and ranges [RDF-SCHEMA] for a property are
interpreted as an intersection,
and thus the above do not provide any additional
information in an OWL 2 DL or OWL 2 Full profile, which also understands
the unions. The more general domain should not be
interpreted as saying, e.g.,
"prov:hadActivity can be used with any prov:Influence",
but as
"Anything using prov:hadActivity is (at least) a prov:Influence".

B. Names of inverse properties

To maximize interoperability, PROV-O intentionally avoids defining too many properties' inverses.
In fact, it only defines two (prov:generated and prov:invalidated).
When all inverses are defined for all properties, modelers may choose from two logically equivalent properties when making each assertion.
Although the two options may be logically equivalent, developers consuming the assertions may need to exert extra effort to handle both
(e.g., by either adding an OWL reasoner or writing code and queries to handle both cases).
This extra effort can be reduced by preferring one inverse over another.

For example, the first PROV-O statement (below) could just as easily be asserted as the second statement.
But if a client queries using prov:wasDerivedFrom when :hadDerivation
was used in the assertion, no results will be returned unless OWL reasoning is applied (or the size of the query is doubled).

<http://www.w3.org/TR/prov-o/> prov:wasDerivedFrom <http://www.w3.org/TR/prov-dm/> .
# These two statements are equivalent if prov:wasDerivedFrom is an inverse of :hadDerivation.
# But extra effort is required to handle both cases (if one is not already using OWL reasoning).
# We cannot assume that everybody is using OWL reasoning.
# We do not want people to write more code and query than necessary.
<http://www.w3.org/TR/prov-dm/> :hadDerivation <http://www.w3.org/TR/prov-o/> .

So, PROV-O avoids this situation by encouraging modelers to use one property instead of its inverse; the preferred property to use is the one defined in the PROV-O ontology. Those asserting and querying for the preferred property avoid the need for OWL reasoning, additional code, and larger queries while maintaining the same level of interoperability.

However, the absence of defined inverses can lead to a different risk to interoperability.
Because modelers are free to create their own properties to suit their needs,
they may be motivated to assert the inverse of any PROV-O property defined herein.

For example, since PROV-O does not define the inverse of prov:wasDerivedFrom,
and if three developers would rather model their assertions in the opposite direction, the following set of assertions might be found in the future web of provenance.
These assertions are not in an interoperable form without the use of an OWL reasoner, additional code, or larger queries.

# If PROV-O's properties' inverses are not defined, modelers may be motivated to introduce their own inverse property name.
# The following three statements are equivalent if their predicates are all inverses of prov:wasDerivedFrom.
<http://www.w3.org/TR/prov-dm/> my:hadDerivation <http://www.w3.org/TR/prov-o/> .
<http://www.w3.org/TR/prov-dm/> your:ledTo <http://www.w3.org/TR/prov-o/> .
<http://www.w3.org/TR/prov-dm/> their:derivedTo <http://www.w3.org/TR/prov-o/> .

To balance these two interoperability risks, this document reserves the names of the PROV-O inverses.
The name of a property's inverse is determined by appending the value of its http://www.w3.org/ns/prov#inverse
annotation to the PROV namespace (http://www.w3.org/ns/prov#).
Modelers wishing to use inverses of the properties defined by PROV-O should use those reserved by this document.

For example, the same three modelers above that defined my:hadDerivation, your:ledTo, and their:derivedTo should instead look for the http://www.w3.org/ns/prov#inverse annotation on prov:wasDerivedFrom to determine that they should use the property http://www.w3.org/ns/prov#hadDerivation.

@prefix prov: <http://www.w3.org/ns/prov#> .
# Each PROV-O property is annotated with the local name of its inverse.
prov:wasDerivedFrom
a owl:ObjectProperty;
rdfs:isDefinedBy <http://www.w3.org/ns/prov#>;
prov:inverse "hadDerivation";
rdfs:domain prov:Entity;
rdfs:range prov:Entity;
.
# Instead of defining their own, modelers should use the
# recommended inverse local name within the PROV namespace:
<http://www.w3.org/TR/prov-dm/> prov:hadDerivation <http://www.w3.org/TR/prov-o/> .
# Following this recommendation avoids a proliferation of inverse definitions,
# while encouraging the use of one inverse over another.
# This increases interoperability.

The following table lists the recommended inverse names that should be used if a modeler does not want to use the recommended PROV-O property.
For convenience, this file lists the resulting inverse properties.

C. Changes since WD-prov-o-20120724

This section is non-normative.

Restated prov:hadRole's domain to 'Association or InstantaneousEvent'
instead of the original that enumerated the subclasses of InstantaneousEvent
('Association or End or Generation or Invalidation or Start or Usage').

Examples have been rewritten to avoid usage of TriG named
graph syntax except for when showing bundles in
prov:asInBundle and prov:mentionOf (since removed to a separate Note). A citation to TriG was added.

Some examples have been elaborated to use resource names
like :illustration_usage rather than
:usage_1.

Added note to Starting Point Terms stating that
rdf:type and rdfs:label are used to express PROV-DM's prov:type and prov:label.

Updated prov:value's out-of-date definition to conform to PROV-DM's (i.e., "Provides a value that is a direct representation of an entity.".

Updated prov:wasDerivedFrom's out-of-date definition to conform to PROV-DM's
(i.e., "A derivation is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-existing entity.".

Added xsd:dateType datatypes to exemplar in Invalidation and invalidatedAtTime.

Fixed some incorrect wasAttributedTo/wasAssociatedWith in the cross reference exemplars.

Changed the status of this document section: added new documents to the PROV Family of Document, and removed the how to read section, referring instead to PROV-OVERVIEW.

Changed all URLs to PROV documents.

E. Acknowledgements

This section is non-normative.

This document has been produced by the PROV Working Group, and its contents reflect extensive discussion within the Working Group as a whole. The editors extend special thanks to Sandro Hawke (W3C/MIT) and Ivan Herman (W3C/ERCIM), W3C contacts for the PROV Working Group.

The editors also thank the developers of the tools that helped create the PROV-O ontology and portions of this document. Without these great tools, developing PROV-O would have been much less of a pleasure.