PROV-N: The Provenance Notation

W3C Working Draft 03 May24 July 2012

This version:: http://www.w3.org/TR/2012/WD-prov-n-20120724/
Latest published version:: http://www.w3.org/TR/prov-n/
Latest editor's draft:: http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-n.html
Previous version:: http://www.w3.org/TR/2012/WD-prov-n-20120503/
Editors:: Luc Moreau, University of Southampton; Paolo Missier, Newcastle University
Authors:: James Cheney, University of Edinburgh; Stian Soiland-Reyes, University of Manchester

Abstract

PROV-DM, the PROVProvenance is information about entities, activities, and people involved in producing a piece of data model,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 data modelbasis for the W3C provenance that describes the entities, people and activities involved in producing a piece(PROV) family of data or thing.specifications. PROV-DM distinguishes core structures, forming the essence of provenance information, from extended structures catering for more specific uses of provenance. PROV-DM is structuredorganized in six components, respectively dealing with: (1) entities and activities, and the time at which they were created, used, or ended; (2) derivations of entities from entities; (3) agents bearing responsibility for entities that were generated and activities that happened; (3) derivations(4) a notion of bundle, a mechanism to support provenance of provenance; and, (5) properties to link entities from entities; (4) propertiesthat refer to link entities that refer to the same thing; (5)(6) collections forming a logical structure for its members; (6) a simple annotation mechanism.members.

To provide examples of the PROV data model, the PROV notation (PROV-N) is introduced: aimed at human consumption, PROV-N allows serializations of PROV instances to be created in a compact manner. PROV-N facilitates the mapping of the PROV data model to concrete syntax, and is used as the basis for a formal semantics of PROV. The purpose of this document is to define the PROV-N notation.

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/.

Last Call

This is a Last Call Working Draft. The design is not expected to change significantly, going forward, and now is the key time for external review.

This specification identifies one feature at risk: the expression Mention (section 3.5.3) might be removed from PROV if implementation experience reveals problems with supporting this construct.

PROV Family of Specifications

This document is part of the PROV family of specifications, a set of specifications defining various aspects that are necessary to achieve the vision of inter-operable interchange of provenance information in heterogeneous environments such as the Web. The specifications are:

PROV-DM,PROV-DM, the PROV data model for provenance;
PROV-CONSTRAINTS,PROV-CONSTRAINTS, a set of constraints applying to the PROV data model;
PROV-N,PROV-N, a notation for provenance aimed at human consumption (this document);
PROV-O,PROV-O, the PROV ontology, an OWL-RLOWL2 ontology allowing the mapping of PROV to RDF;
PROV-AQ,PROV-AQ, the mechanisms for accessing and querying provenance;
PROV-PRIMER,PROV-PRIMER, a primer for the PROV data model; PROV-SEM, a formal semantics for the PROV data model; PROV-XML, an XML schema for the PROV data model.

How to read the PROV Family of Specifications

The primer is the entry point to PROV offering an introduction to the provenance model.
The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL-RLOWL2 ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. PROV-SEM provides a mathematical semantics.

The XML community should focus on PROV-XML defining an XML schema for PROV. Further details can also be found in PROV-DM, PROV-CONSTRAINTS, and PROV-SEM.

Developers seeking to retrieve or publish provenance should focus on PROV-AQ.
Readers seeking to implement other PROV serializations should focus on PROV-DM and PROV-CONSTRAINTS. PROV-O, PROV-N, PROV-XMLPROV-O and PROV-N offer examples of mapping to RDF,RDF and text, and XML, respectively.

First Public Working Draft

This is the first public release of the PROV-N document. Following feedback, the Working Group has decided to reorganize the PROV-DM document substantially, separating the data model, from its constraints, and the notation used to illustrate it. The PROV-N release is synchronized with the release of the PROV-DM, PROV-O, PROV-PRIMER, and PROV-CONSTRAINTS documents. This document was published by the Provenance Working Group as a First PublicLast Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-prov-wg@w3.orgpublic-prov-comments@w3.org (subscribe, archives). The Last Call period ends 18 September 2012. All feedback is welcome.

Publication as a 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 is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. 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.

1. Introduction
2. General grammar considerations
3. PROV-N Productions per Component
4. Expression ContainerToplevel Bundle
5. AccountExtensibility
6. Media Type
A. Acknowledgements
B. References
- B.1 Normative references
- B.2 Informative references

1. Introduction

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 the world. Two companion specifications respectively define PROV-DM, a data model for provenance, allowing provenance descriptions to be expressed [PROV-DM] and a set of constraints that provenance descriptions are expected to satisfy [PROV-CONSTRAINTS].

1.1 Purpose of this Document and target audienceTarget Audience

A key goal of PROV is the specification of a machine-processable data model for provenance. However, communicating provenance between humans is also important when teaching, illustrating, formalizing, and discussing provenance-related issues. With these two requirements in mind, this document introduces PROV-N, the PROV notation, a syntax notation designed to write instances of the PROV data model according to the following design principles:

Technology independence. PROV-N provides a simple syntax that can be mapped to several technologies.
Human readability. PROV-N follows a functional syntax style that is meant to be easily human-readable so it can be used in illustrative examples, such as those presented in the PROV documents suite;
Formality. PROV-N is defined through a formal grammar amenable to be used with parser generators.

PROV-N has several known uses:

It is the notation used in the examples found in [PROV-DM], as well as in the definition of PROV constraints [PROV-CONSTRAINTS];
It is a source language for the encoding of PROV data model instances into a variety of target languages, including amongst others RDF [PROV-RDF] and XML [PROV-XML];
It provides the basis for a formal semantics of the PROV data model [PROV-SEM], in which an interpretation is given to each element of the PROV-N language.

This document introduces the PROV-N grammar along with examples of its usage.

Its target audience is twofold:

Developers of provenance management applications, as well as implementors of new PROV data model encodings, and thus in particular of PROV-N parsers. These readers may be interested in the entire structure of the grammar, starting from the top level nonterminal container bundle.
Readers of the [PROV-DM] and of [PROV-CONSTRAINTS] documents, who are interested in the details of the formal language underpinning the notation used in the examples and in the definition of the constraints. Those readers may find the expression nonterminal a useful entry point into the grammar.

1.2 Structure of this Document

This document defines a grammar using the Extended Backus-Naur Form (EBNF) notation. Its productions correspond to PROV data model types and relations. is structured as follows.

It is structured as follows.

Section 2 provides the design rationale for the PROV Notation. Section 3 defines the notation for the Extended Backus-Naur Form (EBNF) grammar used in this specification.general consideration about the PROV-N grammar.

Section 43 presents the grammar of all expressions of the language grouped according to the PROV data model components.

Section 54 defines the grammar of containers,toplevel bundles, a house-keeping construct of PROV-N capable of packaging up PROV-N expressions and namespace declarations.

Section 65 defines the grammar of accounts.extensibility mechanism for the PROV-N notation.

Section 76 defines media type for the PROV-N notation.

1.3 Notational 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].

The following namespaces prefixes are used throughout this document.

Table 1: Prefix and Namespaces used in this specification
prefix	namespace uri	definition
prov	http://www.w3.org/ns/prov#	The PROV namespace (see Section 4.7.13.7.4)
xsd	http://www.w3.org/2000/10/XMLSchema#	XML Schema Namespace [XMLSCHEMA-2] rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#The RDF namespace [RDF-CONCEPTSXMLSCHEMA11-2]
(others)	(various)	All other namespace prefixes are used in examples only. In particular, URIs starting with "http://example.com" represent some application-dependent URI [URI]

2. General grammar considerations

2.1 Functional-style Syntax

PROV-N adopts a functional-style syntax consisting of a predicate name and an ordered list of terms.

All PROV data model types have an identifier. Furthermore, some expressions also admit additional elements that further characterize it.

Example 1

The following expression should be read as "entity e1".

entity(e1)

Example 2

The following expression should be read as "activity a2, which occurred between 2011-11-16T16:00:00 and 2011-11-16T16:00:01".

entity(e1)
activity(a2, 2011-11-16T16:00:00, 2011-11-16T16:00:01)

All PROV data model relations involve two primary elements, the subject and the object, in this order. Furthermore, some expressions also admit additional elements that further characterize it.

Example 3

The following expression should be read as "e2 was derived from e1". Here e2 is the subject, and e1 is the object.

wasDerivedFrom(e2, e1)

In the

Example 4

The following expressions,expression expands the above derivation relation by providing additional elements the optional activity a along with, the generation g2, and the usage identifiers, and timestamps have been added to further qualify the derivation: u1:

wasDerivedFrom(e2, e1, a, g2, u1)
activity(a2, 2011-11-16T16:00:00, 2011-11-16T16:00:01)

2.2 EBNF Grammar

The grammar is specified using a subset of the Extended Backus-Naur Form (EBNF) notation.notation, as defined in Extensible Markup Language (XML) 1.1 [XML11] section 6 Notation.

The text below provides an introduction to the EBNF notation used in this document.

EachEBNF specifies a series of production rule (or rules (production, for short)). A production rule in the grammar defines one non-terminala symbol E, in expr (nonterminal symbol) using the following form:

expr ::= term

Symbols are written with an initial capital letter if they are the start symbol of a regular language, otherwise with an initial lowercase letter. A production rule in the grammar defines a symbol <TERMINAL> (terminal symbol) using the following form:

<TERMINAL> ::= term

Within the term on the right-hand side of a rule, the following terms terms are used to match strings of one or more characters:

E expr: matches term satisfying ruleproduction for nonterminal symbol E. abc: matches the literal string inside the single quotes.expr
TERMINAL: matches production for terminal symbol TERMINAL
"abc": matches the literal string inside the single quotes.
(term)?: optional, matches term: optional term, matches term or nothing.
term (term)+: matches one or more occurrences of term.
term (term)*: matches zero or more occurrences of term.
term (term | termterm): matches one of the two terms.

Where suitable, the PROV-N grammar reuses production and terminal names of the SPARQL grammar [RDF-SPARQL-QUERY].

2.3 Main Productions

Two productions are entry points to the grammar.

The grammarproduction expression provides the structure for the core expressions of PROV-N.

Each of the symbols included in expression above, i.e., entityExpression, activityExpression etc., corresponds to one concept (e.g., Entity, Activity, etc.) of the PROV data model.

Alternatively, the production rule bundle provides the overall structure of PROV-N descriptions. It is centered on nonterminals a wrapper for various types a set of expressions, such that the text for an element matches the corresponding expression. The main production is introduced here below as it reflects the rationale for the design of the entire grammar. Note that parser developers may use the top level container production, nonterminal as a starting point instead. expression ::= entityExpression | activityExpression | generationExpression | usageExpression | startExpression | endExpression | invalidationExpression | communicationExpression | startByActivityExpression | agentExpression | attributionExpression | associationExpression | responsibilityExpression | derivationExpression | revisionExpression | quotationExpression | hadOriginalSourceExpression | traceExpression | alternateExpression | specializationExpression | noteExpression | annotationExpression Each expression non-terminal expression, i.e., entityExpression, activityExpression etc., corresponds to one element (entity, activity, etc.) of the PROV data model. A PROV-N document consists of a collection of expressions, wrapped in an expression container withand some namespace declarations, such that the text for an element matches the corresponding expression production of the grammar. declarations.

2.32.4 Optional terms in expressions

Some terms in an expression may be optional. For example:

Example 5

wasDerivedFrom(e2, e1, a, g2, u1)
wasDerivedFrom(e2, e1)

In a derivation expression, the activity, generation, and usage are optional terms. They are specified in the first derivation, but not in the second.

Example 6

activity(a2, 2011-11-16T16:00:00, 2011-11-16T16:00:01)
activity(a1)

The start and end times for Activity a1 are optional. They are specified in the first expression, but not in the second.

The general rule for optionals is that, if none of the optionals are used in the expression, then they are simply omitted, resulting in a simpler expression as in the examples above.

However, it may be the case that only some of the optional terms are omitted. Because the position of the terms in the expression matters, an additional marker must be used to indicate that a particular term is not available. The symbol -'-' is used for this purpose.

Example 7

In the first expression below, all optionals are specified. However in the second,second and third, only the last one optional is specified, forcing the use of the marker for the missing terms. In the last, no marker is necessary because all remaining optionals after a are missing.

wasDerivedFrom(e2, e1, a, g2, u1)
wasDerivedFrom(e2, e1, -, -, u1)
wasDerivedFrom(e2, e1, a)a, -, -)

Note that the more succinct form is just shorthand for a complete expression with all the markers specified:

Example 8

activity(a1)
activity(a1, -, -)

2.42.5 Identifiers and attributes

Almost all expressions defined in the grammar include an identifier (see Section 3.7.1 for the full syntax of identifiers). Most expressions defined can aslo include a set of attribute-value pairs, delimited by square brackets. Identifiers are optional except for Entities, Activites, and Agents. Identifiers are always the first term in the grammar include the useany expression. Optional identifiers must be separated using a semi-colon ';', but where the identifiers are required, a regular comma ',' must be used. This makes it possible to completely omit an optional identifier with no ambiguity arising. Also, if the set of two terms:attribute-value pairs is present, it is always the last term in any expression.

Example 9

Derivation has an optional identifier. In the first expression, the identifier for the predicate, and a set of attribute-value pairs, delimited by square brackets. Both are optional (unless specified otherwise). By convention, theis not available, while it is explicit in the second. The third example shows that one can optionally indicate the missing identifier is the first term in any expression, and the set of attribute-value pairs is the last. Consistent with the convention on optional terms, the 'using the -' marker can be used when the identifier marker. This is not available. Additionally, the grammar rules are defined in such a way that the optional identifier can be omitted altogether with no ambiguity arising. Derivation has an optional identifier. Inequivalent to the first expression, the identifier is not available. It is explicit in the second, and marked by a - in the third.expression.

wasDerivedFrom(e2, e1)
wasDerivedFrom(d,wasDerivedFrom(d; e2, e1)
wasDerivedFrom(-,wasDerivedFrom(-; e2, e1)

A distinction is made between expressions with no attributes, and expressions that includeLack of attributes can be equivalently expressed by omitting the list, or by using an empty list of attributes. list.

Example 10

The first and second activity does notexpressions have any attributes. no attributes, and are equivalent. The second has an empty list of attributes. The third activity expression has two attributes.

activity(ex:a10)
activity(ex:a10,activity(ex:a1)
activity(ex:a1, [])
activity(ex:a10,activity(ex:a1, [ex:param1="a", ex:param2="b"])

2.6 Comments

Comments in PROV-N take two forms:

'//' outside an IRI_REF or STRING_LITERAL; such comments continue to the end of line (marked by characters U+000D or U+000A) or end of file if there is no end of line after the comment marker.
'/*' ... '*/', outside an IRI_REF or STRING_LITERAL.

Comments are treated as white space.

3. PROV-N Productions per Component

This section introduces grammar productions for each expression, followed by small examples of expressions illustrating the use ofgrammar. Strings conforming to the grammar are valid expressions in PROV-N. Strings conforming to the grammar are valid expressions in the PROV-N language.

3.1 Component 1: Entities and Activities

3.1.1 Entity

[3]	`entityExpression`	::=	`"entity" "(" identifier optionalAttributeValuePairs ")"`
[4]	`optionalAttributeValuePairs`	::=	`( "," "[" attributeValuePairs "]" )?`
[5]	`attributeValuePairs`	::=	`( \| attributeValuePair ( "," attributeValuePair )* )`
[6]	`attributeValuePair`	::=	`attribute "=" literal`

The following table summarizes how each constituent of a PROV-DM Entity maps to a PROV-N syntax element.

entityExpression ::= entity (

Entity	Non-Terminal

id	`identifier optional-attribute-values ) optional-attribute-values ::= , [ attribute-values ] attribute-values ::= attribute-value \| attribute-value , attribute-values attribute-value ::= attribute = Literal`
attributes	`optionalAttributeValuePairs`

Example 11

entity(tr:WD-prov-dm-20111215, [ prov:type="document" ])

Here tr:WD-prov-dm-20111215 is the optional entity identifier, and [ prov:type="document" ] groups the optional attributes attributes, only one in this example, with their values.

entity(tr:WD-prov-dm-20111215)

HereHere, the optional attributes are not used.absent.

3.1.2 Activity

[7]	`activityExpression ::= activity`	::=	`"activity" "(" identifier ( "," timeOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"`
[8]	`timeOrMarker`	::=	`( time \| "-" )`

The following table summarizes how each constituent of a PROV-DM Activity maps to a PROV-N syntax element.

Activity	Non-Terminal

id	`identifier , (time \| - ) , (time \| - ) optional-attribute-values )`
startTime	`timeOrMarker`
endTime	`timeOrMarker`
attributes	`optionalAttributeValuePairs`

Example 12

activity(ex:a10, 2011-11-16T16:00:00, 2011-11-16T16:00:01, [prov:type="createFile"])

Here ex:a10 is the optional activity identifier, 2011-11-16T16:00:00 and 2011-11-16T16:00:01 are the optional start and end times for the activity, and [prov:type="createFile"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

activity(ex:a10)
activity(ex:a10, -, -)
activity(ex:a10, -, -, [prov:type="edit"])
activity(ex:a10, -, 2011-11-16T16:00:00)
activity(ex:a10, 2011-11-16T16:00:00, -)
activity(ex:a10, 2011-11-16T16:00:00, -, [prov:type="createFile"])
activity(ex:a10, [prov:type="edit"])

3.1.3 Generation

[9]	`generationExpression ::= wasGeneratedBy`	::=	`"wasGeneratedBy" "(" optionalIdentifier eIdentifier ( "," aIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"`
[10]	`optionalIdentifier`	::=	`( identifierOrMarker ";" )?`
[11]	`identifierOrMarker`	::=	`( identifier \| -"-" ) ,`

The following table summarizes how each constituent of a PROV-DM Generation maps to a PROV-N syntax element.

Generation	Non-Terminal

id	`optionalIdentifier`
entity	`eIdentifier , ( aIdentifier \| - ) , (`
activity	`aIdentifierOrMarker`
time \| - ) optional-attribute-values )	`timeOrMarker`
attributes	`optionalAttributeValuePairs`

Example 13

wasGeneratedBy(ex:g1,wasGeneratedBy(ex:g1; tr:WD-prov-dm-20111215, ex:edit1, 2011-11-16T16:00:00,  [ex:fct="save"])

Here ex:g1 is the optional generation identifier, tr:WD-prov-dm-20111215 is the identifier of the entity being generated, ex:edit1 is the optional identifier of the generating activity, 2011-11-16T16:00:00 is the optional generation time, and [ex:fct="save"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1,wasGeneratedBy(e2, a1, -)
wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1,wasGeneratedBy(e2, a1, 2011-11-16T16:00:00)
wasGeneratedBy(e2, a1, -, [ex:fct="save"])     
wasGeneratedBy(e2, -, -, [ex:fct="save"])     
wasGeneratedBy(ex:g1, tr:WD-prov-dm-20111215, ex:edit1, -)
wasGeneratedBy(-, tr:WD-prov-dm-20111215, ex:edit1, -)wasGeneratedBy(ex:g1; e)
wasGeneratedBy(ex:g1; e, a, tr:WD-prov-dm-20111215)

Even though the production Additional semantic rules (Section 3.7.5) apply to generationExpression allows for expressions wasGeneratedBy(e2, -, -) and wasGeneratedBy(-, e2, -, -), these expressions are not valid in PROV-N, since at least one of activity, time, or attributes must be present..

3.1.4 Usage

[12] usageExpression ::= used ::= "used" "(" optionalIdentifier aIdentifier ( ( identifier | - ) , "," eIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Usage maps to a PROV-N syntax element.

Usage	Non-Terminal

id	`optionalIdentifier`
activity	`aIdentifier , eIdentifier , (`
entity	`eIdentifierOrMarker`
time \| - ) optional-attribute-values )	`timeOrMarker`
attributes	`optionalAttributeValuePairs`

Example 14

used(ex:u1,used(ex:u1; ex:act2, ar3:0111, 2011-11-16T16:00:00, [ex:fct="load"])

Here ex:u1 is the optional usage identifier, ex:act2 is the identifier of the using activity, ar3:0111 is the identifier of the entity being used, 2011-11-16T16:00:00 is the optional usage time, and [ex:fct="load"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

used(ex:act2)
used(ex:act2, ar3:0111, 2011-11-16T16:00:00)
used(a1,e1, -, [ex:fct="load"])
used(ex:u1; ex:act2, ar3:0111, -)
used(ex:act2, ar3:0111, 2011-11-16T16:00:00)
used(a1,e1, -, [ex:fct="load"])
used(ex:u1, ex:act2, ar3:0111, -)
used(-, ex:act2, ar3:0111, -)

Additional semantic rules (Section 3.7.5) apply to usageExpression.

3.1.5 Communication

[13] communicationExpression ::= "wasInformedBy" "(" optionalIdentifier aIdentifier "," aIdentifier optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Communication maps to a PROV-N syntax element.

Communication	Non-Terminal

id	`optionalIdentifier`
informed	`aIdentifier`
informant	`aIdentifier`
attributes	`optionalAttributeValuePairs`

Example 15

wasInformedBy(ex:inf1; ex:a1, ex:a2, [ex:param1="a", ex:param2="b"])

Here ex:inf1 is the optional communication identifier, ex:a1 is the identifier of the informed activity, ex:a2 is the identifier of the informant activity, and [ex:param1="a", ex:param2="b"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasInformedBy(ex:a1, ex:a2)
wasInformedBy(ex:a1, ex:a2, [ex:param1="a", ex:param2="b"])
wasInformedBy(i; ex:a1, ex:a2)
wasInformedBy(i; ex:a1, ex:a2, [ex:param1="a", ex:param2="b"])

3.1.6 Start

[14] startExpression ::= wasStartedBy ::= "wasStartedBy" "(" optionalIdentifier aIdentifier ( ( identifier | - ) , "," eIdentifierOrMarker "," aIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Start maps to a PROV-N syntax element.

Start	Non-Terminal

id	`optionalIdentifier`
activity	`aIdentifier , ( eIdentifier \| - ) , (`
trigger	`eIdentifierOrMarker`
starter	`aIdentifierOrMarker`
time \| - ) optional-attribute-values )	`timeOrMarker`
attributes	`optionalAttributeValuePairs`

Example 16

wasStartedBy(s,wasStartedBy(s; ex:act2, ar3:0111,ex:trigger, ex:act1, 2011-11-16T16:00:00, [ex:param="a"])

Here s is the optional start identifier, ex:act2 is the identifier of the startingstarted activity, ar3:0111ex:trigger is the optional identifier offor the entity that triggered the activity start, ex:act1 is the optional identifier for the activity that generated the (possibly unspecified) entity ex:trigger, 2011-11-16T16:00:00 is the optional usagestart time, and [ex:param="a"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasStartedBy(ex:act2, ar3:0111,-, ex:act1, -)
wasStartedBy(ex:act2, ar3:0111,-, ex:act1, 2011-11-16T16:00:00)
wasStartedBy(ex:act2, -, -, 2011-11-16T16:00:00)
wasStartedBy(ex:act2, -, -)
wasStartedBy(ex:act2, -, -, [ex:param="a"])
wasStartedBy(s,wasStartedBy(s; ex:act2, ar3:0111,e, ex:act1, 2011-11-16T16:00:00)
wasStartedBy(-, ex:act2, ar3:0111, 2011-11-16T16:00:00)

Note: Even though the production Additional semantic rules (Section 3.7.5) apply to startExpression allows for expressions wasStartedBy(e2, -, -) and wasStartedBy(-, e2, -, -), these expressions are not valid in PROV-N, since at least one of trigger, time, or attributes must be present..

3.1.63.1.7 End

[15] endExpression ::= wasEndedBy ::= "wasEndedBy" "(" optionalIdentifier aIdentifier ( ( identifier | - ) , "," eIdentifierOrMarker "," aIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM End maps to a PROV-N syntax element.

End	Non-Terminal

id	`optionalIdentifier`
activity	`aIdentifier , ( eIdentifier \| - ) , (`
trigger	`eIdentifierOrMarker`
ender	`aIdentifierOrMarker`
time \| - ) optional-attribute-values )	`timeOrMarker`
attributes	`optionalAttributeValuePairs`

Example 17

wasEndedBy(s,wasEndedBy(s; ex:act2, ex:trigger, ex:trigger,ex:act3,  2011-11-16T16:00:00, [ex:param="a"])

Here s is the optional start identifier, ex:act2 is the identifier of the ending activity, ex:trigger is the identifier of the entity that triggered the activity end, ex:act3 is the optional identifier for the activity that generated the (possibly unspecified) entity e, 2011-11-16T16:00:00 is the optional usage time, and [ex:param="a"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasEndedBy(ex:act2, ex:trigger, -, -)
wasEndedBy(ex:act2, ex:trigger, -, 2011-11-16T16:00:00)
wasEndedBy(ex:act2, -, -, 2011-11-16T16:00:00)
wasEndedBy(ex:act2, -, -, 2011-11-16T16:00:00, [ex:param="a"])
wasEndedBy(e,ex:act2,wasEndedBy(e; ex:act2)
wasEndedBy(e; ex:act2, ex:trigger, -, -)
wasEndedBy(e, ex:act2, ex:trigger, 2011-11-16T16:00:00)
wasEndedBy(-, ex:act2, ex:trigger, 2011-11-16T16:00:00)

Note:Even though the production Additional semantic rules (Section 3.7.5) apply to endExpression allows for expressions wasEndedBy(e2, -, -) and wasEndedBy(-, e2, -, -), these expressions are not valid in PROV-N, since at least one of trigger, time, and attributes must be present..

3.1.73.1.8 Invalidation

[16] invalidationExpression ::= wasInvalidatedBy ::= "wasInvalidatedBy" "(" optionalIdentifier eIdentifier ( ( identifier | - ) , "," aIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Invalidation maps to a PROV-N syntax element.

Invalidation	Non-Terminal

id	`optionalIdentifier`
entity	`eIdentifier , ( aIdentifier \| - ) , (`
activity	`aIdentifierOrMarker`
time \| - ) optional-attribute-values )	`timeOrMarker`
attributes	`optionalAttributeValuePairs`

Example 18

wasInvalidatedBy(ex:i1,wasInvalidatedBy(ex:i1; tr:WD-prov-dm-20111215, ex:edit1, 2011-11-16T16:00:00,  [ex:fct="save"])

Here ex:i1 is the optional invalidation identifier, tr:WD-prov-dm-20111215 is the identifier of the entity being invalidated, ex:edit1 is the optional identifier of the invalidating activity, 2011-11-16T16:00:00 is the optional invalidation time, and [ex:fct="save"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasInvalidatedBy(tr:WD-prov-dm-20111215, ex:edit1, -)
wasInvalidatedBy(tr:WD-prov-dm-20111215, ex:edit1, 2011-11-16T16:00:00)
wasInvalidatedBy(e2, a1, -, [ex:fct="save"])     
wasInvalidatedBy(e2, -, -, [ex:fct="save"])     
wasInvalidatedBy(ex:i1,wasInvalidatedBy(ex:i1; tr:WD-prov-dm-20111215, ex:edit1, -)
wasInvalidatedBy(-, tr:WD-prov-dm-20111215,wasInvalidatedBy(tr:WD-prov-dm-20111215, ex:edit1, -)

Even though the production invalidationExpression allows for expressions wasInvalidatedBy(e2, -, -) and wasInvalidatedBy(-, e2, -, -), these expressions are not valid in PROV-N, since at least one of activity, time, or attributes must be present.

3.1.8 Communication communicationExpression ::= wasInformedBy

Additional semantic rules ( ( identifier | - Section 3.7.5) , aIdentifier , aIdentifier optional-attribute-values ) apply to invalidationExpression.

wasInformedBy(ex:inf1, ex:a1, ex:a2, [ex:param1="a", ex:param2="b"]) Here ex:inf1 is the optional communication identifier, ex:a1 is the identifier of the informed activity, ex:a2 is the identifier of the informant activity, and [ex:param1="a", ex:param2="b"] are optional attributes. The remaining examples show cases where some of the optionals are omitted. wasInformedBy(ex:a1, ex:a2) wasInformedBy(ex:a1, ex:a2, [ex:param1="a", ex:param2="b"]) wasInformedBy(i, ex:a1, ex:a2) wasInformedBy(i, ex:a1, ex:a2, [ex:param1="a", ex:param2="b"]) wasInformedBy(-, ex:a1, ex:a2) wasInformedBy(-, ex:a1, ex:a2, [ex:param1="a", ex:param2="b"])

3.1.9 Start by Activity startByActivityExpression ::= wasStartedByActivity ( ( identifier | - ) , aIdentifier , aIdentifier optional-attribute-values ) wasStartedByActivity(s,ex:a1, ex:a2, [ex:param1="a", ex:param2="b"]) Here s is the optional start-by-activity identifier, ex:a1 is the identifier of the starting activity, ex:a2 is the identifier of the activity that started ex:a1, and [ex:param1="a", ex:param2="b"] are optional attributes. The remaining examples show cases where some of the optionals are omitted. wasStartedByActivity(ex:a1, ex:a2) wasStartedByActivity(ex:a1, ex:a2, [ex:param1="a", ex:param2="b"]) wasStartedByActivity(s,ex:a1, ex:a2) wasStartedByActivity(-,ex:a1, ex:a2) wasStartedByActivity(-,ex:a1, ex:a2, [ex:param1="a", ex:param2="b"])

3.2 Component 2: Agents and ResponsibilityDerivations

3.2.1 AgentDerivation

agentExpression ::=

[17] derivationExpression ::= "wasDerivedFrom" "(" optionalIdentifier eIdentifier "," eIdentifier ( "," aIdentifierOrMarker "," gIdentifierOrMarker "," uIdentifierOrMarker )? optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Derivation maps to a PROV-N syntax element.

Derivation	Non-Terminal

id	`optionalIdentifier`
generatedEntity	`eIdentifier`
usedEntity	`eIdentifier`
activity	`aIdentifierOrMarker`
generation	`gIdentifierOrMarker`
usage	`uIdentifierOrMarker`
attributes	`optionalAttributeValuePairs`

Example 19

wasDerivedFrom(d; e2, e1, a, g2, u1, [ex:comment="a righteous derivation"])

Here d is the optional derivation identifier, e2 is the identifier for the entity being derived, e1 is the identifier of the entity from which e2 is derived, a is the optional identifier of the activity which used/generated the entities, g2 is the optional identifier of the generation, u1 is the optional identifier of the usage, and [ex:comment="a righteous derivation"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasDerivedFrom(e2, e1)
wasDerivedFrom(e2, e1, a, g2, u1)
wasDerivedFrom(e2, e1, -, g2, u1)
wasDerivedFrom(e2, e1, a, -, u1)
wasDerivedFrom(e2, e1, a, g2, -)
wasDerivedFrom(e2, e1, a, -, -)
wasDerivedFrom(e2, e1, -, -, u1)
wasDerivedFrom(e2, e1, -, -, -)
wasDerivedFrom(d; e2, e1, a, g2, u1)
wasDerivedFrom(-; e2, e1, a, g2, u1)

3.2.2 Revision

PROV-N provides no dedicated syntax for Revision. Instead, a Revision must be expressed as a derivationExpression with attribute prov:type='prov:Revision'.

Example 20

wasDerivedFrom(d; e2, e1, a, g2, u1, 
               [prov:type='prov:Revision', 
                ex:comment="a righteous derivation"])

Here, the derivation from Example 19 is extended with a agent prov:type attribute and value ( identifier optional-attribute-values ) agent(ag4, [ prov:type="prov:Person", ex:name="David" ]) Here agprov:Revision. The expression 'prov:Revision' is the agent identifier, and [ prov:type="prov:Person", ex:name="David" ] are optional attributes. convenienceNotation to denote a QUALIFIED_NAME literal (See Section 3.7.3. Literal).

In the next example, the optional attributes are omitted. agent(ag4)

3.2.2 Attribution attributionExpression ::= wasAttributedTo ( ( identifier | - ) , eIdentifier , agIdentifier optional-attribute-values ) wasAttributedTo(id, e, ag, [ex:license="cc:attributionURL" %% "xsd:QName"]) Here id is the optional attribution identifier, e is an entity identifier, ag is the identifier of the agent to whom the entity is abscribed, and [ex:license="cc:attributionURL" %% "xsd:QName"] are optional attributes. The remaining examples show cases where some of the optionals are omitted. wasAttributedTo(e, ag) wasAttributedTo(e, ag, [ex:license="cc:attributionURL" %% "xsd:QName"]) wasAttributedTo(-, e, ag, [ex:license="cc:attributionURL" %% "xsd:QName"])

3.2.3 AssociationQuotation

associationExpression ::= wasAssociatedWith ( ( identifier | - ) , aIdentifier , ( agIdentifier | - ) , ( eIdentifier | - ) optional-attribute-values ) wasAssociatedWith(ex:agas, ex:a1, ex:ag1, ex:e1, [ex:param1="a", ex:param2="b"]) Here ex:agas is the optional attribution identifier, ex:a1 is an activity identifier, ex:ag1 is the optional identifier of the agent associated to the activity, ex:e1 is the optional identifier of the plan used by the agent in the context of the activity, and [ex:param1="a", ex:param2="b"] are optional attributes. The remaining examples show cases where some of the optionals are omitted. wasAssociatedWith(ex:a1, -, ex:e1) wasAssociatedWith(ex:a1, ex:ag1, -) wasAssociatedWith(ex:a1, ex:ag1, ex:e1) wasAssociatedWith(ex:a1, ex:ag1, ex:e1, [ex:param1="a", ex:param2="b"]) wasAssociatedWith(a, ex:a1, -, ex:e1) wasAssociatedWith(-, ex:a1, -, ex:e1) wasAssociatedWith(-, ex:a1, ex:ag1, -) Note:The production associationExpression allows

PROV-N provides no dedicated syntax for expressions wasAssociatedWith(a, -, -) and wasAssociatiedWith(-, a, -, -). However, these expressions are not valid in PROV-N, because at least one of agent or planQuotation. Instead, a Quotation must be present. expressed as a derivationExpression with attribute prov:type='prov:Quotation'.

Example 21

wasDerivedFrom(quoteId1; ex:blockQuote,ex:blog, ex:act1, ex:g, ex:u,
               [ prov:type='prov:Quotation' ])

Here, the derivation is provided with a prov:type attribute and value prov:Quotation.

3.2.4 ResponsibilityPrimary Source

responsibilityExpression ::=

PROV-N provides no dedicated syntax for PrimarySource. Instead, a PrimarySource must be expressed as a derivationExpression with attribute prov:type='prov:Primary-Source'.

Example 22

wasDerivedFrom(src1;  ex:e1, ex:e2, ex:act, ex:g, ex:u, 
               [ prov:type='prov:PrimarySource' ])

Here, the derivation is provided with a actedOnBehalfOf prov:type attribute and value ( ( identifier | - ) , agIdentifier , agIdentifier , ( aIdentifier | - ) optional-attribute-values ) actedOnBehalfOf(act1, ag1, ag2, a, [prov:type="contract"]) Here act1 is the optional attribution identifier, ag1 is the identifier for the subordinate agent, ag2 is the identifier of the responsible agent, a is the optional identifier of the activity for which the responsibility link holds, and [prov:type="contract"] are optional attributes. prov:PrimarySource.

The remaining examples show cases where some of the optionals are omitted. actedOnBehalfOf(ag1, ag2, -) actedOnBehalfOf(ag1, ag2, a) actedOnBehalfOf(ag1, ag2, -, [prov:type="delegation"]) actedOnBehalfOf(ag2, ag3, a, [prov:type="contract"]) actedOnBehalfOf(r, ag2, ag3, a, [prov:type="contract"]) actedOnBehalfOf(-, ag1, ag2, -)

3.3 Component 3: DerivationsAgents, Responsibility, and Influence

3.3.1 DerivationAgent

derivationExpression ::=

[18] agentExpression ::= "agent" "(" identifier optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Agent maps to a PROV-N syntax element.

Agent	Non-Terminal

id	`identifier`
attributes	`optionalAttributeValuePairs`

PROV-N provides no dedicated syntax for Person, Organization, SoftwareAgent. Instead, a Person, an Organization, or a SoftwareAgent must be expressed as an agentExpression with attribute prov:type='prov:Person', prov:type='prov:Organization', or prov:type='prov:SoftwareAgent', respectively.

Example 23

agent(ag4, [ prov:type='prov:Person', ex:name="David" ])

Here wasDerivedFrom ag is the agent identifier, and ( ( identifier | - ) , eIdentifier , eIdentifier , ( aIdentifier | - ) , ( gIdentifier | - ) , ( uIdentifier | - ) optional-attribute-values )[ prov:type='prov:Person', ex:name="David" ] are optional attributes.

In the next example, the optional attributes are omitted.

agent(ag4)

3.3.2 Attribution

[19] attributionExpression ::= "wasAttributedTo" "(" optionalIdentifier eIdentifier "," agIdentifier optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Attribution maps to a PROV-N syntax element.

Attribution	Non-Terminal

id	`optionalIdentifier`
entity	`eIdentifier`
agent	`agIdentifier`
attributes	`optionalAttributeValuePairs`

Example 24

wasDerivedFrom(d, e2, e1, a, g2, u1, [prov:comment="a righteous derivation"])wasAttributedTo(id; e, ag, [ex:license='cc:attributionURL' ])

Here id is the optional attribution identifier, e is an entity identifier, ag is the identifier of the agent to whom the entity is abscribed, and [ex:license='cc:attributionURL' ] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasAttributedTo(e, ag)
wasAttributedTo(e, ag, [ex:license='cc:attributionURL' ])

3.3.3 Association

[20] associationExpression ::= "wasAssociatedWith" "(" optionalIdentifier aIdentifier ( "," agIdentifierOrMarker "," eIdentifierOrMarker )? optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Association maps to a PROV-N syntax element.

Association	Non-Terminal

id	`optionalIdentifier`
activity	`aIdentifier`
agent	`agIdentifierOrMarker`
plan	`eIdentifierOrMarker`
attributes	`optionalAttributeValuePairs`

PROV-N provides no dedicated syntax for Plan. Instead, a Plan must be expressed as an entityExpression with attribute prov:type='prov:Plan'.

Example 25

wasAssociatedWith(ex:agas; ex:a1, ex:ag1, ex:e1, [ex:param1="a", ex:param2="b"])

Here dex:agas is the optional derivationattribution identifier, ex:a1 is an activity identifier, ex:ag1 is the optional identifier of the agent associated to the activity, ex:e1 is the optional identifier of the plan used by the agent in the context of the activity, and [ex:param1="a", ex:param2="b"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

wasAssociatedWith(ex:a1, -, ex:e1)
wasAssociatedWith(ex:a1, ex:ag1)
wasAssociatedWith(ex:a1, ex:ag1, ex:e1)
wasAssociatedWith(ex:a1, ex:ag1, ex:e1, [ex:param1="a", ex:param2="b"])
wasAssociatedWith(a; ex:a1, -, ex:e1)

Additional semantic rules (Section 3.7.5) apply to associationExpression.

3.3.4 Delegation

[21] delegationExpression ::= "actedOnBehalfOf" "(" optionalIdentifier agIdentifier "," agIdentifier ( "," aIdentifierOrMarker )? optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Delegation maps to a PROV-N syntax element.

Delegation	Non-Terminal

id	`optionalIdentifier`
delegate	`agIdentifier`
responsible	`agIdentifier`
activity	`aIdentifierOrMarker`
attributes	`optionalAttributeValuePairs`

Example 26

actedOnBehalfOf(del1; ag2, ag1, a, [prov:type="contract"])

Here del1 is the optional delegation identifier, ag2 is the identifier for the delegate agent, ag1 is the identifier of the responsible agent, a is the optional identifier of the activity for which the delegation link holds, and [prov:type="contract"] are optional attributes.

The remaining examples show cases where some of the optionals are omitted.

actedOnBehalfOf(ag1, ag2)
actedOnBehalfOf(ag1, ag2, a)
actedOnBehalfOf(ag1, ag2, -, [prov:type="delegation"])
actedOnBehalfOf(ag2, ag3, a, [prov:type="contract"])
actedOnBehalfOf(r; ag2, ag3, a, [prov:type="contract"])

3.3.5 Influence

[22] influenceExpression ::= "wasInfluencedBy" "(" optionalIdentifier eIdentifier "," eIdentifier optionalAttributeValuePairs ")"

The following table summarizes how each constituent of a PROV-DM Influence maps to a PROV-N syntax element.

Influence	Non-Terminal

id	`optionalIdentifier`
influencee	`eIdentifier`
influencer	`eIdentifier`
attributes	`optionalAttributeValuePairs`

Example 27

wasInfluencedBy(id;e2,e1,[ex:param="a"])

Here id is the optional influence identifier, e2 is the identifier for the entity being derived, e1 is the identifier of the entity from which e2 is derived, a is the optional identifier of the activity which used/generated the entities, g2 is the optional identifier of the generation, u1 is the optional identifier of the usage, and [prov:comment="a righteous derivation"] are optional attributes. The remaining examples show cases where some of the optionals are omitted. wasDerivedFrom(e2, e1) wasDerivedFrom(e2, e1, a, g2, u1) wasDerivedFrom(e2, e1, -, g2, u1) wasDerivedFrom(e2, e1, a, -, u1) wasDerivedFrom(e2, e1, a, g2, -) wasDerivedFrom(e2, e1, a, -, -) wasDerivedFrom(e2, e1, -, -, u1) wasDerivedFrom(e2, e1, -, -, -) wasDerivedFrom(d, e2, e1, a, g2, u1) wasDerivedFrom(-, e2, e1, a, g2, u1) 3.3.2 Revision revisionExpression ::= wasRevisionOf ( ( identifier | - ) , eIdentifier , eIdentifier , ( agIdentifier | - ) optional-attribute-values ) wasRevisionOf(rev1, tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, w3:Consortium, [prov:comment="??"] ) Here rev1 is the optional revision identifier, tr:WD-prov-dm-20111215 is the identifier of the revised entity, tr:WD-prov-dm-20111018 is the identifier of the original entity, w3:Consortium is the optional identifier of the agent involved in the revision, and [prov:comment="??"] ) are optional attributes. The remaining examples show cases where some of the optionals are omitted. wasRevisionOf(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, -) wasRevisionOf(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, w3:Consortium) wasRevisionOf(id,tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, w3:Consortium) wasRevisionOf(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, -) wasRevisionOf(id,tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, -) wasRevisionOf(-,tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, -) 3.3.3 Quotation quotationExpression ::= wasQuotedFrom ( ( identifier | - ) , eIdentifier , eIdentifier , ( agIdentifier | - ) , ( agIdentifier | - ) optional-attribute-values ) wasQuotedFrom(quoteId1, ex:blockQuote,ex:blog,ex:Luc,ex:Paul,[]) Here quoteId1 is the optional revision identifier, ex:blockQuote is the identifier of the entity that represents the quote (the partial copy) ex:blog is the identifier of the original entity being quoted, ex:Luc is the optional identifier of the agent who performs the quoting, ex:Paul is the optional identifier of the agent to whom the original entity is attributed, and [] is the (empty) optional set of attributes. The remaining examples show cases where some of the optionals are omitted. wasQuotedFrom(ex:blockQuote,ex:blog) wasQuotedFrom(ex:blockQuote,ex:blog,ex:Luc,ex:Paul) wasQuotedFrom(ex:blockQuote,ex:blog,-,ex:Paul) wasQuotedFrom(ex:blockQuote,ex:blog,ex:Luc,ex:Paul,[]) wasQuotedFrom(ex:blockQuote,ex:blog, -, -) wasQuotedFrom(id,ex:blockQuote,ex:blog,ex:Luc,ex:Paul) wasQuotedFrom(-,ex:blockQuote,ex:blog,ex:Luc,-) 3.3.4 Original Source originalSourceExpression ::= hadOriginalSource ( ( identifier | - ) , eIdentifier , eIdentifier optional-attribute-values ) hadOriginalSource(src1, ex:e1, ex:e2,[ex:param="a"]) Here src1 is the optional original source identifier, ex:e1 is the identifier of the derived entity, ex:e2 is the identifier of the original source entity, and [ex:param="a"] is the optional set of attributes. The remaining examples show cases where some of the optionals are omitted. hadOriginalSource(ex:e1, ex:e2) hadOriginalSource(ex:e1, ex:e2,[ex:param="a"]) hadOriginalSource(-,ex:e1, ex:e2,[ex:param="a"]) hadOriginalSource(-,ex:e1, ex:e2) 3.3.5 Trace traceExpression ::= tracedTo ( ( identifier | - ) , eIdentifier , eIdentifier optional-attribute-values ) tracedTo(id,e2,e1,[ex:param="a"]) Here id is the optional trace identifier, e2 is an entity identifier, e1 is the identifier for an ancestor entity that e2 depends on,is influenced by, and [ex:param="a"] is the optional set of attributes.

The remaining examples show cases where some of the optionals are omitted.

tracedTo(e2,e1)
tracedTo(e2,e1,[ex:param="a"])
tracedTo(-,e2,e1)wasInfluencedBy(e2,e1)
wasInfluencedBy(e2,e1,[ex:param="a"])
wasInfluencedBy(id; e2,e1)

3.4 Component 4: Alternate EntitiesBundles

3.4.1 Bundle Constructor

[23] namedBundle ::= "bundle" identifier (namespaceDeclarations)? (expression)* "endBundle"

Named bundles cannot be nested because namedBundle is not an expression, and therefore cannot occurs inside another namedBundle.

Named bundles are self-contained: each identifier occuring in a named bundle, including the bundle identifier itself, must be interpreted with respect to the namespace declarations of that bundle. In other words, for every identifier with a prefix p within a named bundle, there must be a namespace declaration for p in this named bundled; for every identifier without prefix, there must be a default namespace declaration in this named bundled.

Example 28

bundle ex:author-view
  prefix ex  <http://example.org/>
  agent(ex:Paolo,   [ prov:type='prov:Person' ])
  agent(ex:Simon,   [ prov:type='prov:Person' ])
  //...
endBundle

Here ex:author-view is the name of the bundle.

3.4.2 Bundle Type

When described, a Bundle must be expressed as an entityExpression with attribute prov:type='prov:Bundle'.

3.5 Component 5: Alternate Entities

3.5.1 Alternate

[24] alternateExpression ::= alternateOf ( ::= "alternateOf" "(" eIdentifier , "," eIdentifier ) ")"

The following table summarizes how each constituent of a PROV-DM Alternate maps to a PROV-N syntax element.

Alternate	Non-Terminal

alternate1	`eIdentifier`
alternate2	`eIdentifier`

Example 29

alternateOf(tr:WD-prov-dm-20111215,ex:alternate-20111215)

Here tr:WD-prov-dm-20111215 is alternate for ex:alternate-20111215.

3.4.23.5.2 Specialization

[25] specializationExpression ::= specializationOf ( ::= "specializationOf" "(" eIdentifier , "," eIdentifier ) ")"

The following table summarizes how each constituent of a PROV-DM Specialization maps to a PROV-N syntax element.

Specialization	Non-Terminal

specificEntity	`eIdentifier`
generalEntity	`eIdentifier`

Example 30

specializationOf(tr:WD-prov-dm-20111215,tr:prov-dm)

Here tr:WD-prov-dm-20111215 is a specialization of tr:prov-dm.

3.5.3 Mention

Note: This feature is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-prov-comments@w3.org.

The expression Mention might be removed from PROV if implementation experience reveals problems with supporting this construct.

3.5 Component 5: Collections Grammar for collections may under go minor syntactic changes since it has not been implemented yet. In the productions in this section, nonterminals keyValuePairs and keySet are defined as follows. keyValuePairs ::= ( literal , eidentifier ) | ( literal , eidentifier ) , keyValuePairs keySet ::= literal | literal , keySet

[26] mentionExpression ::= "mentionOf" "(" eIdentifier "," eIdentifier "," bIdentifier ")"

The following table summarizes how each constituent of a PROV-DM Mention maps to a PROV-N syntax element.

Mention	Non-Terminal

specificEntity	`eIdentifier`
generalEntity	`eIdentifier`
bundle	`bIdentifier`

3.5.1 Insertion derivationByInsertionFromExpression ::= derivedByInsertionFrom ( identifier , cIdentifier , cIdentifier , { keyValuePairs } optional-attribute-values )

Example 31

 derivedByInsertionFrom(id, c1, c, {("k1", v1), ("k2", v2)}, [])  
    mention(ex:report1_as_in_b1, ex:report1, ex:b1)

Here idex:report1_as_in_b1 is the optional insertionan entity identifier, c1ex:report1 is the identifier for the collection after the insertion, c is the identifier for the collection before the insertion, {("k1", v1), ("k2", v2)} is the set of key-value pairs that have been inserted in c, and [] is the optional (empty) set of attributes. The remaining examples show cases where some of the optionals are omitted. derivedByInsertionFrom(c1, c, {("k1", v1), ("k2", v2)}) derivedByInsertionFrom(c1, c, {("k1", v1)}) derivedByInsertionFrom(c1, c, {("k1", v1), ("k2", v2)}, []) 3.5.2 Removal derivationByRemovalFromExpression ::= derivedByRemovalFrom ( identifier , cIdentifier , cIdentifier , { keySet } optional-attribute-values ) derivedByRemovalFrom(id, c3, c, {"k1", "k3"}, []) Here id is the optional removalan entity identifier, c1ex:b1 is the identifier for the collection after the removal, c is the identifier for the collection before the removal, {("k1", v1), ("k2", v2)} is the set of key-value pairs that have been removed from c, and [] is the optional (empty) set of attributes. a bundle

The remaining examples show cases where some of the optionals are omitted. derivedByRemovalFrom(c3, c1, {"k1", "k3"}) derivedByRemovalFrom(c3, c1, {"k1"}) derivedByRemovalFrom(c3, c1, {"k1", "k3"}, [])

3.5.3 Membership membershipExpression ::= isMemberOf ( identifier , cIdentifier , { keyValuePairs } optional-attribute-values )

memberOf(mid, c, {("k4", v4), ("k5", v5)}, []) Here mid is the optional membership identifier, c is the identifier for the collection whose membership is stated, {("k4", v4), ("k5", v5)} is the set of key-value pairs that are members of c, and [] is the optional (empty) set of attributes. The remaining examples show cases where some of the optionals are omitted. memberOf(c3, {("k4", v4), ("k5", v5)}) memberOf(c3, {("k4", v4)}) memberOf(c3, {("k4", v4), ("k5", v5)},[])

3.6 Component 6: AnnotationsCollections

3.6.1 NoteCollection

noteExpression ::=

PROV-N provides no dedicated syntax for Collection and EmptyCollection. Instead, a Collection or an EmptyCollection must be expressed as an entityExpression with attribute note ( identifier optional-attribute-values )prov:type='prov:Collection', or prov:type='prov:EmptyCollection', respectively.

note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])

3.6.2 AnnotationMembership

annotationExpression ::=

[27] membershipExpression ::= "hadMember" "(" cIdentifier "," eIdentifier ")"

The following table summarizes how each constituent of a PROV-DM Membership maps to a PROV-N syntax element.

Membership	Non-Terminal

collection	`cIdentifier`
entity	`eIdentifier`

Example 32

   hadMember(c, e1)   // c contained e1
   hadMember(c, e2)   // c contained e2

Here hasAnnotation ( identifier , nIdentifier ) hasAnnotation(tr:WD-prov-dm-20111215,ex2:n1) Here ex2:n1c is the identifier for a note of the entity identified bythe collection whose membership is stated, and (tr:WD-prov-dm-20111215. e1 and e2 are the entities that are members of collection c

3.7 Further Expressions

This section defines further expressions of PROV-N.

3.7.1 Namespace Declaration namespaceDeclarations ::= | defaultNamespaceDeclaration | namespaceDeclaration namespaceDeclaration namespaceDeclaration ::= prefix prefix IRI defaultNamespaceDeclaration ::= default IRI In PROV-N, the following prefixes are reserved: prov denotes the PROV namespace with URI http://www.w3.org/ns/prov# xsd denotes the XML Schema namespace with URI http://www.w3.org/2001/XMLSchema#. A PROV-N document must not redeclare prefixes prov and xsd. The following example declares three namespaces, one default, and two with explicit prefixes ex1 and ex2. container default <http://example.org/0/> prefix ex1 <http://example.org/1/> prefix ex2 <http://example.org/2/> ... end 3.7.2 Identifier

Various kinds of identifiers are used in productions.

[28]	`eIdentifier`	::=	`identifier`
[29]	`aIdentifier`	::=	`identifier`
[30]	`agIdentifier`	::=	`identifier`
[31]	`gIdentifier`	::=	`identifier`
[32]	`uIdentifier`	::=	`identifier`
[33]	`cIdentifier`	::=	`identifier`
[34]	`bIdentifier`	::=	`identifier`
[35]	`eIdentifierOrMarker`	::=	`( eIdentifier \| "-" )`
[36]	`aIdentifierOrMarker`	::=	`( aIdentifier \| "-" )`
[37]	`agIdentifierOrMarker`	::=	`( agIdentifier \| "-" )`
[38]	`gIdentifierOrMarker`	::=	`( gIdentifier \| "-" )`
[39]	`uIdentifierOrMarker`	::=	`( uIdentifier \| "-" )`
[40]	`identifier`	::=	`QUALIFIED_NAME`

A qualified name is a name subject to namespace interpretation. It consists of a namespace, denoted by an optional prefix, and a local name. The PROV data model stipulates that a qualified name can be mapped intoto an IRI by concatenating the IRI associated with the prefix and the local part. This section provides the exact details of this procedure for qualified names defined by PROV-N.

A qualified name's prefix is optional. If a prefix occurs in a qualified name, it refersthe prefix must refer to a namespace declared in a namespace declaration. In the absence of prefix, the qualified name refersbelongs to the default namespace.

identifier ::= qualifiedName eIdentifier ::= identifier (intended to denote an entity) aIdentifier ::= identifier (intended to denote an activity) agIdentifier ::= identifier (intended to denote an agent) gIdentifier::= identifier (intended to denote

A PROV-N qualified name (production QUALIFIED_NAME) has a generation) uIdentifier::= identifier (intended to denote a usage) nIdentifier::= identifier (intended to denote a note) cIdentifier::= identifier (intended to denote a collection) qualifiedName ::= prefix : localPart | : localPart prefix ::= a name without colon compatible with the NC_NAME productionmore permissive syntax then XML's QName [XML-NAMES] localPart ::= a name compatible with the reference production and SPARQL PrefixedName [RDFA-CORERDF-SPARQL-QUERY] ]. A QUALIFIED_NAME consists of a prefix and a local part. Prefixes follow the production PN_PREFIX defined by SPARQL [RDF-SPARQL-QUERY]. Local parts have to be conformant with PN_LOCAL, which extends the original SPARQL PN_LOCAL definition by allowing further characters (see PN_CHARS_OTHERS):

an extra set of characters commonly encountered in IRIs;
%-escaped characters (see PERCENT) to be interpreted as per Section 3.1. Mapping of IRIs to URIs in [RFC3987];
and \-escaped characters (see PN_CHARS_ESC).

Given that '=' (equal), ''' (single quote), '(' (left bracket), ')' (right bracket), ',' (comma), ':' (colon), ';' (semi-colon), '"' (double quote), '[' (left square bracket), ']' (right square bracket) are used by the PROV notation as delimiters, they are not allowed in local parts. Instead, among those characters, those that are permitted in SPARQL IRI_REF are also allowed in PN_LOCAL if they are escaped by the '\' (backslash character) as per production PN_CHARS_ESC. Furthermore, '.' (dot), ':' (colon), '-' (hyphen) can also be \-escaped.

A PROVPROV-N qualified name has a more permissive syntax then XML's QName [XML-NAMES] since it allows any syntax for its local part provided that the concatenation with the namespace results inQUALIFIED_NAME can be mapped to a valid IRI [IRI]. ] by concatenating the namespace denoted its local name PN_PREFIX to the local name PN_LOCAL, whose \-escaped characters have been unescaped by dropping the character '\' (backslash).

[61]	<`QUALIFIED_NAME`>	::=	`( PN_PREFIX ":" )? PN_LOCAL \| PN_PREFIX ":"`
[62]	<`PN_LOCAL`>	::=	`( PN_CHARS_U \| [0-9] \| PN_CHARS_OTHERS ) ( ( PN_CHARS \| "." \| PN_CHARS_OTHERS )* ( PN_CHARS \| PN_CHARS_OTHERS ) )?`
[63]	<`PN_CHARS_OTHERS`>	::=	`"/" \| "@" \| "~" \| "&" \| "+" \| "*" \| "?" \| "#" \| "$" \| "!" \| PERCENT \| PN_CHARS_ESC`
[64]	<`PN_CHARS_ESC`>	::=	`"\" ( "=" \| "'" \| "(" \| ")" \| "," \| "-" \| ":" \| ";" \| "[" \| "]" \| "." )`
[65]	<`PERCENT`>	::=	`"%" HEX HEX`
[66]	<`HEX`>	::=	`[0-9] \| [A-F] \| [a-f]`

Example 33

Examples of articles on the BBC Web site seen as entities.

containerbundle
  prefix bbc <http://www.bbc.co.uk/>
  prefix bbcNews <http://www.bbc.co.uk/news/>

  entity(bbc:)                          // bbc site itself
  entity(bbc:news/)                     // bbc news
  entity(bbc:news/world-asia-17507976)  // a given news article

  entity(bbcNews:)                      // an alternative way of referring to the bbc news site

endendBundle

Example 34

Examples of entities with declared and default namespace.

containerbundle
  default <http://example.org/2/>
  prefix ex <http://example.org/1/>

  entity(ex:a)     //  corresponds to IRI http://example.org/1/a
  entity(ex:a/)    //  corresponds to IRI http://example.org/1/a/
  entity(ex:a/b)   //  corresponds to IRI http://example.org/1/a/b
  entity(b)        //  corresponds to IRI http://example.org/2/b
  entity(ex:1234)  //  corresponds to IRI http://example.org/2/1234http://example.org/1/1234
  entity(4567)     //  corresponds to IRI http://example.org/2/4567
end
  entity(c/)       //  corresponds to IRI http://example.org/2/c/
  entity(ex:/)     //  corresponds to IRI http://example.org/1//
endBundle

Example 35

Examples of \-escaped characters.

bundle
  prefix ex <http://example.org/>
  default <http://example.org/default>

  entity(ex:foo?a\=1)            // corresponds to IRI http://example.org/foo?a=1
  entity(ex:\-)                  // corresponds to IRI http://example.org/-
  entity(ex:?fred\=fish%20soup)  // corresponds to IRI http://example.org/?fred=fish%20soup

  used(-;a1,e1,-)                // identifier not specified for usage  
  used(\-;a1,e1,-)               // usage identifier corresponds to http://example.org/default-
endBundle

Note:The productions for qualifiedNamethe terminals QUALIFIED_NAME and prefix PN_PREFIX are conflicting. Indeed, for a tokenizer operating independently of the parse tree, abc matches both QUALIFIED_NAME and PN_PREFIX. In the context of a namespaceDeclaration, a parsertokenizer should give precedence preference to the production for prefixPN_PREFIX.

We need to explicitly disallow '-' as first and only character of local part. Instead, it should be encoded as pct-encoded [RFC3987].

3.7.33.7.2 Attribute

[41] attribute ::= qualifiedName ::= QUALIFIED_NAME

The reserved attributes in the PROV namespace are the following. Their meaning is explained by [PROV-DM] (see Section 5.7.2: Attribute).

prov:label
prov:location
prov:role
prov:type
prov:value

3.7.43.7.3 Literal

Literal ::=

[42]	`literal`	::=	`typedLiteral \| convenienceNotation`
[43]	`typedLiteral`	::=	`STRING_LITERAL "%%" datatype`
[44]	`datatype`	::=	`QUALIFIED_NAME`

[45]	`convenienceNotation`	::=	`STRING_LITERAL (LANGTAG)? typedLiteral ::= quotedString %% \| INT_LITERAL \| QUALIFIED_NAME_LITERAL`
[67]	<`STRING_LITERAL`>	::=	`STRING_LITERAL2 \| STRING_LITERAL_LONG2`
[69]	<`INT_LITERAL`>	::=	`("-")? (DIGIT)+`
[71]	<`DIGIT`>	::=	`[0-9]`
[70]	<`QUALIFIED_NAME_LITERAL`>	::=	`"'" QUALIFIED_NAME "'"`

In production datatype datatype ::= qualifiedName listed in Table permitted-datatypes convenienceNotation ::= stringLiteral | intLiteral stringLiteral ::= quotedString quotedString ::=, the QUALIFIED_NAME is used to denote a finite sequence of characters in which " (#x22) and \ (#x5C) occur only in pairs of the form \" (#x5C, #x22) and \\ (#x5C, #x5C), enclosed in a pair of " (#x22) characters intLiteral ::= a finite-length non-empty sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-) PROV data type [PROV-DM].

The non terminals stringLiteral STRING_LITERAL, INT_LITERAL, and intLiteralQUALIFIED_NAME_LITERAL are syntactic sugar for quoted strings with datatype xsd:string and , xsd:int, and prov:QUALIFIED_NAME respectively.

In particular, a Literal may be an IRI-typed string (with datatype xsd:anyURI); such IRI has no specific interpretation in the context of PROV.

Permitted datatypes in literals xsd:decimal xsd:double xsd:dateTime xsd:integer xsd:float xsd:nonNegativeInteger xsd:string rdf:XMLLiteral xsd:nonPositiveIntegerxsd:normalizedString xsd:positiveInteger xsd:token xsd:negativeInteger xsd:language xsd:long xsd:Name xsd:int xsd:NCName xsd:short xsd:NMTOKEN xsd:byte xsd:boolean xsd:unsignedLong xsd:hexBinary xsd:unsignedInt xsd:base64Binary xsd:unsignedShortxsd:anyURI xsd:unsignedByte xsd:QName

Note:The productions for qualifiedNameterminals QUALIFIED_NAME and intLiteral INT_LITERAL are conflicting. Indeed, for a tokenizer operating independently of the parse tree, 1234 matches both INT_LITERAL and QUALIFIED_NAME (local name without prefix). In the context of a convenienceNotation, a tokenizer should give preference to the production INT_LITERAL.

Example 36

The following examples illustrate convenience notations.

The two following expressions are strings; if datatype is not specified, it is xsd:string.

  In the context"abc" %% xsd:string
  "abc"

The two following expressions are integers. For convenience, numbers, expressed as digits optionally preceded by a minus sign, can occur without quotes.

  "1234" %% xsd:integer
  1234
  "-1234" %% xsd:integer
  -1234

The two following expressions are qualified names. Values of a Literal, a parser should give precedence to the production for intLiteral. type qualified name can be conveniently expressed within single quotes.

Wouldn't it be useful to introduce a literal for a qualified name? Currenlty, we have to write: prov:type="ex:Programmer"

  "ex:value" %% xsd:QNameprov:QUALIFIED_NAME
  'ex:value'

to indicate that ex:Programmer should be interpreted as qualified name (QName). Instead, we could have a notation such as prov:type='ex:Programmer'

Example 37

The following examples respectively are the string "abc", the string (in French) "bonjour", the integer number 1, and the IRI "http://example.org/foo".

  "abc"
  "bonjour"@fr
  "1" %% xsd:integer
  "http://example.org/foo" %% xsd:anyURI

3.7.4.13.7.3.1 Reserved Type Values

The reserved type values in the PROV namespace are the following. Their meaning is defined [PROV-DM] (see Section 5.7.2.4: prov:type).

prov:Accountprov:Bundle
prov:Collection
prov:EmptyCollection
prov:Organization
prov:Person
prov:Plan
prov:PrimarySource
prov:Quotation
prov:Revision
prov:SoftwareAgent

prov:Person

prov:Organization

prov:Plan

prov:Collection

prov:EmptyCollection

Example 38

The entityagent ag is a person (type: prov:Person), whereas the entity pl is a plan (type: prov:Plan).

agent(ag,[prov:type="prov:Person" %% xsd:QName])
entity(pl,[prov:type="prov:Plan" %% xsd:QName])agent(ag,  [ prov:type='prov:Person' ])
entity(pl, [ prov:type='prov:Plan' ])

3.7.4.23.7.3.2 Time Values

Time instants are defined according to xsd:dateTime [XMLSCHEMA-2XMLSCHEMA11-2].

[46] time ::= DATETIME

Example 39

The third argument in the following usage expression is a time instance, namely 4pm on 2011-11-16.

used(ex:act2, ar3:0111, 2011-11-16T16:00:00)

3.7.4 Namespace Declaration

[47]	`namespaceDeclarations`	::=	`( defaultNamespaceDeclaration \| namespaceDeclaration ) (namespaceDeclaration)*`
[48]	`namespaceDeclaration`	::=	`"prefix" PN_PREFIX namespace`
[49]	`defaultNamespaceDeclaration`	::=	`"default" IRI_REF`
[50]	`namespace`	::=	`IRI_REF`

A namespaceDeclaration consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration belongs to this namespace. A defaultNamespaceDeclaration consists of a namespace. Every qualified name without prefix in the scope of this declaration belongs to this namespace. Scope of a declaration is specified as follows:

The scope of a namespace declaration directly occurring in a namedBundle is the namedBundle itself;
the scope of a namespace declaration directly occurring in a toplevel bundle is the toplevel bundle itself, except and namedBundle it may contain.

A set of namespace declarations namespaceDeclarations must not re-declare the same prefix.

A namespace declaration namespaceDeclaration must not declare prefixes prov and xsd (see Table 1 for their IRI).

Example 40

The following example declares three namespaces, one default, and two with explicit prefixes ex1 and ex2.

bundle
  default <http://example.org/0/>
  prefix ex1 <http://example.org/1/>
  prefix ex2 <http://example.org/2/>
...
endBundle

Example 41

In the following example, a toplevel bundle declares a default namespace and the occurrence of e001 directly occurring in the toplevel bundle refers to that namespace. A nested named bundle also declares a default namespace, but with a different IRI. In that named bundle, the occurrences of e001, including for the bundle name, refer to the latest default namespace.

bundle
  default <http://example.org/1/>
  entity(e001)                             // IRI: http://example.org/1/e001

  bundle e001                              // IRI: http://example.org/2/e001
    default <http://example.org/2/>
    entity(e001)                           // IRI: http://example.org/2/e001
  endBundle
endBundle

3.7.5 Summary of additional semantic rules

Some of the grammar productions allow for expressions that are syntactically correct, and yet according to [PROV-DM] they are not acceptable, because additional semantic rules are defined for those expressions. The following table provides a summary of such expressions along with examples of syntactically correct but unacceptable forms, and the additional semantic rules.

Summary of additional semantic rules for grammar productions
Production	Examples of syntactically correct expressions	Additional semantic rule

Generation expression	wasGeneratedBy(e2, -, -) wasGeneratedBy(-; e2, -, -)	At least one of id, activity, time, and attributes must be present.
Usage expression	used(a2, -, -) used(-; a2, -, -)	At least one of id, entity, time, and attributes must be present
Start expression	wasStartedBy(e2, -, -, -) wasStartedBy(-; e2, -, -, -)	At least one of id, trigger, starter, time, and attributes must be present
End expression	wasEndedBy(e2, -, -, -) wasEndedBy(-; e2, -, -, -)	At least one of id, trigger, ender, time, and attributes must be present
Invalidation expression	wasInvalidatedBy(e2, -, -) wasInvalidatedBy(-; e2, -, -)	At least one of id, activity, time, and attributes must be present
Association expression	wasAssociatedWith(a, -, -) wasAssociatedWith(-; a, -, -)	At least one of id, agent, plan, and attributes must be present

4. Expression ContainerToplevel Bundle

An expression containerA toplevel bundle is a house-keeping construct of PROV-N capable of packaging up PROV-N expressions and namespace declarations. An expression containerA toplevel bundle forms a self-contained package of provenance descriptions for the purpose of exchanging them. An expression containerA toplevel bundle may be used to package up PROV-N expressions in response to a request for the provenance of something ([PROV-AQ]).

Given its status of house keeping construct for the purpose of exchanging provenance expressions, ana toplevel bundle is not defined as a PROV-N expression container is not defined as a PROV-N (production expression (production expression).

An A toplevel bundle's text matches the bundle production.

[1] bundle ::= "bundle" (namespaceDeclarations)? (expression container, written container decls exprs endContainer in PROV-N,)* (namedBundle)* "endBundle"

A toplevel bundle contains:

namespaceDeclarations: a set decls of namespace declarations,declarations namespaceDeclarations, declaring namespaces and associated prefixes, which can be used in attributes and identifiers occurring inside exprs;
expressions: a non-empty set of expressions exprsmatching expression;
namedBundles: a set of namedBundle.

An expression container's text matches the expressionContainer production.Thus, named bundles can occur inside a toplevel bundle. Named bundles are self-contained: each identifier occuring in a named bundle, including the named bundle's identifier itself, must be interpreted with respect to the namespace declarations of that named bundle. In other words, named bundles should not inherit namespaces declarations from the toplevel bundle.

expressionContainer ::= container namespaceDeclarations expression endContainer

Example 42

The following containerbundle contains expressions related to the provenance of entity e2.

containerbundle
  default <http://anotherexample.org/>
  prefix ex <http://example.org/>

  entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", 
               ex:content="There was a lot of crime in London last month."])
  activity(a1, 2011-11-16T16:05:00, -,[prov:type="edit"])-, [prov:type="edit"])
  wasGeneratedBy(e2, a1, -, [ex:fct="save"])     
  wasAssociatedWith(a1, ag2, -, [prov:role="author"])
  agent(ag2, [ prov:type="prov:Person" %% xsd:QName,prov:type='prov:Person', ex:name="Bob" ])

endContainerendBundle

This container could for instance be returned as the result of a query to a provenance store for the provenance of entity e2 [PROV-AQ].

5. AccountExtensibility

The PROV data model has introducedis extensible by means of attributes prov:type and prov:role allowing subtyping of expressions. For some applications, novel syntax may also be convenient. Hence, the normative requirements are as follow.

PROV-N compliant parsers must be able to parse expressions matching the extensibilityExpression production defined below.
As PROV provides no definition for these expressions, PROV compliant implementations may ignore these expressions.
Extensions to PROV and PROV-N may specify more specific productions and interpretations for these expressions, which applications may adopt to follow.

[51]	`extensibilityExpression`	::=	`QUALIFIED_NAME "(" optionalIdentifier extensibilityArgument ( "," extensibilityArgument )* optionalAttributeValuePairs ")"`
[52]	`extensibilityArgument`	::=	`( identifierOrMarker \| literal \| time \| extensibilityExpression \| extensibilityTuple )`
[53]	`extensibilityTuple`	::=	`"{" extensibilityArgument ( "," extensibilityArgument )* "}" \| "(" extensibilityArgument ( "," extensibilityArgument )* ")"`

Expressions compatible with the extensibilityExpression production follow a notiongeneral form of account byfunctional syntax, in which the predicate must be a set qualifiedName with a non-empty prefix.

Example 43

Collections are sets of provenance descriptionsentities, whose membership can be bundled up and named.expressed using the hadMember relation. The PROV data model assumes the existencefollowing example shows how one can express membership for an extension of mechanismsCollections, namely sets of key-value pairs. The notation is a variation of that used for Collections membership, allowing multiple member elements to implement accounts, but such mechanisms remain outside its scope.be declared, and in which the elements are pairs. The name of the relation is qualified with the extension-specific namespace http://example.org/dictionaries.

  Itprefix dictExt <http://example.org/dictionaries>
  dictExt:hadMembers(mId; d, {("k1",e1), ("k2",e2), ("k3",e3)}, [])

Note that the generic extensibilityExpression production above allows for alternative notations to be used for expressing membership, if the designers of the extensions so desire. Here is suggestedan alternate syntax that specific serializations may offer solutions to name bundles of descriptions. Given that the primary motivation for PROV-N is to provide a notation aimed at human consumption, it is therefore appropriate to introduce a notation for accounts, which would include an account name and a bundle of expressions. An account, written account(id, exprs) in PROV-N, contains: id: an identifierconsistent with the productions:

  that identifies this account;
expressions: a set exprs of expressions;


In PROV-N, an account's text matches the accountExpression production of the grammar.


accountExpression ::=  
accountprefix dictExt <http://example.org/dictionaries>
  dictExt:hadMembers(mid; d, dictExt:set(dictExt:pair("k1",e1), 
                                         dictExt:pair("k2",e2), 
                                         dictExt:pair("k3",e3)), 
                            [dictExt:uniqueKeys="true"]) 
( 
identifier 
, 

expression 
)

It is also useful to package up one or more account expressions in an expression container, for interchange purpose. Hence, expressionContainer is revised as follows. expressionContainer ::= container namespaceDeclarations expression endContainer | container namespaceDeclarations accountExpression endContainer

The following container container prefix ex <http://example.org/> account(ex:acc1,...) account(ex:acc2,...) endContainer illustrates how two accounts with identifiers ex:acc1 and ex:acc2 can be returned in a PROV-N serialization of the provenance of something. The following container container prefix ex <http://example.org/> ... account(ex:acc1, entity(tr:WD-prov-dm-20111018, [ prov:type="pr:RecsWD" %% xsd:QName ]) entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ]) ... wasAssociatedWith(ex:pub2, w3:Consortium, pr:rec-advance)) account(ex:acc2, entity(ex:acc1, [prov:type="prov:Account" %% xsd:QName ]) wasAttributedTo(ex1:acc1, w3:Consortium)) endContainer illustrates a first account, with identifier ex:acc1, containing expressions describing the provenance of the technical report tr:WD-prov-dm-20111215, and a second account ex:acc2, describing the provenance of the first. In account ex:acc2, ex:acc1 is the identifier of an entity of type prov:Account.

6. Media Type

The media type of PROV-N is text/prov-ntext/provenance-notation. The content encoding of PROV-N content is UTF-8.

Contact:: Ivan Herman
See also:: http://www.w3.org/2002/06/registering-mediatype forHow to Register an Interneta Media Type for a W3C Spec.Specification; Internet Media Type registration, consistency of use
TAG Finding 3 June 2002 (Revised 4 September 2002)

The Internet Media Type / MIME Type for PROV-N is "text/provenance-notation".

It is recommended that PROV-N files have the extension ".provn" (all lowercase) on all platforms.

It is recommended that PROV-N files stored on Macintosh HFS file systems be given a file type of "TEXT".

This information that follows is being submitted to the IESG for review, approval, and registration with IANA.

Type name:: text
Subtype name:: provenance-notation
Required parameters:: None
Optional parameters:: charset — this parameter is mandatory. The value of charset is always UTF-8.
Encoding considerations:: The syntax of PROV-N is expressed over code points in Unicode [UNICODE5]. The encoding is always UTF-8 [UTF-8].; Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]
Security considerations:: PROV-N is a general-purpose language for describing the provenance of things; applications may evaluate given data to infer more descriptions or to dereference URIs, invoking the security 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-N is used to express the provenance of arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on PROV-N documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information.; PROV-N 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 security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup.; PROV-N is a language for describing the provenance of things, and therefore a PROV-N document is metadata for other resources. Untrusted PROV-N documents may mislead its consumers by indicating that a third-party resource has a reputable lineage, when it has not. Provenance of PROV-N document should be sought.; PROV-N uses qualified names mappeable to IRIs as term identifiers. Applications interpreting data expressed in PROV-N should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7.; 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 Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.
Interoperability considerations:: There are no known interoperability issues.
Published specification:: PROV-N: The Provenance Notation, Moreau, Missier, (eds), Cheney, Soiland-Reyes http://www.w3.org/TR/prov-n/
Applications which use this media type:: No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data.
Additional information:
Magic number(s):: PROV-N documents may have the strings 'bundle' near the beginning of the document.
File extension(s):: ".provn"
Base URI:: There are no constructs in the PROV-N Syntax to change the Base IRI.
Macintosh file type code(s):: "TEXT"
Person & email address to contact for further information:: public-prov-comments@w3.org
Intended usage:: COMMON
Restrictions on usage:: None
Author/Change controller:: The PROV-N specification is the product of the World Wide Web Consortium's PROV Working Group. The W3C has change control over this specification.

A. Acknowledgements

WG membership to be listed here. This document has been produced by the PROV Working Group, and its contents reflect extensive discussion within the Working Group as a whole.

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).

B. References

B.1 Normative references

[IRI]: M. Duerst, M. Suignard. Internationalized Resource Identifiers (IRI). January 2005. Internet RFC 3987. URL: http://www.ietf.org/rfc/rfc3987.txt
[RDF-SPARQL-QUERY]: Graham Klyne; Jeremy J. Carroll. Andy Seaborne; Eric Prud'hommeaux. Resource Description Framework (RDF): Concepts and Abstract Syntax.SPARQL Query Language for RDF. 10 February 2004.15 January 2008. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-concepts-20040210 [RDFA-CORE]Shane McCarron; et al. RDFa Core 1.1: Syntax and processing rules for embedding RDF through attributes. 13 March 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/2012/CR-rdfa-core-20120313/http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115
[RFC2119]: S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[RFC3023]: M. Murata; S. St.Laurent; D. Kohn. XML Media Types January 2001. Internet RFC 3023. URL: http://www.ietf.org/rfc/rfc3023.txt
[RFC3986]: T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet RFC 3986. URL: http://www.ietf.org/rfc/rfc3986.txt
[RFC3987]: M. Dürst; M. Suignard. Internationalized Resource Identifiers (IRIs). January 2005. Internet RFC 3987. URL: http://www.ietf.org/rfc/rfc3987.txt
[URI]: T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. Internet RFC 3986. URL: http://www.ietf.org/rfc/rfc3986.txt
[UTF-8]: F. Yergeau. UTF-8, a transformation format of ISO 10646. IETF RFC 3629. November 2003. URL: http://www.ietf.org/rfc/rfc3629.txt
[XML-NAMES]: Richard Tobin; et al. Namespaces in XML 1.0 (Third Edition). 8 December 2009. W3C Recommendation. URL: http://www.w3.org/TR/2009/REC-xml-names-20091208/
[XML11]: Paul V. Biron; Ashok Malhotra. Eve Maler; et al. Extensible Markup Language (XML) 1.1 (Second Edition). 16 August 2006. W3C Recommendation. URL: http://www.w3.org/TR/2006/REC-xml11-20060816
[XMLSCHEMA11-2]: Henry S. Thompson; et al. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes Second Edition.Datatypes. 28 October 2004.5 April 2012. W3C Recommendation.Recommendation URL: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/

B.2 Informative references

[PROV-AQ]: Graham Klyne and Paul Groth (eds.) Luc Moreau, Olaf Hartig, Yogesh Simmhan, James Meyers, Timothy Lebo, Khalid Belhajjame, and Simon Miles Provenance Access and Query. 2011, Working Draft. URL: http://www.w3.org/TR/prov-aq/
[PROV-CONSTRAINTS]: James Cheney, Paolo Missier, and Luc Moreau (eds.)Constraints of the Prov Data Model. 2012, Working Draft. URL: http://www.w3.org/TR/prov-constraints/
[PROV-DM]: Luc Moreau and Paolo Missier (eds.) Khalid Belhajjame, Reza B'Far, Stephen Cresswell, Yolanda Gil, Paul Groth, Graham Klyne, Jim McCusker, Simon Miles, James Myers, Satya Sahoo, and Curt TilmesPROV-DM: The PROV Data Model. 2012, Working Draft. URL: http://www.w3.org/TR/prov-dm/
[PROV-RDF]: James CheneyPROV-RDF Mapping 2012, Working in Progress. URL: http://www.w3.org/2011/prov/wiki/ProvRDF
[PROV-SEM]: James Cheney Formal Semantics Strawman. 2011, Work in progress. URL: http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman
[PROV-XML]: James Cheney PROV-XML Mapping 2012, Working in Progress. URL: http://www.w3.org/2011/prov/wiki/ProvXML
[UNICODE5]: The Unicode Consortium. The Unicode Standard, Version 5.1.0. Addison-Wesley. 2007. ISBN 0-321-48091-0. URL: http://www.unicode.org/versions/Unicode5.1.0/
[UNISEC]: Mark Davis and Michel Suignard. Unicode Security Considerations. 4 August 2010. URL: http://www.unicode.org/reports/tr36/

PROV-N: The Provenance Notation

W3C Working Draft 03 May24 July 2012

Abstract

Status of This Document

Last Call

PROV Family of Specifications

How to read the PROV Family of Specifications

Table of Contents

1. Introduction

1.1 Purpose of this Document and target audienceTarget Audience

1.2 Structure of this Document

1.3 Notational Conventions

2. General grammar considerations

2.1 Functional-style Syntax

2.2 EBNF Grammar

2.3 Main Productions

2.32.4 Optional terms in expressions

2.42.5 Identifiers and attributes

2.6 Comments

3. PROV-N Productions per Component

3.1 Component 1: Entities and Activities

3.1.1 Entity

3.1.2 Activity

3.1.3 Generation

3.1.4 Usage

3.1.5 Communication

3.1.6 Start

3.1.63.1.7 End

3.1.73.1.8 Invalidation

3.2 Component 2: Agents and ResponsibilityDerivations

3.2.1 AgentDerivation

3.2.2 Revision

3.2.3 AssociationQuotation

3.2.4 ResponsibilityPrimary Source

3.3 Component 3: DerivationsAgents, Responsibility, and Influence

3.3.1 DerivationAgent

3.3.2 Attribution

3.3.3 Association

3.3.4 Delegation

3.3.5 Influence

3.4 Component 4: Alternate EntitiesBundles

3.4.1 Bundle Constructor

3.4.2 Bundle Type

3.5 Component 5: Alternate Entities

3.5.1 Alternate

3.4.23.5.2 Specialization

3.5.3 Mention

3.6 Component 6: AnnotationsCollections

3.6.1 NoteCollection

3.6.2 AnnotationMembership

3.7 Further Expressions

3.7.33.7.2 Attribute

3.7.43.7.3 Literal

3.7.4.13.7.3.1 Reserved Type Values

3.7.4.23.7.3.2 Time Values

3.7.4 Namespace Declaration

3.7.5 Summary of additional semantic rules

4. Expression ContainerToplevel Bundle

5. AccountExtensibility

6. Media Type

A. Acknowledgements

B. References

B.1 Normative references

B.2 Informative references