No guarantees are provided as to the correctness of this validation result.
Provenance consists of a description of past entities and activities. Valid provenance instances MUST satisfy ordering constraints between instantaneous events.
Specifically, there exists a preorder between instantaneous events. A constraint of the form 'e1 precedes e2' means that e1 happened at the same time as or before e2. For symmetry, follows is defined as the inverse of precedes; that is, a constraint of the form 'e1 follows e2' means that e1 happened at the same time as or after e2. Both relations are preorders, meaning that they are reflexive and transitive. Moreover, we sometimes consider strict forms of these orders: we say e1 strictly precedes e2 to indicate that e1 happened before e2, but not at the same time. This is a transitive relation.
One way to check ordering constraints is to generate all precedes and strictly precedes relationships arising from the ordering constraints to form a directed graph, with edges marked precedes or strictly precedes, and check that there is no cycle containing a strictly precedes edge.
Expressions are malformed when ...
Statements may be merged when ...
PROV defines some type inferences and identifies some mutually exclusive types. For instance, an activity cannot be an entity. This section identifies type impossiblities.
Specialization is not reflexive.
This is purely a warning. The purpose of this section is to identify terms that are repeated in the current instance but successfully unified. No action is required, since such terms are perfect valid as far as [PROV-Constraints] is concerned.
This is purely a warning. Qualified names, in PROV, map to URIs by concatenating the namespace (denoted by a qualified name prefix) and the local name. Two different qualified names may map to the same URI. Nothing wrong, from a PROV view point, since comparison is on URIs. However, having two distinct qualified names for a same URIs make provenance confusing for human readers.