Web Ontology Language for description of Continuous Changes

Continuous changes are important piece of knowledge and common in sciences, robotics, and other domains which reason about mixed discrete-continuous systems. Descriptions of continuous changes, together with descriptions of objects and data, can be used for many forms of reasoning, e.g. simulation or prediction, planning, post-diction, and finding gaps in known information. Web ontology language for description of continuous changes or WOLCC is an ontology for the description of the quantitative aspects of continuous changes.KF12a

WOLCC can be used to describe the equations of temporal change in quantities, preconditions and boundary conditions that determine when the changes are active, and interaction between changes. Continuous changes may interact in various ways, e.g., changes active concurrently may affect the same quantities, and one set of changes may trigger another set of changes.

A system of continuous changes in the values of quantities (possibly associated with objects in the system) is perceived to progress over time as a sequence of states and actions. A state is characterized as a period where the truth values of qualities, relations, and properties of or between the objects involved in the system are fixed and values of quantities of the system are either fixed or subject to continuous change defined by a fixed set of equations. The fixed aspects of a state may be disturbed by external actions, which may cause discrete changes in the values of qualities (or relations or properties) and/or quantities, or when the system reaches a boundary for some equations. An event may be triggered when the system reaches a boundary condition, which may effect discrete changes in the values of qualities (or relations or properties) and/or quantities.

The core theory or the foundational theory for WOLCC is the Event Calculus (EC)MS96, KF12b. EC is a linear-time logic-based formalism for reasoning about actions and their effects. There is a single time line, and formulas are interpreted over the single time line in the linear time paradigm. In contrast, logic-based formalisms like Situation Calculus (SC) are based in the branching time paradigm. Each moment in time may split into various possible futures in the branching time paradigm. Time is tree-like, and formulas are interpreted over branches of a tree.

EC is a subset of multi-sorted first-order logic (or predicate calculus) which provides a fixed set of predicate constants, a reserved set of function symbols, a set of domain-independent axioms which define the semantics for the fixed and reserved constants, and a default reasoning strategy. Domain descriptions are axiomatized in EC framework through domain-specific axioms, defined using the fixed predicate constants and the reserved function symbols (new function symbols can be used).

We refer to the ontology languages and ontologies used for the description of qualities (or relations or properties), quantities, and actions as data modeling languages. WOLCC concerns only with temporal changes and is designed to be orthogonal to the data modeling languages. Any data modeling language whose constraint and inference axioms can be expressed in EC framework can be used with WOLCC. E.g., the data modeling languages based in Description Logic, e.g. OWL 2 with Direct Model Semantics, and Datalog with the standard first-order semantics can be used with WOLCC. Hybrid reasoning techniques may be used, in the future, for data modeling languages based in Datalog with the Herbrand semantics, Logic Programs, and Answer Set Programs, etc., which have a semantics different from the standard first-order model-theoretic semantics.

Domain-dependent axioms in EC are logic axioms, and RIF-FLD could be used for sharing web-ized domain descriptions. We, however, define a new set of elements for a number of reasons. a) WOLCC abstracts away some nuances of the underlying logic formalism for the domain experts. E.g., a domain description typically consists of following descriptions: effects of actions, action preconditions, constraints on effects of actions, constraints on occurrences of events, cumulative effect of concurrent actions, cancellation axioms, non-additive discontinuous changes, additive discontinuous changes, non-additive continuous changes, additive continuous changes, potential breaks in continuity of parameters, etc. WOLCC contains different elements for these types of descriptions. b) EC imposes little restrictions on how predicate constants may be used, and not every domain-dependent axiom that can be expressed in EC can be represented using the elements of WOLCC. But, controlled domain-dependent axioms is more efficient for designing a reasoner. c) By separating the description and the semantics, the domain descriptions in WOLCC can potentially be used with other logic-based formalisms that reason about actions and effects, e.g. SC, and even non-logic-based formalisms such as Hybrid Automaton.

An overview of the EC formalism and adaptation for interoperability with RDF-based descriptions is given on this page. In the following, we describe the elements of WOLCC, their presentation syntax in EBNF notation, and their semantics via a mapping into EC framework. We begin with an axiomatic description of a multiple tanks example.

The Water Tanks Example

watertanks.jpg
Fig 1. Configuration of Water Tanks. Courtesy Miller.M96

There are two open-top water tanks, Tank(A) and Tank(B), that have identical length and width. Tank(A) is suspended above Tank(B) and has two taps in the bottom, Tap(C) and Tap(D), that discharge water into Tank(B). Taps can be turned on and off. We assume that, through some unspecified mechanism, when Tank(B) begins to overflow, the open taps are triggered to be closed. Water can be scooped from Tank(A), which instantaneously reduces the level by quarter of the height of Tank(A). We assume that scoop happens only when water is above the mid-level. That way, two simultaneous scoops are always allowed.

The following constants symbols are used: TurnOn(C), TurnOn(D), TurnOff(C), TurnOff(D), Scoop(1), and Scoop(2) of sort A (Actions), Open(C) and Open(D) of sort F (Fluents), Level(A), Level(B), Height(A), and Height(B) of sort P (Parameters).

The direct effects of turning on and off taps and scooping are described as:

(T1) Initiates(TurnOn(x), Open(x), t)
(T2) Terminates(TurnOff(x), Open(x), t)
(T3) BreaksPartBy(Scoop(x), Level(A), t, un, -1 × Value(Height(A), t, un)/4)

The assumption regarding scoop is encoded as an action precondition.

(T4) Happens(Scoop(x), t) → Value(Level(A), t, un) ≥ Value(Height(A), t, un)/2

Open tap causes water to flow out of the taps and affects levels of water in both the tanks. Let K be the constant of proportionality between the level of water and the flow through either of the taps when open. (The DCAs are underlined.)

(T5) HoldsAt(Open(x), t) → PartValue(δ(Level(A)), t, x, un, -1× K × Value(Level(A), t, un))
(T6) HoldsAt(Open(x), t) → PartValue(δ(Level(B)), t, x, un, K × Value(Level(A), t, un))

When partial changes in Levels contributed by different taps, Tap(x), have same value, the term x uniquely identifies additive values from different sources.

The water levels are not affected if none of the taps are open.

(T7) ¬∃ x.HoldsAt(Open(x), t) → Value(δ(Level(A)), t, un) = 0
(T8) ¬∃ x.HoldsAt(Open(x), t) → Value(δ(Level(B)), t, un) = 0

When Tank(B) begins to overflow, the open taps are triggered to be closed.

(T9) [HoldsAt(Open(x), t) ∧ Value(Level(B), t, un) - Value(Height(B), t, un) = 0] → Happens(TurnOff(x), t)

Turning on or off taps potentially causes discontinuity in rate of outflow from Tank(A) and that of inflow to Tank(B).

(T10) Breaks(TurnOn(x), δ(Level(y)), t)
(T11) Breaks(TurnOff(x), δ(Level(y)), t)

It is important to explicitly enumerate all potential discontinuities in parameters caused by an action, to eliminate anomalous models of the domain. Explicit enumeration of potential discontinuities indirectly enumerates all parameters that remain continuous after the action has occurred. In absence of that, anomalous models, where, e.g., Level(A) instantaneously becomes zero (from a value significantly greater than zero) when one of the taps is turned off, are deduced.

Uniqueness-of-names are expressed using the UNA[...] notation, which states that functions in the argument are injections and have disjoint ranges.KF12b

(T12) UNA[TurnOn, TurnOff, Scoop] ∧ UNA[Open] ∧ UNA[Level, Height, δ]

The assumption regarding scoops, encoded in Axiom (T4), ensures that any two scoops have additive effects. A more general axiomatization of the direct effects of scoops is given below, using an abnormality predicate, Ab, such that, any number of simultaneous scoops are allowed and when the total amount scooped is more than that in the tank, the level becomes zero.

(T3') ¬Ab → BreaksPartBy(Scoop(s), Level, t, -1 × Value(Height(A), t, un)/4)
(T13) RightLimit(Level(A), t, s) ∧ s ≤ 0 → Ab
(T14) Ab → RightLimit(Level(A), t, 0)

Axiom (T3') replaces Axiom (T3).

(T1) ∧ ... ∧ (T14) are the domain-specific axioms, and the EC theory for the domain can be constructed using CIRCCECA policy. Note that, TESI[(T5) ∧ (T6)] = [(T5) ∧ (T6)], and no initial scenario or narrative were given.

CIRC[(T9) ∧ ... ; Happens] ∧ CIRC[(T1) ∧ (T2); Initiates, Terminates, Releases] ∧ CIRC[(T10) ∧ (T11) ∧ (EC11) ∧ (EC12) ∧ (EC17p); Breaks, BreaksTo] ∧ CIRC[(T3'); BreaksPartBy] ∧ CIRCA[(T5) ∧ (T6); PartValue] ∧ CIRC[(T13); Ab] ∧ [(T7) ∧ (T8) ∧ (EC18p)] ∧ (T4) ∧ (T14) ∧ (T12) ∧ (EC1) ∧ ... ∧ (EC15) ∧ (EC16p)

Abnormality predicates and cancellation axioms are not supported in the current version of WOLCC, however. Thus, we will just use (T3) in the remainder, instead of [(T3') ∧ (T13) ∧ (T14)].

WOLCC elements

The top non-terminal element is DOMAINDESCRIPTION. It lists different types of domain-dependent axioms that can be specified in WOLCC.

DOMAINDESCRIPTION ::= (ACTIONDESCRIPTIONCONSTRAINT | ADDITIVECONTINUOUSCHANGE | ALGEBRAICEQUATIONDECLARATION |BREAKINCONTINUITY | CONSTANTACTIONDESCRIPTION | CONSTANTQTYDESCRIPTION | CONSTANTQTYDESCRIPTION | DIRECTEFFECTOFACTION | EFFECTSDEPENDENCY |EVENTTRIGGER | NONADDITIVECONTINUOUSCHANGE | OBSERVATION | OCCURRENCE |OCCURRENCEPRECONDITION | QTYDESCRIPTIONSCONSTRAINT |RELATIONSCONSTRAINT)*

The EBNF for presentation syntax for these elements is covered over four parts that cover a) description of quanitities, relations (and qualities and properties), and actions (and events), b) description of direct effects of actions, c) description of continuous changes (and relationship between parameters), and d) data modeling constraints. The EBNF syntax is respectively given in Figures 2, 4, 6, and 8. Following that, the XML syntax is discussed very briefly. Finally, WOLCC does not stipulate any specific ontology for the description of quantities, relations, or actions, except for a few restrictions on the underlying logic formalism. We discuss a few restrictions on the ontologies or ontology languages used for their description, for compatibility with WOLCC.

The semantics of the WOLCC elements is given through mapping into EC. The mapping is defined using the Γ function, and an auxilliary function Λ. Γ(Ele) defines the mapping for element Ele. Optional arguments are used to pass context information such as time. (The Λ function is defined later.) The mappings for elements described in Figures 2, 4, 6, 8 is given in Figures 3, 5, 7, 9, respectively.

Quantities, Relations, Actions

Relations (and qualities and propeties) exist in all-or-none (e.g., tap is either on or off), whereas quantities admit of degrees (e.g., rate at which water flows through the tap can take a range of real values)GO94. Only scalar quantities are supported in the current version. Vector quantities can be expressed in terms of scalar quantities though. E.g., a three dimensional velocity vector can be decomposed into three scalar quantities for a particular choice of reference.

We refer to the ontology languages and ontologies used for the description of qualities, quantities, and actions as the data modeling languages. WOLCC is designed to be orthogonal to the data modeling languages, and a wide range of data modeling languages may be used for describing the data. The underlying logic formalism for WOLCC imposes a few restrictions on the data modeling languages, which we discuss later. The data modeling languages are responsible for uniqueness-of-names axioms like Axiom (T12).


 ACTIONDECLARATION ::= 'Action' '(' VARORIRI DESCRIPTION? ')'
 ALGEBRAICVALUE    ::= (* Algebraic-expression-over-reals-qtys-VALUEVAR *) 
 CONSTANTACTIONDESCRIPTION ::= 'Action' '(' IRIref DESCRIPTION ')'
 CONSTANTQTYDESCRIPTION    ::= 'Quantity' '(' IRIref DESCRIPTION ')'
 CONSTANTRELATION          ::= 'Relation' '(' TriplesBlock ')'  
 DERIVATIVEQTY     ::= 'Derivative' '(' VARORIRI ORDER QTYDECLARATION VALUEOFQTYREF* ')'
 DESCRIPTION       ::= 'Description' '(' TriplesBlock ')'
 OBSERVATION       ::= ('Neg')? 'HoldsAt' '(' RELATION TIME ')' 
                       | 'ValueAt' '(' QTYDECLARATION TIME UNIT VALUEDECLARATION ')'
 OCCURRENCE        ::= 'Happens' '(' TIME ACTIONDECLARATION ')'
 ORDER             ::= 'Order' (INTEGER)
 QTYDECLARATION    ::= 'Quantity' '(' VARORIRI DESCRIPTION?VALUEOFQTYREF* ')' | DERIVATIVEQTY  
 RELATION          ::= 'Relation' '(' TriplesBlock ')'
 TIME              ::= 'Time' ((DOUBLE UNIT) | '?t')
 UNIT              ::= 'Unit' (VARORIRI | '?un')
 VALUEDECLARATION  ::= 'HasValue' '(' QTYDECLARATION* ('Value' '(' ALGEBRAICVALUE ')') ')'
 VALUEOFQTYREF     ::= 'QValueRef' '(' QVALUEVAR TIME UNIT ')'
 VALUEVAR          ::= Var
 VARORIRI          ::= Var | IRIref

DOUBLE, INTEGER, IRIref, TriplesBlock, Var as defined in the SPARQL Grammar

Fig 2. Presentation syntax for declaring quantities, relations, and actions.

RELATIONs are denoted by SPARQL BGP-like triple patterns (for obvious reasons). E.g., the quality that a variable tap is open can be declared as { ?x rdf:type xyz:Tap, xyz:Open . }, in the Turtle syntax. Quantities and actions are denoted by IRIs or variable symbols, and optionally associated with triple patterns for their description. E.g., the quantity denoting height of a tank can be declared as Quantity(?q Description({ ?y rdf:type xyz:Tank ; xyz:hasQuantity ?q . ?q xyz:measureOf xyz:Height .}) QValueRef(?qv Time(?t) Unit(xyz:Meter))). VALUEOFQTYREF can be used to create a variable reference to the value of a quantity, in a given unit, at a given time, like ?qv, which equals Value(?q, ?t, xyz:Meter) in EC notation. The first derivative of the height can be declared as Derivative(?dq Order(1) Quantity(?q Description({ ?y rdf:type xyz:Tank ; xyz:hasQuantity ?q . ?q xyz:measureOf xyz:Height .})) QValueRef(?qdv Time(?t) Unit(xyz:MeterPerSecond))). An act of turning on a tap can, e.g., be denoted as Action(?a Description({ ?x rdf:type xyz:Tap . ?a rdf:type xyz:TurnOnAction ; xyz:hasObject ?x .})). Observations regarding the truth values of relations and the values of quantities can be declared using OBSERVATION, and an occurrence of action can be declared using OCCURRENCE. The TIME is assumed to be in the units of Seconds.

As noted earlier, time-varying relations and quantities are not differentiated from time-independent relations and quantities, and association of quantities with objects, but such a distinction is not precluded by present choices.

The auxilliary function used for the mapping in to EC is defined as follows. Λ(X), where X is a ACTIONDECLARATION or a QTYDECLARATION, returns the VARORIRI that identify the action or quantity in X.

The HoldsAt predicate specifies that a triple pattern is true at some time, e.g. HoldsAt(T(S, P, O), Ti). The short-hand notation HoldsAt(TriplesBlock, Ti) stands for ni-1HoldsAt(T(Si, Pi, Oi), Ti), where TriplesBlock is a collection of n triples, { Si, Pi, Oi }, for some n ≥ 1. The short-hand notations HoldsAtA(TriplesBlock, Ti), Initiates(Act, TriplesBlock, Ti), and Terminates(Act, TriplesBlock, Ti) are defined similarly.

 Γ(ACTIONDECLARATION, t) := HoldsAtA(Γ(DESCRIPTION), t)
 Γ(ALGEBRAICVALUE) := (* Replace-any-qty-by-EC-notation-Value(qty, ?t, ?un) *)
 Γ(CONSTANTACTIONDESCRIPTION) := HoldsAtA(Γ(DESCRIPTION), ?t)
 Γ(CONSTANTQTYDESCRIPTION) := HoldsAt(Γ(DESCRIPTION), ?t)
 Γ(CONSTANTRELATION) := HoldsAt(Γ(TriplesBlock), ?t)
 Γ(DERIVATIVEQTY, t) := Γ(QTYDECLARATION, t) ∧ Γ(VALUEOFQTYREF, VARORIRI) ∧ 
                         [Γ(VARORIRI) = δΓ(ORDER)(Λ(QTYDECLARATION))]
 Γ(DESCRIPTION) := TriplesBlock
 Γ(OBSERVATION) := HoldsAt(RELATION, TIME) | ¬ HoldsAt(RELATION, TIME) 
                   | [Γ(QTYDECLARATION, TIME) ∧ Γ(VALUEDECLARATION, TIME, ?nv) 
                      ∧ Value(Λ(QTYDECLARATION), TIME, UNIT) = ?nv]
 Γ(OCCURRENCE) := Γ(ACTIONDECLARATION, Γ(TIME)) ∧ Happens(Λ(ACTIONDECLARATION), Γ(TIME))
 Γ(ORDER) := INTEGER
 Γ(QTYDECLARATION, t) := HoldsAt(Γ(DESCRIPTION), t) ∧ (Γ(VALUEOFQTYREF), VARORIRI)
 Γ(RELATION, t) := HoldsAt(Γ(TriplesBlock), t)
 Γ(TIME) := (double-in-units-of-seconds) | ?t
 Γ(UNIT) := Γ(VARORIRI) | ?un
 Γ(VALUEDECLARATION, t, ?nv) := Γ(QTYDECLARATION, t) ∧ ?nv = Γ(ALGEBRAICVALUE)
 Γ(VALUEOFQTYREF, qty) := Γ(QVALUEVAR) = Value(qty, Γ(TIME), Γ(UNIT))
 Γ(VALUEVAR) := Var
 Γ(VARORIRI) := Var | IRIref

Fig 3. Definition of Γ function for the elements used for declaring quantities, relations, and actions.

Γ(QTYDECLARATION, t) and Γ(ACTIONDECLARATION, t) for the above example QTYDECLARATIONs and ACTIONDECLARATION are given below:

[HoldsAt(T(?y, rdf:type, xyz:Tank), Ti) ∧ HoldsAt(T(?y, xyz:hasQuantity, ?q), Ti) ∧ HoldsAt(T(?q, xyz:measureOf, xyz:Height), Ti)] ∧ ?qv = Value(?q, ?t, xyz:Meter).
[HoldsAt(T(?y, rdf:type, xyz:Tank), Ti) ∧ HoldsAt(T(?y, xyz:hasQuantity, ?q), Ti) ∧ HoldsAt(T(?q, xyz:measureOf, xyz:Height), Ti)] ∧ ?dq = δ1(?q) ∧ ?qdv = Value(?dq, ?t, xyz:MeterPerSecond).
[Happens(?a, Ti) ∧ HoldsAtA(T(?x, rdf:type, xyz:Tap), Ti) ∧ HoldsAtA( T(?a, rdf:type, xyz:TurnOnAction), Ti) ∧ HoldsAtA(T(?a, xyz:hasObject, ?x), Ti)].

Furthermore, HoldsAt(Γ(RELATION), TIME), for the above example RELATION is given below:

[HoldsAt(T(?x, rdf:type, xyz:Tap), Ti) ∧ HoldsAt(T(?x, rdf:type, xyz:Open), Ti)].

The descriptions of actions, quantities, and fluents used in the water tanks example are given below.

E.g., CONSTANTACTIONDESCRIPTIONs:

  Action(ns:TurnOnActionC Description({ ns:TurnOnActionC 
            rdf:type xyz:TurnOnAction ; xyz:hasObject ns:TapC .} ))
  Action(ns:TurnOnActionD Description({ ns:TurnOnActionD 
            rdf:type xyz:TurnOnAction ; xyz:hasObject ns:TapD .}))
  Action(ns:TurnOffActionC Description({ ns:TurnOffActionC 
            rdf:type xyz:TurnOffAction ; xyz:hasObject ns:TapC .}))
  Action(ns:TurnOffActionD Description({ ns:TurnOffActionD 
            rdf:type xyz:TurnOffAction ; xyz:hasObject ns:TapD .}))
  Action(ns:Scoop1 Description({ ns:Scoop1 rdf:type xyz:ScoopAction .}))
  Action(ns:Scoop2 Description({ ns:Scoop2 rdf:type xyz:ScoopAction .}))

E.g., CONSTANTQTYDESCRIPTIONs:

 Quantity(ns:HeightA Description({ ns:TankA xyz:hasQuantity ns:HeightA . 
                                   ns:HeightA xyz:measureOf xyz:Height .}))
 Quantity(ns:HeightB Description({ ns:TankB xyz:hasQuantity ns:HeightB . 
                                   ns:HeightB xyz:measureOf xyz:Height .}))
 Quantity(ns:LevelA Description({ ns:ContainedWaterA xyz:hasQuantity ns:LevelA . 
                                  ns:LevelA xyz:measureOf xyz:Level .}))
 Quantity(ns:LevelB Description({ ns:ContainedWaterB xyz:hasQuantity ns:LevelB . 
                                  ns:LevelB xyz:measureOf xyz:Level .}))

E.g., CONSTANTQTYDESCRIPTIONs:

 Relation({ ns:TankA rdf:type xyz:Tank .})
 Relation({ ns:TankB rdf:type xyz:Tank .})
 Relation({ ns:TapC rdf:type xyz:Tap .})
 Relation({ ns:TapD rdf:type xyz:Tap .})
 Relation({ ns:ContainedWaterA rdf:type xyz:ContainedLiquid ; xyz:containedIn ns:TankA .})
 Relation({ ns:ContainedWaterB rdf:type xyz:ContainedLiquid ; xyz:containedIn ns:TankB .})

To illustrate observations and occurrences, we assume the following observations,

¬ HoldsAt(Open(C), 0) ∧ ¬ HoldsAt(Open(D), 0) ∧ Value(Height(A), t, xyz:Meter) = 2 ∧ Value(Level(A), 0, xyz:Meter) = 1.5,

and the occurrence, Happens(TurnOn(C), 20).

E.g., OBSERVATIONs:

 Neg HoldsAt({ ns:TapC rdf:type xyz:Open .} Time(0))
 Neg HoldsAt({ ns:TapD rdf:type xyz:Open .} Time(0))

 ValueAt(
   Quantity(ns:HeightA)
   Time(?t)
   Unit(xyz:Meter)
   HasValue(Value(2)))

 ValueAt(
   Quantity(ns:LevelA)
   Time(0)
   Unit(xyz:Meter)
   HasValue(Value(1.5)))

E.g., OCCURRENCEs:

 Happens(Time(20) Action(ns:TurnOnActionC))

Effects of Actions


 ALGEBRAICCONSTRAINT      ::= (* Algebraic-inequality-or-equality-over-reals-qtys-VALUEVAR *)
 CONDITION                ::=  CONSTRAINTONSTATE?('ConditionOnCooccurrence' '(' 
                                               CONDITIONONCOOCCURRENCE ')')?  
 CONDITIONONCOOCCURRENCE  ::= CONNECTIVE '(' CONDITIONONCOOCCURRENCE* ')' 
                              | QUANTIFIER '(' CONDITIONONCOOCCURRENCE ')' 
                              | 'Neg' CONDITIONONCOOCCURRENCE 
                              | ACTIONDECLARATION
 CONDITIONONQTY           ::= QTYDECLARATION+ ('ValueConstraint' '(' ALGEBRAICCONSTRAINT ')')
 CONDITIONONRELATION      ::= CONNECTIVE '(' CONDITIONONRELATION* ')' 
                              | QUANTIFIER '(' CONDITIONONRELATION ')'
                              | 'Neg' CONDITIONONRELATION 
                              | RELATION
 CONSTRAINTONSTATE        ::= 'ConstraintOnState' '(' CONDITIONONRELATION? CONDITIONONQTY? ')'
 DIRECTEFFECTOFACTION     ::= 'Effect' '(' IRIref? ACTIONDECLARATION (FLUENTINITIATION 
                                    | FLUENTTERMINATION | QTYNEWVALUE | QTYADDITIVECHANGEINVALUE) ')'
 EFFECTSDEPENDENCY        ::= 'ConstraintOnEffectsOfActions' '(' IRIref? ACTIONDECLARATION CONDITION 
                                             'Implies' '(' FLUENTINITORTERM  FLUENTINITORTERM ')' ')'
 FLUENTINITORTERM         ::= 'FluentInitiation' '(' RELATION ')' | 'FluentTermination' '(' RELATION ')'
 FLUENTINITIATION         ::= 'FluentInitiation' '(' RELATION CONDITION ')'
 FLUENTTERMINATION        ::= 'FluentTermination' '(' RELATION CONDITION ')'
 OCCURRENCEPRECONDITION   ::= 'OccurrencePrecondition' '(' ACTIONDECLARATION CONSTRAINTONSTATE ')' 
 QTYADDITIVECHANGEINVALUE ::= 'AdditiveChangeInValue' '(' QTYDECLARATION UNIT 
                                                        VALUEDECLARATION CONDITION ')'  
 QTYNEWVALUE              ::= 'NewValue' '(' QTYDECLARATION UNIT  VALUEDECLARATION CONDITION ')'

CONNECTIVE, QUANTIFIER as defined in RIF-FLD.

Fig 4. Presentation syntax for describing the direct effects of actions.

The short-hand notation HoldsAt(CONDITIONONRELATION, Ti)
stands for a formula obtained by combining HoldsAt(TriplesBlock, Ti) using logical connectives and quantifier as TriplesBlocks (or RELATIONs) in the TriplesBlockFormula are combined.

The short-hand notation Happens(ConditionOnOccurrences, Ti) stands for a formula obtained by combining [Γ(ACTIONDECLARATION, Ti) ∧ Happens(Λ(ACTIONDECLARATION), Ti)] using logical connectives and quantifier as ACTIONDECLARATIONs in the ConditionOnOccurrences.

  Γ(ALGEBRAICCONSTRAINT) := (* Replace-any-qty-by-EC-notation-Value(qty, ?t, ?un) *)
  Γ(CONDITION, t) := Γ(CONSTRAINTONSTATE, t) ∧ Γ(CONDITIONONCOOCCURRENCE, t)
  Γ(CONDITIONONQTY, t) := Γ(QTYDECLARATION, t) ∧ Γ(ALGEBRAICCONSTRAINT)
  Γ(CONDITIONONRELATION, t) := HoldsAt(CONDITIONONRELATION, t)
  Γ(CONSTRAINTONSTATE, t) := Γ(CONDITIONONRELATION, t) ∧ Γ(CONDITIONONQTY, t)
  Γ(DIRECTEFFECTOFACTION, t) := Γ(FLUENTINITIATION, t, ACTIONDECLARATION) 
                           | Γ(FLUENTTERMINATION, t, ACTIONDECLARATION) 
                           | Γ(QTYNEWVALUE, t, ACTIONDECLARATION) 
                           | Γ(QTYADDITIVECHANGEINVALUE, t, ACTIONDECLARATION)
  Γ(EFFECTSDEPENDENCY) := [Γ(ACTIONDECLARATION, ?t) ∧ Γ(CONDITION, ?t) 
                           ∧ Γ(FLUENTINITORTERM, ?t, Λ(ACTIONDECLARATION))] 
                           → Γ(FLUENTINITORTERM, ?t, Λ(ACTIONDECLARATION))
  Γ(FLUENTINITORTERM, t, Act) := Initiates(Act, RELATION, t) | Terminates(Act, RELATION, t)
  Γ(FLUENTINITIATION, t, ActDecl) := [Γ(ActDecl, t) ∧ Γ(CONDITION, t)] 
                                    → Initiates(Λ(ActDecl), RELATION, t)
  Γ(FLUENTTERMINATION, t, ActDecl) := [Γ(ActDecl, t) ∧ Γ(CONDITION, t)] 
                                    → Terminates(Λ(ActDecl), RELATION, t)
  Γ(OCCURRENCEPRECONDITION, t) := [Γ(ACTIONDECLARATION, t) ∧ Happens(Λ(ACTIONDECLARATION), t)] 
                                       → Γ(CONSTRAINTONSTATE, t)
  Γ(QTYADDITIVECHANGEINVALUE, t, ActDecl) := [Γ(ActDecl, t) ∧ Γ(QTYDECLARATION, t) ∧ Γ(CONDITION, t) 
                           ∧ Γ(VALUEDECLARATION, t, ?nv)] → BreaksPartBy(Λ(ActDecl), t, Γ(UNIT), ?nv)
  Γ(QTYNEWVALUE, t, ActDecl) := [Γ(ActDecl, t) ∧ Γ(QTYDECLARATION, t) ∧ Γ(CONDITION, t) 
                           ∧ Γ(VALUEDECLARATION, t, ?nv)] → BreaksTo(Λ(ActDecl), t, Γ(UNIT), ?nv)

Fig 5. Definition of Γ function for the elements used for defining the direct effects of actions.

We describe the axioms defined in the water tanks example using the WOLCC syntax.

E.g., DIRECTEFFECTOFACTION given by Axioms (T1), (T2), and (T3) can be described as:

 Effect(
   Action(?a Description({ ?a rdf:type xyz:TurnOnAction ; xyz:hasObject ?tap .})
   FluentInitiation({ ?tap rdf:type xyz:OpenTap .}))

 Effect(
   Action(?a Description({ ?a rdf:type xyz:TurnOffAction ; xyz:hasObject ?tap .})
   FluentTermination({ ?tap rdf:type xyz:OpenTap .}))

 Effect(
   Action(?a Description({ ?a rdf:type xyz:ScoopAction .})
   AdditiveChangeInValue(
     Quantity(ns:LevelA)
     Unit(?un)
     HasValue(
       Quantity(ns:HeightA)
       Value(-1 × ns:HeightA/4))))

The water tank example axiomatization contains no effect dependencies. But, consider the following effect dependency. If an object o is placed inside another object x, which itself is inside another object y, then o is also placed inside y.

[HoldsAt(In(x, y), t) ∧ Initiates(PlaceIn(o, x), In(o, x), t)] → Initiates(PlaceIn(o, x), In(o, y), t)

Then, the EFFECTSDEPENDENCY given above can be described as:

 ConstraintsOnEffectsOfActions(
   Action(?a Description({ ?a rdf:type xyz:PlaceInAction ; xyz:targetObject ?o ; xyz:destination ?x .})
   ConstraintOnState({ ?x xyz:in ?y .})
   Implies(
     FluentInitiation({ ?o xyz:in ?x .})
     FluentInitiation({ ?o xyz:in ?y .})))

E.g., OCCURRENCEPRECONDITION given by Axiom (T4) can be described as:

 OccurrencePrecondition(
   Action(?a Description({ ?a rdf:type xyz:ScoopAction .})
   ConstraintOnState(
     Quantity(ns:LevelA)
     Quantity(ns:HeightA)
     ValueConstraint(ns:LevelA ≥ (ns:HeightA/2))))

Continuous Change


 ACTIVECONDITION   ::= 'ActiveWhen' '(' CONDITIONONRELATION?CONDITIONONQTY? ')'
 ADDITIVECONTINUOUSCHANGE ::= 'AdditiveContinuousChange' '(' IRIref QUANTITYDECLARATION UNIT 
                                     VALUEDECLARATION DCA ACTIVECONDITION INSIDEBOUNDARY? ')'
 ALGEBRAICEQUATION ::= (* Algebraic-equation-over-reals-qtys-VALUEVAR *)
 ALGEBRAICEQUATIONDECLARATION ::= 'AlgebraicRelationship' '(' QUANTITYDECLARATION+ 
                                     ('Equation' '(' ALGEBRAICEQUATION ')') CONSTRAINTONSTATE? ')'
 BREAKINCONTINUITY ::= 'BreakInContinuity' '(' IRIref ACTIONDECLARATION QTYDECLARATION CONDITION ')'
 DCA               ::= 'DisambiguatedBy' '(' VARORIRI ')'
 EVENTTRIGGER      ::= 'EventTrigger' '(' IRIref ACTIONDECLARATION CONDITION ')'
 INSIDEBOUNDARY    ::= 'WithinBoundaryWhen' '(' CONDITIONONQTY ')'
 NONADDITIVECONTINUOUSCHANGE  ::= 'NonAdditiveContinuousChange' '(' IRIref QUANTITYDECLARATION+ 
                                     ('ODE' '(' ODE ')') ACTIVECONDITION INSIDEBOUNDARY? ')'  
 ODE               ::= (* ordinary-differential-equation-over-qtys *)

Fig 6. Presentation syntax for describing continuous changes.

 Γ(ACTIVECONDITION, t) := Γ(CONDITIONONRELATION, t) ∧ Γ(CONDITIONONQTY, t)
 Γ(ADDITIVECONTINUOUSCHANGE) := [Γ(QUANTITYDECLARATION, ?t) ∧ Γ(VALUEDECLARATION, ?t, ?nv) 
                                 ∧ Γ(ACTIVECONDITION, ?t) ∧ Γ(INSIDEBOUNDARY, ?t)] 
                                → PartValue(Λ(QUANTITYDECLARATION), ?t, Γ(DCA), Γ(UNIT), ?nv)
 Γ(ALGEBRAICEQUATION) := (* Replace-any-qty-by-EC-notation-Value(qty, ?t, ?un) *)
 Γ(ALGEBRAICEQUATIONDECLARATION) := [Γ(CONSTRAINTONSTATE, ?t) ∧ Γ(QUANTITYDECLARATION, ?t)] 
                                 → Γ(ALGEBRAICEQUATION)
 Γ(BREAKINCONTINUITY) := [Γ(ACTIONDECLARATION, ?t) ∧ Γ(QTYDECLARATION, ?t) ∧ Γ(CONDITION, ?t)] 
                                 → Breaks(Λ(ACTIONDESCRIPTION, ?t), Λ(QTYDECLARATION), ?t)
 Γ(DCA) := Γ(VARORIRI)
 Γ(EVENTTRIGGER) := [Γ(CONDITION, ?t) ∧ Γ(ACTIONDECLARATION, ?t)] → Happens(Λ(ACTIONDECLARATION), ?t)
 Γ(INSIDEBOUNDARY, ?t) := Γ(CONDITIONONQTY, ?t)
 Γ(NONADDITIVECONTINUOUSCHANGE) := [Γ(QUANTITYDECLARATION, ?t) ∧ Γ(ACTIVECONDITION, ?t)
                                 ∧ Γ(INSIDEBOUNDARY, ?t)] → Γ(ODE) 
 Γ(ODE) := (* Replace-any-qty-by-EC-notation-Value(qty, ?t, ?un) *)

Fig 7. Definition of Γ function for the elements used for describing continuous changes.

E.g., ADDITIVECONTINUOUSCHANGE given by Axioms (T5) and (T6) can be described as:


 AdditiveContinuousChange(
   Derivative(?dq Order(1) Quantity(ns:LevelA))
   Unit(?un)
   ActiveWhen({ ?x rdf:type :Tap, :Open .})
   DisambiguatedBy(?x)  
   HasValue(
     Quantity(ns:LevelA)
     Value(-1 × K × ns:LevelA)))

 AdditiveContinuousChange(
   Derivative(?dq Order(1) Quantity(ns:LevelB))
   Unit(?un)
   ActiveWhen({ ?x rdf:type :Tap, :Open .})
   DisambiguatedBy(?x)  
   HasValue(
     Quantity(ns:LevelA)
     Value(K × ns:LevelA)))

The water tanks example axiomatization contains no algebraic equations. But, consider the following relationship between friction forces on the two blocks in contact. If a block b1 is on top of another block b2 then the friction force applied by b2 on b1 (Fr(b1, b2)) and that by b1 on b2 are equal in value and opposite in direction.

Holds(On(b1, b2), t) → Value(Fr(b1, b2), t) = -1 × Value(Fr(b2, b1), t)

Then, the ALGEBRAICEQUATIONDECLARATION given above can be described as:

 AlgebraicRelationship(
   Quantity(?f1 Description({ ?f1 rdf:type xyz:FrictionForce ; xyz:forceBy ?b2 ; xyz:forceOn ?b1 .})) 
   Quantity(?f2 Description({ ?f2 rdf:type xyz:FrictionForce ; xyz:forceBy ?b1 ; xyz:forceOn ?b2 .})) 
   Equation(?f1 = -1 × ?f2)
   ConstraintOnstate({ ?b1 xyz:on ?b2 .}))

E.g., BREAKINCONTINUITY given by Axioms (T10) and (T11) can be described as:

 BreakInContinuity(
   Action(?a Description({ ?a rdf:type xyz:TurnOnAction .}))
   Derivative(
     ?dq 
     Order(1) 
     Quantity(?q Description({ ?x rdf:type xyz:ContainedLiquid ;
                                  xyz:hasQuantity ?q . ?q xyz:measureOf xyz:Level .})))

 BreakInContinuity(
   Action(?a Description({ ?a rdf:type xyz:TurnOffAction .}))
   Derivative(
     ?dq 
     Order(1) 
     Quantity(?q Description({ ?x rdf:type xyz:ContainedLiquid ;
                                  xyz:hasQuantity ?q . ?q xyz:measureOf xyz:Level .})))   

E.g., EVENTTRIGGER given by Axioms (T7) and (T8) can be described as:


 EventTrigger(
   Action(?a Description({ ?x rdf:type ?Tap . 
                           ?a rdf:type ?xyz:TurnOffAction ; xyz:hasObject ?x .}))
   ConstraintOnstate(
     { ?x rdf:type xyz:Open .}
     Quantity(ns:LevelB)
     Quantity(ns:HeightB)
     ValueConstraint((ns:LevelB - ns:HeightB) = 0)))

E.g., NONADDITIVECONTINUOUSCHANGE given by Axioms (T7) and (T8) can be described as:

 NonAdditiveContinuousChange(
   Derivative(?dq Order(1) Quantity(ns:LevelA))
   ActiveCondition((Neg EXIST ?x ({ ?x rdf:type xyz:Tap, xyz:Open .})))  
   ODE(?dq = 0))

 NonAdditiveContinuousChange(
   Derivative(?dq Order(1) Quantity(ns:LevelB))
   ActiveCondition((Neg EXIST ?x ({ ?x rdf:type xyz:Tap, xyz:Open .})))  
   ODE(?dq = 0))

Interoperability with Data Modeling Languages

WOLCC is interpreted via EC, which is based in first-order logic and deploys circumscription for default reasoning. But, no default assumption is directly associated with the predicates of HoldsAt and HoldsAtA. Therefore, data modeling languages with standard first-order semantics can be readily used (for the description of quantities, relations, and actions). E.g., data modeling languages based in Description Logic (e.g., OWL DL or OWL 2 with Direct Semantics) and datalog with a standard first-order semantics (e.g., RIF-BLD) can be used with WOLCC. In other cases, some kind of hybrid reasoning may be considered. E.g., modeling languages based in datalog with Herbrand semantics cannot be used directly.

The axiomatization of first-order logic based data modeling languages can be replicated in the EC framework, albeit with reification of predicates. E.g., the prp-fp rule from OWL 2 RL/RDF rules,

T(?p, rdf:type, owl:FunctionalProperty) ∧ T(?x, ?p, ?y1) ∧ T(?x, ?p, ?y2) → T(?y1, owl:sameAs, ?y2),

interpreted under the OWL 2 Direct Semantics, can be formulated in the EC framework as:

[HoldsAt(T(?p, rdf:type, owl:FunctionalProperty), ?t) ∧ HoldsAt(T(?x, ?p, ?y1), ?t) ∧ HoldsAt(T(?x, ?p, ?y2), ?t)] → ?y1 = ?y2.

Other OWL 2 RL/RDF rules can be described in EC similarly.


 ACTIONDESCRIPTIONSCONSTRAINT ::= 'ConstraintOnActionDescriptions' '(' IMPLIESCONSTRAINT
                                                                    | EQUIVALENTCONSTRAINT 
                                                                    | SAME | DIFFERENT ')'
 DIFFERENT                    ::= VARORIRI ≠ VARORIRI
 EQUIVALENCECONSTRAINT        ::= 'Equivalent' '(' TRIPLESBLOCKFORMULA TRIPLESBLOCKFORMULA ')'
 IMPLIESCONSTRAINT            ::= 'Implies' '(' TRIPLESBLOCKFORMULA   TRIPLESBLOCKFORMULA ')'
 QTYDESCRIPTIONSCONSTRAINT    ::= 'ConstraintOnQuantityDescriptions' '(' IMPLIESCONSTRAINT 
                                                                    | EQUIVALENTCONSTRAINT 
                                                                    | SAME | DIFFERENT ')'
 RELATIONSCONSTRAINT          ::= 'ConstraintOnRelations' '('    IMPLIESCONSTRAINT 
                                                                    | EQUIVALENTCONSTRAINT 
                                                                    | SAME | DIFFERENT ')'
 SAME                         ::= VARORIRI '=' VARORIRI
 TRIPLESBLOCKFORMULA          ::= CONNECTIVE '(' TRIPLESBLOCKFORMULA ')' 
                                  | QUANTIFIER '(' TRIPLESBLOCKFORMULA ')' 
                                  | 'Neg' TRIPLESBLOCKFORMULA 
                                  | TriplesBlock | SAME | DIFFERENT  

Fig 8. Presentation syntax for describing the constraints of data modeling languages.

 Γ(ACTIONDESCRIPTIONSCONSTRAINT) := Γ(IMPLIESCONSTRAINT, HoldsAtA) 
                                | Γ(EQUIVALENTCONSTRAINT, HoldsAtA) 
                                | Γ(SAME) | Γ(DIFFERENT)
 Γ(DIFFERENT) := Γ(VARORIRI) ≠ Γ(VARORIRI)
 Γ(EQUIVALENCECONSTRAINT, Pred) := Γ(TRIPLESBLOCKFORMULAOREQUALITY, Pred) 
                                ↔ Γ(TRIPLESBLOCKFORMULAOREQUALITY, Pred)
 Γ(IMPLIESCONSTRAINT) := Γ(TRIPLESBLOCKFORMULAOREQUALITY, Pred) 
                                → Γ(TRIPLESBLOCKFORMULAOREQUALITY, Pred)
 Γ(QTYDESCRIPTIONSCONSTRAINT) := Γ(IMPLIESCONSTRAINT, HoldsAt) | Γ(EQUIVALENTCONSTRAINT, HoldsAt) 
                                | Γ(SAME) | Γ(DIFFERENT)
 Γ(RELATIONSCONSTRAINT) := Γ(IMPLIESCONSTRAINT, HoldsAt) | Γ(EQUIVALENTCONSTRAINT, HoldsAt) 
                                | Γ(SAME) | Γ(DIFFERENT)
 Γ(SAME := Γ(VARORIRI) = Γ(VARORIRI)
 Γ(TRIPLESBLOCKFORMULAOREQUALITY, Pred) =  Pred(Γ(TRIPLESBLOCKFORMULA, ?t) | Γ(SAME) | Γ(DIFFERENT)

Fig 9. Definition of Γ function for the elements used for describing the constraints of data modeling languages.

E.g., the unique name assertions given by Axioms (T12) can be described using ACTIONDESCRIPTIONCONSTRAINT as follows:


 ConstraintOnActionDescriptions(
   Implies(({ ?a1 rdf:type xyz:TurnOnAction . ?a2 rdf:type xyz:TurnOffAction .}) (?a1 ≠ ?a2)))
 ConstraintOnActionDescriptions(
   Implies(And(({ ?a1 rdf:type xyz:TurnOnAction ; xyz:hasObject ?tap1 . 
                 ?a2 rdf:type xyz:TurnOnAction ; xyz:hasObject ?tap2 .}) (?a1 = ?a2)) 
           (?tap1 = ?tap2)))

Other unique name assumptions in UNA[TurnOn, TurnOff, Scoop] can be asserted similarly. Also, QTYDESCRIPTIONSCONSTRAINT for UNA[Level, Height, δ] and RELATIONSCONSTRAINT for UNA[Open] can be defined similarly.

We could alternatively assert disjoint resources.

 ConstraintOnActionDescriptions(ns:TurnOnActionC ≠ ns:TurnOnActionD)
 ConstraintOnActionDescriptions(ns:TurnOnActionC ≠ ns:TurnOffActionC)

We can also assert that xyz:hasObject is a functional property.

 ConstraintOnActionDescriptions(({ ?a xyz:hasObject ?tap1 . ?a xyz:hasObject ?tap2 .} (?tap1 = ?tap2)).

XML representation

An XML serialization of knowledge described using WOLCC follows straightforwardly from the presentation syntax. The content markup of MathML can be used for serializing math formulas. We are not aware of any standards for XML serialization of RDF triple patterns with variables. In absence of a standard, we first undo any short-hand notation used in the TriplesBlock descriptions. E.g., {?x xyz:hasValue 10, 20; ?p ?o .} is expanded into {?x xyz:hasValue 10 . ?x xyz:hasValue 20 . ?x ?p ?o .}. Then, subject, predicate, and object are marked inside a triple-pattern element. E.g., {?x xyz:hasValue 10 .} is marked as shown below.

 <triple-pattern>
  <sub><Var>X</Var></sub>
  <pred><Const type="&rif;iri">&xyz;hasValue</Const></pred>
  <obj><Const type="&xsd;Integer">&xyz;hasValue</Const></obj>
 </triple-pattern>