Multi-Context Systems (MCS) model, using Computational Logic, distributed systems composed of heterogeneous sources, or “contexts”, interacting via special rules called “bridge rules”. In this paper, we consider how to enhance flexibility and generality in bridge-rules definition and application.
Multi-Context Systems (MCSs) have been proposed in Artificial Intelligence and
Knowledge Representation to model information exchange among heterogeneous
sources [
The reason why MCSs are particularly interesting is that they aim at a formal
modeling of real applications requiring access to distributed sources, possibly on the web.
In many application domains the adoption of MCSs can bring real advances,
whenever different types of heterogeneous information systems are involved and a rigorous
formalization should be adopted, also in view of reliability and verifiability of the
resulting systems. Notice that this kind of systems often involve agents; MCSs encompassing
logical agents have in fact been proposed in [
Given the potential impact of MCSs for practical knowledge representation and
reasoning, there are some aspects in which their definition is still too abstract. In this paper,
we introduce and discuss some formal extensions of MCSs, useful for a practical use
in dynamic environments, and we try to provide guidelines for implementations. The
? This work is partially supported by INdAM-GNCS-17 project, by Xunta de Galicia, Spain
(projects GPC ED431B 2016/035 and 2016-2019 ED431G/01 for CITIC center) and by the
European Regional Development Fund (ERDF).
paper considers the following aspects. (i) The specification of proactive bridge-rule
activation, i.e., a bridge-rule in our approach is no longer applied whenever applicable,
but it must be explicitly enabled by the context where it occurs. (ii) The explicit
definition of evolution of an MCS over time in consequences of updates that can be more
general than sensor input as treated in [
Overall, we propose enhancements which are not in conflict with existing proposals
for MCSs which evolve in time [
Heterogeneous MCSs have been introduced in [
A multi-context system (MCS) M = fC1; : : : ; Cng is a set of n = jM j contexts, each of them of the form Ci = hci; Li; kbi; brii, where ci is the context name (unique for each context, or number i if omitted), Li = hKB i; Cni; ACC ii is a logic, kbi 2 KB i a knowledge base, and bri is a set of bridge rules, each of them 2 bri like s
A1; : : : ; Ah; not Ah+1; : : : ; not Am
(1)
where the left-hand side s is called the head, denoted as hd( ), the right-hand side is
called the body, denoted as body ( ), and the comma stands for conjunction. We define
the positive (resp. negative) body as body +( ) = fA1; : : : ; Ahg (resp. body ( ) =
fAh+1; : : : ; Amg). The head hd( ) = s is a formula in Li such that (kbi [fsg) 2 KB i.
Each element Ak in the body has the form (cj : p) for a given j, 1 j jM j, and
can be seen as a query to the (possibly different) context Cj 2 M whose name is cj , to
check the status of belief p (a formula from Lj ) with respect to the current belief state
(defined below) in Cj . When the query is made in the context j = i we will omit the
context name, simply writing p instead of (ci : p). A relational MCS [
A belief state (or data state) S of an MCS M is a tuple S = (S1; : : : ; Sn) such that for 1 i n = jM j, Si 2 Cni. Thus, a data state associates to each context Ci a possible set of consequences Si. A bridge rule 2 bri of context Ci 2 M is applicable in belief state S when, for any (cj : p) 2 body+( ), p 2 Sj , and for any (ck : p) 2 body ( ), p 62 Sk; so, app(S) is the set of heads from those bridge rules applicable in S.
In managed MCSs (mMCSs)4 the conclusion s, which represents the “bare” bridgerule result, becomes o(s), where o is a special operator. The meaning is that s is processed by operator o, that can perform any elaboration, such as format conversion, belief revision, etc. More precisely, for a given logic L with formulas F = fs 2 kb j kb 2 KB g, a management base is a set of operation names (briefly, operations) OP , defining elaborations that can be performed on formulas. For a logic L and a management base OP , the set of operational statements that can be built from OP and F is aFgOePme=nt ffuon(sc)tijoon,2mOngP;:s22F OFPg. The semantics of such statements is given by a man
KB ! KB , which maps a set of operational
statements and a knowledge base into a (possibly different) modified knowledge base5. Now,
each context Ci = hci; Li; kbi; bri; OPi; mngii in an mMCS is extended to include its
4 For the sake of simplicity, we define mMCS simply over logics instead of “logic suite” as done
in [
Fig. 1. F&K System: General Architecture own management function mngi which is crucial for knowledge incorporation from external sources and can be non-monotonic. The application of the management function mngi to the result of the applicable rules must be acceptable with respect to ACCi. We say that a belief state S is an equilibrium for an mMCS M iff, for 1 i jM j, Si 2 ACCi(mngi(app(S); kbi)) (2)
Namely, we (i) apply all the bridge rules of Ci that are applicable in the belief state S; (ii) apply the management function which, by incorporating bridge-rule results into Ci’s knowledge base kbi, computes a new knowledge base kb0i; and, finally, (iii) determine via ACCi the set of acceptable sets of consequences of kb0i. In an equilibrium, such a set includes Si, i.e., an equilibrium is “stable” w.r.t. bridge-rule application.
Conditions for existence of equilibria and the complexity of deciding equilibrium
existence for mMCS have been studied [
Below we introduce some enhancements to the mMCS paradigm. We devised the
proposed extensions in the perspective of the application of mMCSs to Cyber-Physical
Systems (CPS). In Fig. 1 we depict the scenario outlined in [
Bridge rules as defined in mMCSs are basically a reactive device, as a bridge rule is
applied whenever applicable. In dynamic environments, however, a bridge rule in general
will not be applied only once, and it does not hold that an equilibrium, once reached,
lasts forever. In fact, in recent extensions to mMCS, contexts are able to incorporate
new data items coming from observations, so that a bridge rule can be, in principle,
re-evaluated upon new observations. For this purpose, two main approaches have been
proposed for this type of mMCSs: so-called reactive [
However, in the general case of dynamic environments, contexts can be realistically
supposed to be able to incorporate new data items in several ways, including interaction
with a user and with the environment. We thus intend to propose extensions to explicitly
take into account not only observations but, more generally, the interaction of contexts
with an external environment. Such an interaction needs not to be limited to bridge
rules, but can more generally occur as part of the context’s reasoning/inference process.
We do not claim that the interaction with an external environment cannot somehow
be expressed via the existing approaches to MCSs which evolve in time [
We proceed next to define a new extension called timed MCS (tMCS). In a tMCS,
the main new feature is the idea of (update) action. For each context Ci, we define a set
act i of elementary actions, where each element 2 act i is the name of some action or
operation that can be performed to update context Ci. We allow a subset Obsi acti
for observing sensor inputs as in [
Ui : KBi 2acti ! 2KBi n f;g, so that kb0i 2 Ui(kbi; i) means that the “new” knowledge base kb0i is a possible result of updating kbi with action i under function Ui. We thus assume Ui to encompass all possible updates performed to a module (including, for instance, sensor inputs, updates performed by a user, consequences of messages from other agents or changes determined by the context’s self re-organization). Note that Ui(kbi; i) is (possibly) non-derterministic, but never empty (some resulting kb0i is always specified). In some cases, we may even leave the knowledge base unaltered kbi 2 Ui(kbi; i). Notice that update operations can be non-monotonic.
In order to allow arbitrary sequences of updates, we assume a linear time represented by a sequence of time points ftT gT 0 indexed by natural numbers T 2 N and representing discrete states or instants in which the system is updated. The elapsed time between each pair of states is some real quantity = tT+1 tT > 0. Given T 2 N and context Ci, we write kbi[T ] and i[T ] to respectively stand for the knowledge base content at instant T , and the action performed to update Ci from instant T to T + 1. We define the actions vector at time T as [T ] = ( 1[T ]; : : : ; n[T ]). Finally, Si[T ] denotes the set of beliefs for context Ci at instant T whereas, accordingly, S[T ] denotes the belief state (S1[T ]; : : : ; Sn[T ]).
Definition 1 (timed context). Let Ci = hci; Li; kbi; bri; OPi; mngii be an mMCS context. The corresponding timed context w.r.t. an initial belief state S is defined as: – Ci[0] = hci; Li; kbi[0]; bri; OPi; mngi; act i; Uii – Ci[T +1] = hci; Li; kbi[T +1]; bri; OPi; mngi; act i; Uii, for T 0 where kbi[0] := kbi and S[0] := S, whereas kbi[T + 1]:=mngi(app(S[T ]); kb0) and kb0 2 Ui(kbi[T ]; i[T ]).
Definition 2. We let a tMCS at time T be M [T ] = fC1[T ]; : : : ; Cn[T ]g.
The initial timed belief state S[0] can possibly be an equilibrium, according to original mMCS definition. Later on, however, the transition from a timed belief state to the next one, and consequently the definition of an equilibrium, is determined both by the update operators and by the application of bridge rules. Therefore: Definition 3 (timed equilibrium). A timed belief state of tMCS M at time T + 1 is a timed equilibrium iff, for 1 i n it holds that Si[T +1] 2 ACCi(kbi[T +1]).
The meaning is that a timed equilibrium is now a data state which encompasses
bridge rules applicability on the updated contexts’ knowledge bases. As seen in Def. 1,
applicability is checked on belief state S[T ], but bridge rules are applied (and their
results incorporated by the management function) on the knowledge base resulting from
the update. The enhancement w.r.t. [
In the original definition of mMCSs, bridge rules are ground by definition. In [
In this section, we formally specify reasonable modalities for bridge-rules
grounding and for proactive, rather than reactive, application. The issue of bridge-rule
grounding has been discussed in [
Definition 4. Let r 2 bri be a non-ground bridge rule in a context Ci of a given mMCS M with (timed) belief state S[T ]. A ground instance of r w.r.t. S[T ] is obtained by substituting every variable occurring in r with ground terms occurring6 in S[T ]. By a “ground bridge rule” we implicitly mean a ground instance of a bridge rule w.r.t. a timed data state. We now redefine bridge-rule applicability, by first introducing proactive activation. For each context Ci, let7
Hi[T ] = fsj there exists rule 2 bri with head hd( ) = s at time T g.
We introduce a timed triggering function, tri [T ] : KBi ! 2Hi[T ], which specifies (via their heads) which bridge rules are triggered at time T , and so, by performing some reasoning over the present knowledge base contents. Since Hi[T ] can be in general an infinite set, tri [T ]( ) may itself return an infinite set. However, in practical cases, it will presumably return a finite set of rules to be applied at time T .
2 bri is triggered at time T iff hd( ) 2 tri[T ](kbi[T ]). 6 Variables may occur in p of atoms (cj:p) in the body of r, in its head o(s), or in both. 7 Here, the dependency on T is fictitious. It will be relevant for bridge-rules patterns in Sec. 3.3.
Let grtri[T ] be the set of all ground instances of bridge rules which have been triggered at time T , i.e., 2 grtri[T ] iff is a ground instance w.r.t. S[T ] of some non-ground r such that hd( ) 2 tri[T ](kbi[T ]).
For an mMCS M , data state S[T ] and a ground bridge rule , let S[T ] j= body( ) represent that the rule body holds in belief state S[T ].
Definition 6. The set app(S[T ]) relative to ground bridge rules which are applicable in a timed data state S[T ] of a given tMCS M [T ] = fC1[T ]; : : : ; Cn[T ]g is defined as: app(S[T ]) = fhd( ) j 9T 0 T such that 2 grtri [T 0] and S[T ] j= body( )g: By the definition of app( ), a (ground instance of) a bridge rule can be triggered at a time T 0, but can then become applicable at some later time T T 0. Thus, any bridge rule which has been triggered remains in predicate for applicability, which will occur whenever its body is entailed by some future data state. One alternative solution that may seem equivalent to the proposed one is that of adding a “guard” additional positive subgoal in a bridge-rule body, to be proved within the context itself. Such additional literal would have the role of enabling bridge-rule application. However, in our proposal a context is committed to actually apply bridge rules which have been triggered as soon as they will (possibly) be applicable while an additional subgoal should be re-tried at each stage and, if non-trivial reasoning is involved, this may be unnecessary costly.
The definition of timed equilibria remains unchanged, apart from the modified bridge-rule applicability. However, the added (practical) expressiveness is remarkable as a context in the new formulation is not just the passive recipient of new information, but it can reason about which bridge rules to potentially apply at each stage.
For practical applications, it may be useful to allow the grounding of literals in bridge-rule bodies to be computed at run-time, whenever a bridge rule is actually applied. Such a grounding, and thus the bridge-rule result, can be obtained, for example, by “executing” or “invoking” literals in the body (i.e., querying contexts) so as to obtain the grounding of positive literals first, to be extended to negative ones.
Each positive literal (cj : p) in the body of a bridge rule may fail (i.e., cj will return a negative answer), if none of the instances of p given the partial instantiation computed so far is entailed by cj ’s present data state. Otherwise, the literal succeeds and the other ones are (possibly) instantiated accordingly. Negative literals not (cj : p) make sense only if p is ground at the time of invocation, and succeed if p is not entailed by cj ’s present data state. In case either some literal fails or a non-ground negative literal is found, the overall bridge rule evaluation fails without returning results. Otherwise the evaluation succeeds, and the result can be elaborated by the management function of the “destination” context. For modeling such a run-time procedural behavior, we introduce potential applicability. Assuming that literals occurring in a bridge-rule body are ordered left to right as they appear in the rule definition we can talk about first, second, etc., positive/negative literal.
Definition 7. A ground bridge rule 2 grtri [T 0] for some T 0, of the form (1) is potentially applicable to grade k h at time T T 0 iff given a reduced version 0 of the rule, of the form s A1; : : : ; Ak we have S[T ] j= body( 0).
Hence, a triggered bridge rule is potentially applicable to grade k at time T if the timed belief state at time T entails its first k positive literals. Plainly, we have: Proposition 1. A ground bridge rule is potentially applicable to grade k at time Tk iff for every k0 such that 1 k0 k there exists Tk0 Tk such that is potentially applicable to grade k0 at time Tk0 .
Proposition 2. Let 2 grtri [T 0] be a ground bridge rule, for some T 0, of the form (1) which is potentially applicable to grade h (or simply “potentially applicable”) at time T ; then, hd( ) 2 app(S[T ]) iff for every negative literal not (ck:p) in the body, h + 1 k m, p 62 Sk[T ].
As the contexts composing an mMCS may be non-monotonic, a bridge rule can become potentially applicable at some time and remain so without being applicable, but can become applicable at a later time if the atoms occurring in negative literals are no longer entailed by the belief state at that state.
Notice that, in fact, in a practical distributed setting, literals in the body may succeed/fail at different times, depending on the various context update times, and upon network delay. Let us therefore assume that success of a positive literal A (resp. negative literal not A) is annotated with the time-stamp when such success occurs, of the form A[T ] (resp. of the form not A[T ]). So, for any bridge rule 2 grtri [T 0] like (1) which is triggered at some time and then executed later, by the expression s[Ts]
A1[T1]; : : : ; Ah[Th]; not Ah+1[Th+1]; : : : ; not Am[Tm] we mean that the rule has been executed left-to-right where each literal A[T ]=not A[T ] has succeeded at time T and the result has been processed (via the management function) by the destination context (i.e., the one where the bridge rule occurs) at time Ts. Clearly, we have T1 T2 ::: Tm Ts. The above expression is called the run-time version of rule . It is successful if all literals succeed; otherwise it is failed.
In many practical cases we are able to assume a certain degree of persistence in the system, i.e., that a literal which succeeds at a time Tr would then still succeed (if re-invoked) at every subsequent time Tq with Tr Tq Ts (“local persistence assumption” for rule ). This corresponds to assuming that, during the execution of a bridge-rule, no changes in the involved contexts occur that would invalidate the bridgerule result before actual completion; so, this would enforce what we call the “coherent” execution of a bridge rule. This assumption may sometimes be problematic in practice, but in a distributed system such as an mMCS we cannot realistically assume the execution to be instantaneous. The assumption of persistence can be considered as reasonable whenever the time amount required by the execution of a bridge rule is less than the average system change rate with respect to the involved belief elements. This is the usual condition for artificial intelligence systems to be adequate w.r.t. the environment where they are situated, rather that being “brittle”. There are possible ways of enforcing the assumption. For instance, the contexts involved in a bridge rule execution might commit to keep the involved belief elements untouched until the destination context sends an “ack” to signal the completion of rule execution. This or other strategies to ensure coherent execution are deferred to the implementation of mMCS. Under this assumption we have: Theorem 1. Given a successful run-time version of a ground bridge rule 2 grtri (T^), for some T^, of the form s[Ts] A1[T1]; : : : ; Ah[Th]; not Ah+1[Th+1]; : : : ; not Am[Tm]. Then, hd( ) 2 app(S[Ts]) and there exists T Tm such that hd( ) 2 app(S[T ]). Moreover, for each i j there exists Ti0 Ti and Ti 1 Ti0 if i > 1 such that is potentially applicable to grade i at time Ti0.
Proof. Thanks to the persistence of the system, fixing Ti0 = Ti, for each i j, suffices to prove the first property, and fixing T = Tm suffices for the second one. The third one follows in a straightforward way. tu
The relevance of the above theorem is because, in practice, the execution involves a non-ground rule r 2 grtri [T^] whose rule mentioned therein is a ground instance. Then, successful left-to-right execution of literals in the body of r will lead to dynamically generate at run-time a successful run-time version of . Specifically, the execution of each non-ground positive literal in the body of r will generate a partial instantiation which is propagated to the rest of the bridge-rule body. 3.3
We now generalize and formalize for mMCS the enhanced form of bridge rules
proposed in [
A bridge-rule pattern is an expression of the form:
s (C1:p1); : : : ; (Cj :pj ); not (Cj+1:pj+1); : : : ; not (Cm:pm) where each Cd can be either a constant or a context designator.
New bridge rules can thus be obtained and applied by replacing, in a bridge-rule pattern, context designators via actual contexts names. So, contexts will now evolve also in the sense that they may increase their set of bridge rules by exploiting bridgerule patterns: Definition 9. Given an mMCS, each of the timed composing contexts Ci, 1 i n, is defined, at time 0, as Ci[0] = hci; Li; kbi[0]; bri; brpi; OPi; mngi; act i; Uii, where brpi is a set of bridge-rule patterns, and all the other elements are as in Def. 1. Definition 10 (rule instance). An instance of the bridge-rule pattern 2 brpi, for 1 i n, occurring in an mMCS, is a bridge rule r obtained by substituting every context designator occurring in by a context name c 2 fc1; : : : ; cng. 8 Meaning that m and k belong to the signature of Li, but they do not occur in kbi or in bri.
The context names to replace a context designator must be established by suitable reasoning in context’s knowledge base.
Definition 11. Given an mMCS M , any composing context Ci, for 1 i n, and a timed data state S[T ] of M , a valid instance of a bridge-rule pattern 2 brpi is a bridge rule r^ obtained by substituting every context designator in with a context name c 2 fc1; : : : ; cng such that Si[T ] j= subsi (md(kd); c), where subsi is a distinguished predicate that we assume to occur in the signature of Li.
Let vinst (brpi)[T ] denote the set of valid instances of bridge rule patterns that can be obtained at time T (for Ci). The set of bridge rules associated with a context increases in time with the addition of new ones which are obtained as valid instances of bridge-rule patterns.
Definition 12. Given an mMCS, each of the timed composing contexts Ci, 1 i n, is defined, at time T +1, as:
Ci[T +1] = hci; Li; kbi[T +1]; bri[T +1]; brpi; OPi; mngi; act i; Uii with bri[T +1]=bri[T ][vinst (brpi)[T ], bri[0] = bri, and all the rest as in Def. 1.
All the other previously-introduced notions (equilibria, bridge-rule triggering and
applicability, etc.) remain unchanged. We do not need to modify bridge-rule
triggering, having already introduced the time parameter in the definition of the set Hi[T ]
of bridge-rule heads at time T for context Ci. Notice that instantiation of bridge-rule
patterns corresponds to specializing bridge rules with respect to the context which is
deemed more suitable for acquiring some specific information at a certain stage of a
context’s operation. This evaluation is performed via the predicate subsi (md(kd); c)
that can be defined so as to take several factors into account, among which, for
instance, trust and preferences. Also, this enhancement goes in the direction of dynamic
mMCS, where contexts can either join or leave the system during its operation. Such an
extension has been in fact advocated since [
Definition 13. We let a dynamic mMCS at time T be M [T ] = fC1[T ]; : : : ; CnT [T ]g, where a timed belief state at time T is (as before) a tuple S[T ] = (S1[T ]; : : : ; SnT [T ]).
The meaning is that the set of contexts which compose an mMCS may be different at different times. Here one can see the utility of having a constant acting as the context name; in fact, bridge-rule definition does not strictly depend upon the composition of M , as it would be by using integer numbers. Rather, applicability of a bridge rule depends on the presence in the system of contexts with the names indicated in the bridge-rule definition. Contexts can not only be added or removed, but also substituted by new “versions” with the same name. 3.4
For space reasons we just briefly discuss the complexity issues related to the proposed
approach. In general, the property that we may wish to check is whether a specific belief
of our interest will eventually occur at some stage in one (or all) timed equilibria of a
given mMCS. The formal definition is the following.
Definition 14. The problem Q9 (respectively Q8), consists in deciding whether, for a
given mMCS M under a sequence = [
We resort, like [
The problems Q9 and Q8 are undecidable for infinite update sequences, because contexts’ logics can in general simulate a Turing Machine and thus such problems reduce to the halting problem. Better complexity results can, however, be obtained under some restrictions. In particular, if we assume that all contexts Ci’s knowledge bases and belief states are finite at any stage, all update functions Ui, management functions mngi and triggering functions tri are computable in polynomial time, and that the set of bridge-rule patterns is empty and all bridge rules are ground, then we can proceed as follows: a projected belief state can be guessed for each stage T 2 N by a nondeterministic Turing machine; then, the inclusion of each such projected belief state S^ [T ] in some (all) timed equilibria S[T ] at that stage can be established by an oracle under the system’s context complexity and, if the answer is positive, it must be checked whether pi 2 S^i[T ]; if not, subsequent updates must be performed (in polynomial time) over S^ [T ], and the two checks must be repeated at each stage; this until either pi is found or time T is reached, thus obtaining either a positive or a negative answer to the Q9 problem. Therefore, for finite update sequences the context complexity determines the complexity of Q9 and, complementarily, the complexity of Q8.
Reconsidering bridge-rule patterns and non-ground bridge rules we observe that by assuming that subsi can be computed in polynomial time and produces a finite number of substitutions for each context designator, and given a set of bridge-rule patterns of a certain cardinality (size) c^, the size of the set of its valid instances is in general single exponential in c^. The same holds in principle for the grounding of bridge rules. However, in our setting we assume that bridge-rule are executed and grounded in a Prolog-like fashion: therefore, the computational burden for grounding is consequently smaller. 4
In this paper we have proposed extensions to MCSs, aimed at practical application of
such systems. The enhanced customizable bridge rules that we have formalized here
have been succesfully experimented (though in a preliminar embryonic version) in a
significant case-study, reported in [
In this Section we provide an example of use to illustrates the new features. We refer
to Example 2 in [
We generalize the rMCS to an F&K which is able to detect changes in Bob’s health
but also to notice anomalous behavior which might signify an impaired state. The input
can be provided by means of sensors, but also by recording and monitoring Bob’s
activities via suitable telemedicine appliances, via, e.g., videocameras or via a personalized
assistant/monitoring agent (PMA) which might be incarnated, in different use-cases, in
a chatterbot/avatar on tv or on the mobile phone, or even in a social robot; in our view,
the PMA should be able to “transmigrate” from one form to another one according to
the situation which a patient is experimenting at a certain stage of her/his activities.
The patient’s PMA (in this case Bob’s), is assumed below to be modeled as a
context included in an mMCS where such context is in particular an agent defined in any
agent-oriented logic language [
Bob’s PMA pmabob might for instance, in case of slight variations of, e.g., blood pressure or blood coagulation, re-adjust the quantity of medicament by consulting a treatment knowledge base. In case of more relevant symptoms, the agent might consult either Bob’s physician or a specialist, depending upon the relative importance of symptoms. In case of an emergency, for instance an hemorrhage, immediate help is asked for. Clearly, the example is over-simplified and we do not aim at medical accuracy.
Following [
The following bridge rule associated to each patient’s PMA, and thus also to pmabob, is maybe the most crucial as it is able to ask for immediate help. The last literal in the body concerns a context emergency center , which is supposed to be an interactive component for emergency management able to send, for instance, an ambulance or a helicopter for transportation to the hospital. The last literal in bridge-body will succeed whenever the emergency center context has received and processed the request, which is sent in case severe symptoms have been detected. Those symptoms, and the time when the request is issued, are communicated to the emergency center together with the patient’s data (here, for simplicity, just a patient’s identification code). The bridge rule head is processed by the management function so as to simply add to the PMA’s knowledge base the record of the fact that help has been required at time T for set of severe symptoms S. help asked (bob; S ; T ; T1 ; Th; H ) now (T ); detected symptoms (S ; T1 ); T 1 T; patientid (bob; Bid ); emergency center : urgent help(Bid ; S ; T ; Th; H ) The emergency center is provided with Bob’s patient’s id Bid and returns the time T h and mean H by which the emergency will be coped with (e.g., an ambulance by 15 minutes). In order to ensure application of the rule only in case of a real emergency, it will be triggered (by adding its head to trpmabob [T ]) only upon specific conditions, e.g., if symptoms have occurred that can be considered to be severe for Bob’s particular health conditions, and a physician is not already present or prompltly available. Upon bridge-rule application, the management function will record the (ground) request for help help asked (bob; S ; T ; T1 ; Th; H ) that has been issued; this allows for instance the PMA to check whether the promised assistance will actually arrive in time and possibly to minister palliative treatment in the meanwhile.
The following bridge rule, potentially crucial for cardiophatic patients, will be triggered by in case the blood coagulation value detected at time T is anomalous; this implies that the quantity of anti-coagulant which Bob takes to treat his heart disease must be rearranged accordingly. The correct quantity Q is obtained by the ATC (AntiCoagulant Center) knowledge base according to the last blood coagulation value V and its variation D from previous records. quantity (anticoagulant ; Q )
coagulation val (V ; D ); patientid (bob; Bid ); atc : quantity (Bid ; V ; D ; Q ) In case a patient’s health state is not really critical but is anyway altered, a physician must be consulted. However, in case, e.g., of a simple flu the family doctor suffices, while if there are symptoms that might be related to a more serious condition then a specialist (e.g., a cardiologist) should be consulted. Thus, there will be a bridge-rule pattern of the following form, where a physician can be consulted for condition C. Again, the management function will record the request having been sent; the last literal in the body will succeed, when the rule is dynamically executed, as soon as the doctor receives the request. call physician(bob; T ) now (T ); condition(bob; T ; C ); patientid (bob; Bid ); mydoctor (d ) : consultation needed (Bid ; C ; T ) The physician, represented by the context designator mydoctor (d ), should however be determined according to C. This can be done by suitably augmenting the definition of the distinguished predicate subspmi bob , for instance, as follows. The notation ’ ’ indicates a “don’t care” variable, as time is not taken into account here. subspmi bob (mydoctor (d ); F ) family doctor (F ); condition(bob; ; fever ) subspmi bob (mydoctor (d ); F ) family doctor (F ); condition(bob; ; headache) subspmi bob (mydoctor (d ); G ) my cardiologist (G ); condition(bob; ; chestpain)
Thus, a valid instance of the bridge-rule pattern will be generated according to the patient’s need, as evaluated by the patient’s PMI. The resulting bridge rule will then be immediately executed. So for instance, if Bob has chest pain and the cardiologist who has been following him is Dr. House, then the bridge rule below will be constructed and triggered: call physician(bob; T ) now (T ); condition(bob; T ; chest pain); patientid (bob; Bid ); drHouse : consultation needed (Bid ; chest pain; T )