• a report available at URL: fixes the nature of the thing, i.e. a document, and its location;
• the version of the report available there today: fixes its version number, contents, and its date;
• the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.

• the provenance of a report available at URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;
• the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;
• the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team involved in it.

2.1.2.1Types of Events

Four kinds of events underpin the PROV-DM data model. Theactivity start andactivity end events demarcate the beginning and the end of activities, respectively. Theentity generation andentity usage events demarcate the characterization interval for entities. More specifically:

Anentity generation event is theevent that marks the final instant of an entity's creation timespan, after which it becomes available for use.

Anentity usage event is theevent that marks the first instant of an entity's consumption timespan by an activity.

Anactivity start event is theevent that marks the instant an activity starts.

Anactivity end event is theevent that marks the instant an activity ends.

2.1.2.2Event Ordering

To allow for minimalistic clock assumptions, like Lamport[CLOCK], PROV-DM relies on a notion of relative ordering ofevents,without using physical clocks. This specification assumes that a partial order exists betweenevents.

Specifically,follows is a partialorder betweenevents, indicating that anevent occurs after another.For symmetry,precedes is defined asthe inverse of follows.

How such partial order is realized in practice is beyond the scopeof this specification. This specification only assumes thateachevent can be mapped to an instant in some form oftimeline. The actual mapping is not in scope of thisspecification. Likewise, whether this timeline is formed of a singleglobal timeline or whether it consists of multiple Lamport's styleclocks is also beyond this specification. It is anticipatedthatfollows andprecedes correspond to some orderingover this timeline.

This specification introduces a set of "temporal interpretation"rules allowing to deriveevent ordering constraints fromprovenance records. According to such temporal interpretation,provenance recordsmust satisfy such constraints. We note that theactual verification of such temporal constraints is also outside thescope of this specification.

PROV-DM also allows for time observations to be inserted in specificprovenance records, for each recognizedevent introducedin this specification. The presence of a time observation for agivenevent fixes the mapping of thisevent to thetimeline. It can also help with the verification of associatedtemporal constraints (though, again, this verification is outside thescope of this specfication).

The following entity record,

entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])

The following activity assertion

activity(a1,add-crime-in-london,2011-11-16T16:05:00,2011-11-16T16:06:00,[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])

identified by identifiera1, states the existence of an activity with recipe linkadd-crime-in-london, start time2011-11-16T16:05:00, and end time2011-11-16T16:06:00, running on hostserver.example.org, and of typeedit (declared in some namespace with prefixex). The attributehost is application specific, butmust hold for the duration of activity. The attributetype is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.

With the following assertions,

agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])entity(e2) and wasStartedBy(a1,e2,[prov:role="author"])entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])

the agent record identified bye1 is an explicit agent assertion that holds irrespective of activities it may be associated with. On the other hand, from the entity records identified bye2 ande3, one can infer agent records, as per the following inference.

The following note record

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

consists of a set of application-specific attribute-value pairs, intendedto help the rendering of the record it is associated with, byspecifying its color and its position on the screen. In this example,these attribute-value pairs do not constitute a representation of somethingin the world; they are just used to help render provenance.

5.3.1.1Generation Record

In PROV-DM, ageneration record is a representation of a worldevent, the creation of a new entity by an activity. This entity did not exist before creation. The representation of thisevent encompasses a description of the modalities of generation of this entity by this activity.

Ageneration event may be, for example, the creation of a file by a program, the creation of a linked data set, the production of a new version of a document, and the sending of a value on a communication channel.

A generation record, writtenwasGeneratedBy(id,e,a,attrs,t) in PROV-ASN, has the following components:

• id: anoptional identifierid identifying the generation record;
• entity: an identifiere identifying an entity record that represents the entity that is created;
• activity: an identifiera identifying an activity record that represents the activity that creates the entity;
• time: anoptional "generation time"t, the time at which the entity was created;
• attributes: anoptional set of attribute-value pairsattrs that describes the modalities of generation of this entity by this activity.

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

A generation record's id isoptional. Itmust be used when annotating generation records (see SectionAnnotation Record) or when defining precise-1 derivations (seeDerivation Record).

  wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])  wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])

The assertion of a generation record implies ordering ofevents in the world.

A given entity record can be referred to in a single generation record in the scope of a givenaccount.The rationale for this constraint is as follows.If two activities sequentially set different values to some attribute by means of two differentgeneration events, then they generate distinct entities. Alternatively, for two activities 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 activity. This unicity constraint is formalized as follows.

5.3.1.2Usage Record

In PROV-DM, ausage record is a representation of a worldevent: the consumption of an entity by an activity. The representation includes a description of the modalities of usage of this entity by this activity.

Ausage event may be the consumption of a parameter by a procedure, the reading of a value on a port by a service, the reading of a configuration file by a program, or the adding of an ingredient, such as eggs, in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).

A usage record, writtenused(id,a,e,attrs,t) in PROV-ASN, has the following constituent:

• id: anoptional identifierid identifying the usage record;
• activity: an identifiera for an activity record, which represents the consuming activity;
• entity: an identifiere for an entity record, which represents the entity that is consumed;
• time: anoptional "usage time"t, the time at which the entity was used;
• attributes: an OPTIONIAL set of attribute-value pairsattrs that describe the modalities of usage of this entity by this activity;

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

A usage record's id isoptional, but comes handy when annotating usage records (see SectionAnnotation Record) or when defining derivations.

  used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])  used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])

A usage record's id isoptional. Itmust be present when annotating usage records (see SectionAnnotation Record) or when defining precise-1 derivations (seeDerivation Record).

A reference to a given entity recordmay appear in multiple usage records that share a given activity record identifier.

5.3.2.1Activity Association Record

The key purpose of agents in PROV-DM is to assign responsibilityfor activities. It is important to reflect that there is a degree inthe responsibility of agents, and that is a major reason fordistinguishing among all the agents that have some association with anactivity and determine which ones are really the originators of theentity. For example, a programmer and a researcher could both beassociated with running a workflow, but it may not matter whatprogrammer clicked the button to start the workflow while it wouldmatter a lot what researcher told the programmer to do so. Anotherexample: a student publishing a web page describing an academicdepartment could result in both the student and the department beingagents associated with the activity, and it may not matter whatstudent published a web page but it matters a lot that the departmenttold the student to put up the web page. So there is some notion ofresponsibility that needs to be captured.

To this end, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent and an activity; the second, introduced inSection Responsibility record, represents the fact that an agent was acting on behalf of another, in the context of an activity.

Examples of activity association include designing, participation, initiation and termination, timetabling or sponsoring.

Anactivity association record, writtenwasAssociatedWith(a,ag2,attrs) in PROV-ASN, has the following constituents:

• id: anoptional identifierid identifying the activity association record;
• activity: an identifiera for an activity record;
• attributes: anoptional set of attribute-value pairsattrs that describe the modalities of association of this activity with this agent;
• agent: an identifierag2 for an agent record, which represents the agent associated with the activity.

In PROV-ASN, an activity association record's text matches theactivityAssociationRecord productions of the grammar defined in this specification document.

activity(a,[prov:type="workflow"])agent(ag1,[prov:type="programmer"])agent(ag2,[prov:type="researcher"])wasAssociatedWith(a,ag1,[prov:role="loggedInUser", ex:how="webapp"])wasAssociatedWith(a,ag2,[prov:role="designer", ex:context="phd"])

5.3.2.2Start and End Records

Astart record is a representation of an agent starting an activity. Anend record is a representation of an agent ending an activity. Both relations are specialized forms ofwasAssociatedWith. They contain attributes describing the modalities of acting/ending activities.

A start record, writtenwasStartedBy(id,a,ag,attrs) in PROV-ASN, contains:

• id: anoptional identifierid identifying the start record;
• activity: an identifiera denoting an activity record, representing the started activity;
• agent: an identifierag for an agent record, representing the starting agent;
• attributes: anoptional set of attribute-value pairsattrs, describing modalities according to which the agent started the activity.

An end record, writtenwasEndedBy(id,a,ag,attrs) in PROV-ASN, contains:

• id: anoptional identifierid identifying the end record;
• activity: an identifiera denoting an activity record, representing the ended activity;
• agent: an identifierag for an agent record, representing the ending agent;
• attributes: anoptional set of attribute-value pairsattrs, describing modalities according to which the agent ended the activity.

In PROV-ASN, start and end record's texts match thestartRecord andendRecord productions of the grammar defined in this specification document.

wasStartedBy(a,ag,[ex:mode="manual"])wasEndedby(a,ag,[ex:mode="manual"])

5.3.3.1Responsibility Record

To promote take-up, PROV-DM offers a mild version of responsibilityin the form of a relation to represent when an agent acted on anotheragent's behalf. So in the example of someone running a mail program,the program is an agent of that activity and the person is also anagent of the activity, but we would also add that the mail softwareagent is running on the person's behalf. In the other example, thestudent acted on behalf of his supervisor, who acted on behalf of thedepartment chair, who acts on behalf of the university, and all thoseagents are responsible in some way for the activity to take place butwe don't say explicitly who bears responsibility and to whatdegree.

We could also say that an agent can act on behalf of several otheragents (a group of agents). This would also make possible toindirectly reflect chains of responsibility. This also indirectlyreflects control without requiring that control is explicitlyindicated. In some contexts there will be a need to representresponsibility explicitly, for example to indicate legalresponsibility, and that could be added as an extension to this coremodel. Similarly with control, since in particular contexts theremight be a need to define specific aspects of control that variousagents exert over a given activity.

Given an activity association recordwasAssociatedWith(a,ag2,attrs),aresponsibility record, writtenactedOnBehalfOf(id,ag2,ag1,a,attrs) in PROV-ASN, has the following constituents:

• id: anoptional identifierid identifying the responsibility record;
• subordinate: an identifierag2 for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent;
• responsible: an identifierag1 for an agent record, which represents the agent on behalf of which the subordinate agentag2 acts;
• activity: anoptional identifiera of an activity record for which the responsibility record holds;
• attributes: anoptional set of attribute-value pairsattrs that describe the modalities of this relation.

activity(a,[prov:type="workflow"])agent(ag1,[prov:type="programmer"])agent(ag2,[prov:type="researcher"])agent(ag3,[prov:type="funder"])wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])wasAssociatedWith(a,ag2)actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])

5.3.3.2Derivation Record

In PROV-DM, aderivation record is a representation that some entity is transformed from, created from, or affected by another entity in the world.

Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New-York, the transformation of a relational table into a linked data set, and the melting of ice into water.

According toSection Conceptualization, for an entity to be transformed from, created from, or affected by another in some way, there must be some underpinning activities performing the necessary actions resulting in such a derivation. However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or less precise records of derivation to be asserted. Hence, PROV-DM uses the termsprecise andimprecise to characterize the different kinds of derivation record. We note that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise.

The lack of precision may come from two sources:

• the number of activities that underpin a derivation is not asserted or known, or
• any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage records, and their attributes.

Hence, given a precision axis, with valuesprecise andimprecise, and an activity axis, with valuesone activity andn activities, we can then form a matrix of possible derivations, precise or imprecise, or corresponding to one activity or n activities.Out of the four possibilities, PROV-DM offers three forms of derivation, while the fourth one is not meaningful. The following table summarises names for the three kinds of derivation, which we then explain.

• The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation record.
• The asserter asserts that derivation is due to exactly one activity, but other details, whether known or unknown, are not asserted. We call this an imprecise-1 derivation record.
• The asserter does not know how many activities are involved in the derivation, and other details, whether known or unknown, are also not asserted. We call this an imprecise-n derivation record.

We note that the fourth theoretical case of a precise derivation, where the number of activities is not known or asserted cannot occur.

The three kinds of derivation records are successively introduced. To minimize the number of relation types in PROV-DM, we introduce a PROV-DM reserved attributesteps, which allows us to distinguish the various derivation types.

Aprecise-1 derivation record, writtenwasDerivedFrom(id, e2, e1, a, g2, u1, attrs) in PROV-ASN, contains:

• id: anoptional identifierid identifying the derivation record;
• generatedEntity: the identifiere2 of an entity record, which is a representation of the generated entity;
• usedEntity: the identifiere1 of an entity record, which is a representation of the used entity;
• activity: an identifiera of an activity record, which is a representation of the activity using and generating the above entities;
• generation: an identifierg2 of the generation record pertaining toe2 anda;
• usage: an identifieru1 of the usage record pertaining toe1 anda.
• attributes: anoptional set of attribute-value pairsattrs that describe the modalities of this derivation, optionally including the attribute-value pairprov:steps="1".

It isoptional to include the attributeprov:steps in a precise-1 derivation since the record already refers to the one and only one activity underpinning the derivation.

Animprecise-1 derivation record, writtenwasDerivedFrom(id, e2,e1, attrs) in PROV-ASN, contains:

• id: anoptional identifierid identifying the derivation record;
• generatedEntity: the identifiere2 of an entity record, which is a representation of the generated entity;
• usedEntity: the identifiere1 of an entity record, which is a representation of the used entity.
• attributes: a set of attribute-value pairsattrs that describe the modalities of this derivation; itmust include the attribute-value pairprov:steps="1".

An imprecise-1 derivationmust include the attributeprov:steps, since it is the only means to distinguish this record from an imprecise-n derivation record.

Animprecise-n derivation record, writtenwasDerivedFrom(id, e2, e1, attrs) in PROV-ASN, contains:

• id: anoptional identifierid identifying the derivation record;
• generatedEntity: the identifiere2 of an entity record, which is a representation of the generated entity;
• usedEntity: the identifiere1 of an entity record, which is a representation of the used entity.
• attributes: anoptional set of attribute-value pairsattrs that describe the modalities of this derivation; it optionally includes the attribute-value pairprov:steps="n".

It isoptional to include the attributeprov:steps in an imprecise-n derivation record. It defaults toprov:steps="n".

None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property holds.

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

wasDerivedFrom(e5,e3,a4,g2,u2,[])wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="1"])wasDerivedFrom(e3,e2,[prov:steps="1"])wasDerivedFrom(e2,e1,[])wasDerivedFrom(e2,e1,[prov:steps="n"])

An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications hold.

If a derivation record holds fore2 ande1, then this means that the entity represented by entity record identified bye1 has an influence on the entity represented entity record identified bye2, which at the minimum implies temporal ordering, specified as follows.First, we consider one-activity derivations.

Then, imprecise-n derivations.

Note that temporal ordering is between generations ofe1ande2, as opposed to precise-1 derivation,which implies temporal ordering between the usage ofe1 andgeneration ofe2. Indeed, in the case ofimprecise-n derivation, nothing is known about the usage ofe1,since there is no associated activity.

The imprecise-1 derivation has the same meaning as the precise-1 derivation, except that an activity is known to exist, though it does not need to be asserted. This is formalized by the following inference rule,referred to asactivity introduction:

activity(a,aAttrs)wasGeneratedBy(g,e2,a,gAttrs)used(u,a,e1,uAttrs)

Note that inferring derivation from usage and generation does not holdin general. Indeed, when a generationwasGeneratedBy(g, e2, a, attrs2)precedesused(u, a, e1, attrs1), forsomee1,e2,attrs1,attrs2, anda, onecannot infer derivationwasDerivedFrom(e2, e1, a, g, u)orwasDerivedFrom(e2,e1) since ofe2 cannot possibly be determined byofe1, given the creation ofe2precedes the useofe1.

A further inference is permitted from the imprecise-1 derivation record:

This inference is justified by the fact that the entity represented by entity record identified bye2 is generated by at most one activity in a given account (seegeneration-unicity). Hence, this activity record is also the one referred to in the usage record ofe1.

We note that the converse inference, does not hold.FromwasDerivedFrom(e2,e1) andused(pe,e1), one cannotderivewasGeneratedBy(e2,pe,attrs2) because identifiere1 may occur in usage records referring to many activity records, but they may not be referred to in generation records containing identifiere2.

5.3.3.3Complementarity Record

Acomplementarity record is a relationship between two entities 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 an entity 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 representationcomplements 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 entities at a certain point in time. An entity record 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 record 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 record, with a new characterization interval. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two entities, we can hope to establish correspondences amongst the entity records that represent them at various points along that events line. The figure below illustrates this intuition.

Relationcomplement-of between two entity records is intended to capture these correspondences, as follows. Suppose entity records 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 arecompatible between A and B, then we say thatA is-complement-of B, andB 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 thatB 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 termcompatible 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 entity.

A complementarity record is writtenwasComplementOf(e2,e1), wheree1 ande2 are two identifiers denoting entity records.

entity(rs,[ex:created=1870])entity(rs_l1,[prov:location="loc2"])entity(rs_l2,[prov:location="The Mall"])entity(rs_m1,[ex:membership=250, ex:year=1900])entity(rs_m2,[ex:membership=300, ex:year=1945])entity(rs_m3,[ex:membership=270, ex: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 complementarity relation is not transitive. Let us consider identifierse1,e2, ande3 identifying three entity records such thatwasComplementOf(e3,e2) andwasComplementOf(e2,e1) hold. The recordwasComplementOf(e3,e1) may not hold because the characterization intervals of the denoted entity records may not overlap.

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

An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to link two entity record identifiers that are appear in different accounts. (In particular, the entity record identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through complementarity can only take place within the scope of a single account.

account(ex:acc1,        http://example.org/asserter1,     ...    entity(rs,[ex:created=1870])    ...    )account(ex:acc2,        http://example.org/asserter2,     ...    entity(rs_m1,[ex:membership=250, ex:year=1900])    ...    wasComplementOf(rs_m1, ex:acc2, rs, ex:acc1))

The following records

entity(e1,[prov:type="document"])entity(e2,[prov:type="document"])activity(a,transform,t1,t2,[])used(u1,a,e1,[ex:file="stdin"])wasGeneratedBy(e2, a, [ex:file="stdout"])note(n1,[ex:icon="doc.png"])hasAnnotation(e1,n1)hasAnnotation(e2,n1)note(n2,[ex:style="dotted"])hasAnnotation(u1,n2)

assert the existence of two documents in the world (attribute-value pair:prov:type="document") represented by entity records identified bye1 ande2, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) isdoc.png. It also asserts an activity, its usage of the first entity, and its generation of the second entity. Theusage record is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifieru1, which was then referred to inhasAnnotation(u1,n2).

The following account record

account(ex:acc0,        http://example.org/asserter,           entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])          ...          wasDerivedFrom(e2,e1)          ...          activity(a0,create-file,t)          ...          wasGeneratedBy(e0,a0,[])               ...          wasAssociatedWith(a4, ag5, [prov:role="communicator"])  )

contains the set of provenance records of sectionexample-prov-asn-encoding, is asserted by agenthttp://example.org/asserter, and is identified by identifierex:acc0.

In the following account record, we find two entity records with a same identifiere.

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

Application ofidentified-entity-in-account results in an entity record containing the attribute-value pairsage=20 andage=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 and outside the scope of this specification.

Indeed, let us consider another account record

account(ex:acc2,        http://example.org/asserter2,           entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])          ...          activity(a1,create-file,t1)          ...          wasGeneratedBy(e0,a1,[ex:fct="create"])               ... )

with identifierex:acc2, containing assertions by asserter byhttp://example.org/asserter2 stating that the entity represented by entity record identified bye0 was generated by an activity represented by activity record identified bya1 instead ofa0 in the previous accountex:acc0. If accountsex:acc0 andex:acc2 are merged together, the resulting set of records violatesgeneration-unicity.

The following account record is inspired from sectionexample-prov-asn-encoding. This account, identified byex:acc3, declares entity record with identifiere0, which is being referred to in the nested accountex:acc4. The scope of identifiere0 is accountex:acc3, including subaccountex:acc4.

account(ex:acc3,        http://example.org/asserter1,           entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])          activity(a0,create-file,t)          wasGeneratedBy(e0,a0,[])            account(ex:acc4,                  http://example.org/asserter2,                    entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])                    activity(a0,copy-file,t)                    wasGeneratedBy(e1,a0,[ex:fct="create"])                    wasComplementOf(e1,e0)))

Alternatively, an activity record identified bya0 occurs in each of the two accounts. Therefore, each activity record is asserted in a separate scope, and therefore may represent different activities in the world.

The following container

container  prefix ex: http://example.org/,  account(ex:acc1,http://example.org/asserter1,...)  account(ex:acc2,http://example.org/asserter1,...)endContainer

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

The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the convenience notation) and the IRI "http://example.org/foo".

  "abc"  "abc" %% xsd:string  "1" %% xsd:int  1  "http://example.org/foo" %% xsd:anyURI

  "ex:value" %% xsd:QName