Entity

In PROV-DM, an entity expression is a representation of an identifiable characterized thing.

In PROV-ASN, an entity expression's text matches the entityExpression production of the grammar defined in this specification document.

An instance of an entity expression, noted entity(id, [ attr1=val1, ...]) in PROV-ASN:

• contains an identifier id identifying a characterized thing;
• contains a set of attribute-value pairs [ attr1=val1, ...], representing this characterized thing's situation in the world.

The assertion of an instance of an entity expression, entity(id, [ attr1=val1, ...]), states, from a given asserter's viewpoint, the existence of an identifiable characterized thing, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two events in the world.

The following entity assertion,

entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])

• If an asserter wishes to characterize a thing with the same attribute-value pairs over several intervals, then they are required to assert multiple entity expressions, each with its own identifier (so as to allow potential dependencies between the various entity expressions to be expressed).
• There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.
• A characterization interval may collapse into a single instant.
• An entity assertion is about a characterized thing, whose situation in the world may be variant. An entity assertion is made at a particular point and is invariant, in the sense that its attributes are assigned a value as part of that assertion.
• Activities are not represented by entities, but instead by process executions, as explained below.

Process Execution

In PROV-DM, a process execution expression is a representation an identifiable activity, which performs a piece of work.

In PROV-ASN, a process execution expression's text matches the processExecutionExpression production of the grammar defined in this specification document.

The activity that a process execution expression is a representation of has a duration, delimited by its start and its end events; hence, it occurs over an interval delimited by two events. However, a process execution expression need not mention time information, nor duration, because they may not be known.

Such start and end times constitute attributes of an activity, where the interpretation of attribute in the context of a process execution expression is the same as the interpretation of attribute for entity expression: a process execution expression's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.

An instance of a process execution expression, written processExecution(id, rl, st, et, [ attr1=val1, ...]) in PROV-ASN:

• contains an identifier id;
• MAY contain a recipe link rl, which consists of a domain specific description of the activity;
• MAY contain a start time st;
• MAY contain an end time et;
• contains a set of attribute-value pairs [ attr1=val1, ...], representing other attributes of this activity that hold for its whole duration.

The following process execution assertion

processExecution(pe1,add-crime-in-london,t+1,t+1+epsilon,[host="server.example.org",type="app:edit"])

identified by identifier id, states the existence of an activity with recipe link add-crime-in-london, start time t+1, and end time t+1+epsilon, running on host server.example.org, and of type edit (declared in some namespace with prefix app). The attribute host is application specific, but MUST hold for the duration of activity. The attribute type is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.

The mere existence of a process execution assertion entails some event ordering in the world, since the start event precedes the end event. This is expressed by constraint start-precedes-end.

A process execution expression is not an entity expression. Indeed, an entity expression represents a thing that exists in full at any point in its characterization interval, persists during this interval, and preserves the characteristics that makes it identifiable. Alternatively, an activity in something that happens, unfolds or develops through time, but is typically not identifiable by the characteristics it exhibits at any point during its duration.

Agent

An agent expression is a representation of a characterized thing capable of activity.

In PROV-ASN, an agent expression's text matches the agentExpression production of the grammar defined in this specification document.

An agent expression, written agent(e) in PROV-ASN, refers to an entity expression denoted by identifier e and representing the characterized thing capable of activity.

For a characterized thing, one can assert an agent expression or alternatively, one can infer an agent expression by involvement in an activity represented by a process execution expression.

With the following assertions,

entity(e1, [employee="1234", name="Alice"])  and agent(e1)

entity(e2) and wasControlledBy(pe,e2,qualifier(role="author"))

the entity expression identified by e1 is accompanied by an explicit assertion of an agent expression, and this assertion holds irrespective of process executions it may be involved in. On the other hand, from the entity expression identified by e2, one can infer an agent expression, as per the following inference.

Annotation

An annotation expression is a set of name-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.

In PROV-ASN, an annotation expression's text matches the annotationExpression production of the grammar defined in this specification document.

A separate PROV-DM expression is used to associate an annotation with an expression (see Section on annotation association). A given annotation may be associated with multiple expressions.

The following annotation expression

annotation(ann1,[color="bue", screenX=20, screenY=30])

consists of a list of application-specific name-value pairs, intended to help the rendering of the expression it is associated with, by specifying its color and its position on the screen. In this example, these name-value pairs do not constitute a representation of something in the world; they are just used to help render provenance.

Name-value pairs occurring in annotations differ from attribute-value pairs (occurring in entity expressions and process execution expressions). Attribute-value pairs MUST be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity expression) or the activity duration (for process execution expressions). It is OPTIONAL for name-value pairs to be representations of something in the world. If they are a representation of something in the world, then it MAY change value for the corresponding duration. If name-value pairs are a representation of something in the world that does not change, they are not regarded as determining characteristics of a characterized thing or activity, for the purpose of provenance. Indeed, it is not expected that provenance would contain an explanation for these attribute-values.

Generation

In PROV-DM, a generation expression is a representation of a world event, the creation of a new characterized thing by an activity. This characterized thing did not exist before creation. The representation of this invent encompasses a description of the modalities of generation of this thing by this activity.

In PROV-ASN, a generation expression's text matches the generationExpression production of the grammar defined in this specification document.

An instance of a generation expression, written wasGeneratedBy(e,pe,q,t) in PROV-ASN:

• contains an identifier e identifying an entity expression that represents the characterized thing that is created;
• contain an identifier pe identifying a process execution expression that represents the activity that creates the characterized thing;
• contains a generationQualifier q that describes the modalities of generation of this thing by this activity;
• MAY contain a "generation time" t, the time at which the characterized thing was created.

The following generation assertions

  wasGeneratedBy(e1,pe1,qualifier(port="p1", order=1),t1)
  wasGeneratedBy(e2,pe1,qualifier(port="p1", order=2),t2)

state the existence of two events in the world (with respective times t1 and t2), at which new characterized things, represented by entity expressions identified by e1 and e2, are created by an activity, itself represented by a process execution expression identified by pe1. The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of port and order in these expressions are application specific.

A given entity expression can be referred to in a single generation expression in the scope of a given account. The rationale for this constraint is as follows. If two process executions sequentially set different values to some attribute by means of two different generate events, then they generate distinct entities. Alternatively, for two process executions to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single process execution. This unicity constraint is formalized as follows.

Use

In PROV-DM, a use expression is a representation of a world event: the consumption of a characterized thing by an activity. The representation includes a description of the modalities of use of this thing by this activity.

In PROV-ASN, a use expression's text matches the useExpression production of the grammar defined in this specification document.

An instance of a use expression, written used(pe,e,q,t) in PROV-ASN:

• refers to a process execution expression identified by pe, which represents the consuming activity;
• refers to an entity expression identified by e, which represents the characterized thing that is consumed;
• contains a useQualifier q, which describes the modalities of use of this thing by this activity;
• MAY contain a "use time" t, the time at which the characterized thing was used.

The following use assertions

  used(pe1,e1,qualifier(parameter="p1"),t1)
  used(pe1,e2,qualifier(parameter="p2"),t2)

state that the activity, represented by the process execution expression identified by pe1, consumed two characterized things, represented by entity expressions identified by e1 and e2, at times t1 and t2, respectively; the first one was found as the value of parameter p1, whereas the second was found as value of parameter p2. The semantics of parameter in these expressions is application specific.

A reference to a given entity expression MAY appear in multiple use expressions that share a given process execution expression identifier. If one wants to annotate a use edge expression or if one wants to express a pe-linked-derivationExpression referring to this entity and process execution expressions, the qualifier occuring in this use assertion MUST be unique among the qualifiers qualifiying use expressions for this process execution expression.

Derivation

In PROV-DM, a derivation expression is a representation that some characterized thing is transformed from, created from, or affected by another characterized thing in the world.

PROV-DM offers two different forms of derivation expressions. The first one is tightly connected to the notion of activity (represented by a process execution expression), whereas the second one is not. The first kind of assertion is particularly suitable for asserters who have an intimate knowledge of activities, is more prescriptive, but offers a more precise description of derivation, whereas the second does not put such a requirement on the asserter, and allows a less precise description of derivation to be formulated. Both expressions need to be asserted by asserters, since PROV-DM does not provide the means to infer them; however, from these assertions, further derivations can be inferred by transitive closure.

In PROV-ASN, a derivation expression's text matches the derivationExpression production of the grammar defined in this specification document.

The three kinds of derivation expressions are successively introduced.

wasDerivedFrom(e5,e3,pe4,qualifier(channel="out"),qualifier(channel="in"))
wasDerivedFrom(e3,e2)

                         -------------   e1
 --------------------------------------- e2
    -------------                        e3

Control

A control expression is a representation of the involvement of characterized thing (represented as an agent expression or an entity expression) in an activity, which is represented by a process execution expression; a control qualifier qualifies this involvement.

In PROV-ASN, a control expression's text matches the controlExpression production of the grammar defined in this specification document.

An instance of a control expression, written wasControlledBy(pe,ag,q) in PROV-ASN:

• contains an identifier pe denoting a process execution expression, representing the controlled activity;
• refers to an agent expression or an entity expression identified by ag, representing the controlling characterized thing;
• contains a qualifier q, qualifying the involvement of the thing in the activity.

The following control assertion

wasControlledBy(pe3,a4,qualifier[role="author"])

states that the activity, represented by the process execution expression denoted by pe3 saw the involvement of a characterized thing, represented by entity expression denoted by a4 in the capacity of author. This specification reserves the qualifier name role (see Section Qualifier) to denote the function of a characterized thing with respect to an activity.

Complementarity

A complementarity expression is a relationship between two characterized things stated to have compatible characterization over some continuous interval between two events.

The rationale for introducing this relationship is that in general, at any given time, for a thing in the world, there may be multiple ways of characterizing it, and hence multiple representations can be asserted by different asserters. In the example that follows, suppose thing "Royal Society" is represented by two asserters, each using a different set of attributes. If the asserters agree that both representations refer to "The Royal Society", the question of whether any correspondence can be established between the two representations arises naturally. This is particularly relevant when (a) the sets of attributes used by the two representations overlap partially, or (b) when one set is subsumed by the other. In both these cases, we have a situation where each of the two asserters has a partial view of "The Royal Society", and establishing a correspondence between them on the shared attributes is beneficial, as in case (a) each of the two representation complements the other, and in case (b) one of the two (that with the additional attributes) complements the other.

This intuition is made more precise by considering the entities that form the representations of characterized things at a certain point in time. An entity expression represents, by means of attribute-value pairs, a thing and its situation in the world, which remain constant over a characterization interval. As soon as the thing's situation changes, this marks the end of the characterization interval for the entity expression representing it. The thing's novel situation is represented by an attribute with a new value, or an entirely different set of attribute-value pairs, embodied in another entity expression, with a new characterization interval. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two characterized things, we can hope to establish correspondences amongst the entity expressions that represent them at various points along that events line. The figure below illustrates this intuition.

Relation complement-of between two entity expressions is intended to capture these correspondences, as follows. Suppose entity expressions A and B share a set P of attributes, and each of them has other attributes in addition to P. If the values assigned to each attribute in P are compatible between A and B, then we say that A is-complement-of B, and B is-complement-of A, in a symmetrical fashion. In the particular case where the set P of attributes of B is a strict superset of A's attributes, then we say that B is-complement-of A, but in this case the opposite does not hold. In this case, the relation is not symmetric. (as a special case, A and B may not share any attributes at all, and yet the asserters may still stipulate that they are representing the same thing "Royal Society". The symmetric relation may hold trivially in this case).

The term compatible used above means that a mapping can be established amongst the values of attributes in P and found in the two entity expession. This generalizes to the case where attribute sets P1 and P2 of A, and B, respectively, are not identical but they can be mapped to one another. The simplest case is the identity mapping, in which A and B share attribute set P, and furthermore the values assigned to attributes in P match exactly.

It is important to note that the relation holds only for the characterization intervals of the entity expessions involved As soon as one attribute changes value in one of them, new correspondences need to be found amongst the new entities. Thus, the relation has a validity span that can be expressed in terms of the event lines of the thing.

In PROV-ASN, a complementarity expression's text matches the complementarityExpression production of the grammar defined in this specification document.

An instance of a complementarity expression is written wasComplementOf(e2,e1), where e1 and e2 are two identifiers denoting entity expressions.

entity(rs,[created="1870"])

entity(rs_l1,[location="loc2"])
entity(rs_l2,[location="The Mall"])

entity(rs_m1,[membership="250", year="1900"])
entity(rs_m2,[membership="300", year="1945"])
entity(rs_m3,[membership="270",  year="2010"])

wasComplementOf(rs_m3, rs_l2)
wasComplementOf(rs_m2, rs_l1)
wasComplementOf(rs_m2, rs_l2)
wasComplementOf(rs_m1, rs_l1)

wasComplementOf(rs_m3, rs)
wasComplementOf(rs_m2, rs)
wasComplementOf(rs_m1, rs)
wasComplementOf(rs_l1, rs)
wasComplementOf(rs_l2, rs)

The complementariy relation is not transitive. Let us consider identifiers e1, e2, and e3 identifying three entity expressions such that wasComplementOf(e3,e2) and wasComplementOf(e2,e1) hold. The expression wasComplementOf(e3,e1) may not hold because the characterization intervals of the denoted entity expressions may not overlap.

Ordering of Process Executions

Revision

A revision expression is a representation of the creation of a characterized thing considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who represents someone in the world who takes responsibility for declaring that the former is variant of the latter.

In PROV-ASN, a revision expression's text matches the revisionExpression production of the grammar defined in this specification document.

An instance of a revision expression, written wasRevisionOf(e2,e1,ag) in PROV-ASN:

• contains an identifier e2 identifying an entity that represents a newer version of a thing;
• contains an identifier e1 identifying an entity that represents an older version of a thing;
• MAY refer to a responsible agent with identifier ag.

A revision expression can only be asserted, since it needs to include a reference to an agent who represents someone in the real world who bears responsibility for declaring a variant of a thing. However, it needs to satisfy the following constraint, linking the two entity expressions by a derivation, and stating them to be a complement of a third entity expression.

wasRevisionOf is a strict sub-relation of wasEventuallyDerivedDerivedFrom since two entities e2 and e1 may satisfy wasEventuallyDerivedDerivedFrom(e2,e1) without being a variant of each other.

The following revision assertion

wasRevisionOf(e3,e2,a4)

states that the document represented by entity expression identified by e3 is declared to be revision of document represented by entity expression identified by e2 by agent representy by entity expression denoted by a4.

Participation

A participation expression is a representation of the involvement of a characterized thing in an activity. A participation expression can be asserted or inferred.

In PROV-ASN, a participation expression's text matches the participationExpression production of the grammar defined in this specification document.

An instance of a participation expression, written hadParticipant(pe,e) in PROV-ASN:

• contains to identifier pe identifying a process execution expression representing an activity;
• contains an identifier e identifying an entity expression, which is a representation of a characterized thing involved in this activity.

A thing's participation in an activity can be by direct use or direct control. But also, if a thing and situation are characterized in two complementary manners (and are represented by two entity expressions related by isComplementOf), if one of them participates in an activity, so does the other. The following captures the definition of participation.

Annotation Association

An annotation association expression establishes a link between an identifiable PROV-DM expression and an annotation expression referred to by its identifier. Multiple annotation expressions can be associated with a given PROV-DM expression; symmetrically, multiple PROV-DM expressions can be associated with a given annotation expression. Since annotation expressions have identifiers, they can also be annotated. The annotation mechanism (with annotation expression and the annotation association expression) forms a key aspect of the extensibility mechanism of PROV-DM (see extensibility section).

In PROV-ASN, an annotation expression's text matches the annotationExpression production of the grammar defined in this specification document.

Since relations do not have identifiers but can be annotated, a relationIdentification mechanism is provided allowing the constituents of relations to be listed so as to identify relations.

The interpretation of annotations is application-specific. See Section Annotation for a discussion of the difference between attributes and annotations.

The following expressions

entity(e1,[type="document"])
entity(e2,[type="document"])
processExecution(pe,transform,t1,t2,[])
used(pe,e1,qualifier(file="stdin"))
wasGeneratedBy(e2, pe, qualifier(file="stdout"))

annotation(ann1,[icon="doc.png"])
hasAnnotation(e1,ann1)
hasAnnotation(e2,ann1)

annotation(ann2,[style="dotted"])
hasAnnotation(relation(pe,e1,qualifier(file="stdin")),ann2)

assert the existence of two documents in the world (attribute-value pair: type="document") represented by entity expressions identified by e1 and e2, and annotate these expressions with an annotation indicating that the icon (an application specific way of rendering provenance) is doc.png. It also asserts a process execution, its use of the first entity, and its generation of the second entity. The used relation is annotated with a style (an application specific way of rendering this edge graphically).

Account

In PROV-DM, an account expression is a wrapper of expressions with a dual purpose:

• It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;
• It provides a scoping mechanism for expression identifiers and for some contraints (such as generation-unicity and derivation-use).

In PROV-ASN, an account expression's text matches the accountExpression production of the grammar defined in this specification document.

An instance of an account expression, written account(id, uri, exprs) in PROV-ASN:

• contains an identifier id to identify this account;
• contains an asserter identified by URI denoted by uri;
• contains a set of provenance expressions denoted by exprs.

The following account expression

account(acc0,
        http://example.org/asserter, 
          entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])
          ...
          wasDerivedFrom(e2,e1)
          ...
          processExecution(pe0,create-file,t)
          ...
          wasGeneratedBy(e0,pe0,qualifier())     
          ...
          wasControlledBy(pe4,a5, qualifier(role="communicator"))  )

contains the set of provenance expressions of section example-prov-asn-encoding, is asserted by agent http://example.org/asserter, and is identified by identifier acc0.

Account expressions constitue a scope for identifiers. An identifier within the scope of an account is intended to denote a single expression. However, nothing prevents an asserter from asserting an account containing, for example, multiple entity expressions with a same identifier but different attribute-values. In that case, they should be understood as a single entity expression with this identifier and the union of all attributes values, as formalized in identified-entity-in-account.

Whilst constraint identified-entity-in-account specifies how to understand multiple entity expressions with a same identifier within a given account, it does not guarantee that the entity expression formed with the union of all attribute-value pairs is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity expression, as illustrated by the following example.

In the following account expression, we find two entity expressions with a same identifier e.

account(acc1,
        http://example.org/id,
          entity(e,[type="person",age=20])
          entity(e,[type="person",age=30])
          ...)

Application of identified-entity-in-account results in an entity expression containing the attribute-value pairs age=20 and age=30. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific.

Account expressions can be nested since an account expression can occur among the expressions being wrapped by another account.

An account is said to be well-formed if it satisfies the constraints generation-unicity and derivation-use.

The union of two accounts is another account, containing the unions of their respective expressions, where expressions with a same identifier should be understood according to constraint identified-entity-in-account. Well-formed accounts are not closed under union because the constraint generation-unicity may no longer be satisfied in the resulting union.

Indeed, let us consider another account expression

account(acc2,
        http://example.org/asserter2, 
          entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])
          ...
          processExecution(pe1,create-file,t1)
          ...
          wasGeneratedBy(e0,pe1,qualifier(fct="create"))     
          ... )

with identifier acc2, containing assertions by asserter by http://example.org/asserter2 stating that thing represented by entity expression identified by e0 was generated by an activity represented by process execution expression identified by pe1 instead of pe0 in the previous account acc0. If accounts acc0 and acc2 are merged together, the resulting set of expressions violates generation-unicity.

Account expressions constitue a scope for identifiers. Since accounts can be nested, their scope can also be nested; thus, the scope of identifiers should be understood in the context of such nested scopes. When an expression with an identifier occurs directly within an account, then its identifier denotes this expression in the scope of this account, except in sub-accounts where expressions with the same identifier occur.

The following account expression is inspired from section example-prov-asn-encoding. This account, identified by acc3, declares entity expression identified by e0, which is being referred to in the nested account acc4. The scope of identifier e0 is account acc3, including subaccount acc4.

account(acc3,
        http://example.org/asserter1, 
          entity(e0, [ type="File", location="/shared/crime.txt", creator="Alice" ])
          processExecution(pe0,create-file,t)
          wasGeneratedBy(e0,pe0,qualifier())  
          account(acc4,
                 http://example.org/asserter2,
                 entity(e1, [ type="File", location="/shared/crime.txt", creator="Alice", content="" ])
                 processExecution(pe0,copy-file,t)
                 wasGeneratedBy(e1,pe0,qualifier(fct="create"))
                 isComplement(e1,e0)))

Alternatively, a process execution expression identified by pe0 occurs in each of the two accounts. Therefore, each process execution expression is asserted in a separate scope, and therefore may represent different activities in the world.

The account expression is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. How general meta-information is expressed is beyond the scope of this specification, except for asserters.

Provenance Container

A provenance container is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM expressions. A provenance container is not an expression, but can be exploited to return assertions in response to a request for the provenance of something ([[PROV-PAQ]]).

In PROV-ASN, a provenance container's text matches the provenanceContainer production of the grammar defined in this specification document.

An instance of a provenance container, written provenanceContainer(decls, ids, exprs) in PROV-ASN:

• contains a set of namespace declarations decls, declaring namespaces and associated prefixes, which can be used in attributes (conformant to production attribute) and in names (conformant to production name) in exprs;
• contains a set of identifiers ids naming all accounts occurring (at any nesting level) in exprs;
• contains one or more expressions exprs.

All the expressions in exprs are implictly wrapped in a default account, scoping all the identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts. Consequently, every provenance expression is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.

The following container

container([x http://example.org/], [acc1,acc2]
          account(acc1,http://example.org/asserter1,...)
          account(acc2,http://example.org/asserter1,...))

illustrates how two accounts with identifiers acc1 and acc2 can be returned in a PROV-ASN serialization of the provenance of something.

Qualifier

A qualifier is an ordered list of name-value pairs, used to qualify use expressions, generation expressions and control expressions.

In PROV-ASN, a qualifier's text matches the qualifier production of the grammar defined in this specification document.

Use, generation, and control expressions MUST contain a qualifier. A qualifier's sequence of name-value pairs MAY be empty.

The interpretation of a qualifier is specific to the process execution expression it occurs in, which means that a same qualifier may appear in two different process execution expressions with different interpretations. From this specification's viewpoint, a qualifier's interpretation is out of scope.

By definition, a use (resp. generation, control) expression does not contain an identifier. If one wants to annotate a use (resp. generation, control) expression, this expression MUST be identifiable from its constituents, i.e. its source's identifier, its destination's identifier, and its qualifier.

To be able to annotate use (resp. generation, control) expressions that refer to a given process execution identifier, any qualifier occuring in use expressions (resp. generation, control) with this identifier and a given entity expression identifier MUST be unique.

Qualifiers are used in determining the exact source and destination of a pe-linked-derivationExpression. Hence, if one wants to express a pe-linked-derivationExpression referring to an entity expression and a process execution expression, then:

• the useQualifier MUST be unique among the qualifiers occuring in use expressions for this process execution expression;
• the generationQualifier MUST be unique among the qualifiers occuring in generation expressions for this process execution expression.

The PROV data model introduces the qualifier role in the PROV-DM namespace to denote the function of a characterized thing with respect to an activity, in the context of a use/generation/control relation. The value associated with a role attribute MUST be conformant with Literal.

The following control expression qualifies the role of the agent identified by a5 in this control relation.

          wasControlledBy(pe4,a5, qualifier(role="communicator"))

Attribute

An attribute is a finite sequence of characters. (Exact production TBD).

If a namespace prefix occurs in the qualified name, it refers to a namespace declared in the provenance container.

Name

A name is a finite sequence of characters. (Exact production TBD).

If a namespace prefix occurs in the qualified name, it refers to a namespace declared in the provenance container.

Identifier

An identifier is a finite sequence of characters.

Literal

Time

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

It is OPTIONAL to assert time in use, generation, and process execution expressions.

Asserter

An asserter is a creator of PROV-DM expressions. An asserter is denoted by an IRI.

Namespace Declaration

A namespace declaration declares a namespace and a prefix to denote it.

Recipe Link

A recipe link is an association between a process execution expression and a process specification that underpins the represented activity.

It is OPTIONAL to assert recipe links in process executions.

Process specifications, as referred to by recipe links, are out of scope of this specification.

Location

Location is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, row, column, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations in assertions.

Location is an OPTIONAL attribute of entity expressions and process execution expressions. The value associated with a attribute location MUST be a Literal, expected to denote a location.

Attribution

An attribution expression represents that a characterized thing is ascribed to an agent and is compliant with the attributionExpression production.

An instance of an attribution expression, written wasAttributedTo(e,ag):

• contains an identifer e, identifying an entity expression;
• contains an identifer ag, identifying the agent whom the entity is attributed to.

Attribution models the notion of a process execution generating an entity identified by e being controlled by an agent ag, which takes responsibility for generating e. Formally, this is expressed as the following necessary condition.

processExecution(pe,recipe,t1,t2,attr)
wasGenerateBy(e,pe)
wasControlledBy(pe,ag,q)

Quotation

A quotation exression is a representation of the repeating or copying of some part of a characterized thing, compatible with the quotationExpression production.

An instance of a quotation expression, written wasQuoteOf(e2,e1,ag2,ag1):

• contains an identifier e2, identifying an entity expression that represents the quote;
• contains an identifier e1, identifying an entity expression representing what is being quoted;
• MAY refer to an agent who is doing the quoting, identified by ag2;
• MAY refer to the agent that is quoted, identified by ag1.

wasEventuallyDerivedDerivedFrom(e2,e1)
wasAttributeTo(e2,ag2)
wasAttributeTo(e1,ag1)

Summary

A summary expression represents that a characterized thing is a synopsis or abbreviation of another entity. A summary expression is compliant with the summaryExpression production.

An assertion wasSummaryOf, written wasSummaryOf(e2,e1):

• contains an identifier e2 identifying the entity expression that represents the summary;
• contains an identifier e1 identifying the entity expression that represents what is being summarized.

wasSummaryOf is a strict sub-relation of wasEventuallyDerivedFrom.

Original Source

An original-source expression represents a characterized thing in which another characterized thing first appeared. A original-source expression is compliant with the originalSourceExpression production.

An assertion hadOriginalSource, written hadOriginalSource(e2,e1):

• contains an identifier e1 identifying the entity expression representing the original thing;
• contains an identifier e2 identifying an entity expression, representing a thing that had appeared previously.

hasOriginalSource is a strict sub-relation of wasEventuallyDerivedFrom