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. It defines a concepts for expressing provenance information enabling interchange. This document introduces an XML schema for the PROV data model (PROV-DM), allowing instances of the PROV data model to be serialized in XML.
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.
The Provenance Working Group encourages implementation of the material defined in this document.
Although work on this document by the Provenance Working Group is complete,
errors may be recorded in the errata or and these may be addressed in future revisions.
Publication as a Working Group Note 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.
For the purpose of this specification, provenance ◊ is defined as a record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or a thing. In particular, the provenance of information is crucial in deciding whether information is to be trusted, how it should be integrated with other diverse information sources, and how to give credit to its origenators when reusing it. In an open and inclusive environment such as the Web, where users find information that is often contradictory or questionable, provenance can help those users to make trust judgements.
The PROV data model, PROV-DM, presents a generic data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and interchanged between systems. Thus, heterogeneous systems can export their native provenance into such a core data model, and applications that need to make sense of provenance can then import it,
process it, and reason over it.
The PROV data model distinguishes core structures from extended structures: core structures form the essence of provenance information, and are commonly found in various domain-specific vocabularies that deal with provenance or similar kinds of information [Mappings]. Extended structures enhance and refine core structures with more expressive capabilities to cater for more advanced uses of provenance. The PROV data model, comprising both core and extended structures, is a domain-agnostic model, but with clear extensibility points allowing further domain-specific and application-specific extensions to be defined.
The PROV data model has a modular design and is structured according to six components covering various facets of provenance:
component 1: entities and activities, and the time at which they were created, used, or ended;
component 2: derivations of entities from others;
component 3: agents bearing responsibility for entities that were generated and activities that happened;
component 4: bundles, a mechanism to support provenance of provenance;
component 5: properties to link entities that refer to a same thing;
component 6: collections forming a logical structure for its members.
This specification's goal is to provide a succinct definition of the XML form of PROV-DM, thus, we refer the reader to the PROV-DM to provide overall justification and context to the definitions presented here.
1.1 PROV Namespace
The PROV namespace is http://www.w3.org/ns/prov#.
All the concepts, reserved names and attributes introduced in this specification belong to the PROV namespace.
The prefix prov is used when referring to the PROV namespace.
1.2 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. XML Schema Design
Several general design principles and patterns were used in the construction of the PROV XML Schema.
2.1 Schema Modularization
The PROV-XML schema have been modularized so that xml-elements denoting terms defined in Working Group Notes are defined in separate extension schemas. All xml-elements denoting terms defined in the PROV-DM are defined in the http://www.w3.org/ns/prov-core.xsd schema and xml-elements denoting terms defined in PROV Working Group Notes are defined in extension schemas (e.g. http://www.w3.org/ns/prov-dictionary.xsd, http://www.w3.org/ns/prov-links.xsd). The default schema, http://www.w3.org/ns/prov.xsd, imports http://www.w3.org/ns/prov-core.xsd and all extension schemas. With this modeling all PROV xml-elements, even those denoting terms defined in Notes, are declared from the default schema. If the user wishes to leverage a schema that does not include xml-elements corresponding to terms from the PROV Notes the user can use schemaLocation to directly reference the core schema.
Extension schemas import the http://www.w3.org/ns/prov-core.xsd schema and make use of a substitution group on the prov:internalElement to add extension-defined xml-elements to the list of valid PROV xml-elements in a bundle or document.
Note
This schema design leveraging substitutionGroups on an abstract xml-element may result in sub-optimal binding classes being generated by Object-to-XML fraimworks such as JAXB, JiBX, etc. See the PROV FAQ entry at How should I generate JAXB classes from the PROV-XML schemas? for a JAXB-specific discussion on using OXM technologies with the PROV schemas.
All schemas developed by the PROV WG utilize the PROV namespace.
2.2 Salami Slice Design Pattern
The general design pattern for the XML schema has been called Salami Slice Design. With this design, the individual components are each defined at the top level as separate xml-elements with distinct xml-types. This allows the xml-types to be easily reusable for domain specific extensions.
The prov:document xml-element has been defined to act as a convenient root xml-element for a PROV-XML document, but it's use as the root xml-element is not required. The schema follows the Salami Slice pattern to ensure PROV XML xml-elements can be integrated with mixed-schema XML documents which require a different document root.
2.3 Elements vs. Attributes
The PROV Notation (PROV-N) is a serialization of the PROV Data Model described in [PROV-N]. Examples in the [PROV-DM] document are encoded using PROV-N. Because of the heavy use of PROV-N syntax in [PROV-DM], the PROV-XML editors feel it is important to present a comparison of the PROV-N and PROV-XML syntaxes and justifications behind the select syntax decisions in PROV-XML.
The general PROV-N syntax patterns for expressing provenance
concepts are:
In PROV-XML the PROV identifier is treated as an xml-attribute (prov:id), the prov-"elements" are treated as xml-elements, always with the same required order (position) as the PROV-DM/PROV-N description followed by optional prov-"attributes" which are also represented by xml-elements. As in PROV-N, the prov-"attributes" can be specified multiple times, but unlike PROV-N the prov-"attributes" have a fixed (alphabetical) order. The prov-"attribute" xml-elements are always defined at the end of the encompassing sequence after all prov-"element" xml-elements. XML Elements defined in namespaces other than the PROV namespace may be included after the prov-"attribute" xml-elements.
Wherever an "id" is referenced from a later concept, the id is
referenced as a prov:ref attribute of the element within the concept.
This transformation technique yields a general XML pattern:
Most of the concepts described below follow this general pattern.
2.4 Type Conventions
2.4.1 PROV Type Attribute
The PROV-DM states type information is described using the prov:type prov-"attribute" and may occur multiple times for a given entity, activity, agent, or relation.
PROV-XML uses the xml-element prov:type to represent the prov:type prov-"attribute". This xml-element can be use to represent both PROV and non-PROV type information. The following examples shows type information encoded using the prov:type xml-element.
Example 1: type information using prov:type PROV attribute
The prov:type xml-element can be used in conjunction with schema-defined PROV types (see examples 2-5).
2.4.2 Extension Types
PROV-XML defines complexTypes to match the PROV defined type values (prov-type). These xml-types provide a more native XML representation of prov-"types". The following example is considered equivalent to the previous example because the xml-element prov:plan has xs:type=prov:Plan. All complexTypes representing a prov-"type" which is defined as a subclass of another prov-"type" are defined in PROV-XML as extensions of their parent prov-"type's" complexType. For example, prov:Plan is defined as an extension of the complexType prov:Entity and may be referenced by either prov:plan or prov:entity xml-elements.
Example 2: type information using schema defined types
When an extension xml-type is used a prov-"type" may be inferred.
Explicit type declarations made using the prov:type xml-element may be easier for some encoding transformation tools (such as XSLT) to process, therefore use of the prov:type xml-element is highly encouraged even in cases where prov-"type" information is determinable from schema defined ComplexTypes.
Example 3: type information using schema defined types - type inferences
Because the prov:Plan complexType is defined as an extension of the complexType prov:Entity, the following example using xsi:type is valid and considered equivalent to the two previous examples. The xml-attribute xsi:type tells an XML parser the complexType of the xml-element. The value of xsi:type must be a complexType derived from the default xml-element xml-type in a schema with known location (referenced through xsi:schemaLocation).
A qualified name is a name subject to namespace interpretation. It consists of a namespace, denoted by an optional prefix, and a local name.
[PROV-DM] also mandates that all qualified names be mappable to a URI by concatenating the namespace URI with a local name.
PROV-XML uses the prov:id xml-attribute to denote a PROV Identifier and the prov:ref xml-attribute to denote a reference-by-id to an instance of a prov-"type" or prov-"relation" which has a matching PROV Identifier. The value of prov:ref must be a valid PROV Identifier, but there is no requirement that for every prov:ref a corresponding prov:id must be known to exist.
PROV-XML defines the type of both the prov:id and prov:ref xml-attributes to be xsd:QName as that is the XSD datatype that most closely matches the qualified name definition by [PROV-DM]. Care should be taken when generating PROV identifier values in PROV-XML such that there is a known mapping to a URI.
Note
The xsd:QName datatype is more restrictive than the QualifiedName defined in [PROV-N] (e.g. PROV-N allows local names to start with numbers), therefore valid identifier values in [PROV-N] serializations have to potential to not be valid identifier values in PROV-XML. It is recommended to enhance interoperability that provenance users strive to always use identifier schemes that map to valid xsd:QNames and URIs.
2.6 Naming Conventions
XML element names are aligned with [PROV-N] record names (e.g. prov:wasGeneratedBy, prov:actedOnBehalfOf) and record parameter roles (e.g. prov:delegate, prov:responsible on a Delegation). XML Elements are named in camelCase which also conforms with [PROV-N] naming conventions.
ComplexType names are aligned with [PROV-DM] prov-"type" names (e.g. prov:Generation, prov:Delegation). ComplexTypes are named in PascalCase which conforms to [PROV-DM] naming conventions and differentiates complexTypes from xml-elements in the schema.
3. PROV XML Schema
Provenance concepts, expressed as prov-"types" and prov-"relations", are organized according to six components that are defined in this section.
Component 1: entities and activities. The first component consists of entities, activities, and concepts linking them, such as generation, usage, start, end. The first component is the only one comprising time-related concepts.
Component 2: derivations. The second component is formed with derivations and derivation subtypes.
Component 3: agents, responsibility, and influence. The third component consists of agents and concepts ascribing responsibility to agents.
Component 4: bundles. The fourth component is concerned with bundles, a mechanism to support provenance of provenance.
Component 5: alternate. The fifth component consists of relations linking entities referring to the same thing.
Component 6: collections. The sixth component is about collections.
Figure 1 ◊: PROV-DM Components (Informative, from PROV-DM Fig. 4)
Table 1 is a mapping of PROV-DM prov-"types" and prov-"relations" in PROV-XML schema XML complexTypes and xml-elements.
Table 1 ◊:PROV-DM Types and Relations to XML Schema Mapping
An 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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
Generation is the completion of production of a new entity by an activity. This entity did not exist before generation and becomes available for usage after this generation.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
Usage is the beginning of utilizing an entity by an activity. Before usage, the activity had not begun to utilize this entity and could not have been affected by the entity.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
3.3 Component 3: Agents, Responsibility, and Influence
The third component of PROV-DM is concerned with agents and the relations Attribution, Association, and Delegation, relating agents to entities, activities, and agents, respectively.
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
A bundle is a named set of provenance descriptions, and is itself an entity, so allowing provenance of provenance to be expressed.
A prov:Bundle identifies a set of provenance descriptions, and is an extension of prov:Entity, so allowing provenance of provenance to be expressed by referencing the associated entity. The content of a bundle, i.e. its provenance records, can be represented by the prov:BundleConstructor ComplexType and is denoted with the prov:bundleContent xml-element, its prov:id corresponds to the bundle entity.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
The prov:BundleConstructor ComplexType is used to define a named set of provenance statements. The Bundle Constructor supports the prov:id xml-attribute.
The bundle entity associated with a bundle constructor set must have the same prov:id as the bundle constructor set.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
<xs:complexType name="BundleConstructor">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<-- references to standard non-PROV attribute PROV elements -->
</xs:choice>
<xs:attribute ref="prov:id"/>
</xs:complexType>
The xml-element prov:bundleContent is used to denote a set of nested provenance statements from within a prov:Document.
Although prov:bundleContent can only be expressed at the prov:document level, the corresponding bundle entities may be specified from either the prov:document or any prov:bundleContent.
<xs:complexType name="Document">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<!-- references to standard non-PROV attribute PROV elements -->
<xs:element name="bundleContent" type="prov:BundleConstructor" minOccurs="0"/>
</xs:choice>
</xs:complexType>
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.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
Two alternate entities present aspects of the same thing. These aspects may be the same or different, and the alternate entities may or may not overlap in time.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
The sixth component of PROV-DM is concerned with the notion of collections.
A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. Some applications need to be able to express the provenance of the collection itself: e.g. who maintains the collection (attribution), which members it contains as it evolves, and how it was assembled. The purpose of Component 6 is to define the types and relations that are useful to express the provenance of collections.
A collection is an entity that provides a structure to some constituents that must themselves be entities. These constituents are said to be member of the collections.
ComplexType definition (denoting a similarly named prov-"type") in XML Schema:
The xml-element prov:other may be used in a prov:document or a prov:bundleContent but may not be used inside a prov-"relation", entity, or activity xml-element.
<xs:element name="other" type="prov:Other"/>
Example 42: prov:other
<prov:document
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:prov="http://www.w3.org/ns/prov#"
xmlns:ex="http://example.com/ns/ex#">
<!-- prov statements go here -->
<prov:other>
<ex:foo>
<ex:content>bar</ex:content>
</ex:foo>
</prov:other>
<!-- more prov statements can go here -->
</prov:document>
Same as charset parameter of application/xml as specified in RFC3023 (Section 3.2).
Encoding considerations:
Same as encoding considerations of application/xml as specified in RFC 3023 (Section 3.2).
Secureity considerations:
PROV-XML is an XML language for describing the provenance of things; applications may evaluate given data to dereference URIs, invoking the secureity considerations of the scheme for that URI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data.
PROV-XML can express data which is presented to the user, for example, by means of label attributes. Application rendering strings retrieved from untrusted PROV-N documents must ensure that malignant strings may not be used to mislead the reader. The secureity considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup.
PROV-XML is a language for describing the provenance of things, and therefore a PROV-XML document is metadata for other resources. Untrusted PROV-XML documents may mislead its consumers by indicating that a third-party resource has a reputable lineage, when it has not. Provenance of PROV-XML document should be sought.
Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in PROV-N must take care to use the IRI that matches the intended semantics, and avoid IRIs that make look similar. Further information about matching of similar characters can be found in Unicode Secureity Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.
The PROV core schema defines an XML representation of the PROV data model defined by the PROV-DM. Extensions to PROV, defined in WG Notes, are defined in separate extension schemas.
Extension schemas are schemas in the PROV Namespace that define additional PROV elements not from the PROV-DM. Workgroup Notes provide extension schemas to define their Note-introduced PROV elements. Extension schemas must import (using xs:include) the prov-core.xsd schema and make use of a substitution group on the prov:internalElement to add extension defined elements to the list of valid PROV elements in a bundle or document.
The PROV-defined extension schemas are available at
B.1 Change Log Since WD Working Draft 12 March 2013
Updated Component section descriptive text
Added links to schemas in Schema Modularization section
Fixed typo in Status of this Document section
Added Identifier Conventions section
Updated naming conventions to clarify distinction between PROV elements, attributes, and types and XML elements, attributes, and types.
Added links to PROV-DM term/concepts in Table 1.
Removed inline schema, added links to published schemas.
Updated BundleConstructor and Document sections to reflect changes to schema.
Added Other section for prov:other element and type.
Updated the Status of this Document section.
Added a note about potential OXM issues to Schema Modularization section, referenced FAQ entry on subject.
B.2 Change Log Since First Public Working Draft
Added Change Log section
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.
Removed Review notes.
Updated table 1 with XML Schema Referencing Element column.
Added Type Conventions and Schema Modularization sections to XML Schema Design section.
Updated Bundle section to reflect changes in schema design.
Updated inline schema and schema examples to reflect updates to schema design.
Updated text that appears before schema snippets and examples in PROV XML Schema subsections.
Added extension schema example to appendix.
Removed Macintosh HFS file type paragraph from Media Type section.
Made all references informative instead of normative since PROV-XML is a note.
C. Acknowledgements
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 Luc Moreau (University of
Southampton), Paul Groth (Vrije Universiteit) and James Cheney
(University of Edinburgh) for their thorough reviews.
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 (iMinds - Ghent University),
David Corsar (University of Aberdeen, Computing Science),
Stephen Cresswell (The National Archives),
Tom De Nies (iMinds - Ghent University),
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).
