FormalSemanticsCR
From Provenance WG Wiki
(→Inference 11 (derivation-generation-use-inference)) |
(→Inference 15 (influence-inference)) |
||
| Line 573: | Line 573: | ||
#<math> \forall id, a, ag, pl, attrs.~ wasAssociatedWith(id; a,ag,pl,attrs) \Longrightarrow wasInfluencedBy(id; a, ag, attrs)</math> Here, pl may be a placeholder -. | #<math> \forall id, a, ag, pl, attrs.~ wasAssociatedWith(id; a,ag,pl,attrs) \Longrightarrow wasInfluencedBy(id; a, ag, attrs)</math> Here, pl may be a placeholder -. | ||
#<math> \forall id, ag_2, ag_1, a, attrs.~ actedOnBehalfOf(id; ag_2,ag_1,a,attrs) \Longrightarrow wasInfluencedBy(id; ag_2, ag_1, attrs)</math> | #<math> \forall id, ag_2, ag_1, a, attrs.~ actedOnBehalfOf(id; ag_2,ag_1,a,attrs) \Longrightarrow wasInfluencedBy(id; ag_2, ag_1, attrs)</math> | ||
| + | |||
| + | '''TODO: In 4 and 5, should e be a1? Otherwise these two rules are redundant since the influence of e on a2 can also be derived using other inferences.''' | ||
=== Inference 16 (alternate-reflexive) === | === Inference 16 (alternate-reflexive) === | ||
Revision as of 13:51, 9 January 2013
Overview
See also FormalSemantics.
The idea of this document is to sketch what aspects of the provenance model can be formalized and how they can be formalized, as a first step towards establishing a consensus on the (intended) meaning of the components of the model and the consistency constraints or inferences that can be applied to the model to distinguish valid from invalid provenance records.
The PROV-CONSTRAINTS document contains formal content specifying a notion of validity (approximately, logical consistency) for PROV documents. The formal semantics, PROV-SEM, is planned for release as a W3C Note that will complement the procedural specification in PROV-CONSTRAINTS with a declarative specification formulated in terms of first-order logic. The formal semantics is work in progress. The drafts below are intermediate stages and some of them are out of date.
The current version (editor's draft) of the formal semantics can always be found at: FormalSemanticsED.
Status
This is work in progress. The semantics is being updated to be consistent with the Candidate Recommendation of PROV. The plan is to release the semantics as a Note over the next few months. At that point, the wiki pages containing drafts of the semantics will be superseded.
Idea of the semantics
As a starting point, I will assume that we intend the assertions made in a PROV-DM instance to be intended to describe one, consistent state of the world, much like a logical formula is said to be satisfied in a mathematical model. That is, I propose an approach similar to that taken in model theory, where the PROV-DM instance corresponds to a formula or theory of a logic, and the semantics corresponds to what logicians call a model.
For example, the formula
is satisfied in a mathematical model where the relation P denotes a set of elements that is contained in that denoted by Q. Here, the goal is to come up with a plausible "intended model" for interpreting PROV-DM instances, where the formulas are assertions in PROV-DM and the individuals are things and agents. This is complicated by the fact that many statements about provenance involve talking about objects that change over time.
The word "world" is used in PROV-DM to talk about the actual state of affairs that the PROV-DM instance describes, which is what I would usually call a "model". The word "model" is used in PROV-DM mainly in the sense of "data model", that is, to talk about what I would otherwise call the syntax of PROV-DM. To avoid confusion with the uses of terms in PROV-DM, I will use "world model" to describe the mathematical structure that corresponds to actual state of affairs, and will try to avoid ambiguous, unqualified uses of the word "model".
Axiomatization and relationship to PROV-CONSTRAINTS
One goal of the semantics is to link the procedural specification of validity and equivalence with traditional notions of logical consistency and equivalence of theories, for example in first-order logic. A first-order axiomatization that corresponds to the formal constraints and is sound for reasoning about the models described below is in progress at the end of the document.
Basics
I will use syntax for PROV-DM records (which I will usually call formulas) as described in the Candidate Recommendation of PROV-DM (PROV-DM CR).
A PROV-DM instance, or set of atomic formulas φ1...φn, is interpreted as a conjunction, that is, the overall instance is considered to hold in a given structure if each atomic formula in it holds.
The rest of the document will discuss the structures and define when an atomic assertion holds in a given world.
Identifiers
A lowercase symbol x,y,... on its own denotes an identifier. Identifiers may or may not be URIs. I view identifiers as being like variables in logic (or blank nodes in RDF): just because we have two different identifiers x and y doesn't tell us that they denote different things, since we could discover that they are actually the same later. We write Identifiers for the set of identifiers of interest in a given situation (typically, the set of identifiers present in the PROV instance of interest).
Times and Intervals
We assume a linearly ordered set
of time instants. For convenience we assume the order is total or linear order, corresponding to a linear timeline; however, PROV does not assume that time is linear and events could be partially ordered and not necessarily reconciled to a single global clock.
We also consider a set Intervals of closed intervals of the form
.
Attributes and Values
We assume a set Attributes of attribute labels and a set Values of possible values of attributes.
Formulas
The following atomic formulas correspond to the statements of PROV-DM. We assume that definitions 1-4 of PROV-CONSTRAINTS have been applied in order to expand all optional parameters; thus, we use uniform notation
instead of the semicolon notation
.
Each parameter is either an identifier, a constant (e.g. a time or other literal value in an attribute list), or a null symbol "-". Null symbols can only appear in the specified arguments in wasAssociatedWith and wasDerivedFrom, as shown in the grammar below.
World Models
Things
Things are things in the world. Each thing has a lifetime during which it exists and attributes whose values can change over time.
To model this, a world model W includes
- a set Things of things
- a function
from objects to time intervals
- a function
Note that this description does not say what the structure of an object is, only how it may be described in terms of its time interval and attribute values. An object could just be a record of fixed attribute values; it could be a bear; it could be the Royal Society; it could be a transcendental number like π. All that matters from our point of view is that we know how to map the object to its time interval and attribute mapping.
The range of the value function us
, that is,
, the set of values with an additional element
. When
, we say that attribute a is undefined for x at time t.
It is possible for two Things to be indistinguishable by their attribute values and lifetime, but have different identity.
Objects
A Object is described by a time interval and attributes with unchanging values. Objects encompass entities, interactions, and activities.
To model this, a world includes
- a set Objects
- a function
from objects to time intervals
- a function
Intuitively, lifetime(e) is the time interval during which object e exists. The value value(e,a) is the value of attribute a during the object's lifetime.
As with Things, the range of value includes the special undefined value
, making value effectively a partial function. It is also possible to have two different objects that are indistinguishable by their attributes and time intervals. Objects are not things, and the sets of Objects and Things are disjoint; however, certain objects, namely entities, are linked to things.
Entities
An entity is a kind of object that describes a time-slice of a thing, during which some of the thing's attributes are fixed. We assume:
- a set
of entities, disjoint from Activities and Events below.
- a function
that associates each Entity with a Thing, such that for each
, and for each attribute a such that
, we have value(obj,a) = value(thingOf(obj),a,t).
-
.
Remark: Although both entities and things can have undefined attribute values, their meaning is slightly different: for a thing,
means that the attribute a has no value at time t, whereas for an entity,
only means that the entity does not record a fixed value for a. This does not imply that
when
. In particular, if the value(x,a,t) has multiple values during the lifetime of e, then value(e,a) must be
, since assigning a value to value(e,a) would violate condition (3) above.
Plans
We identify a specific subset of the entities called plans,
.
Agents
An agent is an entity that can act, by controlling, starting, ending, or participating in activities. Agents can act on behalf of other agents. We introduce:
- a set
of agents.
Actvities
An activity is an object that encompasses a set of events. We introduce
- a set
of activities, disjoint from Entities and Events
Interactions
We consider a
which are split into Events between entities and activities, Associations between agents and activities, and Derivations that describe chains of generation and usage steps. (The first two sets may overlap.) Interactions are disjoint from entities, activities and agents.
Events
An Event is an interaction whose lifetime is a single time instant, and relates an activity to an entity (which could be an agent). Events have types including usage, generation, starting and ending (possibly more may be added such as destruction/invalidation of an entity). Events are instantaneous. We introduce:
- A set
of events.
- A function
giving the time of each event; i.e. lifetime(evt) = {time(t)}.
- The derived ordering on events given by
- A function
such that Events have types in {start,end,use,generate}.
Associations
An Association is an interaction relating an agent to an activity. Associations can overlap with events; for example, a start event is also an association. To model associations, we introduce:
- A set
, such that every event
that is a start or end event is also an association. That is,
implies
Associations are used below in the ActsFor and AssociatedWith relations. Add types for association or delegation?
Derivations
A Derivation is an interaction chaining one or more generation and use steps. Derivations can also carry attributes, so we introduce an explicit kind of interaction for them that can carry attributes.
- A set
, disjoint from
.
See below for the associated derivation path and DerivedFrom relation.
Relations
Simple relations
The entities, interactions, and activities in a world model are related in the following ways:
- A relation
saying when an event used an entity. An event can use at most one entity, and if
then
and type(g) = use must hold.
- A relation
saying when an event generated an entity. An event can generate at most one entity, and if
then min(lifetime(e)) = time(evt) and type(g) = generation must hold.
- A relation
saying when an event invalidated an entity. An event can invalidate at most one entity, and if
then min(lifetime(e)) = time(evt) and type(g) = invalidation must hold.
- A relation
associating activities with events, such that
implies
.
- A relation
indicating when an agent is associated with an activity, and giving the identity of the association relationship, and an optional plan.
- A relation
indicating when one agent acts on behalf of another with respect to a given activity.
Derivation paths and DerivedFrom
Recall that above we introduced a subset of interactions called Derivations. These identify paths of the form
where the enti are entities, acti are activities, gi are generations, and ui are usages.
Formally, we consider the (regular) language:
-
with the constraints that for each derivation path:
- for each substring
we have
and
, and
- for each substring
we have
and
.
and we use this language to give meaning to derivations:
- A function
Note: The reason why we need paths and not just individual derivation steps is that imprecise wasDerivedFrom formulas can represent multiple derivation steps.
Putting it all together
A world model W is a structure containing all of the above described data. If we need to talk about the objects or relations of more than one world model then we may write W1.Objects; otherwise, to decrease notational clutter, when we consider a fixed world model then the names of the sets, relations and functions above refer to the components of that model.
TODO: List the components.
Semantics
In what follows, let W be a fixed world model with the associated sets and relations discussed in the previous section, and let I be an interpretation of identifiers as objects in W.
The annotations [WF] refer to well-formedness constraints that correspond to typing constraints.
Interpretations
We need to link identifiers to the objects they denote. We do this using a function which we shall call an interpretation.
The mapping from identifiers to objects may not change over time. Thus, we consider interpretations as follows:
- An interpretation function
describing which object is the target of each identifier.
Satisfaction
Consider an atomic formula φ, a world W and an interpretation I. We define notation
which means that φ is satisfied in W,I. For basic assertions, the definition of the satisfaction relation is given in the next few subsections. For a conjunction of assertions
we write
to indicate that
and ... and
hold.
TODO: Satisfiability of additional formulas to explain constraints/inferences
Attribute matching
We say that an object obj matches attributes [attr1 = val1,...] in world W provided:
- for each attribute attri, we have W.value(obj,attri) = vali.
This is sometimes abbreviated as: match(W,obj,attrs)
Semantics of Element Records
Entity Records
An entity formula is of the form entity(id,attrs) where id denotes an entity.
Entity assertions entity(id,attrs) can be interpreted as follows:
-
if and only if:
- [WF] id denotes an entity
- the attributes match: match(W,ent,attrs).
For example, the following formulas both hold if x denotes an entity e such that value(e,a) = 4,value(e,b) = 5,value(e,c) = 6 hold:
entity(x,[a=4,b=5]) entity(x,[a=4,b=5,c=6])
Activity Records
An activity record is of the form activity(id,st,et,attrs) where id is a identifier referring to the activity, st is a start time and et is an end time.
- We say that
if and only if:
- [WF] The identifier id maps to an activity
- If st is specified then it is equal to the start time of the activity, that is: min(lifetime(id)) = st
- If et is specified then it is equal to the end time of the activity, that is: max(lifetime(id)) = et
- The attributes match: match(W,act,attrs).
Agent Records
An agent formula is of the form agent(id,attrs) where id denotes the agent and attrs describes additional attributes.
Agent assertions agent(id,attrs) can be interpreted as follows:
-
if and only if:
- [WF] id denotes an agent
- The attributes match: match(W,ag,attrs).
Semantics of Relations
Entity-Activity
Generation
The generation assertion is of the form wasGeneratedBy(id,e,a,t,attrs) where id is an event identifier, e is an entity identifier, a is an activity identifier, attrs is a set of attribute-value pairs, and t is an optional time.
-
if and only if:
- [WF] The identifier id denotes an event
- [WF] The identifier e denotes an entity
- [WF] The identifier a denotes an activity
.
- The event evt is involved in act, that is, such that
.
- The type of evt is generation, i.e. type(evt) = generation
- The event evt occurred at time t, i.e. time(evt) = t
- The event evt generated ent, i.e.
.
- The attribute values match: match(W,evt,attrs)
Use
The use assertion is of the form used(id,a,e,t,attrs) where id denotes an event, a is an activity identifier, e is an object identifier, attrs is a set of attribute-value pairs, and t is an optional time.
-
if and only if:
- [WF] The identifier id denotes an event
- [WF] The identifier a denotes an activity
- [WF] The identifier e denotes an entity
- The event evt is part of act, i.e.
.
- The type of evt is use, i.e., type(evt) = use.
- The event evt occurred at time t, i.e. time(evt) = t
- The event evt used obj, i.e.
.
- The attribute values match: match(W,evt,attrs)
Invalidation
The invalidation assertion is of the form wasInvalidatedBy(id,e,a,t,attrs) where id is an event identifier, e is an entity identifier, a is an activity identifier, attrs is a set of attribute-value pairs, and t is an optional time.
-
if and only if:
- [WF] The identifier id denotes an event
- [WF] The identifier e denotes an entity
- [WF] The identifier a denotes an activity
.
- The event evt is involved in act, that is, such that
.
- The type of evt is invalidation, i.e. type(evt) = invalidation
- The event evt occurred at time t, i.e. time(evt) = t
- The event evt invalidated ent, i.e.
.
- The attribute values match: match(W,evt,attrs)
Agent-Activity
Association Records
An association record has the form wasAssociatedWith(id,a,ag,pl,attrs).
-
holds if and only if:
- [WF] assoc denotes an association
.
- [WF] a denotes an activity
.
- [WF] ag denotes an agent
.
- [WF] pl is either the placeholder − or denotes a plan
.
- The association associates the agent with the activity and plan, i.e.
.
- The attributes match: match(W,assoc,attrs).
Start Records
A start record wasStartedBy(id,a2,e,a1,attrs) is interpreted as follows:
-
holds if and only if:
- [WF] id denotes an event
- [WF] a2 denotes an activity act2 = I(a2)
- [WF] e denotes an entity ent = I(e)
- [WF] a1 denotes an activity act1 = I(a1)
- The event evt has type start, i.e. type(evt) = start.
- The event happened at the start of act2, that is,
, and min(lifetime(act2)) = time(evt).
- The event happened during act1, that is,
.
- The attributes match: match(W,evt,attrs).
End Records
An activity end record wasEndedBy(id,a2,e,a1,attrs) is interpreted as follows:
-
holds if and only if:
- [WF] id denotes an event
- [WF] a2 denotes an activity act2 = I(a2)
- [WF] e denotes an entity ent = I(e)
- [WF] a1 denotes an activity act1 = I(a1)
- The event evt has type end, i.e. type(evt) = end.
- The event happened at the end of act2, that is,
, and max(lifetime(act2)) = time(evt).
- The event happened during act1, that is,
.
- The attributes match: match(W,evt,attrs).
Agent-Entity
Attribution Records
An attribution record wasAttributedTo(id,e,ag,attrs) is interpreted as follows:
-
holds if and only if:
- [WF] id denotes an event evt = I(id) that is also an association
- [WF] e denotes an entity ent = I(e)
- [WF] ag denotes an agent agent = I(ag)
- The event evt has type attribution, i.e. type(evt) = attribution.
- The entity was attributed to the agent, i.e.
- The attributes match: match(W,evt,attrs).
Agent-Agent
Responsibility
The actedOnBehalfOf(id,ag2,ag1,act,attrs) relation is interpreted using the ActsFor relation as follows:
-
holds if and only if:
- [WF] id denotes an association
that is an association interaction, and type(id) = responsibility.
- [WF] a denotes an activity
is an activity.
- [WF] ag1,ag2 denote agents
are agents.
- The agent agent2 acts for the agent agent1 with respect to the activity act, i.e.
.
- [Redundant?] The association id associates both agents with the activity, i.e.
.
- The attributes match: match(W,assoc,attrs).
Entity-Entity
Derivation
Precise
A precise derivation record has the form wasDerivedFrom(id,e2,e1,a,g,u,attrs).
-
if and only if:
- [WF] id denotes a derivation
- [WF] e1,e2 denote entities
- [WF] a denotes an activity
- [WF] g denotes a generation event
and type(I(g)) = generation
- [WF] u denotes a use event
and type(I(u)) = use
- The derivation denotes a valid one-step derivation
- The attribute values match: match(W,deriv,attrs).
Imprecise
An imprecise derivation record has the form wasDerivedFrom(id,e2,e1, − , − , − ,attrs).
-
if and only if there exists
such that:
- [WF] id denotes a derivation
- [WF] e1,e2 denote entities
-
for some w
- The attribute values match: match(W,deriv,attrs).
Specialization
The specializationOf(e1,e2) relation indicates when one entity record presents more specific aspects of another.
-
if and only if:
- [WF] Both e1 and e2 are entity identifiers, denoting
and
.
- The two Entities refer to the same Thing, that is, thingOf(ent1) = thingOf(ent2).
- The lifetime of obj1 is contained in that of ent2,i.e.
.
- For each attribute such that
we have value(obj1,attr) = value(obj2,attr).
The second criterion says that the two Entities present aspects of the same Thing. Note that the third criterion allows obj1 and obj2 to have the same lifetime (or that of obj2 can be larger). The last criterion allows obj1 to have more defined attributes than obj2, but they must agree on the attributes defined by obj2.
Remark: There has been discussion whether specializationOf is transitive and/oranti-symmetric:
- Transitivity: If specializationOf(a,b) and specializationOf(b,c) hold then specializationOf(a,c) hold. This holds for the above definition.
- Antisymmetry: If specializationOf(a,b) and specializationOf(b,a) hold then a = b. This doesn't follow from the current definition (but it would if we stipulated that two entities that have the same interval, attribute and thing are equal).
Alternate
The alternateOf relation indicates when two entity records present (possibly different) aspects of the same thing. The two entities may or may not overlap in time.
-
if and only if:
- [WF] Both e1 and e2 are entity identifiers, denoting ent1 = I(e1) and ent2 = I(e2).
- The two objects refer to the same underlying Thing: thingOf(ent1) = thingOf(ent2)
Remark: There has been discussion whether alternateOf is symmetric and transitive:
- Symmetry: If alternateOf(a,b) holds then alternateOf(b,a) holds.
- Transitivity: If alternateOf(a,b) and alternateOf(b,c) hold then alternateOf(a,c) hold. This holds of the above definition.
We also consider the following properties which have been suggested:
- specializationOf(e1,e2) implies alternateOf(e1,e2)? (This holds at the moment.)
- alternateOf(a,b) if and only if there exists c such that specializationOf(a,c) and specializationOf(b,c)? This does not necessarily hold without further assumptions about the Entities.
Axiomatization
Definitional Rules
The definitions are essentially used to map the compact notation and implicit placeholder notation used n PROV-N with the abstract syntax of PROV-DM used in the rest of this semantics. We can formalize the definitional expansion rules as follows:
Definition 1 (optional-identifiers)
For each
the following axioms hold:
Definition 2 (optional-attributes)
- For each p in {entity, activity, agent}, if an is not an attribute list parameter then the following definitional rule holds:
- For each
, if an is not an attribute list parameter then the following definition holds:
Definition 3 (definition-short-forms)
Definition 4 (optional-placeholders)
-
. Here, t2 may be a placeholder.
-
. Here, t1 must not be a placeholder.
- For each
, if the ith parameter of r is an expandable parameter of r as specified in Table 3 of PROV-CONSTRAINTS then the following definition holds:
.
-
-
.
Inference Rules
Inference 5 (communication-generation-use-inference)
Inference 6 (generation-use-communication-inference)
Inference 7 (entity-generation-invalidation-inference)
Inference 8 (activity-start-end-inference)
Inference 9 (wasStartedBy-inference)
Inference 10 (wasEndedBy-inference)
Inference 11 (derivation-generation-use-inference)
In this inference, none of a, gen2 or use1 can be placeholders -.
Inference 12 (revision-is-alternate-inference)
In this inference, any of a, g or u may be placeholders.
Inference 13 (attribution-inference)
Inference 14 (delegation-inference)
Inference 15 (influence-inference)
Here, a, g, u may be placeholders -.
Here, pl may be a placeholder -.
TODO: In 4 and 5, should e be a1? Otherwise these two rules are redundant since the influence of e on a2 can also be derived using other inferences.
Inference 16 (alternate-reflexive)
Inference 17 (alternate-transitive)
Inference 18 (alternate-symmetric)
Inference 19 (specialization-transitive)
Inference 20 (specialization-alternate-inference)
Inference 21 (specialization-attributes-inference)
Constraints
Constraint 22 (key-object)
- The identifier field id is a KEY for the entity(id,attrs) statement.
- The identifier field id is a KEY for the activity(id,t1,t2,attrs) statement.
- The identifier field id is a KEY for the agent(id,attrs) statement.
Constraint 23 (key-properties)
- The identifier field id is a KEY for the wasGeneratedBy(id;e,a,t,attrs) statement.
- The identifier field id is a KEY for the used(id;a,e,t,attrs) statement.
- The identifier field id is a KEY for the wasInformedBy(id;a2,a1,attrs) statement.
- The identifier field id is a KEY for the wasStartedBy(id;a2,e,a1,t,attrs) statement.
- The identifier field id is a KEY for the wasEndedBy(id;a2,e,a1,t,attrs) statement.
- The identifier field id is a KEY for the wasInvalidatedBy(id;e,a,t,attrs) statement.
- The identifier field id is a KEY for the wasDerivedFrom(id;e2,e1,a,g2,u1,attrs) statement.
- The identifier field id is a KEY for the wasAttributedTo(id;e,ag,attr) statement.
- The identifier field id is a KEY for the wasAssociatedWith(id;a,ag,pl,attrs) statement.
- The identifier field id is a KEY for the wasAssociatedWith(id;a,ag, − ,attrs) statement.
- The identifier field id is a KEY for the actedOnBehalfOf(id;ag2,ag1,a,attrs) statement.
- The identifier field id is a KEY for the wasInfluencedBy(id;o2,o1,attrs) statement.
Constraint 24 (unique-generation)
Constraint 25 (unique-invalidation)
Constraint 26 (unique-wasStartedBy)
Constraint 27 (unique-wasEndedBy)
Constraint 28 (unique-startTime)
Constraint 29 (unique-endTime)
Constraint 30 (start-precedes-end)
Constraint 31 (start-start-ordering)
Constraint 32 (end-end-ordering)
Constraint 33 (usage-within-activity)
Constraint 34 (generation-within-activity)
Constraint 35 (wasInformedBy-ordering)
Constraint 36 (generation-precedes-invalidation)
Constraint 37 (generation-precedes-usage)
Constraint 38 (usage-precedes-invalidation)
Constraint 39 (generation-generation-ordering)
Constraint 40 (invalidation-invalidation-ordering)
Constraint 41 (derivation-usage-generation-ordering)
In this constraint, a, gen2, use1 must not be placeholders.
Constraint 42 (derivation-generation-generation-ordering)
In this constraint, any of a, g, u may be placeholders.
Constraint 43 (wasStartedBy-ordering)
Constraint 44 (wasEndedBy-ordering)
Constraint 45 (specialization-generation-ordering)
Constraint 46 (specialization-invalidation-ordering)
Constraint 47 (wasAssociatedWith-ordering)
In the following inferences, pl may be a placeholder -.
Constraint 48 (wasAttributedTo-ordering)
Constraint 49 (actedOnBehalfOf-ordering)
Constraint 50 (typing)
- In this constraint, a, g2, and u1 must not be placeholders.
- In this constraint, pl must not be a placeholder.
Constraint 51 (impossible-unspecified-derivation-generation-use)
In the following rules, g and u must not be -.
Constraint 52 (impossible-specialization-reflexive)
Constraint 53 (impossible-property-overlap)
For each r and s in { used, wasGeneratedBy, wasInvalidatedBy, wasStartedBy, wasEndedBy, wasInformedBy, wasAttributedTo, wasAssociatedWith, actedOnBehalfOf} such that r and s are different relation names, the following constraint holds:
Constraint 54 (impossible-object-property-overlap)
For each
and for each
, the following impossibility constraint holds:
Constraint 55 (entity-activity-disjoint)
Constraint 56 (membership-empty-collection)
Automatically generated inferences
Inference 5 (communication-generation-use-inference)
Inference 6 (generation-use-communication-inference)
Inference 7 (entity-generation-invalidation-inference)
Inference 8 (activity-start-end-inference)
Inference 9 (wasStartedBy-inference)
Inference 10 (wasEndedBy-inference)
Inference 11 (derivation-generation-use-inference)
In this inference, none of a, gen2 or use1 can be placeholders -
Inference 12 (revision-is-alternate-inference)
In this inference, any of a, g or u may be placeholders.
Inference 13 (attribution-inference)
Inference 14 (delegation-inference)
Inference 15 (influence-inference)
- In this rule, a, g, u may be placeholders -.
- In this rule, pl may be a placeholder -
Inference 16 (alternate-reflexive)
Inference 17 (alternate-transitive)
Inference 18 (alternate-symmetric)
Inference 19 (specialization-transitive)
Inference 20 (specialization-alternate-inference)
Inference 21 (specialization-attributes-inference)
HTML auto-generated rules
Inference 5 (communication-generation-use-inference)
∀ id,a_2,a_1,attrs. wasInformedBy(id,a_2,a_1,attrs) ⟹ ∃ e,gen,t_1,use,t_2. wasGeneratedBy(gen,e,a_1,t_1,[]) ∧ used(use,a_2,e,t_2,[])
Inference 6 (generation-use-communication-inference)
∀ gen,a_1,t_1,attrs_1,id_2,a_2,t_2,attrs_2. wasGeneratedBy(gen,e,a_1,t_1,attrs_1) ∧ used(id_2,a_2,e,t_2,attrs_2) ⟹ ∃ id. wasInformedBy(id,a_2,a_1,[])
Inference 7 (entity-generation-invalidation-inference)
∀ gen,e,a_1,t_1,attrs_1,id_2,a_2,t_2,attrs_2. wasGeneratedBy(gen,e,a_1,t_1,attrs_1) ∧ used(id_2,a_2,e,t_2,attrs_2) ⟹ ∃ id. wasInformedBy(id,a_2,a_1,[])
Inference 8 (activity-start-end-inference)
∀ a,t_1,t_2,attrs. activity(a,t_1,t_2,attrs) ⟹ ∃ start,e_1,a_1,end,a_2,e_2. wasStartedBy(start,a,e_1,a_1,t_1,[]) ∧ wasEndedBy(end,a,e_2,a_2,t_2,[])
Inference 9 (wasStartedBy-inference)
∀ id,a,e_1,a_1,t,attrs. wasStartedBy(id,a,e_1,a_1,t,attrs) ⟹ ∃ gen,t_1. wasGeneratedBy(gen,e_1,a_1,t_1,[])
Inference 10 (wasEndedBy-inference)
∀ id,a,e_1,a_1,t,attrs. wasEndedBy(id,a,e_1,a_1,t,attrs) ⟹ ∃ gen,t_1. wasGeneratedBy(gen,e_1,a_1,t_1,[])
Inference 11 (derivation-generation-use-inference)
In this inference, none of a, gen2 or use1 can be placeholders -∀ id,e_2,e_1,a,gen_2,use_1,attrs. wasDerivedFrom(id,e_2,e_1,a,gen_2,use_1,attrs) ⟹ ∃ s,t_1,t_2. used(use_1,a,e_1,t_1,[]) ∧ wasGeneratedBy(gen_2,e_2,a,t_2,[])
Inference 12 (revision-is-alternate-inference)
In this inference, any of a, g or u may be placeholders.∀ id,e_1,e_2,a,g,u. wasDerivedFrom(id,e_2,e_1,a,g,u,.(=(prov:type,prov:Revision),[])) ⟹ alternateOf(e_2,e_1)
Inference 13 (attribution-inference)
∀ att,e,ag,attrs. wasAttributedTo(att,e,ag,attrs) ⟹ ∃ a,t,gen,assoc,pl. wasGeneratedBy(gen,e,a,t,[]) ∧ wasAssociatedWith(assoc,a,ag,pl,[])
Inference 14 (delegation-inference)
∀ id,ag_1,ag_2,a,attrs. actedOnBehalfOf(id,ag_1,ag_2,a,attrs) ⟹ ∃ id_1,pl_1,id_2,pl_2. wasAssociatedWith(id_1,a,ag_1,pl_1,[]) ∧ wasAssociatedWith(id_2,a,ag_2,pl_2,[])
Inference 15 (influence-inference)
- ∀ id,e,a,t,attrs. wasGeneratedBy(id,e,a,t,attrs) ⟹ wasInfluencedBy(id,e,a,attrs)
- ∀ id,a,e,t,attrs. used(id,a,e,t,attrs) ⟹ wasInfluencedBy(id,a,e,attrs)
- ∀ id,a_2,a_1,attrs. wasInformedBy(id,a_2,a_1,attrs) ⟹ wasInfluencedBy(id,a_2,a_1,attrs)
- ∀ id,a_2,e,a_1,t,attrs. wasStartedBy(id,a_2,e,a_1,t,attrs) ⟹ wasInfluencedBy(id,a_2,e,attrs)
- ∀ id,a_2,e,a_1,t,attrs. wasEndedBy(id,a_2,e,a_1,t,attrs) ⟹ wasInfluencedBy(id,a_2,e,attrs)
- ∀ id,e,a,t,attrs. wasInvalidatedBy(id,e,a,t,attrs) ⟹ wasInfluencedBy(id,e,a,attrs)
- ∀ id,e_2,e_1,a,g,u,attrs. wasDerivedFrom(id,e_2,e_1,a,g,u,attrs) ⟹ wasInfluencedBy(id,e_2,e_1,attrs)
- In this rule, a, g, u may be placeholders -.∀ id,e,ag,attrs. wasAttributedTo(id,e,ag,attrs) ⟹ wasInfluencedBy(id,e,ag,attrs)
- In this rule, pl may be a placeholder -∀ id,a,ag,pl,attrs. wasAssociatedWith(id,a,ag,pl,attrs) ⟹ wasInfluencedBy(id,a,ag,attrs)
- ∀ id,ag_2,ag_1,a,attrs. actedOnBehalfOf(id,ag_2,ag_1,a,attrs) ⟹ wasInfluencedBy(id,ag_2,ag_1,attrs)
Inference 16 (alternate-reflexive)
∀ e. entity(e) ⟹ alternateOf(e,e)
Inference 17 (alternate-transitive)
∀ e_1,e_2,e_3. alternateOf(e_1,e_2) ∧ alternateOf(e_2,e_3) ⟹ alternateOf(e_1,e_3)
Inference 18 (alternate-symmetric)
∀ e_1,e_2. alternateOf(e_1,e_2) ⟹ alternateOf(e_2,e_1)
Inference 19 (specialization-transitive)
∀ e_1,e_2,e_3. specializationOf(e_1,e_2) ∧ specializationOf(e_2,e_3) ⟹ specializationOf(e_1,e_3)
Inference 20 (specialization-alternate-inference)
∀ e_1,e_2. specializationOf(e_1,e_2) ⟹ alternateOf(e_1,e_2)
Inference 21 (specialization-attributes-inference)
∀ e_1,attrs,e_2. entity(e_1,attrs) ∧ specializationOf(e_2,e_1) ⟹ entity(e_2,attrs)
