1 Summary BIM is a new language for capturing business models containing information relevant for strategic analysis of business operations. It has been used in several large case studies and is being pursued in industry. The paper introduces the key notions of BIM, including goals, evidence, and in uence. It also outlines their translation into DL axioms, forming an upper-level ontology. Speci c BIM domain models then result from the addition of axioms to this. The result provides both a formal semantics of the BIM language, and all the familiar advantages of decidable DL reasoning, including consistency checking, de ned-concept classi cation, and, in our case \What if" scenario analysis. We focus on the parts of the translation which are most interesting, including: i) modeling \evidence and pursuit propagation" about goals, ii) dealing with \meta-properties", which were introduced as a result of an ontological analysis of previous BI languages, and iii) the repeated need for too many similar axioms. For the last two, we sketch how parametrized concepts, together with rules, would signi cantly help knowledge-base maintenance. This opens up a new research area in hybrid DL+rule KBs, involving rules that generate new axioms.
+ # Data processing
AND OR
+P
economic growth
competitive +
SubCsofcellreeipcttion cwaiatrhdgrocMetoehammekrpeecanrntesideist
revenue +
sales +
A portion of a realistic BIM schema for the credit card industry is shown in
in Fig. 1, using a (provisional) graphical notation based on the i* GM [
Generally, the model shows the decomposition of basic business services (e.g., o er cards, o er international banking) into operational tasks, their effects on strategic goals, an assessment of in uencing situations, and measurement through indicators. So BIM focuses on four types of things: Situations,
abbreviate this to Thing, using OWL:Thing, if we need, to talk about the top DL concept.) Situations are partial descriptions of world state, which may a ect business objectives, and in BIM are specialized into Goals, OperationalSituations, and DomainAssumptions.
Goals are situations that may be desired by the modeling organization, such as \Increase revenue". Goals may or may not be actively pursued at any time, and have an evidence value. As usual in GM, goals are re ned until one nds actions that help achieve them (Tasks), or domain assertions that are assumed to hold in the real world.
Additional concepts found in other BI languages can be obtained in BIM by providing values to meta-attributes (see Section 3.4). These provide an optional richer subclass structure for BIM without over-complicating the initial model design, and language learning.
BIM includes ve di erent types of relationships between things: in uences, evaluates, re nes , and measures, but their domains/ranges are restricted to various subclasses of Thing.
We are only going to touch on those aspects of BIM that raise interesting
issues for DL modeling. Unfortunately, this excludes one of the most interesting
features of BIM: the notion of indicators, which measure the performance of
some business activity. These use heavily numeric functions [
The Translation of BIM to DL
The DL axioms capturing the semantics4 of the subclass hierarchy under Thing are standard, as is the speci cation of disjointness between sibling classes.
BIM allows accumulation of evidence for or against every thing in BIM. The
question \Evidence for . . . ?" is answered depending on the speci c type of thing.
So BIM tracks evidence for the occurrence of situations, the satisfaction of goals
and domain assumptions, the performance of indicators, the execution of tasks,
and the existence of entities. In this way, we use BIM to monitor the state of
relevant business concepts. Following [
SFThing
Such repetitions of axioms are frequent and annoying for BIM so we introduce schemas for them, using the notation of programming language features such as C++ templates and Java generics:
Thingh?Vi Thing u (evidence : ?V) for ?V 2fSF,WF,WA,SFg Note that in C++ and Java, parameters may be restricted to be subtypes of other types; for example, a class SortedListh?Vi may require ?V to be a subtype of Comparable to guarantee a lessThan operation. We will present parameterized DL concepts using rules, whose body limits the parameter values using P-facts (think of these as \parameter facts"), about individuals or \punned" class identi ers. Thus after introducing P-predicate EvidV alues, with instances SF, WF, WA and SF, we can write: 4 We have intentionally not chosen a particularly restrictive DL at this point, since a lower bound on complexity of BIM reasoning can only be obtained directly. Since we want to have o -the shelf reasoners, we have limited ourselves to OWL2, though nominals, transitivity and even inverses are not strictly needed for reasoning.
For more complicated cases, and more uniform notation, we might prefer to
use rules extending the syntax of higher-order logics such as Hi(D) [
InstanceOfC (?V , EvidValues)
Returning to BIM, we need to also say that strong implies weak evidence, using axioms:
Information about the pursuit property can also come from multiple situations, so its value is a subset of fPur,NegPurg.
In uences. The in uences relationship is used to represent the (transmission of) (un)favorable e ects on situations. As natural, we represent BIM relationships by DL properties, so we have simply
in uences vr Situation Situation infBy r in uences
Borrowing from GM [
Re nes. The re nes relationship helps decompose concepts into other, often more detailed, concepts of that type. Re nes is also used to determine evidence for/against a thing, based on the evidence for/against its re nements. Unlike other relationships (or UML associations), re nes is limited to di erent pairs of sub-(domain,range) pairs. Thus a goal re nes other goals (not other kinds of situations), but goals can be re ned into goals, domain assumptions (DA) or tasks:
Every other subclass of Situation, except Task, only has axioms like
Re nements are by default interpreted disjunctively, but can also be marked as explicitly AND-ed: e.g., both \Facilitate card processing" and \Select type of card(s)" are required to satisfy \O er cards". Since on any particular node, we want all re nements to be AND-ed or OR-ed, we add a subclass AND Thing of Thing, and have axioms:
These concepts will be used below to de ne the propagation of evidence values for AND and OR re nements.
provide the precise rules for relating both evidence and pursuit values in the presence of re nes and in uences relationships between nodes.
For re nes, we use the rules for combining evidence on AND and OR nodes
inspired from [
For negative evidence, the converse holds:
Note that the presence of common DL concept constructors, such as quali ed number restrictions n R:C, immediately suggests extending BIM to support AND(n) nodes, which require the satisfaction of at least n re nements.
For in uences, ideally we would separate the evidence and pursuit aspects, but the desired semantics sometimes requires knowing both aspects at the same time. So we introduce a taxonomy of properties, starting with leafs like ++P InfBy. These are then grouped in various ways as subproperties of others like InfByP and infBy++; in turn, infBy++ and infBy+ are subproperties of infByPositively. This allows us to later state some axioms once, for a higher property, rather than repeat it for each subproperty.
The evidence values of the source are propagated to the target depending on
the strength of the source evidence and the in uence label. The 12 rules from
[
However, if we used parametrized classes and axioms, the following shows much more intuitively what happens in the 6 axioms involving positive in uence:
The meaning of negative in uences requires more complexity, because the \polarity" of the evidence value must be switched. Using P-facts complement(SF; W F ) and complement(SF; W F ), with symmetric complement, we encode the 6 other axioms with the rule
complement(?V,?W).
The propagation of pursuit along in uence links from goals to goals is similar to that of evidence with P ur; N otP ur; P; !P playing the role of ++; ; SF; SA respectively. Again, we can choose 4 ordinary axioms, or 2 parameterized ones.
attribute. This means complex special cases.
If the source does not have a pursuit attribute, e.g. a situation in uencing a goal, the satisfaction polarity of the source determines the pursuit of the target in P and !P in uence types. This is one of the 4 axioms for this:
If the source has a pursuit attribute but the destination does not, e.g. a goal in uencing a situation, then the in uence of the source evidence on the destination evidence only occurs when the goal is pursued, in case P is on the label, or not pursued, in the case of !P. For example, if the goal is satis ed and pursued, and the label is +P, the target situation partially occurs. If the goal is satis ed and not pursued, the situation has no incoming evidence from that goal. This requires replacing each of the original 12 axioms for propagating evidence by pairs such as
which check the appropriate combination of edge and node labels. Again, these could be stated much more succinctly by using parametric concepts and properties:
EvidV alue(?S),P ursuitV alue(?P). where we must now distinguish parameterizing concepts like Goal and Thing by evidence or by pursuit
Translating BIM Models to DL Given a speci c model, such as the one in Fig.1, we need to generate axioms that connect it to the generic terms of BIM axiomatized above. For this, we make every node a class, and add axioms describing its \BIM type". For example, node \O er International Banking", which is a goal, would generate:
We also add axioms declaring the disjointness of all nodes. Finally, every edge is translated into DL axioms in a manner that respects the following intuition of GM users: for every instance of a top-level goal, there is a separate set of instances connected to it, which result in an isomorphic copy of the (concept level) graph. This is assured by pairs of axioms, illustrated for the + in uences edge from StayCompetitive to IncreaseSales:
StayCompetitive v (= 1 + in uences . IncreaseSales) CWA axioms such as O erCards v (= 2 re nedBy . Thing) complete the encoding of the graph. \What if " Scenarios Frequently, business managers want to explore \What if?" scenarios, such as \How is the evidence for/against any particular model element a ected if our organization o ers cards but does not o er international banking?".
There are two approaches to such explorations. The rst, more comfortable for domain experts, who view element models as propositions, is carried out at the class level. Thus, we would add:
and then check whether BroadRangeOfServices is classi ed as a subclass of
tion of any other component, such as IncreaseRevenue, to see the e ect of these assumptions on it.
One might also want to answer a di erent question: \Is it possible to fully satisfy BroadRangeOfServices?" At its simplest, this is just adding the axiom
and wait for the reasoner to detect any inconsistent concepts. Using the ability of DLs to represent incomplete information, one could of course also explore less precise scenarios (e.g., \What if we o er cards or international banking").
A nal variant of exploration, supported for goals in [
The alternative approach to studying scenarios, more natural to those familiar with DL modeling, would be to create an A-Box with individuals describing the particular goals, etc. being considered. For example, it would contain A-Box assertions such as BroadRangeOf Services(brs1) , Of f erCards(oc1) and ref ines(oc1,brs1). One can the then provide evidence for a scenario, such as SF Goal(oc1) , and check for consequences on individuals.
The advantage of such an approach is that it does not require changing the schema (enabling better run-time monitoring), as well as allowing the coexistence of models for multiple businesses, with potentially overlapping individuals. The disadvantage is that for a single business, one essentially duplicates the concept level axioms in the A-Box.
Rather than simply make BIM the union of all sorts of unrelated concepts found in other business analysis languages (e.g., Vision, Mission, Strategy (BMM), Softgoal, Hardgoal (GM), Initiative (BSc)), an ontological analysis was performed on their underlying meaning. The result is a set of six meta-properties: duration (long-term/short-term), likelihood of ful llment (high/low), nature of de nition (formal/informal), scope (broad/narrow), number of instances (many/ few), and perspective ( nancial/ customer/ internal/ learning and growth).
New, more specialized, BIM subconcepts can now be obtained using values for these metaproperties. For example, the BMM concept of a Vision is a \goal with a long duration, broad scope, low chance of ful llment, informal de nition, and few instances". Examples of Visions from our credit card organization could include \Stay competitive" or \Have a worldwide presence".
Not all meta-properties must take on speci c values in order to express a more specialized BIM concept. Thus, Vision does not deal with perspectives. And, Softgoals/Hardgoals from GM can just be goals with an informal/formal de nition, leaving the values of other metaproperties open.
The values of metaproperties at the class level do not constrain class instances, but only say something about the nature of instances, that they are likely or generally conform to the expressed metaproperties.
The representation of metaproperties in DLs is known to be problematic, especially in our case, where we want the metaproperties to behave so that restricting their possible values results in subclasses. However, this is exactly the behavior one would get if the metaproperties were treated as ordinary (functional) properties. So we could just add property axioms like
number of instances vr Thing and then de ne classes f few, many g
DL reasoning would then automatically classify Vision as a subclass of SoftGoal. The main di culty with the above approach is that this conceptual model no longer makes sense intuitively, since it associates with individual goal g, belonging to Vision, (which I might be pursuing tomorrow), the property number of instances, with value few. It would be much more desirable to be able to have real meta-properties of classes, but then state that, for a group of such metaproperties, value restrictions result in subclasses at the class (rather than metaclass) level.
Ideally, one would be able to state rules dealing with meta-properties, like duration, such as the following (namedC=1 is a predicate that is true of atomic concept names used in DL axioms) : ?C v ?D :- namedC(?C); namedC(?D); not dif f duration(?C; ?D): dif f duration(?C; ?D) :- duration(?C; ?X); duration(?D; ?Y ); ?X 6=?Y . Since duration is functional, this says that C is a subclass of D as long as D has not been speci ed to have a di erent meta-property value than C (i.e., D's duration is unrestricted, or restricted to the same value as C's). The idea is that such rules are interpreted as in Logic Programming, with negation as failure. (The precise semantics of such rules is given in Section 4.1.)
Since we want to do this for an entire set of meta-properties, we could try
to use the idea of HiLog [
IntersectionOf(SomeValuesFrom(#hasLeftRightSelector #leftSelection) #Eye)) Declaration(Class(#RightEye)) EquivalentClasses(#RightEye
IntersectionOf(SomeValuesFrom(#hasLeftRightSelector #rightSelection) #Eye)) The following parametric declaration Declaration(Class(#Eye<?LR>), ?LR in {#leftSelection,#rightSelection} EquivalentClasses(#Eye<?LR>
IntersectionOf(SomeValuesFrom(#hasLeftRightSelector ?LR) #Eye)) is meant to capture the two axioms, using an enumeration of possible concept values for the variables. Instead of the name #LeftEye, we would then use #Eyeh#leftSelectioni, or more likely abbreviate the values, and say #Eyeh#lefti. Both #Eyeh#lefti and #Eyeh?Vi could then be used in axioms. If this was the only example, the gain would not be much. But there are far more complex de nitions involving #hasLeftRightSelector. And the above kind of repetition occurs for everything we have two in our body due to vertical symmetry. Also, there are other selectors, including #hasPositionalSelector, #hasMedialLateralSelector, #hasAnteriorPosteriorSelector, some with more than 2 values, while some concepts, such as #LeftInferiorPulmonaryVein, combine multiple selectors.
In fact a grep of the Galen OWL les revealed over 26,000 lines containing Selector (and naming in Galen is very systematic). So our approach would not only eliminate roughly half these axioms, but, more importantly would make maintenance of the ontology much easier and likely to be correct, by lessening the chance of errors when the de nitions are modi ed later, since it is highly likely that both de nitions need to be changed the same way.
Note also that in BIM, the set of qualitative values such as StrongEvidenceFor (SF), etc. might be extended to include more alternatives, such as VeryStrongEvidenceFor (VSF). For our above axiomatization of evidence propagation, this could be handled by adding only three more P-assertions: EvidV alues(VSF), EvidV alues(VSA), and complement(VSF,VSA) { clearly showing that we had captured signi cant patterns in our rules.
The following is a sketch of the simplest formalization of the hybrid DL+rule language we used to give the semantics of BIM. The set of primitive identi ers is split into atomic ones and parametric ones. Then axioms are formed as usual, except that parametric identi ers require atomic primitive constants or variables as arguments, and variables may occur alone as identi ers in axioms. However, any non-ground DL axiom must appear as the head of a rule, whose body binds positively all the variables in the axiom. Rules have the form (X) :
r1(Y1); :::; rk(Yk); not s1(Z1); :::; not sm(Zm) where ri and sj are P-predicates (i.e., not in the signature of the DL), and all variables in X and Zj appear among the variables in Yi for some i. The Patoms in the body are constructed using variables or constants, some of which are atomic identi ers from the DL. is either another P-atom, or a DL axiom with free parameters X. When k = m = 0, if is a P-atom then we have a P-assertion, such as EvidV alues(SF ); otherwise, it is an ordinary (ground) DL-axiom.
The semantics of the resulting hybrid system obeys the desirable property of
\modularity of reasoning" [
In our case the rules are restricted to be non-recursive, so there are no problems with in nite Herbrand universes, decidability and complexity in part (i): one can use bottom-up evaluation as for strati ed Datalog:; so the complexity will likely reduce to that of part (ii), since we are using a fairly expressive DL. (The precise details of this formalization can be found at http://www.cs.rutgers.edu/ ~borgida/BIM/dl12.appendix.pdf.)
As usual, the semantics should not be taken as guide to preprocess the KB and eliminate rules. First, if the bene ts of parametric concepts for KB maintenance are to be realized, then the rule format should be maintained for editing, etc. Second, lightweight type-checking techniques used in Programming Languages can be used to detect certain errors in axioms without theorem proving. Third, even for absorption in tableau implementations one can perform uni cation to see if the parameterized axiom should be applied. Only experimental evaluation can tell whether this would result in speed-ups in an ontology like Galen, where thousands of axioms might be eliminated. 5
Summary The presentation of BIM semantics as translation into DL provided several potentially interesting observations for the DL community.
Foremost, it led us to consider parametric concepts, axioms and rules. We have only scratched the surface of this area, and there remain lots of formal questions on how far one can push this in terms generalizing the syntax, semantics, complexity, and implementations.
In addition, we provided a novel way to express so-called \goal reasoning"
using DL constructors. This translation makes possible the posting of goal
models on the Semantic Web, and made evident the possibility of a useful \at least k
subgoals need to be satis ed" variant of AND decomposition. However, in order
to compete with [
Acknowledgments We are very grateful to Daniel Amyot, Daniele Barone, Lei Jiang, and Eric Yu for co-developing and applying BIM.