Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
Provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness. PROV-DM is the conceptual data model that forms a basis for the W3C provenance (PROV) family of specifications.
This document presents a model-theoretic semantics for the PROV data model (called the naive semantics), viewing PROV-DM statements as atomic formulas in the sense of first-order logic, and viewing the constraints and inferences specified in PROV-CONSTRAINTS as a first-order theory. It is shown that the first-order theory is sound with respect to the naive semantics. This information may be useful to researchers or users of PROV to understand the intended meaning and use of PROV for modeling information about the actual history, derivation or evolution of Web resources. It may also be useful for development of additional constraints or inferences for reasoning about PROV or integration of PROV with other Semantic Web vocabularies. It is not proposed as a canonical or required semantics of PROV and does not place any constraints on the use of PROV.
The PROV Document Overview describes the overall state of PROV, and should be read before other PROV documents.
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/.
This document was published by the Provenance Working Group as a First Public Working Draft. If you wish to make comments regarding this document, please send them to public-prov-comments@w3.org (subscribe, archives). All comments are welcome.
Publication as a First Public Working Draft 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.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Provenance is a record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or a thing. This document complements the PROV-DM specification [PROV-DM] that defines a data model for provenance on the Web, and the PROV-CONSTRAINTS specification [PROV-CONSTRAINTS] that specifies definitions, inferences, and constraints that can be used to reason about PROV documents, or determine their validity. This document provides a naive formal semantics of PROV, providing a formal counterpart to the informal descriptions and motivations given elsewhere in PROV specifications.
The PROV-DM and PROV-CONSTRAINTS give motivating examples that provide an intuition about the meaning of the constructs. For some concepts, such as use, start, end, generation/invalidation, and derivation, the meaning is either obvious or situation-dependent. However, during the development of PROV, the importance of additional concepts became evident, but the intuitive meaning or correct use of these concepts were not clear. For example, the and relations are used in PROV to relate different entities that present aspects of "the same thing". Over time the working group came to a consensus about these concepts and how they are to be used, but this understanding is based on abstract notions that are not explicit in PROV documents; instead, some of their properties are captured formally through certain constraints and inferences, while others are not captured in PROV specifications at all.
The purpose of this document is to present the working group's consensus view of the semantics of PROV, using tools from mathematical logic, principally model theory (though our use of these tools is lightweight). This information may be useful to users for understanding the intent behind certain features of PROV, to researchers investigating richer forms of reasoning over provenance, or to future efforts building upon PROV. It is intended as an exploration of one semantics for PROV, not a definitive specification of the only semantics of PROV. We intend to provide an intuitive semantics that satisfies all of the constraints on valid PROV instances, which ensures that no invalid PROV instance has a model. The current naive semantics, however, is not complete in the sense that some valid PROV instances lack models.
TODO: Revise this to reflect future improvements in the semantics.
Although it is a work in progress, the naive semantics has some appealing properties. Specifically, it provides a declarative counterpart to the operational definition of validity taken in PROV-CONSTRAINTS. In the specification, validity is defined via a normalization process followed by constraint checking on the normal form. This approach was adopted to keep the specification closer to implementations, although other implementations are possible and allowed. In addition to providing a naive semantics, this document shows that the operational presentation of PROV validity checking is sound with respect to the declarative presentation adopted here. This could help justify alternative approaches to validity checking.
This document mostly considers the semantics of PROV statements and instances. PROV documents can consist of multiple instances, and the semantics does not (as yet) cover PROV documents, but the semantics can be used on each instance in a document separately, just as PROV-CONSTRAINTS specifies that each instance in a document is to be validated separately. So, in the rest of this document, we do not discuss PROV documents. The semantics of other features of PROV, such as dictionaries [PROV-DICTIONARY] and linking across bundles [PROV-LINKS], are beyond the scope of this document.
TODO: We would like to say something stronger here, such as a completeness result for naive models, but this will take more work.
This document assumes familiarity with [PROV-DM] and [PROV-CONSTRAINTS] and employs (a simplified form of) [PROV-N] notation. In particular it assumes familiarity with the concepts from logic, and the relationship between PROV statements and instances and first-order formulas and theories, respectively, presented in Section 2.5 of PROV-CONSTRAINTS.
This document may be useful to users of PROV who have a formal background and are interested in the rationale for some of the constructs of PROV; for resaerchers investigating extensions of PROV or alternative approaches to reasoning about PROV; or for future efforts on provenance standardization.
A lowercase symbol on its own denotes an identifier. Identifiers may or may not be URIs. Identifiers are viewed as variables from the point of view of logic: they denote objects, but just because we have two different identifiers and doesn't tell us that they denote different objects, since we could discover that they are actually the same later. We write for the set of identifiers of interest in a given situation (typically, the set of identifiers present in the PROV instance of interest).
We assume a linearly ordered set of time instants. For convenience we assume the order is total or linear order, corresponding to a linear timeline; however, PROV does not assume that time is linear and events could be partially ordered and not necessarily reconciled to a single global clock.
Restricting attention to linearly-ordered times, and imposing this order on events, is a simplifying assumption; it is more restrictive than required to model the constraints. As a result, there are currently some valid PROV instances that do not have naive models. It is intended that the final version of the semantics will provide a more general class of models such that every valid instance has a model.
We also consider a set of closed intervals of the form .
We assume a set of attribute labels and a set of possible values of attributes. To allow for the fact that some attributes can have undefined or multiple values, we sometimes use the set , that is, the set of sets of values.
The following atomic formulas correspond to the statements of PROV-DM. We assume that definitions 1-4 of PROV-CONSTRAINTS have been applied in order to expand all optional parameters; thus, we use uniform notation instead of the semicolon notation .
Each parameter is either an identifier, a constant (e.g. a time or other literal value in an attribute list), or a null symbol "-". Placeholder symbols can only appear in the specified arguments in and in , as shown in the grammar below.
We include the standard PROV collection types ( and ) and the membership relation ; however, we do not model dictionaries or the insertion or deletion relations in the PROV-DICTIONARY [PROV-DICTIONARY], since these are not part of the PROV recommendations. If these features are incorporated into future standards, their semantics (and the soundness of the associated constraints) should be modeled. We omit the prefixes from the and types.
As stated in the Introduction, we do not explicitly model bundles or PROV documents; however, each instance can be viewed as a set of formulas and can be modeled separately. The semantics of the standard features of PROV can be defined without talking about multiple instances; however, the relation in PROV-LINKS [PROV-LINKS] is intended to support linking across bundles. Future editions of PROV may incoporate or other cross-instance assertions, and this semantics should be generalized in order to provide a rationale for such an extension and to establish the soundness of constaints associated with .
We also consider the usual connectives and quantifiers of first-order logic [Logic].
Things is a set of things in the situation being modeled. Each thing has a lifetime during which it exists and attributes whose values can change over time.
To model this, a structure includes:
The range of is the set , indicating that is essentially a multi-valued that returns a set of values (possibly empty). When , we say that attribute is undefined for at time .
Note that this description does not say what the structure of a is, only how it may be described in terms of its time interval and attribute values. A thing could be a record of fixed attribute values; it could be a bear; it could be the Royal Society; it could be a transcendental number like . All that matters from our point of view is that we know how to map the to its time interval and attribute mapping.
The identity of a Thing is not observable through its attributes or lifetime, so it is possible for two different to be indistinguishable by their attribute values and lifetime. That is, if the set of and the attributes are specified as for each and , this does not imply that .
are things in the world that have attributes that can change over time. may not have distinguishing features that are readily observable and permanent. In PROV, we do not talk explicitly about , but instead we talk about various objects that have discrete, fixed features, and relationships among these objects. Some objects, called , are associated with , and their fixed attributes need to match those of the associated during their common lifetime.
In this section, we detail the different subsets , and give disjointness constraints and associated functions. Generally, these constraints are necessary to validate disjointness constraints from PROV-CONSTRAINTS [PROV-CONSTRAINTS].
An Object is described by a time interval and attributes with fixed values. Objects encompass entities, activities, agents, and interactions (i.e., usage, generation, and other events or influence relations). To model this, a structure includes:
Intuitively, is the time interval during which object exists. The set is the set of values of attribute during the object's lifetime.
As with Things, the range of is sets of values, making effectively a multivalued function. It is also possible to have two different objects that are indistinguishable by their attributes and time intervals. Objects are not things, and the sets of and are disjoint; however, certain objects, namely entities, are associated with things.
Disjointness between and is not necessary but is assumed in order to avoid confusion between the different categories (time-varying vs fixed ).
An entity is a kind of object that describes a time-slice of a thing, during which some of the thing's attributes are fixed. We assume:
Although both entities and things can have undefined or multiple attribute values, their meaning is slightly different: for a thing, means that the attribute has no value at time , whereas for an entity, only means that the thing associated to entity does not have a fixed value for during the lifetime of . This does not imply that when .
Furthermore, all of the attribute values of the entity must be present in the associated thing throughout the lifetime of the entity. For example, suppose is at some time in and at some other time . Then must be because there is no other set of values that is simultaneously contained in both and .
In the above description of how relate to , we require whenever . Intuitively, this means that if we are talking about a indirectly by describing an , then any attributes we ascribe to the must also describe the associated during their common lifetime. Attributes of both and are multi-valued, so there is no inconsistency in saying that an entity has two different values for some attribute. In some situations, further uniqueness constraints or range constraints could be imposed on attributes, for example by extending the PROV-O ontology.
Only are associated with , and this is necessary to provide an interpretation for the and relations. It might also make sense to associate , , and with , or with some other structures; however, this is not necessary to model any of the current features of PROV, so in the interest of simplicity we do not do this.
We identify a specific subset of the entities called plans:
A set of plans.
An activity is an object that encompasses a set of events. We introduce
An agent is an object that can act, by controlling, starting, ending, or participating in activities. An 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. Agents can act on behalf of other agents. An agent may be a particular type of entity or activity; an agent cannot be both entity and activity because the sets of entities and activities are disjoint. We introduce:
A set of agents.
There is no requirement that every agent is either an activity or an entity.
We consider a set which are split into Events connecting entities and activities, Associations between agents and activities, Communications between pairs of activities, Delegations between pairs of agents, and Derivations that describe chains of generation and usage steps. These kinds of interactions are discussed further below. Interactions are disjoint from entities, activities and agents.
An Event is an interaction whose lifetime is a single time instant, and relates an activity to an entity (which could be an agent). Events have types including usage, generation, invalidation, starting and ending. Events are instantaneous. We introduce:
An Association is an interaction relating an agent to an activity. To model associations, we introduce:
A set , such that if and only if .
Associations are used below in the and relations.
A Derivation is an interaction chaining one or more generation and use steps.
A set , such that if and only if .
See below for the associated derivation path and DerivedFrom relation.
A derivation path implies the existence of at least one chained generation and use step. However, not all such potential derivation paths are associated with derivations; there can (and in general will) be many such paths that are not associated with derivation steps. In other words, because we require derivations to be explicitly assocated with derivation paths, it is not sound to infer the existence of a derivation from the existence of an alternating generation/use chain.
The entities, interactions, and activities in a structure are related in the following ways:
Recall that above we introduced a subset of interactions called Derivations. These identify paths of the form
where the are entities, are activities, are generations, and are usages.
Formally, we consider the (regular) language:
with the constraints that for each derivation path:
Each derivation has an associated derivation path. We link each derivation to an associated derivation path using the function .
The function links each to a derivation path. A derivation has exactly one associated derivation path. However, if the PROV-N statement wasDerivedFrom(e_2,e_1,-,-,-) is asserted in an instance, there may be multiple derivation paths linking to , each corresponding to a different, identified by different derivations .
A structure is a structure containing all of the above described data. If we need to talk about the objects or relations of more than one structure then we may write , , etc.; otherwise, to decrease notational clutter, when we consider a fixed structure then the names of the sets, relations and functions above refer to the components of that model.
We need to link identifiers to the objects they denote. We do this using a function which we shall call an interpretation. Thus, we consider interpretations as follows: An interpretation is a function describing which object is the target of each identifier. The mapping from identifiers to objects may not change over time.
In what follows, let be a fixed structure with the associated sets and relations discussed in the previous section, and let be an interpretation of identifiers as objects in . The annotations [WF] refer to well-formedness constraints that correspond to typing constraints.
Consider a formula , a structure and an interpretation . We define notation which means that is satisfied in . For atomic formulas, the definition of the satisfaction relation is given in the next few subsections. We give the standard definition of the semantics of the other formulas:
In the semantics above, note that the domain of quantification is the set of ; that is, quantifiers range over entities, activities, agents, or interactions (which are in turn further subdivided into types of interactions). and relations cannot be referenced directly by identifiers.
A PROV instance consists of a set of statements, each of which can be translated to an atomic formula following the definitional rules in PROV-CONSTRAINTS, possibly by introducing fresh existential variables. Thus, we can view an instance as a set of atomic formulas , or equivalently a single formula , where are the existential variables of .
We say that an object matches attributes in structure provided: for each attribute , we have . This is sometimes abbreviated as: .
An entity formula is of the form where denotes an entity.
Entity formulas can be interpreted as follows:
holds if and only if:
Not all of the attributes of an entity object are required to be present in an entity formula about that object. For example, the following formulas all hold if denotes an entity such that hold:
entity(x,[]) entity(x,[a=5]) entity(x,[a=4,a=5]) entity(x,[a=4,b=6])
Note that PROV-CONSTRAINTS normalization will merge these formulas to a single one:
entity(x,[a=4,a=5,b=6])
An activity formula is of the form where is a identifier referring to the activity, is a start time and is an end time, and are the attributes of activity .
holds if and only if:
An agent formula is of the form where denotes the agent and describes additional attributes.
The generation formula is of the form where is an event identifier, is an entity identifier, is an activity identifier, is a set of attribute-value pairs, and is a time.
holds if and only if:
The use formula is of the form where denotes an event, is an activity identifier, is an object identifier, is a set of attribute-value pairs, and is a time.
holds if and only if:
The invalidation formula is of the form where is an event identifier, is an entity identifier, is an activity identifier, is a set of attribute-value pairs, and is a time.
An invalidation formula holds if and only if:
An association formula has the form .
holds if and only if:
holds if and only if:
A start formula is interpreted as follows:
holds if and only if:
An activity end formula is interpreted as follows:
holds if and only if:
An attribution formula is interpreted as follows:
holds if and only if:
The relation is interpreted using the relation as follows:
holds if and only if:
Derivation formulas can be of one of two forms:
A precise derivation formula has the form .
holds if and only if:
An imprecise derivation formula has the form .
holds if and only if:
The relation indicates when one entity formula presents more specific aspects of another.
TODO: The content of this definition may need to be moved into the semantic structure via an irreflexive/transitive specialization relation on Entities, since by itself this definition is not transitive.
holds if and only if:
The second criterion says that the two Entities present (possibly different) aspects of the same Thing. Note that the third criterion allows and to have the same lifetime (or that of can be larger). The last criterion allows to have more defined attributes than , but they must include the attributes defined by .
The relation indicates when two entity formulas present (possibly different) aspects of the same thing. The two entities may or may not overlap in time.
holds if and only if:
The relation relates a collection to an element of the collection.
holds if and only if:
Additional constraints needed above to refer to (not yet defined) collection structure of entities/things.
In this section, we define the semantics of additional formulas concerning ordering, null values, and typing. These are used in the logical versions of constraints.
As usual, an equality formula means that two expressions denote the same value. Identifiers always denote .
holds if and only if .
The precedes relation holds between two events, one taking place before (or simultaneously with) another. Since the naive semantics assumes that times are linearly ordered and event times are mapped to a single time line, this amounts to comparing the event times. The semantics of strictly precedes ( is similar, only must take place strictly before ).
Because we use a linearly ordered time to define event precedence, there are valid PROV instances that are not satisfied in any naive model. For example:
entity(e) activity(a1) activity(a2) wasGeneratedBy(gen1; e, a1, 2011-11-16T16:05:00) wasGeneratedBy(gen2; e, a2, 2012-11-16T16:05:00) //different date
This instance is valid, and must satisfy precedence constraints and , but $time(gen_1)=
The formula is used to specify that a value may not be the null value . The symbol always denotes the null value (i.e. ).
holds if and only if .
The typing formula constrains the type of the value of .
In this section we restate all of the inferences and constraints of PROV-CONSTRAINTS in terms of first-order logic. For each, we give a proof sketch showing why the inference or constraint is sound for reasoning about the naive semantics. We exclude the definitional rules in PROV-CONSTRAINTS because they are only needed for expanding the abbreviated forms of PROV-N statements to the logical formulas used here.
In this inference, none of ,, or can be placeholders -.
In this inference, any of ,, or can be placeholders -.
In this rule, ,, or may be placeholders -.
In this rule, may be a placeholder -.
Suppose . Clearly and , so .
Suppose and and . Then by assumption , , and are in and and , so , as required to conclude .
Suppose and . Then by assumption both and are in and , as required to conclude .
Suppose the conditions for specialization hold of and and for and , where and and . Then . Moreover, , and similarly so . (TODO: How do we know ? Need strict ordering on entities in semantics.)
If and are specializations, then .
Suppose and . Suppose is an attribute-value pair in . Since holds, we know that . Thus since . Since this is the case for all attribute-value pairs in , and since obviously denotes an entity, we can conclude ).
In this constraint, ,, or must not be placeholders -.
In this constraint, any of ,, or may be placeholders -.
Each typing constraint follows immediately from well-formedness criteria marked [WF] in the corresponding semantics for formulas.
Each part follows from the fact that the semantics of only allows formulas to hold when either all three of are (denoting ) or none of them are.
This follows from the fact that in the semantics of , the two entities denoted by the first and second arguments are required to be distinct.
For each and such that and are different relation names, the following constraint holds:
This follows from the assumption that the different classes of interactions are disjoint sets, characterized by their types.
For each and each , the following constraint holds:
This follows from the assumption that interactions are distinct from other objects (entities, activities or agents).
This follows from the assumption that entities and activities are disjoint.
Above we have presented arguments for the soundness of the constraints and inferences with respect to the naive semantics. Here, we relate the notions of validity and normal form defined in PROV-CONSTRAINTS to the semantics. Our main observation is:
For part 1, the arguments are as in the previous section.
For part 2, proceed by induction on a terminating sequence of inference or uniqueness constraint steps: if is in normal form them we are done. If is not in normal form then if an inference is applicable, then use part 1; if a uniqueness constraint is applicable, then from the uniqueness constraint cannot fail on and .
For part 3, the arguments are as in the previous section for each constraint.
Finally, for part 4, suppose . Then where is the normal form of by part 2. By part 3, satisfies all of the remaining constraints, so is valid.
In this section we relate PROV instances and validation as specified in PROV-CONSTRAINTS to certain models, which we call syntactic models. We will show that valid PROV instances correspond to syntactic models of the first-order theory of PROV.
This document has been produced by the PROV Working Group, and its contents reflect extensive discussion within the Working Group as a whole.
Thanks also to Robin Berjon for the ReSPec.js specification writing tool and to MathJax for their LaTeX-to-HTML conversion tools, both of which aided in the preparation of this document.
Members of the PROV Working Group at the time of publication of this document were: Ilkay Altintas (Invited expert), Reza B'Far (Oracle Corporation), Khalid Belhajjame (University of Manchester), James Cheney (University of Edinburgh, School of Informatics), Sam Coppens (IBBT), David Corsar (University of Aberdeen, Computing Science), Stephen Cresswell (The National Archives), Tom De Nies (IBBT), Helena Deus (DERI Galway at the National University of Ireland, Galway, Ireland), Simon Dobson (Invited expert), Martin Doerr (Foundation for Research and Technology - Hellas(FORTH)), Kai Eckert (Invited expert), Jean-Pierre EVAIN (European Broadcasting Union, EBU-UER), James Frew (Invited expert), Irini Fundulaki (Foundation for Research and Technology - Hellas(FORTH)), Daniel Garijo (Universidad Politécnica de Madrid), Yolanda Gil (Invited expert), Ryan Golden (Oracle Corporation), Paul Groth (Vrije Universiteit), Olaf Hartig (Invited expert), David Hau (National Cancer Institute, NCI), Sandro Hawke (W3C/MIT), Jörn Hees (German Research Center for Artificial Intelligence (DFKI) Gmbh), Ivan Herman, (W3C/ERCIM), Ralph Hodgson (TopQuadrant), Hook Hua (Invited expert), Trung Dong Huynh (University of Southampton), Graham Klyne (University of Oxford), Michael Lang (Revelytix, Inc.), Timothy Lebo (Rensselaer Polytechnic Institute), James McCusker (Rensselaer Polytechnic Institute), Deborah McGuinness (Rensselaer Polytechnic Institute), Simon Miles (Invited expert), Paolo Missier (School of Computing Science, Newcastle university), Luc Moreau (University of Southampton), James Myers (Rensselaer Polytechnic Institute), Vinh Nguyen (Wright State University), Edoardo Pignotti (University of Aberdeen, Computing Science), Paulo da Silva Pinheiro (Rensselaer Polytechnic Institute), Carl Reed (Open Geospatial Consortium), Adam Retter (Invited Expert), Christine Runnegar (Invited expert), Satya Sahoo (Invited expert), David Schaengold (Revelytix, Inc.), Daniel Schutzer (FSTC, Financial Services Technology Consortium), Yogesh Simmhan (Invited expert), Stian Soiland-Reyes (University of Manchester), Eric Stephan (Pacific Northwest National Laboratory), Linda Stewart (The National Archives), Ed Summers (Library of Congress), Maria Theodoridou (Foundation for Research and Technology - Hellas(FORTH)), Ted Thibodeau (OpenLink Software Inc.), Curt Tilmes (National Aeronautics and Space Administration), Craig Trim (IBM Corporation), Stephan Zednik (Rensselaer Polytechnic Institute), Jun Zhao (University of Oxford), Yuting Zhao (University of Aberdeen, Computing Science).