A GUI Tool for Plausible Reasoning in theSemantic Web using MEBN © Springer-Verlag by Rommel Carvalho

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN Rommel N. Carvalho1 , Marcelo Ladeira1 , Lacio L. Santos1 , Shou Matsumoto1 , and Paulo Cesar G. Costa2 1

Computer Science Department - University of Brasilia - Brasilia, DF - Brazil {rommel.carvalho, laecio, cardialfly}@gmail.com, mladeira@unb.br Center of Excellence in C4I - George Mason University - Fairfax, VA - USA pcosta@gmu.edu

As the work with semantics and services grows more ambitious in the Semantic Web community, there is an increasing appreciation on the need for principled approaches for representing and reasoning under uncertainty. Reacting to this trend, the World Wide Web Consortium (W3C) has recently created the Uncertainty Reasoning for the World Wide Web Incubator Group (URW3-XG) to better define the challenge of reasoning with and representing uncertain information available through the World Wide Web and related WWW technologies. In according to the URW3-XG effort this Chapter presents the implementation of a graphical user interface (GUI) for building probabilistic ontologies, an application programming interface (API) for saving and loading these ontologies and a grammar proposal to specify formulas for creating conditional probabilistic tables dynamically. The language used for building probabilistic ontologies is Probabilistic OWL (PR-OWL), an extension for OWL based on Multi-Entity Bayesian Network (MEBN). The GUI, API, and the compiler for the proposed grammar were implemented into UnBBayes-MEBN, an open source, Java-based application that provides an easy way for building probabilistic ontologies and reasoning based on the PR-OWL/MEBN framework.

1 Introduction Writing has been the dominant way of representing and communicating until the second half of the last century, when the digital computing became the main force of what Alvin Toffler [14] called the “Third Wave” (the first being the agricultural revolution and the second being the industrial revolution). In this Third Wave we can see the “information technology revolution”. However, this phase is coming to its end with the arrival of what we call “knowledge revolution” that emerges as a natural subsequent phase of the

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

Third Wave. The “knowledge revolution” will be seen, in the future, as the phase where the arduous and manual task of identifying, accessing and utilizing information was successfully assigned to computers, allowing human beings to change their focus from data driven to knowledge driven activities. Within this context, the Semantic Web (SW) emerges as a collaboration effort between the W3C, various researchers, and industrial partners aimed to both understand the current Web and to provide a common framework for allowing data sharing and reusing among applications, enterprises, and communities. The SW will achieve its full potential when it becomes a place where data can be shared and processed by automatic tools the same way it is currently done by human beings [2]. According to the W3C [5], ontologies are envisioned as the technology providing the cement for building the SW. Ontologies contain a common set of terms for describing and representing a domain in a way that allows automated tools to use stored data in a wiser, context-aware fashion, intelligent software agents to afford better knowledge management, and many other possibilities brought by a standardized, more intensive use of metadata. Unlike what happens in syntactic-only protocols, ontologies allow applications to infer the difference between the surname White and the color white. Yet, when comparing two ontologies containing the term “White”, current SW deterministic reasoning algorithms will either consider it to be a color or an undefined concept (which is not the same as a non-color), with no intermediate grading. This is acceptable when complete information is available, which is frequently the case under the closed world assumption but much less common in open world environments such as the Web, where available information can be partial (not complete) or approximate (not exact). Thus, it is necessary to have ways of dealing with uncertainty in the SW. In spite of that scenario, current development for SW applications (which includes automated reasoning in most of its activities) is based on classical logic. As an example, OWL, a W3C recommendation [5, 10], has no built-in support for probabilistic representation and reasoning. This is a major shortcoming for a technology that is expected to operate in a complex, uncertain open world environment. The W3C responded to this limitation with the recently created Uncertainty Reasoning for the World Wide Web Incubator group (URW3-XG) [8]. The group’s mission was to better define the challenge of representing and reasoning with uncertain information within the World Wide Web and its related technologies. The use of probabilistic reasoning enables information systems to derive benefit from uncertain, incomplete information, instead of being restricted to complete knowledge alone. This seems to be a promising prospect for the SW. One of the most promising approaches to deal with uncertainty in the SW is Bayesian networks (BN) [11], a graphical, flexible means of parsimoniously expressing joint probability distributions over many interrelated hypotheses. However, BNs have some limitations on representational power that restricts their use for the SW. Amongst these limitations are the fact that the number

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

of variables has to be known in advance and the technique’s lack of support for recursion. In order to address these shortcomings within the context of the SW, Costa [2] proposed a Bayesian framework to probabilistic ontologies that provides a basis for representation and reasoning under uncertainty with the expressiveness required by SW applications. This framework is based on the probabilistic ontology language PR-OWL [4, 3], which uses Multi-Entity Bayesian Networks (MEBN) [6, 7] as its underlying logic. MEBN is a formalism that brings together the expressiveness of First-Order Logic (FOL) with BN’s ability to perform plausible reasoning. This Chapter introduces an implementation of MEBN being currently developed at the University of Brasilia (UnB) with support from George Mason University’s C4I Center. Its current feature list includes a GUI for modeling probabilistic ontologies, the ability to save probabilistic ontologies in PROWL format, and a MEBN-based reasoning engine. This framework is being implemented as an extension of the UnBBayes, an open source software developed at UnB that is capable of modeling, making inferences and learning probabilistic networks. This Chapter is structured as follows. Section 2 introduces the basic concepts of the MEBN formalism. Section 3 presents the PR-OWL language. Section 4 is dedicated to describe some features of the UnBBayes-MEBN3 and to discuss implementation details, with a focus on creating, loading, and saving PR-OWL files as well as on logic formulas for representing MEBN conditional probabilistic tables (CPT). These formulas are used to dynamically create CPTs needed to perform probabilistic reasoning.

2 An overview of the MEBN MEBN is a first-order Bayesian logic that integrates classical first-order logic with probability theory. MEBN represents the world as comprised of entities that have attributes and are related to other entities. Knowledge about the attributes of entities and their relationships with each other is represented as a collection of MEBN fragments (MFrags) organized into MEBN Theories (MTheories). MFrag consists of both a set of CPTs and FOL logical con-straints that establish their validating conditions. The number of random variables (RV) is not fixed in a MEBN model. Instead, RVs are instantiated dynamically. An MTheory is a set of MFrags that satisfy certain FOL consistence conditions that guaranty the existence of a unique joint probabilistic distribution (JPD) under its RVs. When all RVs are instantiated, all consistence conditions are satisfied, and all CPTs are generated, the MEBN yields a Situation Specific Bayesian Network (SSBN). An SSBN is a normal BN. As a means to provide a smooth introduction to the fairly complex concepts of MEBN logic, we needed to explore a domain of knowledge that would 3

UnBBayes-MEBN is available at http://sourceforge.net/projects/unbbayes.

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

be easily understood, while still rich enough to include scenarios that would demand a highly expressive language. In order to provide a consistent scenario without the need of a comprehensive explanation of its domain, the examples in this Chapter follow the Starship MTheory used in [2], which was based on the Star Trek television series4 . The explanations and examples presented here assume no previous familiarity with the particulars of the Star Trek series. 2.1 MEBN fragments An MFrag represents a conditional probabilistic distribution of the resident RVs instances given the values of its parent instances in the graph. This distribution can only be applied if the domain context restrictions are satisfied. One of the advantages of using MEBN instead of BN is that the number of RV instances is not limited and does not need to be previously known. RVs are instantiated dynamically and represent domain entities. Directed arrows going from parent to child variables in the graph present relations between these entities. Thus, an MFrag represents the conditional probability distribution of its RV instances given the values of their parents, as long as the context nodes are satisfied. In the Star Trek series, the U.S.S. Enterprise starship is equipped with various sensors that provide information the Commander needs to keep it out of danger. The MFrag in Figure 1 represents the level of danger a given starship is exposed to.

Fig. 1. An example of a Starship MFrag

This MFrag has seven nodes: four context nodes, two input nodes and one resident node. The context nodes are Boolean variables that represent conditions that have to be satisfied so that the probabilistic distribution of the resident nodes applies. Their possible values are: True (the condition 4

Star Trek and related marks are registered trademarks of Paramount Pictures.

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

is satisfied), False (the condition is not satisfied), and Absurd (a condition expression does not make sense). For instance, if s in the node IsOwnStarship(s) is replaced by the Enterprise identifier, the context node value will be true. If it is replaced by any other starship identifier then the context node value will be false. If any other thing that is not a starship replaces the argument, the context node value will be Absurd. Input nodes are variables that influence the probabilistic distribution of its child resident nodes, but their distributions are defined within their own MFrags. In other words, in a complete MTheory, every input node must be a resident node in another MFrag, where its probabilistic distribution will be defined. Resident nodes have the local probabilistic distributions defined in that MFrag, including the probabilistic dependence on its parent values (that can be input or resident nodes). A node can have a list of arguments in parenthesis, which are replaced by unique identifiers of domain entities when the net is instantiated. By convention, these identifiers begin with an exclamation point and two distinct entities cannot have the same unique identifier. In Figure 1, node DangerToSelf(s,t) has two arguments: s and t. In this domain, s must be a starship and t a discrete point in time. The instance DangerToSelf(!Enterprise,!T0 ) evaluates the level of danger the Enterprise is exposed to during the time instance T0. Also, the values of nodes states are not shown in the MFrag graph. This is because an MFrag is just a template, in other words, it does not represent individuals RVs, but a class of RVs. The values of its states appear only when the MFrag is instantiated. For instance, to discover the probabilistic distribution of an instance of the variable DangerToSelf(s,t), it is first necessary to find all instances of HarmPotential(st,t) and OpSpec(st) for which the context nodes are satisfied. A pseudo code to produce the probabilistic distributions of the DangerToSelf(s,t) variable is showed in the Figure 2. This pseudo code gives rise to the local distribution for the danger to which a starship is submitted given all the starships that influence its level of danger. This distribution takes into consideration that the number of starships is not previously known. This situation cannot be represented using BNs. However, for greater flexibility, the specification of PR-OWL CPTs and formulas was not completely defined in [2]. Section 4 introduces the UnBBayes-MEBN approach to deal with this problem. 2.2 MEBN theories A MEBN theory, or MTheory for short, is a collection of MFrags that satisfies consistency constraints ensuring the existence of a unique joint probabilistic distribution (JPD) over the RVs mentioned in the theory. This JPD is specified by the local distribution and pattern of each MFrag, which collectively form a generative MTheory. This information can be modeled in a knowledge base using a combination of experts and Bayesian network learning. In a complete

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

Fig. 2. A code example to produce a CPT

MTheory, each RV has just one home MFrag where its local distribution is defined. See [6] for a more information on MTheories. An MTheory assigns probabilities to sets of worlds. This is done in a way that ensures that the set of worlds consistent with the logical content of the MTheory has probability 100%. Each random variable instance maps a possible world to the value of the random variable in that world. In statistics, random variables are defined as functions mapping a sample space to an outcome set. For MEBN random variable instances, the sample space is the set of possible worlds. For example, ZoneNature(!Z0 ) maps a possible world to the nature of the zone labeled !Z0 in that world. The probability that !Z0 is a deep space zone is the total probability of the set of possible worlds for which ZoneNature(!Z0 ) has value DeepSpace. In any given possible world, the generic class random variable ZoneNature(z ) maps its argument to the nature of the zone whose identifier was substituted for the argument z. Thus, the sample space for the class random variable ZoneNature(z ) is the set of unique identifiers that can be substituted for the argument z. Information about statistical regularities among zones is represented by the local distributions of the MFrags whose arguments are zones. As more information is obtained about which possible world might be the actual world, the probabilities of all related properties of the world must be adjusted in a logically coherent manner. This is accomplished by adding findings to an MTheory to represent the new information, and then using Bayesian conditioning to update the probability distribution represented by the revised MTheory. For example, suppose the system receives confirmed information that at least one enemy starship is navigating in !Z0. This information means that worlds in which ZoneEShips(!Z0 ) (which means the number of enemy starships in the given zone) has value Zero are no longer possible. In classical logic, this new information makes no difference to the inferences one can draw about ZoneNature(!Z0 ). All four values (One, Two, Three, and MoreThanThree star-

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

ships) were possible before that new information arrived (i.e. there’s at least one enemy starship in !Z0 for sure), and all four values remain possible. The situation is different in a probabilistic logic. To revise the current probabilities, it is necessary to first assign probability zero to the set of worlds in which !Z0 contains no enemy starships. Then, the probabilities of the remaining worlds should be divided by the prior probability that ZoneEShips(!Z0 ) had a value other than Zero. This ensures that the set of worlds consistent with the new knowledge has probability 100%. These operations can be accomplished in a computationally efficient manner using SSBN construction algorithm. Figure 3 depicts the Star Trek MTheory used by Costa [2]. In a simplified way, the main task of this MTheory is to model the problem of detecting Romulan starships (here considered as hostile by the United Federation of Planets) and assessing the level of danger they bring to the own starship, the Enterprise. All other starships are considered either friendly or neutral. Starship detection is performed by the Enterprise’s suite of sensors, which can correctly detect and discriminate starships with an accuracy of 95%. However, Romulan starships may be in “cloak mode”, which makes them invisible to the Enterprise’s sensors. Even for the most current sensor technology, the only hint of a nearby starship in cloak mode is a slight magnetic disturbance caused by the enormous amount of energy required for cloaking. The Enterprise has a magnetic disturbance sensor, but it is very hard to distinguish background magnetic disturbance from that generated by a nearby starship in cloak mode. There are four basic entities in this MTheory: Starship, Zone, TimeStep, and SensorReport. According to the Treknology Encyclopedia5 , Starship is the designation for a large type of space vessel with warp drive. A starship typically consists of more than one deck and has separate departments such as the bridge, engineering or sickbay. In this model, this word is used to designate any space vessel. A zone can be either a Deep Space, a Planetary System, or the Boundary of a Black Hole. It is assumed that a OwnStarship, when in operation, has 80% chance of being traveling in a Deep Space Zone, 15% in a Planetary System and 5% in the Boundary of a Black Hole. In this model, black hole boundaries are preferred places for ambushes from attacking starships with cloaking devices, since the high magnetic turbulance generated in those zones makes it very hard to even the most advanced sensors to distinguish it from the magnetic disturbance created by a cloaking device. TimeStep is a special class that is used to model dynamic nodes, and there are quite a few in this domain. Finally, starship detection is performed by the Enterprise’s suite of sensors, which can correctly detect and discriminate starships with an accuracy of 95%. The product of those sensors are individuals of the class SensorReport. 5

http://www.ex-astris-scientia.org/treknology1.htm

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

MEBN logic allows multiple, equivalent ways of portraying the same knowledge. Nevertheless, Costa [2] encourages the use of object oriented approach sought with the Star Trek MTheory, which used the concept of an entity cluster defined also in [2]. Definition 1. An entity cluster is a group of MFrags within a generative MTheory having the following characteristics: (a) in any MFrag contained in the entity cluster, there is an ordinary variable, called the subject argument of the MFrag, such that any nonconstant random variable in the MFrag has the subject argument as one of its arguments. (b) the context constraints of each MFrag in the entity cluster specify the type of the subject argument. This type is called the subject type of the MFrag. (c) the subject types of all MFrags in the entity cluster are the same. Having this in mind, it is possible to map this MTheory in four clusters. The TimeStep MFrag for the TimeStep cluster. The Zone MFrag for the Zone cluster. The Starship Existence, Starship Data, Starship, Danger To Others, and Danger To Self MFrags for the Starship cluster. Finally, the SR Data and Sensor Report MFrags for the SensorReport cluster. Using this modeling approach makes it easier to keep MEBN logic’s flexibility to display the same information in different MFrag configurations. The other MFrags, IsA and Entity Type, are used for defining type safety and it is better explained in [2]. The TimeStep cluster is used to make the use of recursion with this entity possible and it is explained in details also in [2]. In the Zone cluster there are the following resident nodes: ZoneNature(z ) has been explained above, when the type Zone was described. ZoneEShips(z ) establishes the relationship between a given zone and the likelihood of having enemy starships within OwnStarship’s sensor range. In other words, it is the probable number of enemy ships into sensor range assumed to find in a given zone. This means it is considered that exists a prior probability of finding an enemy starship given the nature of the zone in which OwnStarship is navigating through. In this model, the infinitely possible number of starships was restrained to only five states. That is, it is assumed that it is unlikely to find four or more hostile ships in that area, so most of the probability distribution mass for this node will be restricted to the states None, One, Two, and Three, while the remaining probability will be restricted to the aggregating state MoreThanThree. ZoneFShips(z ) establishes the relationship between a given zone and the likelihood of having friendly starships within OwnStarship’s sensor range. Following the very same rationale of node ZoneEShips(z ), it is assumed that there is a prior probability in the number of friendly or neutral starships to appear into OwnStarship’s sensor range given the nature of the zone it is navigating.

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

ZoneMD(z,t) assesses the value of the magnetic disturbance in Zone z at the current TimeStep t. This value is influenced by the MD in the previous TimeStep (tprev ), the fact of whether there is or there is not a starship in cloak mode nearby, and the nature of the space zone in which the starship is located. The input node t=!T0 is used to “anchor” the time recursion. In the Starship cluster there are the following resident nodes: IsOwnStarship(st) identify if st is the OwnStarship, in this case the Enterprise. StarshipZone(st) identify the Zone the starship st is navigating into. Exists(st) is the probatility of existence for Starships. It is a useful way of conveying hypothetical instances of a Starship since there is a prior probability of finding enemy or friendly starships depending on where OwnStarship is navigating, these parameters will also influence the prior probability of existence. Thus ZoneEShips(z ) and ZoneFShips(z ), where Zone z is the same Zone the Starship st is at, are parents of Exists(st). OpSpec(st) conveys the information on what species is operating a given starship. Its distribution is derived from the number of Friendly and Enemy Starships in the vicinity. StarshipClass(st) assesses what is the class of the starship represented by st. It is influenced by the kind of species that is operating the starship and the very own existence of the starship itself (as defined in the context node Exists(st)). There is a vast literature of classes and subclasses of starships for each species (e.g. see http://techspecs.acalltoduty.com). However, for this simple model it is used a general taxonomy that aggregates the starships in five different classes (WarBird, Cruiser, Explorer, Frigate and Freighter ). CloakMode(st) is a boolean variable that defines whether the starship in question is in cloak mode. In this model, it is assumed that only Romulan and Klingon starships can be in cloak mode, since the Federation still does not have such technology. DistFromOwn(st,t) assesses the distance from a starship st to OwnStarship at TimeStep t. This distance is measured according to weapon’s ranges, since its main purpose is to assess the ability to any given starship to harm OwnStarship. HarmPotential(st,t) assesses the potential of starship st to harm OwnStarship at current TimeStep t. It is based on the starship weapons’ range (based on its class) and its distance from OwnStarship. It is important to note that here it is not being assessed the intention to harm, but only the ability to do so. Therefore, even friendly starships can have HarmPotential with value true (e.g. provide that they are within their respective weapons range). DangerToSelf(s,t) assesses the level of danger to which OwnStarship s is exposed at a given time t. Basically, this danger level will be a funcion of the ability of a starship st to harm OwnStarship and of the intention of

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

whoever is operating starship st to harm OwnStarship, the latter being implied from the knowledge of what species is operating starship st. DangerToOthers(s,t) conveys the ability of OwnStarship s to inflict danger to another starship st at TimeStep t. It is based on OwnStarship’s weapons (implicitly considered in the probability distribution) and its distance from starship st. In the SensorReport cluster there are the following resident nodes: Subject(sr ) has as its possible values all the unique identifiers of the entities that can be the subject of the sensor report being represented by the variable sr. In this model, sensor reports can refer to starships (real or hypothetical), in which case the node will assume the unique identier of that starship as its value, or it can refer to nothing (i.e. a spurious report), in which case it will assume the unique identifier of a spurious report as its value (e.g. OSpurious). SRClass(sr,t) conveys the result of a sensor report sr regarding to the class of a given starship at current TimeStep t. SRDistance(sr,t) conveys the result of a sensor report sr regarding to the distance of a given starship to OwnStarship at current TimeStep t. Each of these eleven MFrags represents the probability information about a group of their respective random variables. Collectively, the group implicitly expresses a JPD over truth-values of sets of FOL sentences. That is, probability distributions are specified locally over small groups of hypotheses and composed into globally consistent probability distributions over sets of hypotheses. MEBN theories extend ordinary Bayesian networks to provide an inner structure for random variables. Random variables in MEBN theories take arguments that refer to entities in the domain of application. As an example from the Sensor Report MFrag, the predicate StarshipClass(st) might represent the class of the starship designated by the variable st. To refer to the class of the starship instance labeled !Avenger, one would fill in a value for st to obtain an instance StarshipClass(!Avenger ) of the StarshipClass(st) random variable. Remind that, in MEBN syntax, an exclamation mark starts a string when it is used as an instance label. Captain Picard, the Commander of the Enterprise starship, has more than an academic interest in the danger from nearby starships. He must make decisions with life and death consequences. Multi-Entity Decision Graphs (MEDGs, or “medges”) extend MEBN logic to support decision making under uncertainty. MEDGs are related to MEBNs in the same way influence diagrams are related to Bayesian networks. A MEDG can be applied to any problem that involves optimal choice from a set of alternatives subject to given constraints. When a decision MFrag (i.e. one that has decision and utility nodes) is added to a generative MTheory such as the one portrayed in Figure 3, the result is a MEDG. As an example, Figure 4 depicts a decision MFrag representing Captain Picard’s choice of which defensive action to take. The decision

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

Fig. 3. The Starship MTheory

node DefenseAction(s) represents the set of defensive actions available to the Captain (in this case, to fire the starship’s weapons, to retreat, or to do nothing). The value nodes capture Picard’s objectives, which in this case are to protect the Enterprise while also avoiding harm to innocent people as a consequence of his defensive actions. Both objectives depend on Picard’s decision, while ProtectSelf(s) is influenced by the perceived danger to Enterprise and ProtectOthers(s) is depends on the level of danger to other starships in the vicinity.

Fig. 4. The Star Trek Decision MFrag

The model described here is clearly an oversimplification of any “real” scenario a Captain would face. Its purpose is to convey the core idea of extending MEBN logic to support decision-making. Indeed, a more common situation is to have multiple, mutually influencing, often conflicting factors that together form a very complex decision problem, and require trading off different attributes of value. For example, a decision to attack would mean that little power would be left for the defense shields; a retreat would require aborting a very important mission.

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

MEDGs provide the necessary foundation to address all the above issues. Readers familiar with influence diagrams will appreciate that the main concepts required for a first-order extension of decision theory are all present in Figure 4. In other words, MEDGs have the same core functionality and characteristics of common MFrags. Thus, the utility table in Survivability(s) refers to the entity whose unique identifier substitutes for the variable s, which according to the context nodes should be our own starship (Enterprise in this case). Likewise, the states of input node DangerToSelf(s,t) and the decision options listed in DefenseAction(s) should also refer to the same entity. Of course, this confers to MEDGs the expressive power of MEBN models, which includes the ability to use this same decision MFrag to model the decision process of the Captain of another starship. Notice that a MEDG Theory should also comply with the same consistency rules of standard MTheories, along with additional rules required for influence diagrams (e.g., value nodes are deterministic and must be leaf nodes or have only value nodes as children). 2.3 MEBN Inference Algorithm The MTheory depicted in Figure 3 is a generative MTheory, which provides prior knowledge that can be updated upon receipt of evidence represented as finding MFrags. We now describe the process used to obtain posterior knowledge from a generative MTheory and a set of findings. In a BN model, assessing the impact of new evidence involves conditioning on the values of evidence nodes and applying a belief propagation algorithm. When the algorithm finishes, beliefs of all nodes, including the node(s) of interest, reflect the impact of all evidence entered thus far. This process of entering evidence, updating beliefs, and inspecting the posterior beliefs of one or more nodes of interest is called belief propagation. Usually, the belief propagation process is carrying on answering probabilistic queries. MEBN inference works in a similar way (after all, MEBN is a Bayesian logic), but following a more complex yet more flexible process. Whereas BNs are static models that must be changed whenever the situation changes (e.g. number of starships, time recursion, etc.), an MTheory implicitly represents an infinity of possible scenarios. In other words, the MTheory represented in Figure 3 is a model that can be used for as many starships as wanted, and for as many time steps that are necessary to get the conclusions needed. That said, the obvious question is how to perform queries within such a model. In [6], Laskey proposed a SSBN construction algorithm that uses an initial generative MTheory, a finding set (which conveys particular information about the situation), and a target set (which indicates the nodes of interest to the query being made). UnBBayes-MEBN uses a variation of that algorithm, which is explained in Section 4.2. For comparison, let’s suppose there is a situation in which four starships are within the Enterprise’s range. In this particular case, a BN can be used

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

to represent the situation at hand, which means the model would be “hardwired” to a known number (four) of starships, and any other number would require a different model. A standard Bayesian inference algorithm applied to that model would involve entering the available information about these four starships (i.e., the four sensor reports), propagating the beliefs, and obtaining posterior probabilities for the hypotheses of interest (e.g., the four Starship Type nodes). Similarly, MEBN inference begins when a query is posed to assess the degree of belief in a target random variable given a set of evidence random variables. It is started with a generative MTheory, add a set of finding MFrags representing problem-specific information, and specify the target nodes for the query. The first step in MEBN inference is to construct the SSBN, which can be seen as an ordinary Bayesian network constructed by creating and combining instances of the MFrags in the generative MTheory. Next, a standard Bayesian network inference algorithm is applied. Finally, the answer to the query is obtained by inspecting the posterior probabilities of the target nodes. The UnBBayes-MEBN algorithm does not handle decision graphs at this stage of development. Thus, the illustration presented in the following lines extends the algorithm for purposes of demonstrating how the MEDG Theory formed by adding the MFrag in Figure 4 to the MTheory in Figure 3 can be used to support the Captain’s decision. In this example, the finding MFrags convey information that there are five starships (!ST0 through !ST4 ) and that the first is Enterprise itself. For the sake of illustration, let’s assume that the finding set also includes data regarding the nature of the space zone Enterprise is currently located (!Z0 ), its magnetic disturbance for the first time step (!T0 ), and sensor reports (!SR1 to !SR4 ) for starships for the first two time steps. Figure 5 shows the situation-specific Bayesian network for such query. To construct that SSBN, the initial step is to create instances of the random variables in the MTheory and the random variables for which there are findings. The random variables of interest are DangerLevel(!ST0 ) and DefenseAction(!ST0 ). The finding random variables are the eight SRDistance nodes (2 time steps for each of four starships) and the two ZoneMD reports (one for each time step). Although each finding MFrag contains two nodes, the random variable on which there is a finding and a node indicating the value to which it is set, only the first of these is included in the situation-specific Bayesian network, and declared as evidence that its value is equal to the observed value indicated in the finding MFrag. Evidence nodes are shown with bold borders. UnBBayes-MEBN algorithm starts retrieving and instantiating random variables of the MTheory and its findings database. That way, when random variables are created, they represent known background information, observed evidence, and queries of interest to the decision maker. If there are any random variables with undefined distributions, then the algorithm proceeds by using its respective default distribution. The process continues until there are no remaining random variables having either undefined distributions or unknown

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

Fig. 5. SSBN for the Star Trek MTheory with Four Starships within Range

values. The result, if this process terminates, is the SSBN or, in this example, a situation-specific decision graph (SSDG). Mahoney and Laskey [9] define a SSBN as a minimal Bayesian network sufficient to compute the response to a query. A SSBN may contain any number of instances of each random variable, depending on the number of entities and their interrelationships. The SSDG in Figure 5 is the result of applying this process to the MEDG Theory obtained with the aggregation of Figure 3 and Figure 4 with the finding and target set defined above.

3 An overview of the PR-OWL Language The usual workaround for representing probabilities in deterministic languages like OWL is to show probability information as annotations. This means that numerical information is stored as text strings. Because this solution does not convey the structural features of a probabilistic domain theory, it is no more than a palliative. This is no a minor shortcoming. Researchers have stressed the importance of structural information in probabilistic models (see [12]). For instance, Shafer ([13], pages 5-9) stated that probability is more about structure than it is about numbers. A major concept behind PR-OWL is that of probabilistic ontologies, which goes beyond simply annotating ontologies with probabilities to provide a means of expressing all relevant uncertainties about the entities and relationships that exist in a domain in a logically coherent manner. This not only provides a consistent representation of uncertain knowledge that can be reused by different probabilistic systems, but also allows applications to perform plausible reasoning with that knowledge, in an efficient way. PR-OWL uses the following definition of a probabilistic ontology [2]:

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

Definition 2. A probabilistic ontology is an explicit, formal knowledge representation that expresses knowledge about a domain of application. This includes: (a) types of entities existing in the domain; (b) properties of those entities; (c) relationships among entities; (d) processes and events that happen with those entities; (e) statistical regularities that characterize the domain; (f ) inconclusive, ambiguous, incomplete, unreliable, and dissonant knowledge; (g) uncertainty about all the above forms of knowledge; where the term entity refers to any concept (real or fictitious, concrete or abstract) that can be described and reasoned about within the domain of application. Probabilistic ontologies are used for the purpose of comprehensively describing knowledge about a domain and the uncertainty associated with that knowledge in a principled, structured, and sharable way. PR-OWL was developed as an extension enabling OWL ontologies to represent complex Bayesian probabilistic models in a way that is flexible enough to be used by diverse Bayesian probabilistic tools based on different probabilistic technologies (e.g. PRMs, BNs, etc.). More specifically, PR-OWL is an upper ontology (i.e. an ontology that represents fundamental concepts that cross disciplines and applications) for probabilistic systems. PR-OWL is expressive enough to represent even the most complex probabilistic models. It consists of a set of classes, subclasses and properties that collectively form a framework for building probabilistic ontologies. Currently, the first step toward building a probabilistic ontology as defined above is to import the PR-OWL ontology into an ontology editor (e.g. OntoEdit, Protege, Swoop, etc.) and start constructing the domain-specific concepts, using the PR-OWL definitions to represent uncertainty about their attributes and relationships. Using this procedure, a knowledge engineer is not only able to build a coherent generative MTheory and other probabilistic ontology elements, but also make it compatible with other ontologies that use PR-OWL concepts. However, building MFrags this way is a manual, error prone, and tedious process that requires deep knowledge of the logic and of the data structures of PR-OWL in order to avoid errors or inconsistencies. UnBBayes-MEBN changes all that by providing a GUI-based editing process for building probabilistic ontologies based on the PR-OWL upper ontology on probabilistic models [1]. The major advantages of using PR-OWL are its flexibility and representational power, both inherited from the fact that the language is based on MEBN, a full integration of First-Order Logic and probability that merges the expressiveness of the former with the inferential power of the latter. UnBBayes-MEBN leverages that power with a built-in MEBN reasoner that

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

implements both the SSBN creation process and its respective evaluation. The next section provides an overall view of the current state of that tool. The prospective reader can find additional details on PR-OWL at http://www.prowl.org. PR-OWL was proposed as an extension to the OWL language based on MEBN, which can express a probabilistic distribution under any axiomatic FOL theory model. As a consequence, there are no guaranties that the reasoning with PR-OWL ontology will be efficient or even decidable [2]. PR-OWL was built to be interoperable with non-probabilistic ontologies. Since PR-OWL adds new definitions to current OWL while retaining backward compatibility with its base language, OWL-built legacy ontologies will be able to interoperate with newly developed probabilistic ontologies. However, the ontologyâ&#x20AC;&#x2122;s probabilistic definitions have to form a valid MTheory. OWL has three different versions with increasing expressive power designed for specific communities of developers and users. The less expressive is OWL Lite, which has a limited set of simple restrictions. More expressiveness is found in OWL DL, which is based in Descriptive Logic and aims to maximize expressiveness while maintaining its completeness (all conclusions are computable) and decidability (all computations end in a finite time). It has all OWL constructions, but they have to be used under certain restrictions. The most powerful version, OWL Full, was built for users that want the most expressiveness possible. As a consequence, there are no guaranties of computability. Following the same reasoning, a PR-OWL Lite version could be created as suggested in [2] with some restrictions. Figure 6 shows the main concepts involved in defining an MTheory in PR-OWL.

Fig. 6. Concepts of the PR-OWL language

In the diagram, ellipses represent general classes while arrows represent the main relationships between these classes. A probabilistic ontology (PO) has to have at least one individual of class MTheory, which is basically a label linking a group of MFrags that collectively form a valid MTheory. In actual PR-OLW syntax, that link is expressed via the object property hasMFrag (which is the inverse of object property isMFragIn). Individuals of class MFrag are comprised of nodes, which can be resident, input, or context nodes (not shown in the picture). Each individual of class Node is a random vari-

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

able RV and thus has a mutually comprehensive, collectively exhaustive set of possible states. In PR-OWL, the object property hasPossibleValues links each node with its possible states, which are individuals of class Entity. Finally, random variables (represented by the class Nodes in PR-OWL) have unconditional or conditional probability distributions, which are represented by class ProbabilityDistribution and linked to its respective nodes via the object property hasProbDist. Figure 7 depicts the main elements of the PR-OWL language, its subclasses, and the secondary elements necessary for representing an MTheory. The relations necessary to express the complex structure of MEBN probabilistic models using the OWL syntax are also depicted.

Fig. 7. PR-OWL ontology elements

Building MFrags and all its elements into a PO is a hard, tiring and error prone process. It demands deep knowledge of PR-OWLâ&#x20AC;&#x2122;s syntax, semantics and data structure. UnBBayes-MEBN GUI was built to address this problem, providing a visual tool for building MEBN models. Section 4 shows the advantages of the GUI. Another important feature is the ability to save and open models created by the UnBBayes-MEBN GUI in PR-OWL format, with backwards compatibility to OWL through the use of the Protege API. Protege is an ontology editor and a flexible and configurable framework for building knowledge-base tools and applications that has been developed by the Stanford Medical Informatics.

4 UnBBayes-MEBN The current lack of a software tool makes the task of creating a PO using the PR-OWL language very difficult. Basically, the easiest way of building PR-

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

OWL ontologies is via a graphical ontology editor such as Protege. In this case, PR-OWL definitions have to be imported into Protege (from http://www.prowl.org/pr-owl.owl), making the task of building a PO a bit easier because it is not necessary to remember all information and OWL tags that should be filled. However, the input of information is not intuitive and the user has to know all technical terms as hasPossibleValues, isNodeFrom, hasParents, etc (Figure 8). Many of these terms could be omitted and filled automatic by a software application such as UnBBayes-MEBN, designed to enforce the consistency of a MEBN model. UnBBayes-MEBN was planned to allow building a PO in an intuitive way and not having to rely on a deep knowledge about the PR-OWL specification. In addition, a click in the “R” icon and another click anywhere in the edition panel will create a resident node. This is shown in Figure 9.

Fig. 8. Node specification with Protege

After that, clicking in the “+” button allows to fill a name and to add the states of the node. All the remaining tasks required by PR-OWL syntax (e.g. filling the terms as isResidentNodeIn, etc.) are automatically done. Figure 10 shows how UnBBayes allows a more adequate and better visualization of the MTheory and MFrags being created, as well as their nodes. In short, it is not difficult to perceive the advantages of building POs with the GUI implemented in UnBBayes-MEBN.

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

Fig. 9. Node specification with UnBBayes-MEBN

Implementing a complex logic such as MEBN while focusing on the usability requirements of an (probabilistic) ontology editor requires making tradeoffs between performance, decidability, expressivity, and ease of use. In other words, the complexity of the logic and the fact that it is still in development imply that any implementation has to include alternative algorithms and optimizations to make a working, feasible tool. UnBBayes-MEBN is no exception to this rule, and many of the design decisions were based on the above-cited constraints. 4.1 The API and Data Structure Probabilistic ontologies in UnBBayes-MEBN, or UnBBayes for short, are saved with the PR-OWL format, which is an extension of OWL format. UnBBayes uses the Java open source Protege application programming interface (API) for dwelling with OWL files. Protege allows for the edition of ontologies in two ways: using Protege-Frames editor and using Protege-OWL editor. The ontologies can be saved in various formats, including RDF, OWL, and XML Schema. UnBBayes provides support for MEBN input/output operations using the Protege-OWL API, which is based on the class JenaOWLModel. Protege uses the Jena API for various tasks, in particular for parsing OWL/RDF files. We will now describe the implementation components used for saving and opening MTheories.

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

Fig. 10. General view of the MTheory and MFrag in UnBBayes

Package unbbayes.io.mebn has the classes that are needed for saving and opening MEBN models in the supported format. Interface MebnIO is the interface that the classes implementing input/output features for a given format must provide. These classes are LoadMebn (loads a MEBN from a valid file) and SaveMebn (saves a MEBN in a valid file). Class PrOwlIO implements the MebnIO interface to save and load files in the PR-OWL format. It uses the Protege-OWL API to achieve this. This API allows an MTheory created using the UnBBayes GUI to be saved, while also keeping compatibility with any editions made in Protege. An MTheory saved in Protege can be opened in UnBBayes and vice-versa. This compatibility is important because it ensures that files created in UnBBayes can be opened and edited in any OWL-compliant application such as Protege (although these applications will not be able to understand the ontologyâ&#x20AC;&#x2122;s probabilistic characteristics). In addition, ontologies that have already been defined using Protege can be extended to the PR-OWL format in a quick and direct way. All that is needed is to open the OWL file in UnBBayes and create a MTheory for this ontology and save the result. In order to account for the complexity of PR-OWL/MEBN elements, an object-oriented (OO) MEBN data structure was designed. Some elements were not implemented as their use was either not relevant or outside the scope of this initial stage of the tool (such as the exemplar variables described in

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

[6]). Initially, extra elements were included into the design to account for the algorithmsâ&#x20AC;&#x2122; inner logical tasks such as the finding MFrag, finding nodes and others. However, design choices such as the use of PowerLoom rendered much of these extra elements unnecessary, facilitating the implementation. That was possible because PowerLoom was capable of handling all finding information, as it will be explained later on. The main MEBN elements, as implemented in the tool, can be seen in Figure 11.

Fig. 11. Main MEBN elements design

The MultiEntityBayesianNetwork (MEBN for short) depicted in the figure accounts for Network that can be edited in UnBBayes, and it is a collection of MFrag (when it is composed by the more general definition of resident and input nodes), or DomainMFrag (when it is composed by the more specific definition of resident and input nodes). There are three types of nodes defined: context, input, and resident. The input and resident nodes have more specific definitions: generative and domain respectively. The ResidentNode is the only one that has a table associated, through the interface ITabledVariable. Another useful information is that the InputNode is an input instance of a BuiltInRV or a ResidentNode. Also part of UnBBayes-MEBN design is the built-in implementation of type and ordered type for recursion. In Figure 12, every entity has a type and the implementation enforces a type-safe policy. As for recursion, the design solution involves the ObjectEntityInstanceOrdereable, also in Figure 12, which

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

ensures that a certain type, TimeStep for instance, has a total order for every instance created, enabling the assessment of the previous and next instances. Using this approach, implementing recursion was mostly reduced to allowing a node to be set as recursive and setting the stop condition by defining the last instance in the recursion for a given entity. This approach is currently being considered to be included as part of the PR-OWL specification.

Fig. 12. Main MEBN Entity and Type design

MEBN, as a first-order Bayesian logic, poses the implementation challenge of how to evaluate FOL sentences. A difficult task on its own, the design option involved searching for an open-source API to deal with it. The choice was PowerLoom , a Knowledge Representation and Reasoning (KR&R) tool that is a highly expressive, logic-based KR&R system with multiple built-in deductive reasoning capabilities including a query processor, a description classifier, and a context mechanism. It was developed at the University of Southern California as a successor to the successful Loom KR&R system, with Hans Chalupsy as the project leader. PowerLoom is now distributed in three options of open source licensing terms: GPL, LGPL, and Mozilla. Using PowerLoom in the UnBBayes-MEBN implementation forced the team to design the KnowledgeBase and PowerLoomKB to build, load, and save a knowledge base (KB) from a MTheory. It can load and save finding and generative information through its modules within the environment. Through the environment, the KBFacade and PowerLoomFacade make it easier within the MEBN implementation to verify whether an entity exists, to evaluate formulas, to search for findings, and to obtain other useful information about the KB. This design is shown in Figure 13.

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

Fig. 13. Knowledge Base and PowerLoom design

4.2 SSBN Construction Algorithm UnBBayes-MEBN also includes a knowledge base (KB) to store domain information. When a query is submitted, the KB is searched for information to answer the query. If the available information does not suffice, then the KB and the generative MTheory are used to construct a BN to answer the query. This process is called SSBN construction. In the current implementation, a query consists of a single random variable (RV) instance, which is not allowed to have any evidence below it. The following procedure takes a node name and a list of entity instances as arguments. It is called initially with the query node and its arguments. PROCEDURE SSBN-CNSTR(NODE, ENTITY-LIST): (i) For the RV instance NODE(ENTITY-LIST), search for evidence in the KB. If there is a finding for this given entry, finish. (ii) Search for the resident node that has the name NODE and get its MFrag. Once NODE(OV-LIST) is found, verify if the type of ENTITY-LIST is the same as OV-LIST (where OV-LIST is the list of ordinary variable arguments for NODE in its home MFrag). (iii) Verify in the KB which context nodes refer to the OVs in OV-LIST, replacing each OV by the appropriate instance in ENTITY-LIST. If any context variable is false, mark the MFrag to use the default distribution. (iv) If the truth-value of the context node in (iii) is not determined, make it a parent of NODE.

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

(v) For each parent of NODE, identify any instance of the parent that can be constructed by replacing the OVs by the known entities (contained in the query or KB), and has not yet been added to the SSBN. For each such parent instance, call procedure SSBN-CNSTR for the parent node and its arguments. (vi) Create the NODEâ&#x20AC;&#x2122;s CPT. (vii) Finish. This algorithm is easily enhanced to allow multiple query nodes and evidence below query nodes. These enhancements are currently under development. A few performance issues had to be considered in the implementation of UnBBayes-MEBN. Depending on the complexity of the domain, the algorithm may reach a context node that cannot be immediately evaluated. This happens when all ordinary variables in the parents set of a resident random variable term do not appear in the resident term itself. In this case, there may be an arbitrary, possibly infinite number of instances of a parent for any given instance of the child. For example, in the Starship MFrag depicted in Figures 1 and Figure 2, if the zone where a starship is located is uncertain, the number of enemies and friends (ZoneEStarships(z ) and ZoneFStarships(z )) in any zone it might be located is relevant to the distribution of the OpSpec(st) random variable. If time step t has previous time steps, then more than one distance (DistanceFromOwn(st,tprev )) must be evaluated, which makes the distance measured in all time steps relevant to the distribution of the DistFromOwn(st,tprev ) random variable in time t. Thus, any number of instances of the ZoneEShips(z ), ZoneFShips(z ), and DistFromOwn(st,tprev ) random variables might be relevant to the distributions of the OpSpec(st) and DistFromOwn(st,tprev ) random variables in time step t. In this case, the local distribution for a random variable must specify how to combine influences from all relevant instances of its parents. However, especially in complex formulas this may have a strong impact in the performance of the algorithm, so the designed solution involves asking the user for more information. In the current implementation, if one does not provide such information the algorithm will just halt. Another design option was to restrict memory usage in a way that a possible memory overload triggers a warning to the user and stops the algorithm. In step (iii), a design optimization over the general SSBN algorithm in [6], only the necessary context nodes for a given MFrag are evaluated, in contrast with the original solution of revising all the context nodes for that MFrag. Although the implementation addressed other optimization issues, for the sake of conciseness only the most relevant are listed here. To better understand the SSBN construction procedure shown above, an step by step example will be shown. Suppose the following query is entered in UnBBayes, after some entity instances and findings are defined: HarmPotential(!ST4,!T3 ). Once the procedure starts (see Figure 14), it will try to look for a finding for this query and it will not find. Therefore, it will search

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

for the MFrag with the given node finding the Starship MFrag. As the their types match, the procedure continues. It verifies wich context nodes to evaluate, which gives: IsA(Starship,st), IsA(TimeStep,t), Exists(st), and Ë&#x153;IsOwnStarship(st). They all return true, so the node HarmPotential(!ST4,!T3 ) is created. Now it is time to call the same procedure for its parents. It first finds the DistFromOwn(st,t) node, for the entities !ST4 and !T3.

Fig. 14. SSBN construction for HarmPotential(!ST4,!T3 ) query - Step 1

It goes through the same steps, but with one difference (see Figure 15), when it is about to call the same procedure for its parent, it realizes that it is a recursive definition, as its parent has the same name and arguments type and it also has a orderable argument, TimeStep. Therefore, it will keep calling the procedure for its parent but with the previous TimeStep, !T2 in this case, until it reaches the last TimeStep or a finding.

Fig. 15. SSBN construction for HarmPotential(!ST4,!T3 ) query - Step 2

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

In Figure 16 it finally reaches a finding for the TimeStep !T0. As it has no more parents, the node DistFromOwn(!ST4,!T1 ) can generate its CPT.

Fig. 16. SSBN construction for HarmPotential(!ST4,!T3 ) query - Step 4

In Figure 17 it is possible to see the resulting CPT for DistFromOwn(!ST4,!T1 ) and this node is finally added as a parent of DistFromOwn(!ST4,!T2 ). As DistFromOwn(!ST4,!T2 ) has no more parents, it can also generate its CPT.

Fig. 17. SSBN construction for HarmPotential(!ST4,!T3 ) query - Step 5

Some similar steps later (see Figure 18), it verifies that the next parent is defined in another MFrag, so it has to change its context for the new MFrag and call the procedure for ZoneFShips(!Z2 ), as this Zone was the one that made the context node z =StarshipZone(!ST4 ) return true. Once all nodes have generated their CPTs and the query node HarmPotential(!ST4,!T3 ) has no more parents to evaluate (see Figure 19), it is then ready to generate its CPT and finish the SSBN construction returning the

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

Fig. 18. SSBN construction for HarmPotential(!ST4,!T3 ) query - Step 9

generated BN, or the situation-specific Bayesian network, for a normal BN belief propagation (see Figure 20).

Fig. 19. SSBN construction for HarmPotential(!ST4,!T3 ) query - Step 18

4.3 Modifications to the Original PR-OWL PR-OWL was designed as a general formalism for building POs, without a focus on implementing an actual tool such as UnBBayes-MEBN. Thus, some contributions from this work were actually introduced into the revised PROWL specification. One example is the the possibility of defining the instances of a given entity as possible state values for a resident node. In the Starship Data MFrag, for instance, the node StarshipZone(st) has all instances of the Zone entity as its possible state values. This contribution was accepted and incorporated in PR-OWL version 1.03. As a consequence, it was necessary to

ÂŠ Springer-Verlag 2009

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

Fig. 20. SSBN generated for the HarmPotential(!ST4,!T3 ) query

define a standard for the CPT associated to this given resident node. As the number of instances for the entity is unknown and the pseudocode can not be used in this case, the adopted solution was to define its CPT as a uniform distribution. Another example is the grammar defined for writing formulas to dynamically build CPTs, which addresses a key aspect of reasoning process: the generation of the combined probability tables (CPT) for nodes with dynamically defined distributions. More specifically, when a query is posed to the system, it triggers the algorithm for building the Situation Specific Bayesian Network (SSBN) that will answer the query by instantiating all random variables that can add information towards its solution. In this process, some nodes may have an unknown number of parents, so instead of a static, previously defined CPT there will be a formula for dynamically generating the CPT given the number of parents in that specific situation. Although the original work on the PR-OWL language does not contain a rigid specification for representing formulas that perform the dynamic definition of probability distributions of an instantiated MFragâ&#x20AC;&#x2122;s nodes, it presents pseudo code ([2], page 64) that was used as a basis for specifying conditional probabilistic tables (CPT) in UnBBayes-MEBN. The implementation of this CPT generator is a key aspect for the SSBN construction, as many real world models include nodes with no previously defined number of parents. In UnBBayes-MEBN, a grammar and a complete new compiler, featuring a lexical, syntactic, and semantic analyzer were designed from the ground up. During the SSBN construction algorithm, they act by evaluating dynamic probability distribution formulas and then building the CPT for the respective node.

ÂŠ Springer-Verlag 2009

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

Figure 21 shows a sample of the grammar’s pseudo-code, which can be understood as a sequence of probability assignment blocks conditioned by if-else clauses. The clause else has a special purpose: it not only declares nonspecified probabilities, but also establishes the default distribution (i.e. the one used when a context node is not satisfied).

Fig. 21. Grammar used for dynamically generating a CPT

Evaluation of the pseudo-code is performed via syntactical analysis by a recursive descent parser, which is a top-down technique in which each production rule is implemented via a procedure. Commands and additional data structures were also added to the grammar as a means to allow for a semantic analysis of the code and for the generation of intermediate code. The latter is composed of specific blocks that are evaluated once all random variable conditioning cases are known, and is responsible for performing the final SSBN CPT generation. As an example of an element of the grammar, the production rule varsetname declares how the pseudo-code references a given set of parent nodes. Parent node instances can be divided into subsets that have similar predominant arguments. To better understand the concept, suppose that all parent nodes that have arguments st and z as their respective predominant arguments form a subset of parent nodes. Then, a hypothetical condition “if any st.z” would be applied only to members of that subset. Currently, nonpredominant arguments (weak arguments) are the recursive ordinary variables (e.g. ordinary variable t in DangerToSelf(s,t)).

R. N. Carvalho, M. Ladeira, L. L. Santos, S. Matsumoto, P. C. G. Costa

Another contribution to PR-OWL was the inclusion of information on global exclusivity, useful in situations when only one finding is allowed for a specific node in a given state. For instance, in Starship Data MFrag of Figure 1, the IsOwnStarship(st) has the state True as possible for just one starship st. That is, the state True has globally exclusive with respect to the RV IsOwnStarship(st). Global Exclusivity was accepted as a contribution by the PR-OWL team, and was inserted in PR-OWL version 1.05 (www.prowl.org).

5 Conclusions This Chapter presents a proposal for a GUI that facilitates the creation of probabilistic ontologies built on MFrags and MTheories. In addition, it also presents a MEBN CPT formula editor that can deal with previously unknown number of nodes. Besides that, it presents the algorithm implemented for the SSBN generation with an detailed step by step example. This work is currently being implemented in the UnBBayes software, which is alpha phase at the time of this writing and is able to create, load, and save MEBN models in the PR-OWL file format. This research represents a contribution to the SW community and, more specifically, to the current work of the URW3XG Incubator Group, created by the W3C to better define the challenge of reasoning with and representing uncertain information available through the World Wide Web and related technologies.

References 1. R.N. Carvalho, L.L. Santos, M. Ladeira, and P.C.G. Costa. A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN. In Proceedings of the Seventh International Conference on Intelligent Systems Design and Applications, pages 381–386, Rio de Janeiro, Brazil, October 2007. IEEE Press. 2. P.C.G. Costa. Bayesian Semantics for the Semantic Web. PhD thesis, Department of Systems Engineering and Operational Research, George Mason University, 2005. 3. P.C.G. Costa and K.B. Laskey. PR-OWL: A Framework for Probabilistic Ontologies. In Proceedings of the Fourth International Conference on Formal Ontology in Information Systems, Baltimore, USA, 2006. 4. P.C.G. Costa, K.B. Laskey, and K.J. Laskey. PR-OWL: A Bayesian Ontology Language for the Semantic Web. In Proceedings of the ISWC Workshop on Uncertainty Reasoning for the Semantic Web, Galway, Ireland, 2005. 5. J. Heflin. OWL Web Ontology Language - Use Cases and Requirements (W3C Recommendation). www.w3.org/TR/2004/REC-webont-req-20040210, 2004. 6. K.B. Laskey. MEBN: A Language for First-Order Bayesian Knowledge Bases. Artificial Intelligence, 172(2–3):172–225, 2007.

A GUI Tool for Plausible Reasoning in the Semantic Web using MEBN

7. K.B. Laskey and P.C.G. Costa. Of Klingons and Starships: Bayesian Logic for the 23rd Century. In Proceedings of the Twenty-first Conference Uncertainty in Artificial Intelligence (UAI-05), pages 346–353, Edinburgh, Scotland, 2005. 8. K.J. Laskey, K.B. Laskey, and P.C.G Costa. Uncertainty Reasoning for the World Wide Web Incubator Group Charter (W3C Incubator Activity). www.w3.org/2005/Incubator/urw3/charter, 2007. 9. S.M. Mahoney and K.B. Laskey. Constructing Situation Specific Networks. In Proceedings of the Fourteenth Conference on Uncertainty in Artificial Intelligence (UAI-98), pages 370–378, University of Wisconsin Business School, Madison, WI, USA, July 1998. 10. P.F. Patel-Schneider, P. Hayes, and I. Horrocks. OWL Web Ontology Language - Semantics and Abstract Syntax (W3C Recommendation). www.w3.org/TR/owl-semantics/, 2004. 11. J. Pearl. Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference. Morgan Kaufmann Publishers, San Mateo, CA, USA, 1988. 12. D.A. Schum. Evidential Foundations of Probabilistic Reasoning. WileyInterscience, 1994. 13. G. Shafer. The Construction of Probability Arguments. Boston University Law Review, 66(3–4):799–823, 1986. 14. A. Toffler. The Third Wave. Morrow, New York, NY, USA, 1980.