Enhancing Probabilistic Model Checking with Ontologies

Probabilistic model checking (PMC) is a well-established method for the quantitative analysis of state based operational models such as Markov decision processes. Description logics (DLs) provide a well-suited formalism to describe and reason about knowledge and are used as basis for the web ontology language (OWL). We investigate how such knowledge described by DLs can be integrated into the PMC process, introducing ontology-mediated PMC. Specifically, we propose ontologized programs as a formalism that links ontologies to behaviors specified by probabilistic guarded commands, the de-facto standard input formalism for PMC tools such as Prism. Through DL reasoning, inconsistent states in the modeled system can be detected. We present three ways to resolve these inconsistencies, leading to different Markov decision process semantics. We analyze the computational complexity of checking whether an ontologized program is consistent under these semantics. Further, we present and implement a technique for the quantitative analysis of ontologized programs relying on standard DL reasoning and PMC tools. This way, we enable the application of PMC techniques to analyze knowledge-intensive systems.We evaluate our approach and implementation on amulti-server systemcase study,where different DL ontologies are used to provide specifications of different server platforms and situations the system is executed in.


Introduction
Probabilistic model checking (PMC) is an automated technique for the quantitative analysis of systems (see for example [BK08,FKNP11] for surveys). PMC has been successfully applied in many areas to verify non-functional quality requirements such as energy efficiency or low probabilities of failure. Probabilistic guarded command (PGC) programs rely on a probabilistic variant of Dijkstra's guarded command language [Dij76,JSM97] and provide the de-facto standard specification formalism for PMC used in many PMC tools such as Prism [KNP11] and Storm [DJKV17].
Usually, the behavior described by a PGC program is part of a larger system, or might even be used within a collection of systems that have an impact on the operational behavior. There are different ways how to model such Correspondence to: Clemens Dubslaff, E-mail: clemens.dubslaff@tu-dresden.de The Author(s) © 2021 distributed systems with PGC programs. First, we could integrate additional knowledge about the surrounding system directly into the program. While this approach benefits from the full expressiveness of PGC programs, it has the disadvantage that guarded command languages are not well-suited for describing complex knowledge about the contexts. Alternatively, we could use the concept of nondeterminism to over-approximate the possible behaviors of the surrounding system. This approach, however, leads to a coarse model that does not fully specify the impact of the context onto the system described by PGC programs. When it comes to verifying the overall system, a best-and worst-case PMC analysis might then not allow for meaningful interpretation.
In this paper, we propose a third option, an approach we call ontology-mediated PMC where we separate the specification of the operational behavior of a system from the specification of the additional knowledge that influences the behavior. This allows us to use different, specialized formalisms for describing the operational behavior and knowledge about the surrounding system. As knowledge description formalism, we use the wellestablished family of description logics (DLs). DLs are fragments of first-order logic balancing expressivity and decidability [BCM + 03, BHLS17]. While the worst-case complexity for DL reasoning can be very high, modern optimized systems often allow to reason about very large knowledge bases in short time [PMG + 17]. Logical theories formulated in a DL are called ontologies, hence the naming of ontology-mediated PMC: knowledge expressed in ontologies mediate the PMC process.
The core of our approach relies on ontologized PGC programs, which formalize the idea of completely separating concerns to describe operational behavior by PGC programs and knowledge by ontologies. To specify the interplay between both formalisms, we use the concept of an interface. The interface mediates between these two worlds by providing mappings from PGC statements to DL statements and vice versa. Specifically, ontologized programs are PGC programs that use hooks to refer to the ontology within the behavior description. These hooks are linked to DL expressions via the interface. The loose coupling achieved in this way allows us to reuse and replace both components easily. PGC programs then can be analyzed with different ontologies (to describe different system configurations and contexts), and the same ontology can be used with different programs (for example, to describe different implementations of the behavior to be analyzed while keeping the same context). This design distinguishes our approach from other approaches that use DLs for the verification of systems, in which DL constructs are used directly within the program [BZ13, CDGLR11, HCM + 13, ZC15].
Let us now briefly summarize our contributions before we explain our approach of ontology-mediated verification more in detail. Besides introducing ontologized programs and methods for their analysis through PMC, this paper makes the following contributions: 1. Three semantics of ontologized programs that differ in the treatment of inconsistent states, 2. complexity results for checking consistency of ontologized programs under these semantics, 3. a practical method to generate standard PGC programs from ontologized programs using DL reasoning, 4. an implementation of the transformation for the quantitative analysis with PMC, and 5. a case study and evaluation of the implementation on a multi-server system model.
Here, we rely on the semantical framework introduced in [DKT20] especially for the contributions (1) and (2). For (3) and (4), we extend the approach of [DKT19] by providing full proofs, a slightly more general formalisms for ontologized programs with weights, and introduce a formal notion of mediators that enable more elegant and clean proofs. Our evaluation case study (5) is extended towards more analyses than discussed in [DKT19].
Semantics of ontologized programs. The presented semantics of ontologized programs are all formalized in terms of Markov decision processes (MDPs, cf. [Put94]), while other state-based operational semantics of PGC programs are also imaginable. They follow a product construction of the MDP-semantics of the PGC program and those DL ontologies that are compatible with states of the program. In theory, this allows states to be associated with an ontology that is logically inconsistent, so that we have to treat inconsistent states. Consider the following example: A program compiled for a specific processor architecture might not run properly on a different architecture. But future architectures might not be known during program specification such that after a new architecture release, an execution of the program might run into inconsistent states with respect to the architecture properties specified in the ontology. According to our first semantics, called consistency-independent semantics, there is no special treatment of such inconsistencies and the resulting MDP may contain inconsistent states. We used this semantics initially as the basis for our definition of ontology-mediated PMC given in [DKT19]. However, consequences drawn by classical DL reasoning on inconsistent ontologies are rarely useful: The only valuable information we can infer here is the inconsistency itself. Thus, the task of resolving the inconsistency is left to the program component under consistency-independent semantics, e.g., by implementing an explicit notion of exception handling in the program.
While in some instances, handling inconsistencies by the program might be sufficient, in other situations it is more convenient to let the DL component directly control the state space of the program by using a semantics that excludes inconsistent states altogether. For example, inconsistencies that would appear under the consistencyindependent semantics could also be a result of under specification of the program component, where the model of the program relies on further knowledge. In our architecture example, there could be an external component that only allows for executing programs on a compatible architecture. Or there might be actions only partly enabled for the user, but modeled through nondeterminism in the program. Then, a semantics that rules out states with an inconsistent ontology is favorable. For this, we introduce consistency notions for ontologized programs and present in addition to the consistency-independent semantics two further semantics. These are the probabilitynormalizing and probability-preserving semantics [DKT20] that differ in the treatment of inconsistent states. Probability-normalizing semantics assumes that stochastic behaviors in the program component arise within the program itself, e.g., to break symmetries as done within randomized algorithms. Here, it is natural to redistribute the probability mass that leads to inconsistent states to consistent ones. We achieve this by normalizing the distributions of probabilistic choices in the program. Probability-preserving semantics assumes that probabilistic choices have their origin in the surrounding system, e.g., to stochastically model environmental influences. Here, we strictly disallow any execution that may reach inconsistent states by pruning nondeterministic choices. For all of the three semantics we present complexity results for deciding consistency of programs. Practical analysis of ontologized programs. To be able to analyze ontologized programs practically, we develop a two-step procedure. First, the ontologized program and the properties to be analyzed are rewritten into a plain PGC program and modified versions of the properties. This way, essentially all model-checking tasks supported by state-of-the-art PMC tools such as Prism [KNP11] can be applied for analyzing ontologized programs. These tasks range from verifying standard statements about probabilities and expectations to the more advanced quantitative analysis such as presented in [BDK + 14, KBC + 18]. We first approach our rewrite method formally by defining what properties a rewrite function should satisfy to allow for a reduction. Then, we present two rewrite functions: one that is simple and easy to understand but leads to inefficient rewritings, and one that is efficient. Technically, our rewriting replaces expressions in the ontologized program by expressions that are derived using a DL reasoner. To allow for concise rewritings that can be computed efficiently, it is important to minimize the amount of DL reasoning. To this end, we use a technique that concentrates on the relevant axioms called axiom pinpointing. Implementation and evaluation. Then, we turn to our practical implementation of this procedure in which the operational behavior is specified in the input language of Prism, and where the ontology is given in web ontology language (OWL) [MCH + 09]. Since our approach is independent of any particular DL, the implementation supports any OWL fragment for which a DL reasoner exists. Technically, we transform the hooks from an ontologized program into expressions derived from reasoning on its ontology.
We evaluate our implementation based on a heterogeneous multi-server scenario and show that our approach facilitates the analysis of knowledge-intensive systems when varying behavior and ontology. In the case study, we consider multiple servers with architecture compatibility constraints running various job-executing processes. The job-scheduling protocol that decides which process is executed next is modeled through the program component. Here, we model two variants: one randomized algorithm and one that selects the next process in a round-robin fashion. Specific characteristics of the processes and servers are modeled in the ontology component, where we consider different contexts the program runs in. Processes may have different priorities depending on the importance of the job to be executed. An inconsistent system state occurs when a process is running on a server with different architecture compatibility. We resolve these inconsistencies explicitly in the program component, following ideas for resolving inconsistencies in the probability-normalizing and probability-preserving semantics. We analyze several instances of the multi-server system, arising from the two job-scheduling protocols, different server configurations, and four different contexts modeled by ontologies. Our focus of the analysis is to compute probabilities of running into certain critical situations specified by the ontologies, as well as an energy-utility analysis [BDD + 14] to investigate the trade-off between the number of successfully processed jobs and the consumed energy.

Preliminaries
We recall well-known notions and formalisms from probabilistic model checking and description logics required to ensure a self-contained presentation throughout the paper. By Q, Z, and N we denote the set of rationals, integers, and nonnegative integers, respectively. Let X be a countable set. We denote by ℘(X ) the powerset of X . A (rational) probability distribution over X is a function μ : X → [0, 1] ∩ Q with x ∈X μ(x ) 1. The set of distributions over X is denoted by Distr(X ).

Markov Decision Processes
The operational model used in this paper is given in terms of Markov decision processes (MDPs) (see, e.g., [Put94]). MDPs are tuples M Q, Act, P , ι, , λ where Q and Act are countable sets of states and actions, respectively, P : Q × Act Distr(Q) is a partial probabilistic transition function, ι ∈ Q an initial state, and a set of labels assigned to states via the labeling function λ : Q → ℘( ). An action α ∈ Act is enabled in a state q ∈ Q if P (q, α) is defined. The set of all enabled actions in q ∈ Q of M is denoted by En M (q). As usual, we assume that M does not have final states, i.e., En The probability of π is the product of its transition probabilities, i.e., Pr(π ) p 0 · p 1 · . . . · p k −1 . Infinite paths are defined accordingly, i.e., as sequences there exists a path π in M as above for which q 0 q and there is an index j with q j q .
Intuitively, the behavior of M in state q is to select an enabled action α and move to a successor state q with probability P (q, α, q ). A probability measure over sets of infinite paths is defined relying on the concept of (randomized) schedulers. Schedulers are functions S that map any finite path to a distribution over actions. We require that for each finite path π in M ending in a state q that P (q, α) is defined for any α ∈ Act with S(π )(α) > 0. A path π q 0 α 0 q 1 . . . is an S-path if for all i ∈ N for which α i is defined in π we have that S(q 0 α 0 . . . q i )(α i ) > 0. By the use of schedulers S, a probability measure Pr S M,q over infinite S-paths that start in q is defined in the standard way (cf. [Put94]).
Amending M with a weight function wgt : Q → N turns M into a weighted MDP M, wgt . The weight of a finite path π q 0 α 0 q 1 . . . q k is defined as wgt(π ) i≤k wgt(q i ). For a scheduler S we define by Exp[wgt] S M the function that maps a measurable set of infinite S-paths to the expected value of the weight of these paths.

Probabilistic model checking
MDPs are suitable for a quantitative analysis using probabilistic model checking (PMC, cf. [BK08,FKNP11]). A property to be analyzed is usually defined using temporal logics over the set of labels, constituting a set of maximal paths for which the property is fulfilled after the resolution of nondeterministic choices. By ranging over all possible resolutions of nondeterminism, this enables a best-and worst-case analysis on the property. Standard analysis tasks ask, e.g., for the minimal and maximal probability of a given property, or the expected weight reaching a given set of states. Quantitative properties. Let φ be a property expressed in a temporal logic over the set of labels , defining a set of maximal paths in the MDP that fulfill φ. For the purpose of this paper, it suffices to consider path properties specified in linear temporal logic (LTL, [Pnu77]), which we extend with a dedicated operator to express reachability with constraints on the accumulated weight. Specifically, an LTL formula over a set of labels is an expression of the grammar where ranges over , ∈ {<, , >, ≥, , ≤}, and τ ∈ N. Here, tt stands for the formula that is always satisfied, X for the next operator, and U for the until operator. We may also use LTL formulas with the common syntactic abbreviations, e.g., ϕ ∨ ψ ≡ ¬(¬ϕ ∧ ¬ψ), the eventually operator 3ϕ ≡ ttUϕ, or the globally operator 2ϕ ≡ ¬3¬ϕ. The set of paths reaching states labeled by a particular ∈ could be, e.g., formalized in LTL by ϕ 1 3 . Similarly, the set of paths where always when such a state is reached, within two time steps a state not labeled by is reached again, could be formalized by ϕ 2 2 → (X¬ ∨ XX¬ ) .
The semantics [[ϕ]] of an LTL formula ϕ in a weighted MDP M Q, Act, P , ι, , λ, wgt is recursively defined as the set of infinite paths π q 0 α 0 q 1 . . . where To reason about cost-utility trade-offs in weighted MDPs, we rely on energy-utility quantiles [BDD + 14]. Formalized in our theoretical framework, we have given a weighted MDP where its weight function is nonnegative and integer-valued and stands for costs invested, e.g., energy consumed. Then, for a probability threshold θ ∈ [0, 1] ∩ Q, and LTL formulas ϕ and ψ, the min-cost quantile with respect to θ , ϕ, and ψ is defined as min c ∈ N | M | P max (ϕU wgt≤c ψ) > θ . (1) The above quantile specifies the minimal cost budget required such that there is a scheduler under which the probability to reach some state in which ψ holds through states where ϕ holds is greater than θ , not exceeding the cost budget. Min-cost quantiles can be used to reason about cost-utility trade-offs in weighted MDPs by additionally encoding a utility value into the state space of the MDP. This additional value then formalizes the utility gained (e.g., number of tasks completed) during an execution of the MDP. LTL formulas that include arithmetic constraints on the utility value as labelings then can put utility constraints on the paths over which the costs are minimized in the min-cost quantile. As an example, a constraint utilit y ≥ 20 would label all states with utility value at least 20. Quantitative queries. While classical PMC tasks for MDPs are to decide whether a probabilistic property or expectation property is satisfied in the given (weighted) MDP, the computational task to determine the value of probabilities and expectations to fulfill an LTL property is also of interest. To this end, we define a probability query to be an expression of the form P ex (ϕ) ? and an expectation query to be an expression of the form E[wgt] ex (ϕ) ?, where ϕ is an LTL formula over the same label set as for the given (weighted) MDP and ex ∈ {min, max}. Queries of the above form can be answered by using standard methods like value iteration or policy iteration. For more details on MDPs and PMC, we refer to standard textbooks and surveys such as [Put94,BK08,FKNP11].
To specify computational tasks of min-cost quantiles, we define quantile queries to be expressions of the form Qu >θ (ϕU ≤wgt ψ) ? where θ ∈ Q ∩ [0, 1] and ϕ and ψ are LTL formulas. Answering a quantile query amounts to compute the value of the corresponding quantile, e.g., for the above query computing (1).

Probabilistic guarded command programs
As a concise and natural representation of MDPs we use probabilistic guarded command (PGC) programs, which are essentially expressed in a probabilistic variant of Dijkstra's guarded command language [Dij76,JSM97]. Our PGC programs are compatible to the input language of the probabilistic model checker system Prism [KNP11]. In such a program, initial integer values for variables are explicitly given, while the changes of values for variables are provided through commands of the form [action] guard → p 1 :update 1 + p 2 :update 2 + . . . + p n :update n .
Here, action describes the action the program performs when executing this command. Furthermore, guard is a Boolean expression over arithmetic constraints on variable evaluations, e.g., (x 1) ∧ (y ≤ 5) for some variables x, y is fulfilled if x has value 1 and y has a value smaller or equal than 5. In case the guard evaluates to true in a state, the command is enabled and the values of the program's variables could be updated. An update describes how variables change depending on the current variable evaluation, e.g., x:=1+y changes the value of x to the increment of the value of y. Each update update i is chosen with probability p i for i ∈ {1, . . . , n}. That is, in every state fulfilling guard the evaluations of the expressions p 1 , p 2 , . . . , p n constitute a probability distribution, i.e., must sum up to 1.
Any execution of the program starts in the initial variable evaluation and in each arising evaluation, it nondeterministically picks a guarded command whose guard is satisfied, and then modifies the current evaluation according to the update.
Example 2.1 (Multi-server platform commands) Let us introduce an excerpt of a PGC program that models a multi-server platform where processes are scheduled for execution on servers. The scheduling strategy is modeled by a program over variables server proci that evaluate to the number of the server the process i runs on. To increase the efficiency of the server platform, processes can be migrated from one server to another. For instance, the command [migrate] (server proc1 2 ∧ server proc2 2 ∧ server proc3 2) → 1/2 : server proc1 : 1 1/2 : server proc1 : 3 describes that if Process 1 and Process 2 are on Server 2 and Process 3 is on Server 2, then Process 1 is migrated to either Server 1 or Server 3 with probability of 50% each. 3 To formally define PGC programs, we first introduce states as evaluations of variables, conditions on states, and updates. Let V be a finite set of variables where a range function ρ : V → N defines the domain of each variable as non-negative integers of (v ) {−ρ(v ), −ρ(v ) + 1, . . . , ρ(v )}. An evaluation over V is a function η that assigns to each v ∈ V a value in (v ). We denote the set of evaluations over V by Eval(V). The set E(V) of arithmetic expressions is defined by the following grammar, where z ∈ Z and v ∈ V: Variable evaluations are extended to arithmetic expressions in the natural way, i.e., η(z ) z , η(χ 1 + χ 2 ) η(χ 1 ) + η(χ 2 ), and η(χ 1 · χ 2 ) η(χ 1 ) · η(χ 2 ). We denote by C(V) the set of arithmetic constraints over V, which are terms of the form (χ z ) with χ ∈ E(V), ∈ {<, , >, ≥, , ≤}, and z ∈ Z. For a given evaluation η ∈ Eval(V) and constraint (χ z ) ∈ C(V), we write η | (χ z ) iff η(χ ) z and say that (χ z ) is satisfied by η. We denote by C(η) the constraints satisfied by η, i.e., C(η) {γ ∈ C(V) : η | γ }. For a countable set X and x ranging over X , we define Boolean expressions B(X ) over X by the grammar We define a satisfaction relation | ⊆ ℘(X ) × B(X ) for Boolean expressions as usual: for Y ⊆ X , we have For an evaluation η ∈ Eval(V) and φ ∈ B(C(V)), we write η | φ iff C(η) | φ. The connectives disjunction ∨ and implication → can be expressed using ∧ and ¬ in the usual way. The length of arithmetic expressions, constraints, and Boolean expressions is the size of the string encoding following the defined grammars.
We call a function u : V → E(V) an update. Recall that E(V) stands for the set of arithmetic expressions over variables V. A probabilistic update is a distribution σ ∈ Distr(U pd) over a given finite set U pd of updates. The effect of an update u : V → E(V) on an evaluation η ∈ Eval(V) is their composition η • u ∈ Eval(V), which we define for all v ∈ V to be (η • u)(v ) max{−ρ(v ), min{η(u(v )), ρ(v )}}. Note that we extended the definition of evaluations towards arithmetic expressions through their natural meaning of addition and multiplication operations. This notion naturally extends to probabilistic updates σ ∈ Distr(U pd) by η • σ ∈ Distr(Eval(V)), where for any η ∈ Eval(V) we have To provide an intuition why we have to sum over multiple updates when evaluating probabilistic updates, let us consider a variable space V {v } and variable evaluations η, η ∈ Eval(V) where η(v ) 2 and η (v ) 4. Furthermore, let us consider three updates U pd We define a probabilistic update σ : {u 1 , u 2 , u 3 } → Eval({v }) by σ (u 1 ) 1/2, σ (u 2 ) 1/3, and σ (u 3 ) 1/6. Then, η η • u 1 η • u 2 η • u 3 and thus, (η • σ )(η ) 1, the sum of all probabilities of the above updates, as 2 + 2 4 2 · 2. Differently, when η(v ) 1, we would have (η • σ )(η ) 1/3, since then only the update u 2 is effective.
A probabilistic guarded command (PGC) over a finite set of updates U pd, briefly called command, is a pair g, σ where g ∈ B(C(V)) is a guard and σ ∈ Distr(U pd) is a probabilistic update. Similarly, a weight assignment is a pair g, w where g ∈ B(C(V)) is a guard and w ∈ N a weight. A PGC program over V, also briefly called program, is a tuple P V, C, W, η 0 where C is a finite set of commands, W a finite set of weight assignments, and η 0 ∈ Eval(V) is an initial variable evaluation. We define U pd(P) as the union of all supports of probabilistic updates σ for which there is a guard g ∈ B(C(V)) with g, σ ∈ C. Note that for brevity we did not formalize the common notion of actions in commands here, which however does not restrict the expressiveness of the formalism. The size of program P is defined as the sum of the lengths of its commands, weight annotations, the initial state, and the range specification of each variable used, where we count variables and operators as one, and encode all numbers in binary. Semantics. The semantics of a program P V, C, W, η 0 is specified via the weighted MDP

Note that M[P]
is indeed a weighted MDP and that P (η, σ ) is a probability distribution with finite support for all η ∈ Eval(V) and σ ∈ Distr(U pd(P)) due to the finite domains assigned to each variable. Further, if we use binary encoding of numbers, each state in the MDP can be represented in space polynomial in the size of the program, and there can be at most exponentially many states.
Non-probabilistic programs. While our focus is on analyzing PGC programs through probabilistic model checking, there are applications in which probabilities are not relevant, and a program without probability distributions is sufficient. Clearly, such programs can be captured by our formalism. However, as some of our complexity results improve if we discard probabilities, we explicitly define a non-probabilistic variant of programs. In the following, a program is called non-probabilistic if for every command g, σ ∈ C there is an update u ∈ U pd(P) such that σ (u) 1. We then simply abbreviate such a command by g → u. Note that non-probabilistic programs might be nondeterministic, as there can be more than one command that can be executed in a state.

Description logics
Description logics (DLs) are a family of logics that vary in expressivity and that are often fragments of first-order logic for which reasoning is decidable. Theories formulated in a DL are usually called ontologies. The results in this paper apply to the expressive DL SROIQ underlying the web ontology language OWL 2 [MCH + 09], but for ease of presentation, we introduce its fragment ALCQ in detail. ALCQ is sufficiently expressive for modeling and is the DL that is used in our running example and in our evaluation. The description logic ALCQ. An ontology is a finite set of DL axioms, which put concepts, roles, and individuals in relation to each other. Intuitively these describe sets, binary relations, and individual objects, respectively. The syntax of ALCQ is defined based on a set N C of concept names, a set N R of role names, and a set N I of individual names. We first describe the syntax and semantics of concepts, and then consider axioms and ontologies. Concepts are built by the use of a set of concept constructors available to the respective DL. In the DL ALCQ, concepts are defined inductively according to the following grammar, where A ∈ N C , r ∈ N R , and n ∈ N: The semantics of concepts is given in terms of first-order logic interpretations. An interpretation I ( I , · I ) consists of a non-empty set I (the domain) and a mapping function · I that assigns to each individual name a ∈ N I a domain element a I ∈ I , to each concept name A ∈ N C a subset A I ⊆ I , and to each role name r ∈ N R a binary relation r I ⊆ I × I . In other words, individual names correspond to constants, concept names to unary predicates, and role names correspond to binary predicates in first-order logic. The mapping function · I extends to complex concepts as shown in Table 1. Here, given a set X , we use #X to denote the cardinality of X . For example, the qualified at-most restrictions ( n r.C ) describe sets of objects that are in the r -relation to at most n many objects that satisfy the concept C .
Let a and b be individual names, C and D be concepts, and r be a role. An axiom is a statement of one of the following forms: GCIs are terminological axioms and state sub-concept relationships, concept assertions state concept membership of an individual, and role assertions state that two individuals are related via the mentioned role. Formally, an interpretation I satisfies a  C (a)). An ontology is consistent if it has any model, and otherwise it is inconsistent. Note that an inconsistent ontology entails every axiom, because it does not have any models.
Example 2.2 (Multi-server platform ontology) Let us continue the description of our running example started in Example 2.1, by describing an ontology for our multi-server platform. Here, qualified at-most restrictions are used to describe the concept of "servers that run up to two processes that have high priority": Server ( 2 runsProcess. ∃ hasPriority.High) .
As an example for reasoning in DLs, the GCIs (5) and (7) imply that the subsumption relationship ( 3 runsProcess.(∃ hasPriority.High)) Server Overloaded holds. Furthermore, it can be derived from the assertions (3) and (4) together with the GCIs (5) and (7) that Overloaded Server(server2) holds. This together with assertion (2) entails the instance relationship PlatformWithOverload(platform) w.r.t. the example ontology. 3 Other description logics. As DLs can differ in expressivity, so can the complexity for reasoning in them. The fragment of ALCQ without qualified number restrictions is the DL ALC, which is the smallest propositionally complete DL. The fragment of ALC that offers only conjunction, existential restrictions, and the top-concept is called EL. The formal ontology languages standardized by the W3C are captured in the OWL 2 standard [MCH + 09] and most of these languages are based on DLs. The light-weight DL EL is the core language of the OWL-EL profile, because of its good computational properties. Reasoning in EL [Bra04] and in its moderate extensions [BBL05] can be done in polynomial time.
The most expressive ontology language in that standard is OWL-DL which corresponds to the DL SROIQ [HKS06]. This DL extends ALCQ by additional constructors for roles, concepts and axioms, shown in Table 2. For example, SROIQ provides nominals, which are individuals that can be used in complex concepts, and it admits the use of inverse roles. By the use of the nominal {ACME} and the inverse of the role produces, we can state that ACME servers are servers produced by ACME:
In addition, the DL SROIQ can express complex inclusions between (composition of) roles, for example runsOS • runs runs. Such inclusions can model transitivity and more complex relationships. We omit the details of the full syntax of SROIQ, which comes with additional restrictions on the use of role names to ensure decidability, and refer the interested reader to [HKS06].

Construct
Syntax Semantics , while reasoning in ALCQ [Tob01] (and already in ALC [Sch91]) is ExpTime-complete. There are several highly optimized implementations of OWL reasoners that can decide consistency and axiom entailment (see [KKS14, GHM + 14, SLG14, SPG + 07]). We use the DL ALCQ in the evaluation part of this paper. However, our approach for ontology-mediated PMC can employ any DL for which reasoning is decidable.

Ontologized programs
In general, an ontologized program comprises the following three components: The Program is a specification of the operational behavior. The Description Logic Ontology contains static background knowledge that may influence the behavior of the program. The Interface links program and ontology by providing mappings between the languages used for the program and the ontology.
Ontologized programs combine the two formalisms of probabilistic guarded command (PGC) language and DLs. To achieve a division of concerns, the operational behavior and the static background knowledge are specified separately and are only loosely coupled by an interface. On the one hand, this allows for specifying operational behavior in the usual way and to extend and reuse existing program specifications. On the other hand this allows us to easily link well-established or standardized ontologies to a program.
In this section, we describe the syntax of ontologized programs, and specify a foundational MDP semantics for ontologized programs called consistency-independent semantics, which we originally introduced in [DKT19]. In Sect. 5 we define two other semantics that refine consistency-independent semantics in taking care of inconsistencies arising from the DL component.

Syntax of ontologized programs
In order to prepare for the formal definition of the syntax of ontologized programs, we first explain how states of ontologized programs are represented. Both formalisms, PGC language and DL, represent abstracted versions of states in different ways. For the PGC language, a state is described as an evaluation of variables, while for the DL, a state is described using a set of axioms. Both formalisms require different degrees of abstraction and detail, depending on their dedicated purpose. Consequently, states of ontologized programs are composed of two components, which we call the command perspective and the DL perspective on the system state (see Fig. 1). As can be seen in the figure, there are some elements in the two perspectives that correspond to each other, while others have no direct counter-part. This correspondence, depicted by arrows in the figure, is defined in the interface component of the ontologized program via a function Dc (DL to command), that maps DL axioms to command expressions. The part of the DL perspective depicted inside the box is not mapped to anything on the command side. This is the so-called static part, which contains the background knowledge about the system independent of the current state of the system. In contrast, the set of mapped axioms in the ontology perspective may change, depending on changes in the program perspective.

DL Perspective
OverloadedServer ≡ Server 3runsProcess.Process Ontologized programs also allow the command perspective to use variables that have no correspondence in the DL perspective, which we call private variables. (These are not depicted in the figure for brevity.) In order for the DL component to provide background knowledge for the program component, the description of global states needs to depend on DL reasoning. To invoke a reasoning task from the command side of ontologized programs, we introduce the notion of hooks. A hook is a propositional variable in the program component that is linked by the interface to a Boolean query over the DL perspective of the ontologized program state. Technically, such a query consists of a set of DL axioms, to which the answer is true or false depending on whether or not all the axioms are entailed by the DL perspective. The result of the query determines the value of the hook using the function cD (command to DL). To enable the actual use of hooks in the PGC language, we have to extend the definition of commands slightly. Specifically, we define abstract programs as programs where guards are Boolean expressions over arithmetic expressions as well as hooks. Given an abstract program P, we denote by H P the set of hooks used in P.
Example 3.1 (Hooks) In our server platform example from Example 2.1 and Example 2.2, we would define a hook migrateServeri for each server i ∈ {1, 2, 3} that represents the information that processes should be migrated from server i : In the ontologized state shown in Fig. 1, the hook migrateServer2 is active because the axioms in the DL perspective entail OverloadedServer(s 2 ).
To specify a scheduling strategy similarly as in Example 2.1 but with including the concept of hooks, we can specify a command of an abstract program in the following form: [migrate] (migrateServer2 ∧ server proc1 2) → 1/2 : server proc1 : 1 1/2 : server proc1 : 3 (9) While the intention of this command is similar to the command in Example 2.1, this version omits the specification of the condition under which Server 2 needs to migrate. The idea is to specify and test this migration condition in the DL component rather than in the program itself, enabling a scheduling strategy that depends on background knowledge specified in the DL. 3 We are now ready to formally define ontologized programs. To indicate the different components of ontologized programs, we sometimes use a subscript, that is, we adopt the notation P P P , O P , I P .

Consistency-independent semantics for ontologized programs
PGC programs are used as concise representations of MDPs that can be subject of a quantitative analysis. Analogously, ontologized programs are concise representations of ontologized MDPs, where the behavior specified can further rely on information provided by the ontology. There are different ways how the background knowledge formulated in the ontology can influence the operational behavior of an ontologized program, leading to different MDP semantics. Choosing an appropriate semantics is a modeling decision to be made when constructing the ontologized program. We first present the most basic semantics, called consistency-independent semantics, which also underlies our model-checking approach. Under this semantics, states with inconsistent corresponding DL query evaluations do not lead to a special treatment when specifying the operational behavior, i.e., the behavior is independent from the consistency status. Before we go into detail, we specify how states in ontologized MDPs look like. For this, we formalize the intuitive description of states from Sect. 3.1 by defining ontologized states comprised of a command perspective and a DL perspective (as illustrated in Fig. 1).

The set of active hooks in
For every evaluation η ∈ Eval(V P ), there is always a unique ontology O η s.t. η, O η is an ontologized state in P. We denote the ontologized state induced by an evaluation η as e(P, η). To define updates on ontologized states, we exploit the facts that • updates can only modify the command perspective of ontologized states directly, and • the DL perspective of ontologized states is fully determined by the command perspective.
Thus, we can easily lift the effect of updates on evaluations to updates on ontologized states. For an update u ∈ U pd(P P ) and an ontologized state q, we define u(q) e(P, u(η q )). Correspondingly, we extend probabilistic updates σ ∈ Distr(U pd(P P )) to ontologized states q by setting σ (q, u(q)) σ (u) for all u ∈ U pd(P P ).
Example 3.2 To illustrate how commands are executed on ontologized states, we consider the ontologized state q 1 shown in Fig. 1 and the abstract command (9) of Example 3.1. First, we note that the guard in the command is active, since the hook migrateServer2 is active and server proc1 2 holds in q 1 . The command can thus be executed on this state, and executes each of its updates with a 50% chance. For the first update, server proc1 : 1, we obtain the ontologized state q 2 shown in Fig. 2 in which server proc1 2 is replaced by server proc1 1, and runs(s 2 , p 2 ) is replaced by runs(s 1 , p 2 ). As a result of this update, the hook migrateServer2 becomes inactive in q 2 . More precisely, the interface in the example specifies cD(migrateServer2) {OverloadedServer(s 2 )}, and OverloadedServer(s 2 ) is not entailed by O q 2 , i.e., by the DL perspective of q 2 . 3

DL Perspective
OverloadedServer ≡ Server 3runsProcess.Process State q 2 after the update server proc1 : 1 on state q 1 .
The definition of the MDP induced by an ontologized program under consistency-independent semantics now closely follows the semantics for MDPs induced by plain programs.
In an induced MDP, the set of states Q contains the ontologized states that can be constructed based on the evaluations of the variables V P occurring in the program component P. Correspondingly, the initial state q 0 , is the ontologized state e(P, η 0 ) obtained from the initial evaluation η 0 of the program component. The label set determines which information on the nodes the probabilistic properties can access. As for MDPs induced by plain programs, this contains the set C(V P ) of arithmetic constraints on the program variables, but in addition it also contains the set H I of hooks defined by the interface. The labeling function λ associates ontologized states with those labels that are active in that state. Finally, probabilistic transitions and weights are assigned to ontologized states based on which guards are entailed by the label of the respective node. This is done in the same way as for plain programs. Similarly as for the MDP induced by (plain) programs, the set of actions corresponds to the set of distributions over the updates that occur in the program.

Model checking under consistency-independent semantics
Following the definition of the inconsistency-independent semantics (see Definition 3.3), it is straightforward to establish an approach towards a quantitative analysis of ontologized programs under consistency-independent semantics. Recall that, because each program variable has a bounded range, the MDPs induced by our programs always have a finite number of states. Therefore, we could simply apply standard PMC techniques directly on the MDP induced by the ontologized program. However, in practice an explicit construction of the induced MDP is not feasible: even though the range of each program variable is bounded, the number of states is exponential in the size of the input. Moreover, associating labels to ontologized states is much more expensive than for plain programs, since we have to use DL reasoning to determine which hooks are active. Depending on the DL used, testing entailment of axioms can range up to N2ExpTime (see Sect. 2.4). Consequently, it is desirable to keep the number of entailment tests small. There exist advanced techniques to represent the MDP states concisely to mitigate the exponential blow-up of the states space, e.g., through symbolic representations via multiterminal binary decision diagrams (MTBDDs) [MP04]. However, it is not clear how to extend those approaches to ontologized states, and we would still need a way to evaluate the hooks. Instead of devising a new procedure for constructing the MDP from scratch, our approach is to reduce ontology-mediated PMC to standard PMC. This is inspired by ontology-based data access (OBDA) [PLC + 08, BO15], where ontologies are used in connection with database systems to improve query answering. Specifically, the data in the database is considered incomplete, and the ontology is used to infer some of the missing information. Queries can then be used to query explicit as well as implicit information from the database. For some DLs, it is possible to use a technique called query rewriting to reduce query answering in an OBDA setting to querying without ontology. For this, the query is rewritten into a new query that yields the same answers as the original one, but can be evaluated without the ontology so that standard database systems can be used [CDL + 07].
We propose a similar technique to perform PMC on ontologized programs, where we rewrite the ontologized program, together with the property to be checked, into a plain program and a translated property. These can then be directly evaluated using standard PMC methods. Our technique preserves the shape of the MDP induced by ontologized program based on a notion of isomorphism, which we introduce in Sect. 4.1. To show correctness of our approach, we also define an abstract specification of rewriting in terms of so-called mediators and rewriters.
If an MDP is isomorphic to another MDP, a mediator guarantees that state labels from the first MDP can be translated to those of the second MDP. This allows us to reduce model checking on the first MDP to model checking on the second. A rewriter is a function that rewrites an ontologized program into a plain program. If there exists a mediator from the MDP induced by the ontologized program to the MDP induced by the rewritten program, then model-checking the ontologized program can be reduced to model-checking of the rewritten program, and we call the rewriter sound.
We specify two instances of sound rewriters in Sect. 4.2. The first one, which we call naive rewriter, has a simpler definition and we use it mainly to illustrate the basic idea. Because the naive rewriter is not feasible in practice, we present an optimized variant, the justification-based rewriter. This rewriter reduces the amount of DL reasoning required by focusing on the relevant axioms. Our reduction technique works for analyzing programs under consistency-independent semantics.

Isomorphic MDPs and mediators
We formalize a rewriting procedure that takes as input an ontologized program P as in Definition 3.1 and generates a plain program P. Our rewriting procedure has to ensure that the MDP M[ P] induced by P corresponds "in some way" to the MDP M[P] induced by P. To make sure that a variety of model-checking tasks on P can be easily translated to model-checking tasks on P, we require a strong correspondence between M  Q 1 , Act 1 , P 1 , ι 1 , 1 , λ 1 , wgt 1 and M 2 Q 2 , Act 2 , P 2 , ι 2 , 2 , λ 2 , wgt 2 . Then, M 1 and M 2 are isomorphic modulo labelings iff there exist bijections b : Q 1 → Q 2 and a : Act 1 → Act 2 that satisfy the following conditions: I2 for every q ∈ Q 1 , wgt 2 (b(q)) wgt 1 (q), I3 for every q, q ∈ Q 1 and σ ∈ Act 1 , If for such MDPs, there exists a function m : 1 → B( 2 ) s.t.
I4 for every q ∈ Q 1 and ∈ 1 , then m is called a mediator from M 1 to M 2 .
Since probabilistic properties refer to states via their label sets, we need a way of translating the label sets. If M 1 and M 2 are not only isomorphic modulo labelings, but there also exists a mediator m from M 1 to M 2 , we can use m to translate properties over label sets in M 1 to properties over label sets in M 2 . In this case it is straightforward to reduce model-checking tasks for M 1 to corresponding model-checking tasks in M 2 . The following lemma is an easy consequence of Definition 4.1.
Lemma 4.1 Let M 1 be an MDP with labels 1 and M 2 an MDP with labels 2 such that M 1 and M 2 are isomorphic modulo labelings and there exists a mediator m : 1 → B( 2 ) from M 1 to M 2 . Let be a probabilistic property or an expectation property over the label set 1 , and m is the result of replacing every ∈ 1 by m( ).
Note that as a consequence of this lemma, we can also reduce translate probabilistic, expectation, and quantile queries using a mediator.
Fix an ontologized program P as in Definition 3.1. Our method rewrites P into a program P such that M[P] and M[ P] are isomorphic modulo labelings and have a mediator m. Since each evaluation η ∈ Eval(V P ) can be uniquely extended to an ontologized state e(η) η, O η , there is a one-to-one correspondence between ontologized states and their command perspective. Our rewriting is such that the MDP induced by P is obtained from M[P] by replacing each ontologized state q by its command perspective η q , and reducing the label set to C(V P ). The states in M[P] are labeled with arithmetic constraints and hooks, and the states in M[ P] are labeled with the same arithmetic constraints as the corresponding states in M[P]. Hence, the mediator m only needs to take care of the hooks, and for every arithmetic constraint γ ∈ C(V P ), we have m(γ ) γ . This mediator does not only establish the correspondence between the MDP induced by the ontologized program and the MDP of the rewritten program, it is also used to rewrite the program in the first place. How a rewriting takes place is specified in the following definition.
Definition 4.2 (Rewriting) Let P be an ontologized program as in Definition 3.1, a probabilistic or expectation property over the labelling in M[P]. A rewriter for P is a function r : H I → B(C(V P )). The rewriting of P using r is the program P r obtained from P P by replacing every hook h ∈ H I by r (h). Correspondingly, the rewriting of is the property r obtained by replacing every hook h ∈ H I in by r (h). The function r is called sound rewriter for P iff its extension m : C(V P ) ∪ H I → B(C(V P )) given by Example 4.1 (Rewriting) In our running example, the states of the MDP induced by the rewritten program just correspond to their command perspective (see Fig. 1 and 2). The way we defined the ontologized program, the hook migrateServer2 becomes active if there are three processes on the second server. As we have exactly three processes in our example, a possible mediator m could capture this by m(migrateServer2) server proc1 2 ∧ server proc2 2 ∧ server proc3 2 .
By restricting the domain of the mediator to H I , we obtain a sound rewriter r . Using this rewriter, our command (9) of Example 3.1 [migrate] (migrateServer2 ∧ server proc1 2) → 1/2 : server proc1 : 1 1/2 : server proc1 : 3 would be replaced by the following command without hooks in the rewritten program: [migrate] server proc1 2 ∧ server proc2 2 ∧ server proc3 2 ∧server proc1 2 → 1/2 : server proc1 : 1 1/2 : server proc1 : 3 Note that there could be many rewriters in this example that would produce the same induced MDP. For instance, omitting server proc1 2 in the rewritten command would yield the same operational behavior without directly including constraints on all process-server placements. 3 The following is an easy consequence of Lemma 4.1 and shows that sound rewriters are sufficient to reduce model checking in ontologized programs to model checking in plain programs. Thus, by computing a sound rewriter, we can reduce probabilistic model checking of ontologized programs to probabilistic model checking of programs. For those, standard tools are available [KNP11,DJKV17]. The main task is to obtain a sound rewriter that can be effectively and efficiently computed.

Constructing sound rewriters
To obtain a sound rewriter for a given program P, we have to define for each hook h ∈ H I a Boolean expression over Eval(V P ) that identifies exactly the ontologized states q ∈ Q P in which h is active. In other words, we need to identify conditions on the program perspective of q that determine when h is active.
Before looking at the program perspective, we recall the mechanism of hook activation starting from the DL perspective. Activation of h is determined via the interface function cD: h is active in q iff O q | cD(h). By Condition S2 in Definition 3.2, every axiom in O q is either taken from O P , the background ontology of the ontologized program, or from F, the set of fluents. Since by Condition S3, O P is contained in the DL perspective of every ontologized state for P, only the axioms in F are relevant. We can thus identify the ontologized states in which h is active solely based on the axioms in F. For a hook h ∈ H I , let be the set containing the sets of fluents responsible for (the activation of) h. Hence, a hook h is active in an ontologized state q iff there exists some F ∈ F h s.t. F ⊆ O q . On the command perspective, this in turn can be determined using the interface function Dc. Namely, we have F ⊆ O q iff η q | α∈F Dc(α). We can thus identify the states in which h is active using the rewriter r n : H I → B(C(V P )) defined by We call r n the naive rewriter for P.

Lemma 4.3
Let P be an ontologized program and r n be the naive rewriter for P. Then, r n is a sound rewriter for P. Act 1 , P 1 , ι 1 , 1 , λ 1 , wgt 1 , be the MDP induced by P. Our proof proceeds in four steps: (1) We first construct an MDP M 2 based on M 1 by restricting the label set. (2) We show that M 1 and M 2 are isomorphic modulo labelings. (3) We then show that we obtain a mediator m n from M 1 to M 2 if we extend r n to C(V P ) ∪ H I by setting m n (γ ) γ for all γ ∈ C(V P ). (4) Finally, we show that M 2 is the MDP induced by the program P r n that is the result of rewriting P using r n .
(2) Since every evaluation η ∈ Eval(V P ) can be uniquely extended to an ontologized state e(η, P) ∈ Q 1 , the function b : Q 1 → Q 2 given by b(q) η q is invertible by b − (q) e(q, P), and thus a bijection. Since Act 1 Act 2 , we can define another bijection a : Act 1 → Act 2 by setting a(σ ) σ for all σ ∈ Act 1 . M 1 and M 2 are isomorphic modulo labelings via the bijections b and a.
(3) To show that m n as defined above is a mediator from M 1 to M 2 , we have to consider the labels in 1 C(V P ) ∪ H I . By construction, for every φ ∈ C(V P ) and q ∈ Q 1 , we have m n (φ) φ and thus φ ∈ λ 1 (q) iff For every α ∈ F, by Definition 3.2, η q | Dc(α). Consequently, η q | α∈F Dc(α). By definition of r n , we obtain η q | r n (h) m n (h), and since λ 2 (b(q)) λ 2 (η q ), we have that λ 2 (b(q)) | m n (h). Assume h ∈ λ 1 (q). Then, O q | cD(h), and F (O q ∩F) ∈ F h . By monotonicity of the entailment relation, there also cannot be any subset F F s.t. F ∈ F h . It follows that λ 2 (η q ) | r n (h) and thus that λ 2 (b(q)) | m n (h).
We have shown that for every label ∈ 1 and every state q ∈ Q 1 , ∈ λ 1 (q) iff λ 2 (b(q)) | m n ( ). Hence, m n is a mediator from M 1 to M 2 .
(4) It remains to show that M 2 is the MDP induced by P r n . We show that M 2 M 3 by checking the components of M 3 one after the other.
2. Act 3 Distr(U pd(P r n )) Distr(U pd(P)) Act 1 Act 2 , where P is the program component of P, because the updates in P operate only on V P , as do the updates in P r n .
3. 3 C(V P ) 2 . 4. For all η ∈ Q 3 Q 2 , λ 3 (η) C(η) λ 2 (η). 5. For q ∈ Q 3 and σ ∈ Act 3 , P 3 (q, σ ) is defined if there exists (g, σ ) ∈ C r n , where C r n are the commands in P r n , and q | g. In this case, P 3 (q, σ, q ) (q • σ )(q ) for all q ∈ Q 3 . Since (g, σ ) ∈ C r n , there must exist a command (g , σ ) ∈ C P , where C P is the set of commands in P, and g is obtained from g by replacing each hook h ∈ H I with r n (h). Since m n is a mediator from M 1 to M 2 and also q ∈ Q 2 , q | g iff b − (q) e(q, P) | g . It follows that P 3 is defined iff P 1 is defined, which is the case iff P 2 is defined. Assume P 3 and P 2 are defined. We then have for all q ∈ Q 2 Q 3 , that P 2 (q, σ, q ) P 1 (e(q, P), σ, e(q , P)) (e(q, P) • σ )(e(q , P)) (q • σ )(q ) P 3 (q, σ, q ).
It follows that P 3 P 2 .
6. Let W P be the weight assignments in P, and W r n the weight assignments in P r n . For every q ∈ Q 3 , we have For every weight assignment g, w ∈ W r n , there exists a weight assignment g , w ∈ W P , where g is obtained from g by replacing every hook h by r n (h). Since r n extends to a mediator, we have for every such weight g, w and state q ∈ Q 2 Q 3 that q | g iff b − (q) e(q, P) | g . It follows that wgt 3 (q) wgt 1 (e(q, P)) wgt 2 (q). Consequently, wgt 3 wgt 2 .
We have shown that M 3 M 2 , and thus that M 2 is the MDP M[P r n ] induced by P r n . Therefore, m n mediates from M 1 [P] to M 2 [P r n ], and by Definition 4.2, r n is a sound rewriter for P. While the rewriter r n is a sound rewriter, it may not be efficiently computable in practice: For each hook h ∈ H I , the set F h contains up to exponentially many elements. Since entailment testing in DLs can be an expensive operation, a brute-force method for computing r n would not perform well in practice. Furthermore, the rewritten program P r n would be very large. As an optimization, we can discard from F h all sets F ∈ F h for which there exists some F ∈ F h s.t. F ⊂ F, that is, we only need the subset-minimal sets in F h . Those are the subset minimal sets F ⊆ F s.t. O P ∪ F | cD(h). Subset-minimal subsets of an ontology that entail a consequence are usually called justifications [Hor11].
The computation of justifications is called axiom pinpointing for which various algorithms have been developed for different DLs [SC03,BPS07,Hor11]. Some of these algorithms can be adapted to compute also relative justifications (see also Sect. 6). To determine in which ontologized states a hook h is active, we only need to consider the justifications of O P ∪ F | cD(h) relative to the static background knowledge O P , which are exactly the subset-minimal sets in F h we are looking for. Thus we can replace the sets F h used in the naive rewriter by the sets J(h) J(O P ∪ F, cD(h), O P ). For h ∈ H I the rewriter r J is defined as follows: We call r J the justification-based rewriter for P.
Lemma 4.4 Let P be an ontologized program and r J the justification-based rewriter for P. Then, r J is a sound rewriter for P.
Proof. The only element in the proof of soundness of the naive rewriter in Lemma 4.3 that we have to adapt is Step (3), which establishes that the extension of the rewriter r n to the label set of M 1 M[P] is a mediator from M 1 to M 2 . Let m J be defined as m J (γ ) γ for γ ∈ C(V P ) and m J (γ ) r J (γ ) otherwise. We show that m J is a mediator from M 1 to M 2 , after which the rest of the proof works as before. For this, we need to show that for every hook h ∈ H I and every ontologized state q ∈ Q 1 , h ∈ λ 1 (q) iff λ 2 (b(q)) λ 2 (η q ) | m J (h). Assume h ∈ λ 1 (q). Then, by Definition 3.3, h is active in q, which by Definition 3.2 means that O q | cD(h). Consequently, there exists a justification J for O q | cD(h) relative to O P . Since O q ⊆ O P ∪ F by Condition S2 in Definition 3.2, J also a justification for O P ∪ F | cD(h) relative to O P , which means J ∈ J(h). Moreover, by Condition S4, λ 2 (η q ) λ 2 (b(q)) | Dc(α) for every α ∈ J ⊆ O q , which means that λ 2 (b(q)) | α∈J Dc(α) and λ 2 (b(q)) | m J (h). Assume h ∈ λ 1 (q). Then, O q | cD(h), which also means that no subset of O q entails cD(h). It follows that for no J ∈ J(h), J ⊆ O q , and thus that λ 2 (η q ) λ 2 (b(q)) | m J (h).
As direct consequence of Lemmata 4.2, 4.3, and 4.4 we obtain the main theorem of this section:

Inconsistency handling and further semantics
Under consistency-independent semantics, it is well possible that an ontologized program enters a state whose DL perspective is inconsistent. This indicates that the state describes a situation that should be impossible according to the background knowledge.
Example 5.1 In our running example, it could be the case that some processes run only on servers with a specific architecture. Suppose our background ontology contains additionally the following axioms: ArchitectureA ArchitectureB ⊥ ArchitectureA ∀ runsProcess.ArchitectureA ArchitectureA(s 1 ) ArchitectureB(p 1 ) These axioms state that the two concepts ArchitectureA and ArchitectureB are disjoint, meaning that the two architectures A and B are incompatible. Furthermore, any server with architecture A can only run processes properly that were compiled for the same architecture. The Server 1 is of architecture A through the axiom ArchitectureA(s 1 ) and Process 1 is of architecture B through the axiom ArchitectureB(p 1 ). With these additional axioms, the ontologized program state shown in Fig. 2 would be inconsistent, as Process 1 is now running on a server that does not support the architecture the process has been compiled for. 3 Inconsistent ontologies entail any axiom and thus any hook. Furthermore, hooks are associated to states based on the entailments in the DL perspective and thus, all hooks are active in an inconsistent state. This usually indicates undesired behaviors of the ontologized program and asks for a special treatment of inconsistent states. There are different ways in how one can deal with such situations: 1. Make sure the program component deals with such a situation using a sort of exception handling, 2. make sure the ontologized program never enters an inconsistent state, or 3. use an alternative semantics which makes inconsistent states impossible.
In this section, we discuss these options in detail and specify alternative semantics to treat inconsistencies. We first have a closer look at inconsistencies under consistency-independent semantics, how hard it is to detect them, and how they might be used in a verification process using probabilistic model checking. Then, we define two alternative semantics which deal with inconsistent states in a different way, the probability-normalized semantics and the probability-preserving semantics. Which semantics is appropriate ultimately depends on the nature of the probabilities involved. The right semantics thus depends on the use case. While these semantics avoid inconsistent states altogether, it is still possible for an ontologized program to be inconsistent under these semantics, which is the case if no induced MDP for the respective semantics can be found. Therefore, a central reasoning task is to determine, whether an ontologized program is consistent under the respective semantics. We keep practical approaches for deciding this as future work, and analyze the computational complexity of determining inconsistencies under the three semantics from a theoretical perspective. This analysis also reveals a close relation between ontologized programs and space-bounded Turing machines with oracles.

Auxiliary Lemmas for the hardness results
Before we introduce and discuss the semantics, we give some technical results in preparation for the proofs of our complexity results. We define the size of a concept, an axiom, or an ontology in the usual way as its string length, that is, the number of symbols needed to write it down. Here concept, role, and individual names count as one, as do logical operators, and number restrictions are encoded using unary encoding. We first show how to represent ontologies using on a polynomially bounded enumeration of DL axioms by renaming axioms. In order to show this, we need a more liberal definition of conservative extensions where, in contrast to the usual conservative extensions, we may also rename concept or role names. Proof. Let n ∈ N be the bound on ontology sizes. Using standard structural transformations (see for example [RKGH16]), we can compute for every SROIQ ontology O in polynomial time a normalized ontology that is a conservative extension of O and in which every axiom is in one of the following twelve forms:
As every normalized axiom is of one of the twelve forms above, it uses at most three names from X and one number, the number of axioms in A is bounded by p(n) 12 · |X| 3 · m 12m 4 , which is polynomial in n because m is polynomial in n.
The axiom enumeration π required by the lemma can then be defined as follows: for i ∈ {0, . . . , p(n)}, we set π (i ) α, where α is determined as follows: 1. α is of the form (i mod 12)+1 as above, 2. for a ∈ {1, 2, 3}, the ath (concept or role) name occurring in α is X j , where j For every ontology O, we obtain the index set I as required by first normalizing O, renaming it accordingly, and then assigning the indices.
Using an index function π as in Lemma 5.1, we can define a special type of oracle Turing machines called (alternating) Turing machines with DL oracles. Such a Turing machine uses an oracle tape with tape alphabet {0, 1, 2} (2 being the blank symbol), and is specified using an enumeration π of DL axioms as above, and some axiom α. Based on the current oracle tape content, we obtain an index set I that contains the number i iff the oracle tape contains a 1 at position i . The oracle then answers yes if {π (i ) | i ∈ I } | α, and no otherwise. For a given DL L, we may additionally require that the oracle only accepts inputs for which the corresponding ontology is in L, in which case we call the Turing machine a Turing machine with L-oracle for π, α . Lemma 5.2 Let k be a complexity class and L a DL for which deciding entailment is k -hard, and let T be a Turing machine with k -oracle and bound n on the size of the oracle tape. Then, we can construct in time polynomial in n and T a Turing machine T with L-oracle for some axiom enumeration π and CI α that accepts the same set of words with at most polynomial overhead.
Proof. We first argue that it suffices to focus on entailment of axioms of the form α A(a), since entailment of CIs can be reduced to it. Specifically, for any ontology O and CI C D, , where a and A do not occur in O. Because entailment in L is k -hard, we can construct for every query to the k -oracle in polynomial time an ontology O that entails α iff the query should return true. Because the oracle tape is bounded, we can use Lemma 5.1 to translate that ontology into a corresponding index set to serve as input for the L-oracle. T thus proceeds as T , but before sending a query to the oracle, it reduces it to the entailment of the axiom α from an ontology O, which it then translates to a query to the L-oracle.

Consistency-independent semantics
Before we can discuss inconsistencies under the consistency-independent semantics, we need a formal definition of what it means for an ontologized state of an ontologized program to be inconsistent. Based on this definition, we say an ontologized program is inconsistent under consistency-independent semantics if it can reach an inconsistent state.

Definition 5.2 An ontologized state q is inconsistent if O q is inconsistent. Let P be an ontologized program, and let M[P]
be the weighted MDP induced by P as in Definition 3.3. Then, P is inconsistent if there exists a state q ∈ Q that is inconsistent and reachable from the initial state ι.
Even though inconsistencies are allowed, we may still want to avoid inconsistent states under consistencyindependent semantics, and directly construct the ontologized program in such a way that inconsistent states are never reached. Inconsistent states may then indicate a bug in the ontologized program that we might want to detect using appropriate tool support. We provide a theoretical analysis about the arising complexity in the next subsection. The proof shows a close relation between L-ontologized programs and polynomially-space bounded Turing machines depending on the complexity k of deciding entailment in L. Thus it also gives an idea of the expressivity of ontologized programs. The underlying reduction to prove hardness via a reduction to oracle Turing machines will be reused for later results.
Theorem 5.1 Let k be a complexity class and L a DL for which deciding entailment is k -complete. Then, deciding consistency of L-ontologized programs is PSpace k -complete, even for non-probabilistic programs.
Proof. Let M[P] be the MDP induced by some ontologized program P as in Definition 3.3 where O is expressed in L. For the upper bound, we specify a non-deterministic PSpace algorithm that, starting from the initial state, explores all reachable states in M[P] and decides in k whether the current state is inconsistent. Specifically, for each current variable evaluation in P, we nondeterministically select a command in P P whose guard is satisfied. Then, we nondeterministically select an update that has a positive probability in the distribution of the command and apply this update on the current evaluation. In each step, we use a k -oracle to determine whether the current state is consistent, and which hooks are active. As each state can be stored in polynomial space, the algorithm runs in PSpace k .
For the lower bound, we provide a polynomial reduction of the acceptance problem for polynomially spacebounded, deterministic Turing machines T with k -oracle. Let be such a Turing machine, where • Q are the states, • o is the oracle tape alphabet, • q 0 is the initial state, • F ⊆ Q is the set of accepting states, 0, +1} is the transition relation, (which works on two tapes, the standard tape and the oracle tape), • q ? ∈ Q \ F is the query state to query the oracle, and • q yes , q no ∈ Q \ F are the query answer states.
The Turing machine uses two polynomially bounded tapes: one standard tape and one oracle tape. In every state that is non-final and not the query state, δ defines the successor state of T . Whenever the current state is q ? , the oracle is invoked, leading to T entering q yes in the next step if the oracle accepts the content of the oracle tape, and entering q no otherwise. Based on T and the input word w w 0 . . . w l , we build an ontologized program P T ,w s.t. P T ,w is inconsistent iff T accepts w .
Since entailment in L is k -hard, we can use Lemma 5.2 to construct a polynomially space-bounded Turing machine T with L-oracle for π, A(a) that accepts w iff so does T . Specifically, we obtain a set A of DL axioms, polynomially bounded in |w |, an axiom enumeration π : {0, . . . , r (|w |)} → A, where r is a polynomial, where Q {q 0 , . . . , q n }, and T accepts the same language as T , is still polynomially space-bounded, but uses an L-oracle. If T is in state q ? , and the oracle tape contains the word w 0 . . . w r (|w |) , the Turing machine moves into the state q yes iff {π (i ) | 0 ≤ i ≤ r (|w |), w i 1} | A(a), and otherwise moves to q no . We can construct T so that queries to the L-oracle are always posed using consistent ontologies, and in fact even that the oracle tape never describes an inconsistent ontology. Based on this Turing machine, we construct the ontologized program P T ,w .
Let p be a polynomial s.t. T uses at most p(|w |) tape cells on input w . We start by introducing the program component of the ontologized program. Recall that for each variable v in the program, we need to specify also its range via the function ρ. Specifically, variable v can only take values in The program uses the following variables: • state with ρ(state) |Q | stores the state of the Turing machine, • for 0 ≤ i ≤ p(|w |), wtape i with ρ(wtape i) | | stores the letter on the work tape position i , • for 0 ≤ i ≤ r (|w |), otape i with ρ(otape i) 1 stores the letter on the oracle tape at position i , • wpos with ρ(wpos) p(|w |) stores the current position on the default tape, • opos with ρ(opos) r (|w |), stores the current position on the oracle tape.
We use a single hook H {oracle yes} standing for the positive oracle answer. For every every i ∈ {0, . . . , p(|w |)} and every j ∈ {0, . . . , r (|w |)}, we use the following non-probabilistic command: Note that we omitted the action label of the command, as it is irrelevant for our purposes. To handle the behavior of the oracle, we further add the following commands, where q ? q i 1 , q yes q i 2 and q no q i 3 The initial state η P,0 of the program is the evaluation state 0, wtape i w i for i ∈ {0, . . . , l }, wtape i 0 for i ∈ {l , . . . , p(|w |)}, otape i 0 for i ∈ {0, . . . , r (|w |)}, wpos 0 opos. This completes the definition of the program component P in P T ,w . As DL axioms, we set as background ontology O ∅ and for the fluents F A ∪ { ⊥}. It remains to specify the interface functions Dc and cD. The interface is used to translate the oracle calls, as well as to establish the correspondence between acceptance of the Turing machine to inconsistency of the ontologized program.
For Dc, we set for every i ∈ {0, . . . , r (|w |)}, Dc(π (i )) otape i 1 to translate the oracle calls, and to encode that the ontologized states that correspond to accepting states in the Turing machine are inconsistent. Finally, we specify cD by setting It is standard to verify that the Turing machine T accepts w iff the ontologized program P T ,w is inconsistent, i.e., can reach an inconsistent state. Since T accepts w iff so does T , this completes the reduction.
Ontology-mediated PMC under consistency-independent semantics. Inconsistency in ontologized programs is not such a severe handicap as in other logic-based formalisms, as probabilistic properties can still be evaluated on MDPs with inconsistent states. In fact, they can even have a designated meaning, e.g., for modeling exceptions the program has to face. Note that commands can be used to detect if a program is in an inconsistent state. To this end, we can employ a designated hook inc that is satisfied in exactly those states that are inconsistent, i.e., a hook for which cD(inc) ( ⊥). Using this hook in guards of the program, the program can invoke the actions to undertake when an exception has occurred.Note that while all inconsistent states agree on the hooks that are active (it is always the full set of hooks), the command perspective of states can still differ. Specifically, private variables can encode additional information about the current state that can be used to decide how to react to inconsistencies.
The dedicated hook inc can then also be used to analyze whether the exception handling in the program satisfies the intended requirements. An example for an ontology-mediated PMC analysis under consistencyindependent semantics would be to decide whether P min 2(inc → (X¬inc ∨ XX¬inc)) > 95% Intuitively, this probabilistic property states that an exception is always successfully handled with a high probability of at least 95%. Here, successful handling means that, whenever an inconsistent state is reached, a consistent state is reached within at most two steps. Such a probabilistic property can be checked using the rewriting technique presented in Sect. 4 and hence, has full tool support by the PMC tool Prism [KNP11].

Probability-normalizing semantics
If a program is inconsistent, consistency-independent semantics relies on the program specification to deal with inconsistent states. On the one hand, this can offer flexibility on how inconsistent states are handled. On the other hand, it is more convenient to let the semantics handle the situation by definition. Since inconsistent states have no correspondence to states of the modeled system, they could stand for undesired states that should not occur in the MDP at all. The idea of probability-normalizing semantics is to remove all paths that can lead to an inconsistent state, and then normalize the resulting probabilities accordingly. Under this semantics, the ontology serves an additional purpose: not only does it assign meaning to the hooks, it also specifies which program states are possible, and thus restricts the transitions from a given state. This allows for a further separation of concerns and provides further reusability of the behavioral and the DL component of the program towards putting constraints on the state space. In the running example of the multi-server platform, our extended background ontology disallows execution of Process 1 on Server 1. Consequently, the outcome of the command (9) in Example 3.1 can only be the update in which Process 1 is moved to Server 3, which means that this update is now executed with a probability of 1. Note that we could achieve this behavior in this particular example also under consistencyindependent semantics. However, this requires an explicit handling of inconsistencies and modifications in the program that "provisions" the possible variable evaluations. More specifically, we then need a possibility to decide for each update in the command whether it would lead to an inconsistent state or not. While this works out well in our running example (see Sect. 6.2), we cannot expect such an encoding for any ontologized program.
To capture the probability-normalizing semantics, we define a different MDP that fulfills the above conditions. Intuitively, under probability-normalizing semantics, we consider the MDP obtained by removing all inconsistent states in the induced MDP and normalizing its probabilities. It is possible that for some state q and command g, σ with λ(q) | g, such a normalization is not possible, since all successor states that should have a positive probability lead to an inconsistent state. In this case, the command cannot be applied on q.

Definition 5.3 Let P be an ontologized program, and M[P]
Q, Act, P , ι, , λ, wgt the MDP induced by P. An MDP M is probability-normalizing w.r.t. P if M Q , Act, P , ι, , λ , wgt , where PN1 Q ⊆ Q contains only consistent states, PN2 λ and wgt are obtained from λ and wgt by restricting their domain to Q , PN3 for all q ∈ Q and σ ∈ Act s.t. P (q, σ ) is defined, we have for all q ∈ Q : P is called probability-normalizable if there exists a probability-normalizing MDP w.r.t. by P. In this case, we denote by M pn [P] the MDP induced by P under probability-normalizing semantics as the unique maximal probability-normalizing MDP w.r.t. P. Here, maximality is understood w.r.t. subset-maximality of Q and where the P is defined for the largest set of tuples (q, σ ) ∈ Q × Act.
Recall that according to our definition, MDPs cannot have final states. Therefore, to obtain the probabilitynormalizing MDP, it does not suffice to remove inconsistent states, but also states that would otherwise become final, since all of their every successor states are removed. As this operation mightlead to a removal of the initial state, not every ontologized program is probability-normalizable. If the program is probability-normalizable, we are not interested in any arbitrary probability-normalizing MDP, but in the one that maximizes both the set Q of states and the set P of transitions. The induced MDP under probability-normalizing semantics is always unique: Given two probability-normalizing MDPs M 1 and M 2 w.r.t. the same ontologized program P, we can construct their component-wise union, which is again a probability-preserving MDP. By doing this for all probability-normalizing MDPs for P, we obtain M pn [P], the maximal probability-normalizing MDP. Determining consistency under probability-normalizing semantics. Probability-normalizability is a stronger form of consistency in the following sense: if an ontologized program is not probability-normalizable, then not only can it reach an inconsistent state in M[P], but in fact every path in M[P] starting from the initial state eventually leads to an inconsistent state. We may thus also speak of inconsistency under probability-normalizing semantics. Even though this notion of inconsistency is much weaker than the one defined in Definition 5.2, the complexity of determining probability-normalizability is in fact the same. Intuitively, this is because we need to solve dual problems for both consistency notions: for inconsistency under consistency-independent semantics, we need to determine whether some path leads from the initial state to an inconsistent state, while for inconsistency under probability-preserving semantics, we need to determine whether all paths from the initial state lead to an inconsistent state.
Theorem 5.2 Let k be a complexity class and L a DL for which deciding entailment is k -complete. Then, deciding whether an L-ontologized program is probability-normalizable is PSpace k -complete, even for non-probabilistic programs.
Proof. For the upper bound, we note that the only way for P to be inconsistent under probability-normalizing semantics is if all probabilistic choices would lead to an inconsistent state in the M[P]. We can thus use a non-deterministic PSpace k -algorithm similar to the one described in the proof for Theorem 5.1 to determine whether a program is probability-normalizable: instead of testing for inconsistency of the current state, we test for consistency. Note that for an ontologized program to be probability-normalizable, it suffices to have a single execution path that never reaches an inconsistent state. Because M[P] has no final states, this execution path has infinite length. However, because the state space is bounded, any infinite execution path would need to visit some state twice. We use a counter to put an exponential bound on the visited states. After we visited exponentially many states, we know that some state must have been repeated, and we found an unbounded execution path that never visits an inconsistent state, and accept.
For the lower bound, we note that the reduction used in the proof for Theorem 5.1 can also be used for probability-normalizability. In that reduction, we reduce the word problem of deterministic polynomially-space bounded Turing machines with k -oracle to consistency of ontologized programs under consistency-independent semantics. Inspection of the construction reveals that the constructed program P T ,w is not only non-probabilistic, but even deterministic, in the sense that in every ontologized state, there is at most one command that can be executed. Specifically, there is exactly one command (11) for each assignment to the variables state, wpos, opos, wtape i and otape j, which means that in each ontologized state, at most one of these commands is executable. Moreover, for the assignment state i 1 , where q i 1 q ? denotes the oracle query state, there is no such command, because there is no transition in the Turing machine for the oracle state, and exactly one of the commands (12) and (13) is executable if state i 1 , unless the state is inconsistent. We obtain that, if some path in M[P T ,w ] leads from the initial state to an inconsistent state, then all paths lead to an inconsistent state, in which case the program is not probability-normalizable. Consequently, P T ,w is probability-normalizable iff P T ,w is consistent, which is the case iff T does not accept w . Since non-acceptance of words in polynomially space-bounded Turing machines with k -oracle is also PSpace k -complete, we obtain that probability-normalizability is PSpace k -hard.

Probability-preserving semantics
The probability-normalizing semantics changes the probabilities specified in the commands to avoid inconsistent states. This is the right choice if the program uses probabilities to model randomized behavior. For instance, in our running example, the program migrates a process as soon as this becomes necessary, and it does so by choosing each possible server with equal probability.If the ontology restricts the number of possible choices, e.g., disallowing migration to incompatible server architectures, then consequently the probabilities need to change as well. There are other scenarios where a change of probabilities is not desired: rather than using probabilistic commands to model randomized behavior, the program component may describe probabilistic outcomes of the modeled system that are based on measured probabilities. For instance, we might know that at any point in time the server has a probability of 1% of becoming disfunct and needs a restart. This probability should not be affected by the specifications: the semantics should not allow this probability to become 0% because having a disfunct server would be inconsistent with the background ontology. Rather, states from which we cannot ensure that the server becomes disfunct with a probability of 1% should be impossible by the semantics as well. To capture this behavior, we introduce the probability-preserving semantics. PP3 for all q ∈ Q and σ ∈ Act for which P (q, σ ) is defined, P (q, σ ) P (q, σ ).
P is called probability-preservable if there exists a probability-preserving MDP w.r.t. P. In this case, we denote by M pp [P] the MDP induced by P under probability-preserving semantics, which is the unique maximal probabilitypreserving MDP w.r.t. P, where maximality is understood as in Definition 5.3.
The difference to Definition 5.3 is Condition PP3, which does not normalize the probabilities in P , but keeps them if possible. Thus M pp [P] can be obtained from M[P] by removing all transitions that lead with a positive probability to an inconsistent state, and then removing all inconsistent states and those states for which all outgoing transitions have to be removed.
Determining consistency under probability-preserving semantics. The consistency notion that is used for the probability-preserving semantics is that of probability-preservability. We can see that this consistency notion is stricter than the one of probability-normalizability: it does not only remove parts of a probabilistic transition that lead to an inconsistent state, but also removes the whole transition if it can lead to an inconsistency. It turns out that deciding probability-preservability is more challenging than for the other consistency notions. Intuitively, the main reason for this is that we now need to take full care of the alternations of non-deterministic and probabilistic choices that underlie the semantics of ontologized programs: in each state, we non-deterministically select the next command to execute, after which there is a probabilistic selection of the outcome of that command. If one of the probabilistic choices would lead to an inconsistency, then we have to restrict the set of non-deterministic choices. It is thus not sufficient anymore to find a single execution path that leads to an inconsistency, as in the case of inconsistency in consistency-independent semantics, or a single execution path that leads to a consistency, as is the case for probability-normalizing semantics. Instead, execution trees have to be analysed.

Theorem 5.3
Let k be a complexity class and L be a DL for which deciding entailment is k -complete. Then, deciding whether an L-ontologized program is probability-preservable is APSpace k -complete. For non-probabilistic programs, it is PSpace k -complete.
Proof. Both bounds are via reductions from and to alternating Turing machines. In an alternating Turing machine, we switch between ∃-non-determinism and ∀-non-determinism, meaning that the Turing machine can switch between ∃-non-deterministic choices and ∀-non-deterministic transitions. Acceptance is then defined inductively according to the choices involved: a configuration is accepting if 1) it is in an accepting state, 2) there exists an ∃-non-deterministic transition to a configuration that is accepting, or 3) all ∀-non-deterministic transitions lead to an accepting configuration.
For the upper bounds, we use a modification of the algorithm used in the proof for Theorem 5.1 that runs in alternating polynomial space and decides probability-preservability of ontologized programs. Let P be an ontologized program as in Definition 3.1, and M ci [P] Q, Act, P , ι, , λ, wgt the MDP induced by P under consistency-independent semantics. The algorithm guesses the states q ∈ Q to be included in the probabilitypreserving MDP one after the other, starting from ι, where we use alternation to switch between the nondeterministic and the probabilistic choices of the program. Specifically, we have to guess a set of states Q s.t.: 1) no state in Q is inconsistent, 2) for every Q there is always somecommand that can be executed on the current state, and 3) all successor-states into which this command brings us with a positive probability are included in Q . Our algorithm thus proceeds as follows based on the currently guessed state q. If q is inconsistent, we reject. Otherwise, we non-deterministically select a command g, σ ∈ C P s.t. q | g (∃-non-determinism) and continue on all states q ∈ Q such that P (q, σ, q ) > 0 (∀-non-determinism). Each state takes polynomial space, and we use a k -oracle to determine which hooks are active and whether the state is consistent. Since this procedure can be implemented by an alternating Turing machine with k -oracle that uses polynomial space, probabilitypreservability can be decided in APSpace k . If the program is non-probabilistic, the ∀-non-determinism is not needed, and the algorithm runs in PSpace k .
For the lower bound, we adapt the reduction used in the proof for Theorem 5.1. However, this time, we reduce the word problem for polynomially space bounded alternating Turing machines with k -oracle. Specifically, let be such a Turing machine, where Q {q 0 , . . . , q n }, {γ 0 , . . . γ m } is the standard tape alphabet, i ⊆ is the input alphabet containing the blank symbol γ 0 2 ∈ , o is the oracle alphabet, q 0 is the initial state, is the transition function, the states q ? , q yes , q no ∈ Q manage the querying of the oracle, and g : Q → {∀, ∃, accept, reject} partitions the states Q into four categories of universal and existential quantified states, and accepting and rejecting states, respectively. The oracle works as in the proof for Theorem 5.1, and a configuration with state q is accepting if • g(q) accept, • g(q) ∃ and one of the successor configurations is accepting, or • g(q) ∀ and all successor configurations are accepting.
Again, we use Lemma 5.2 to construct, based on T and the input word w , a polynomially bounded set A of DL axioms, an axiom enumeration π : A → {0, . . . , r (|w |)}, where r is a polynomial, and an alternating Turing machine T Q , , γ 0 , i , {0, 1, 2}, q 0 , δ , q ? , q yes , q no , g with an L-oracle for π, A B , that is polynomially space bounded, and accepts w iff so does T . If T is in state q ? , and the oracle tape contains the word σ 0 . . . σ r (|w |) , the Turing machines moves into the state q yes iff and otherwise moves to q no . Based on this Turing machine, we construct the ontologized program P T ,w in a similar way as in the proof for Theorem 5.1 by making the accepting states of the Turing machine correspond to inconsistent program states, except that this time we use a different set C P of commands. Let p be the polynomial that bounds the number of tape cells. We first model the ∀-transitions. For every That is, we model ∀-non-determinism using the non-deterministic choices of the ontologized program. The reason for this is that for the program to be not probability preservable, every command that we can execute in an ontologized state would lead to an inconsistency. This corresponds to the situation in which every successor state in the Turing machine is accepting.
The corresponding transition has to be excluded from the probability-preserving MDP if at least one of the updates leads with a positive probability to an inconsistent state, which corresponds to the acceptance condition of ∃-states: at least one successor configuration has to be accepting. The commands that handle the use of the oracle are as in the proof for Theorem 5.1. It is standard to show that the resulting program is probability-preserving iff w is accepted by the Turing machine. As a consequence, we obtain that probability-preservability is APSpace k -hard. Now assume that for no state q ∈ Q we have g(q) ∃. Then, T corresponds to a Turing machine in which every execution path should lead to an accepting state, for which the word problem is coNPSpace k PSpace kcomplete. The ontologized program P T ,w is then non-probabilistic. As a consequence, deciding whether nonprobabilistic programs are probability-preserving is PSpace k -hard.

Implementation and evaluation
We demonstrate the feasibility of ontology-mediated PMC by an implementation of the methods described in Sect. 4 according to consistency-independent semantics. We apply our implementation on the running example of the multi-server system presented in the last sections, modeled more in detail than described throughout the paper.

Implementation details
Our implementation consists of two components: an ontology reasoning component, which computes the rewritings for each hook, and the program generation component, which then integrates those into the program. In the end, we obtain a program in the standard input language of the PMC tool Prism [KNP11]. Ontology reasoning. Our implementation relies on the justification-based rewriter as defined in Sect. 4.2. The ontology-component of the ontologized program is provided in the standard web ontology language OWL-DL [HKS06]. To compute the hook rewritings, we implemented a tool in Scala that uses the OWL-API [HB11] to parse and access the ontology, and the OWL reasoning system Openllet based on Pellet [SPG + 07] for computing the justifications. The OWL-API [KPHS07] comes with an implementation of the black-box approach for axiom pinpointing, which can be used with any reasoning system compatible with the OWL-API. However, this approach turned out to be too slow in practice for our purposes. To this end, we decided to rely on Openllet, the only state-of-the art reasoner that supports most of the OWL-DL profile and comes with an integrated whitebox implementation for computing justifications [SPG + 07]. This method for computing justifications worked out to be much faster on our examples. We adapted this implementation to reduce computation times further. Neither the implementation of the black-box approach in the OWL-API nor the one of the white-box approach in Openllet directly support relative justifications. Note that, in order to compute the hook rewritings, we only need to vary the fluent axioms in F, and not the axioms in the static DL knowledge O. Since the justification algorithm implemented in Openllet varies both, and thus potentially explores the exponentially many subsets of O, it was not able to create any hook rewriting without running into memory problems.
We adapted the justification algorithm in Openllet to support relative justifications w.r.t. O and to only return the axioms from F. Especially for large numbers of axioms in O, this reduces the search space for computing justifications drastically. Program and query specification. For the program component of the ontologized program, we use the input language of Prism and the preprocessor templating functionalities provided by Prism. Note that programs as formally defined in Sect. 2 form a subclass of the Prism language. However, our implementation supports the full class of the Prism language and even Prism language extensions such as ProFeat [CDKB18]. We further allow the use of hooks in guards that are not specified in the program itself, approaching abstract programs as issued in Sect. 3.1. Thus, the specified program cannot be analyzed without a specification of hook rewriters, obtained through the interface and reasoning over the given ontology. In the current implementation, the interface directly provides the combination of hook names and axioms for their evaluation during the reasoning process on the given ontology. After the reasoning process, the hook rewritings are generated as standard formula expressions in the input language of Prism that allow for a macro-like replacement of hooks by the Boolean expressions returned from ontology reasoning. Technically, the concatenation of the program specification and the hook formula expressions then leads to a standard Prism program, which we use as input for a quantitative analysis by Prism. Note that due to the global evaluation of formula expressions, hook rewriters apply also for hooks used in probabilistic, expectation, and quantile queries and hence allow for expressing knowledge-dependent property specifications.

Case study setup
Our evaluation scenario is based on the multi-server platform example used throughout this paper, modeled in more detail. The test suite itself consists of the ontology, the program, and the quantitative queries for the analysis. For the automated generation of different system setups, we use scripts that take the number of servers and processes as input and generate ontologies and programs. Ontology: multi-server knowledge base. The ontology conducted for this study uses the DL ALCQ. It models background knowledge on different capacity constraints of the servers and different priority settings on the processes. To model compatibility of processes with server architectures (see Example 5.1), we distinguish between two types of architectures: ♦ and . Servers could be of and processes could be compiled for either architecture. Then, ♦-processes can only be executed on servers having architecture ♦ and likewise, -processes can only be executed on servers with architecture . We used three different types of hooks to link the abstract program with the ontology: critical system state hook "critical" is active in states the system should avoid and which we call critical states in the following, migrate hook "migrateServers" is active in those situations where the system should schedule the migration of some process on server s to another server, and inconsistency hook "inc p s" is active when a process p assigned to a particular server s would lead to an inconsistent state of the system, taking into account both capacity and compatibility limitations.
We defined four ontologies in total, which we denote by O 1 , . . . , O 4 in the following. These ontologies differ in their capacity and compatibility constraints, as well as properties of the server and processes. Table 3 gives an overview of the four ontologies in terms of those concepts that enable the critical system state hook (C), the migrate hook (M), and the inconsistency hooks (I). For instance, for O 2 , the system is in a critical system state when a prioritized process runs on an overloaded server; the migrate hook becomes active when either a prioritized process runs on an almost overloaded server or some server is overloaded; and a system state is inconsistent when the maximal number of processes on a server is surpassed or a process runs on a server those architecture is not compatible with the process. For ontology O 1 , the situation is similar as for O 2 , but where processes compiled for incompatible architectures do not lead to an inconsistent system state. Intuitively, the servers according to O 1 could differ to the servers of other ontologies by running virtualization software that enables processing any kind of processes independent from the architecture the process is compiled for. To evaluate the flexibility regarding the operational behavior in ontologized programs, we provide two programs components, differing in their policy on how jobs are processed on each server. The first program, denoted P rand , uses a randomized policy, i.e., the process to be scheduled next is selected by tossing a fair coin. The second, denoted P rr is using a deterministic policy selecting the next process in a round-robin fashion. For each program we assume a fixed rate how likely it is in a step to spawn a new process. Processes will then be assigned to a server with compatible system architecture according to a uniform distribution.
As apparent in the specification of the ontologies, an inconsistent system state would occur when a process is running on a server with different architecture compatibility. This undesired situation is resolved explicitly in the program component, following ideas for resolving inconsistencies in the probability-normalizing and probability-preserving semantics. The probability mass of the randomized selection of processes to be executed next in the program P rand is redistributed in case of leading to an inconsistent state. After the redistribution, the full probability mass leads to states where all processes run on servers with the same architecture as the process, implementing a similar approach as for the probability-normalizing semantics. Note that when spawning new processes, these processes are also assigned to servers with the same architecture as the process is compiled for, also avoiding inconsistent system states through redistribution. Differently, for the case of migrating processes, the nondeterministic choices responsible for the migration of processes to a server running incompatible architecture are disallowed in a similar fashion as done within probability-preserving semantics. Due to the mixture of these two kinds of inconsistency handling, we perform ontology-mediated PMC under consistency-independent semantics, but with explicit handling of inconsistencies.
Towards a quantitative analysis of both programs P rand and P rr , we consider three different weight assignments. The weight time describes the time required for processing by a set of weight assignments W time { tt, 1 } where to each step one unit of time is assigned to. Weight critical describes the number of critical states entered by weight assignments W critical { critical, 1 } assigning weight one to each critical state. Note that thus, reasoning on the ontology is required to determine the weight structure critical for the MDP semantics of the program. Finally, energy describes energy consumption by weight annotations where #S stands for the total number of servers, #P for the total number of processes in the multi-server system, and W migrate energy is the set of weight assignments that assign one unit of energy to each process that has been migrated in the last step 1 . Intuitively, a server to consume one unit of energy when one or more processes are assigned to the server. In case no process is assigned to the server, this server is idling and does not consume any significant amount of energy, which we model with zero energy costs. Furthermore, a migration task that moves a process from one server to another requires one additional unit of energy.
In each program, we include a dedicated counter variable utility that at any moment evaluates to the total number of jobs completed so far. Here, prioritized processes achieve double the utility of low prioritized processes. With the weight annotations above and the value of the utility counter, trade-offs between costs and utility can be considered where time, number of criticalstates, or energy consumption are interpreted as costs. For instance, it might be favorable to migrate a prioritized process to a different server. On the one hand this requires one additional unit of energy, but on the other hand it could, depending on the ontology, reduce the chance of entering a critical system state. Furthermore, migrating a process can increase the chance of completing this process and thus achieving more utility. Quantitative queries. Towards a quantitative analysis we specified the following standard probability and expectation queries: (i) What is the probability of reaching a critical system state within 15 time steps? P ex (3 time≤15 critical) ?
(ii) What is the expected energy consumption until achieving a utility value of at least 20?
(iii) What is the expected number of critical states entered before achieving a utility value of at least 20?
For each of these queries, we consider their minimizing and maximizing variant when ranging over all resolutions of non-deterministic choices in the MDP, i.e., ex ∈ {min, max} in the above formalization of queries. Note that query (i) directly contains the hook critical in the LTL formula, hence requiring knowledge of the ontology to be evaluated.
To show-case our approach for more advanced model-checking tasks, we investigate the cost-utility tradeoff between energy or critical situations and utility in terms of energy-utility quantiles [BDD + 14]. For this, we consider the following quantile queries: (iv) What is the minimal energy required to achieve a utility value of at least 20 with probability at least 95%? Qu >0.95 3 ≤energy (utilit y ≥ 20) ?
(v) What is the minimal number of critical states entered to achieve a utility value of at least 20 with probability at least 95%?
Note that the amount of utility achieved is encoded into the state space, i.e., there is a variable utilit y that evaluates to the utility achieved so far. To this end, utilit y ≥ 20 is an arithmetic constraint that can be used as label in any LTL formula and evaluated as atomic proposition in the MDP semantics of the program (cf. Sect. 2.3).

Evaluation
For an evaluation of our implementation, we performed a quantitative analysis of the aforementioned queries on ontologized programs formed by the two programs P rand and P rr and the four ontologies O 1 , . . . , O 4 , each on systems with two and three servers, respectively. While the system with two servers comprises one server of each architecture, the three-server system has two servers of architecture ♦ and one of architecture . Within all of these combinations, we obtained 4 · 2 · 2 16 ontologized programs in total, which we translated into programs expressed in the input language of Prism. Quantitative analysis results. The numerical results of the probability query (i), the expectation queries (ii) and (iii), and the quantile queries (iv) and (v) are shown in Table 4. In Fig. 3, these results are visualized, ordered by probability queries (upper left), expectation and quantile queries for the energy weight annotations (upper right), expectation and quantile queries for the critical weight annotations (lower left), and the overall running time to evaluate these queries (lower right, logarithmic scale). The ontologies are denoted by "O i (a)" where i is the index of the ontology number and "a" indicates the architectures of the servers of the system setup. Left (blue) bars show results for randomized scheduling, right (red) bars show results for round-robin scheduling. Bars span the results for minimizing and maximizing queries, while dots indicate the quantile results.
In the case of the setup with two servers, only under ontology O 1 there is some freedom in performing migrations while keeping a consistent system state as all processes of any architecture can be processed on both servers. The other ontologies O 2 , O 3 , and O 4 disallow processes to be placed on server with a different architecture than the process, since this would lead to inconsistent system states (see Table 3). Hence, only in the setup O 1 (♦ ) (ontology O 1 with two servers, one of each architecture) the minimal and maximal expected number of critical situations and expected energy consumption differ. The probability of reaching a critical situation where a prioritized process runs on an overloaded server is very high in the two-server setup, as there are comparably many processes to be scheduled on two servers. In the three-server setup, the additional server provides enough freedom for migration strategies and less processes than in the two-server setup have to be scheduled. Hence, as we can see in the results of the minimizing probability to reach a critical situation, a clever scheduling can reduce the probability of reaching critical situations in settings O 1 (♦♦ ), O 2 (♦♦ ), and O 3 (♦♦ ). In the setting O 4 (♦♦ ), more critical situations can occur according to ontology O 4 (see Table 3) and thus, there is less flexibility to avoid critical situations even with clever strategies.
While cost-utility trade-offs lead to higher costs than corresponding expectations in most of the two-server setups, they are close to the minimal expected cost values in most of the three-server setups. Again, the reason can be seen in the greater migration flexibility the three-server setups provide. This statement is underpinned by the three-server setup O 4 (♦♦ ), where ontology O 4 is more restrictive than the other ontologies, and the cost-utility trade-offs are slightly greater than corresponding worst-case expectations. Likewise, in the two-server setup O 1 (♦ ), the ontology O 1 is less restrictive ontology than the ontologies within the other two-server setups, leading to cost-utility trade-offs within the expectation ranges.
In all scenarios we see that a round-robin job-selection policy performed slightly better than the randomized one when the objective is to minimize energy consumption, reaching critical system states, and minimizing costutility trade-off. This can be explained by the fact that when analyzing optimal schedulers, they can provision the next job selection and thus, can preemptively prevent critical situations by migrating processes or suppress migration to save energy in case there is no urgent need for such a migration.
From our experiments, we can draw the following conclusions: First of all, our approach of separating concerns by loosely coupled program and ontology components enables us to independently specify and analyze all kinds of combinations of programs and ontologies, leading to different but explainable results. Varying program and ontology component thus has direct impact on the global systemcharacteristics (see Table 4). Second, programs executed in more restrictive contexts modeled by ontologies show more restricted results with respect to the possibilities to resolve nondeterminism. Inconsistent states have great impact with this respect, as the greater the number of states inconsistent in the ontology, the less flexibility is given to a scheduler to resolve nondeterminism. In Fig. 3, the effect of more restrictive ontologies is visualized by showing smaller bars. Third, our approach to translate ontologized programs to standard Prism models enables the quantitative analysis of all state-of-the-art analyses supported by Prism, involving the analysis of cost-utility trade-offs. Performance statistics. All the experiments were carried out on an Intel Xeon E5-2680@2.70GHz server platform (Turbo Boost and HT enabled) with 128 GB of RAM running Debian GNU/Linux 9.1. The rewriting of all 16 ontologized programs into Prism programs took 130 seconds in total, including the computation of hook formulas using justifications by our adjusted version of the DL reasoner Openllet. We used the symbolic MTBDD engine of Prism in the version presented in [KBC + 18], which supports the computation of energy-utility quantiles [BDD + 14]. Furthermore, we applied variable-reordering techniques to reduce the size of the MTBDD representation of the model and speed-up the computations. In Table 5, the model characteristics in terms of system states of the resulting MDP, the symbolic representation of the model using MTBDD nodes, and the analysis times for evaluating the queries (i)-(iii) and cost-utility quantile queries (iv) and (v) are shown. Note that the different ontologies, as well as program variants have a great impact on the model and analysis characteristics. We see a big difference in both model size and analysis times between the experiments that involve ontology O 1 and experiments with other ontologies. This can be explained by the fact that ontology O 1 imposes no constraints on process and server architectures such that only servers exceeding the number of maximal processes are in an inconsistent state (see Table 3). To this end, those states where processes run on a server with a different architecture the process is compiled for are also reachable in a system execution. This is not the case in the other system setups with ontologies different than O 1 , where such states are pruned and hence, the state space is restricted there. The sizes of the models have direct impact on their analysis times. As for the analysis results, we visualized the run-time characteristics of evaluating all queries in Fig. 3 on the lower right. This also explains the huge analysis times for the setups with ontology O 1 . Our experiments hence show that model-checking speed and results benefit from sufficiently precise and restrictively modeled knowledge given by ontologies.

Related work
Model checking context-dependent systems. The idea of using different formalisms for behaviors and contexts to facilitate model checking goes back to [DBRL12], where a scenario-based context description language (CDL) based on message sequence charts is used to describe environmental behaviors. Their aim is to mitigate the state-space explosion problem by resolving nondeterminism in the system to model the environment by parallel composition with CDL descriptions of the context. However, the approach by [DBRL12] also uses an operational description of the context. Our approach focuses on separating the description of operational behavior and contexts by using dedicated specification formalisms. Role-based conceptual modeling describe formalisms to specify contexts and their dynamics w.r.t. role-playing entities (see, e.g., [KBGA15]). Here, components may play different roles in specific contexts (modeled through elements called compartments). Modeling and model checking role-based systems with exogenous coordination has been detailed in [CDB + 16, BCD + 18, CBDK20]. While their specification of the relationships between components in role-based systems follow a graphical specification language [KBGA15, CDB + 16], the semantics is provided following an automata-theoretic approach. Feature-oriented systems describe systems comprising features that can be active or inactive (see, e.g., [DBK15]). We used similar principles within our framework to combine ontological elements as show-cased in our evaluation in Sect. 6: in Table 3, the columns indicate different feature formalizations of the context while the rows indicate for which ontology description which of these features are considered. A reconfiguration framework for context-aware feature-oriented systems has been considered in [MNSY16]. All the above formalisms use an operational description of contexts, while we intentionally focused on a declarative representation through ontologies that allows for reasoning about complex information and enables the reuse of established knowledge bases.

Description logics in Golog programs.
There is a relation between our work and work on integrating DLs and ConGolog programs [BZ13,ZC15]. The focus there is on verifying properties formulated in computation tree logic for ConGolog programs, where also DL axioms specify tests within the program and within the properties to be checked. Differently, we provide a generic approach that allows to employ various PMC tasks using existing tools, and allow for probabilistic guarded command programs. Furthermore, while in ConGolog programs the operational and DL part is integrated in one formalism, our approach separates both parts so that they can easily be varied within the constraints of the interface. However, the main difference is that in the semantics of [BZ13,ZC15], states are identified with interpretations rather than ontologies, which are directly modified by the program. This makes reasoning much more challenging, and easily leads to undecidability if syntactic restrictions are not carefully imposed. Closer to our semantics are the DL-based programs presented in [HCM + 13, CDGLR11], where actions consist of additions and removals of assertions in the ontology. Again, there is no separation of concerns in terms of program and ontology, and they only support a Golog-like program language that cannot describe probabilistic behavior. Ontology-oriented programming. Within the concept of ontology-oriented programming [HCN08], ontologies are described and referred to in the program itself, without separating concerns by using different suitable formalisms for operational behaviors and ontology for knowledge representation. However, our approach currently supports only static ontologies, while the expression of ontologies in the same formalism as the behaviors allows for dynamic changes of the ontology. Ontology-mediated query answering. There is a resemblance between our concept of ontology-mediated PMC and ontology-mediated query answering (OMQA) [PLC + 08, BO15]. OMQA is concerned with the problem of querying a possibly incomplete database, where an ontology is used to provide for additional background knowledge about the domain of the data, so that also information that is only implicit in the database can be queried. Sometimes, additionally a mapping from concept and role names in the ontology to tables in the database is provided, which plays a comparable role to our interface [PLC + 08]. Similar to our approach, a common technique for OMQA is to rewrite ontology-mediated queries into queries that can be directly evaluated on the data using standard database systems. However, differently to our approach, this is in general only possible for very restricted DLs. In fact, for expressive DLs, the complexity of OMQA is often an exponential higher than standard DL reasoning tasks [Lut07,NOS16], or not even fully characterized yet [RG10].

Discussion and conclusion
To facilitate the quantitative analysis of knowledge-intensive systems, we introduced ontologized programs where probabilistic guarded command programs specify operational behaviors and DLs are used to describe additional knowledge. We have devised a reduction algorithm for ontology-mediated PMC using ontologized programs to the case of standard PMC, implemented this reduction, and illustrated an application of our approach for a quantitative analysis of a multi-server platform.
From an abstract point of view, the general idea of ontologized programs is to use different domain-specific formalisms for specifying the program and the background knowledge, which are then linked by an interface. We believe that the general idea of specifying operational behavior and static system properties separately, each using a dedicated formalism, would indeed be useful for many other applications. To this end, behaviors could be specified, e.g., by program code of any programming language, UML state charts, control-flow diagrams, etc. that are amended with hooks referring to additional knowledge, e.g., described by databases where hooks are resolved through database queries. Depending on the chosen formalisms, our method for rewriting ontologized programs could still be applicable in such settings.
Note that while we discussed our approach for operational system models in terms of MDPs, it is almost straightforward to apply our methods and implementation to any other formalism that can be described in the input language of Prism. To this end, also (probabilistic) model checking of transition systems, discrete Markov chains, or continuous-time Markov chains could be enhanced with ontology knowledge for quantitative analysis.
Lessons learnt. The presented approach exploits the formalisms and techniques that are well-suited to the respective concerns. This approach made it very easy to benefit from the most recent developments in the respective fields without a dedicated implementation built from scratch, but using standard state-of-the-art tooling. Furthermore, varying behavioral descriptions and ontologies was simple on the conceptual and also on the evaluation side. On initial tryouts not relying on the techniques presented, a direct encoding of knowledge into probabilistic guarded command language turned out to be far more complicated and error-prone. One aspect that was not obvious from the start was the impact of the specification of knowledge on the model sizes and analysis times. Our experiments showed that the more specific knowledge is provided, the more the state-space could be reduced and thus, the analysis could be vastly speed up (cf. Table 5). Further directions. Besides investigating the applicability of our approach on different formalisms for the program component and ontology component of ontologized programs and their use with different analysis techniques, there is plenty room for further improvements already in the setting presented in this paper. First, our definitions of probability-normalizing and probability-preserving semantics are generative, i.e., they can be algorithmically pursued by a model transformation on the consistency-independent semantics. It would be interesting to implement these transformations and investigate the impact of the different semantics on the resulting model size and analysis speed. Second, one could consider a closer integration between the ontology and the abstract program by means of a richer interface. For example, it might be desirable to exchange numerical values between the components. Such values could be mapped directly into the DL by the use of concrete domains [BH91], which would allow to express more numerical constraints in the ontology. Another way to extend the expressivity is to employ non-classical variants of DLs, such as probabilistic DLs. Such DLs can express probabilistic constraints in the ontology. There are several approaches to enrich DL ontologies by probabilities (see, e.g., [LS10,BKT17]) on which reasoning procedures have been devised and even axiom pinpointing has been investigated [PT13]. Third, we plan to investigate dynamic switching of ontologies during program execution, to model complex interaction between ontologies as in [DBK15], exploiting the close connection to feature-oriented systems discussed in Sect. 7. By doing so, we could achieve a switch from context-dependent PMC on knowledge-intensive systems to context-aware PMC. Fourth, one could further optimize the generation of hook evaluations. Currently, such Boolean expressions are represented in disjunctive normal form (see Equation (10)). These could be optimized via well-known reduction methods from circuit design such as Espresso [BSVMH84].