Although several languages have been proposed for dealing with uncertainty in the Semantic Web (SW), almost no support has been given to ontological engineers on how to create such probabilistic ontologies (PO). This task of modeling POs has proven to be extremely di cult and hard to replicate. This paper presents the rst tool in the world to implement a process which guides users in modeling POs, the Uncertainty Modeling Process for Semantic Technologies (UMP-ST). The tool solves three main problems: the complexity in creating POs; the di culty in maintaining and evolving existing POs; and the lack of a centralized tool for documenting POs. Besides presenting the tool, which is implemented as a plug-in for UnBBayes, this papers also presents how the UMP-ST plug-in could have been used to build the Probabilistic Ontology for Procurement Fraud Detection and Prevention in Brazil, a proof-of-concept use case created as part of a research project at the Brazilian O ce of the General Comptroller (CGU).
However, the increase of expressive power these languages have provided did not come without its drawbacks. In order to express more, the user is also expected to deal with more complex representations. This increase in complexity has been a major obstacle to making these languages more popular and used more often in real world problems.
While there is a robust literature on ontology engineering [
To ll the gap, Carvalho [
Nevertheless, the UMP-ST is only a guideline for ontology designers. In this paper we present the UMP-ST plug-in for UnBBayes. This plug-in has the objective of overcoming three main problems:
This paper is organized as follows. Section 2 introduces the UMP-ST process and the Probabilistic Ontology Modeling Cycle (POMC). Section 3 presents UnBBayes and its plug-in framework. Then, Section 4 describes UMP-ST plugin, which is the main contribution of this paper. Section 5 illustrates how this tool could have been used to create a probabilistic ontology for procurement fraud detection and prevention. Finally, Section 6 presents some concluding remarks. 2
UMP-ST The Uncertainty Modeling Process for Semantic Technologies (UMP-ST) consists of four major disciplines: Requirements, Analysis & Design, Implementation, and Test.
Figure 1 depicts the intensity of each discipline during the UMP-ST is iterative and incremental. The basic idea behind iterative enhancement is to model the domain incrementally, allowing the modeler to take advantage of what is learned during earlier iterations of the model. Learning comes from discovering new rules, entities, and relations that were not obvious previously. Some times it is possible to test some of the rules de ned during the Analysis & Design stage even before having implemented the ontology. This is usually done by creating simple probabilistic models to evaluate whether the model will behave as expected before creating the more complex rst-order probabilistic models. That is why some testing occurs during the rst iteration (I1) of the Inception phase, prior to the start of the implementation phase.
Figure 2 presents the Probabilistic Ontology Modeling Cycle (POMC). This
cycle depicts the major outputs from each discipline and the natural order in
which the outputs are produced. Unlike the waterfall model [
In Figure 2 the Requirements discipline (blue circle) de nes the goals that should be achieved by reasoning with the semantics provided by our model. The Analysis & Design discipline describes classes of entities, their attributes, how they relate, and what rules apply to them in our domain (green circles). This de nition is independent of the language used to implement the model. The Implementation discipline maps our design to a speci c language that allows uncertainty in semantic technologies (ST). For our case study, the mapping is to PR-OWL (red circles). Finally, the Test discipline is responsible for evaluating whether the model developed during the Implementation discipline is behaving as expected from the rules de ned during Analysis & Design and whether they achieve the goals elicited during the Requirements discipline (purple circle). As noted previously, it is a good idea to test some rules and assumptions even before the implementation. This is a crucial step to mitigate risk by identifying problems before wasting time in developing an inappropriate complex model.
An important aspect of the UMP-ST process is de ning traceability of
requirements. Gotel and Finkelstein [
Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forward and backward directions.
To provide traceability, requirements should be arranged in a speci cation tree, so that each requirement is linked to its \parent" requirement. In our procurement model, each item of evidence is linked to a query it supports, which in turn is linked to its higher level goal. This linkage supports requirements traceability.
In addition to the hierarchical decomposition of the speci cation tree, requirements should also be linked to work products of other disciplines, such as the rules in the Analysis & Design discipline, probability distributions de ned in the Implementation discipline, and goals, queries, and evidence elicited in the Requirements discipline. These links provide traceability that is essential to validation and management of change.
This kind of link between work products of di erent disciplines is typically
done via a Requirements Traceability Matrix (RTM) [
UnBBayes is an open-source JavaTM application developed by the Arti cial
Intelligence Group from the Computer Science Department at the University of
Brasilia in Brazil that provides a framework for building probabilistic graphical
models and performing plausible reasoning. It features a graphical user interface
(GUI), an application programming interface (API), as well as plug-in support
for unforeseen extensions. It o ers a comprehensive programming model that
supports the exploitation of probabilistic reasoning and intrinsically provides a
high degree of scalability, thus presenting a means of developing AI systems on
the y [
Unlike APIs, plug-ins o er a means to run new code inside the UnBBayes' runtime environment. A plug-in is a program that interacts with a host application (a core) to provide a given function (usually very speci c) \on demand". The binding between a plug-in and a core application usually happens at loading time (when the application starts up) or at runtime.
In UnBBayes, a plug-in is implemented as a folder, a ZIP or a JAR le containing the following elements: (a) a plug-in descriptor le3 (a XML le containing meta-data about the plug-in itself), (b) classes (the Java program itself - it can be a set of \.class " les or a packaged JAR le), and (c) resources (e.g. images, icons, message les, mark-up text).
UnBBayes currently relies on Java plug-in Framework (JPF) version 1.5.1 to provide a exible plug-in environment. JPF is an open source plug-in infrastructure framework for building scalable Java projects, providing a runtime engine that can dynamically discover and load plug-ins on-the- y. The activation process (i.e. the class loading process) is done in a lazy manner, so plug-in classes are loaded into memory only when they are needed.
One speci c type of plug-in that can be added to UnBBayes is the module plug-in. Module plug-ins provide a means to create a relatively self-su cient feature in UnBBayes (e.g. new formalisms or completely new applications). In UnBBayes vocabulary, modules are basically new internal frames that are initialized when tool bars or menu buttons are activated. Those internal frames do not need to be always visible, so one can create modules that add new functionalities to the application without displaying any actual \internal" frame (wizards or pop-ups can be emulated this way). The UMP-ST tool presented in this paper is a completely new application, since it was implemented as a module plug-in.
Figure 3 illustrates the main classes of a module plug-in. UnBBayesModule
is the most important class of a module and it is an internal frame (thus,
it is a subclass of swing JInternalFrame). Classes implementing
IPersistenceAwareWindow are GUI classes containing a reference to an I/O class, and
because UnBBayesModule implements IPersistenceAwareWindow, a module should
be aware of what kind of les it can handle (so that UnBBayes can
consistently delegate I/O requests to the right modules). NewModuleplug-in and
NewModuleplug-inBuilder are just placeholders representing classes that should
be provided by plug-ins. The builder is necessary only if NewModuleplug-in does
not provide a default constructor with no parameters. For more information on
UnBBayes plug-in framework see [
As seen in Section 2, the UMP-ST process consists of four major disciplines: Requirements, Analysis & Design, Implementation, and Test. Nevertheless, the 3 A plug-in descriptor le is both the main and the minimal content of a UnBBayes plug-in, thus one can create a plug-in composed only by a sole descriptor le. UMP-ST plug-in focuses only on the Requirements and Analysis & Design disciplines, since they are the only language independent disciplines. Moreover, as explained in Section 1, the objective of the UMP-ST plug-in is overcoming three main problems:
The UMP-ST plug-in is a almost like a wizard tool that guides the user in each and every step of the Requirements and Analysis & Design disciplines. This involves the de nition of the goals that should be achieved by the probabilistic ontology (PO) as well as the queries that should be answered by the PO in order to achieve that goal and the evidence needed in order to answer these queries. Only then the user is allowed to move to the next phase of the process which is de ning the entities, then the rules, and nally the groups related to the de ned goals, queries, and evidence (see Figure 2).
Respecting this order of steps de ned in the process allows the tool to incorporate an important aspect which is traceability. In every step of the way, the user is required to associate which working product previously de ned requires the de nition of this new element. For instance, when de ning a new query, the user has to say which goal that query helps achieve. We call this feature backtracking. This feature allows, for instance, the user to identify which goals are being achieved by the implementation of a speci c group. This feature provides an easy and friendly way of maintaining the RTM matrix, de ned previously.
The step by step guidance provided by the tool allows the user to overcome the complexity in creating POs ( rst problem). Moreover, the plug-in also solves the third problem, since all the documentation related to the PO being designed is centralized in the tool and can be saved for future use.
Finally, the di culty in maintaining and evolving existing POs (second problem) is addressed mainly by the traceability feature. When editing any element (e.g., a goal, an entity, a rule, etc), two panels are always present. On the one hand, the back-tracking panel shows every element from previous steps of the process associated with the element being edited. On the other hand, the forward-tracking panel shows every element created in the following steps of the process associated with the element being edited. This provides a constant attention to where and what your changes might impact, which facilitates maintainability and evolution of existing POs.
Figure 4 presents the panel for editing entities with some of the main features of the UMP-ST plug-in.
The UMP-ST tool was implemented as a module plug-in in UnBBayes. The
UMP-ST plug-in is mostly structured in a Model-View-Controller (MVC4)
de4 A MVC design isolates logic and data from the user interface, by separating the
components into three independent categories: Model (data and operations), View
(user interface) and Controller (mostly, a mediator, scheduler, or moderator of other
classes) [
A major source of corruption is the procurement process. Although laws attempt to ensure a competitive and fair process, perpetrators nd ways to turn the process to their advantage while appearing to be legitimate. For this reason, a specialist has didactically structured di erent kinds of procurement frauds encountered by the Brazilian O ce of the Comptroller General (CGU) in past years.
This section presents how the UMP-ST plug-in could have been used to build
the Probabilistic Ontology for Procurement Fraud Detection and Prevention
in Brazil, an use case presented by Carvalho [
As explained in Section 2, the objective of the Requirements discipline is to de ne the objectives that should be achieved by representing and reasoning with a computable representation of domain semantics. For this discipline, it is important to de ne the questions that the model is expected to answer, i.e., the queries to be posed to the system being designed. For each question, a set of information items that might help answer the question (evidence) should be de ned.
One of the goals presented in [
ii. Evidence: Member and responsible person of an enterprise live at the same address.
Figure 5 presents how this goal and its corresponding queries and evidence would be displayed in the UMP-ST plug-in. Note that both query and evidence are considered hypothesis in our tool. The idea is to generalize, since an evidence for a query could be another query. Therefore, we decided to call them both hypothesis.
The next step in the POMC model is to de ne the entities, attributes, and relationships by looking on the set of goals/queries/evidence de ned in the previous step. For instance, from the evidence that says \responsible person of an enterprise" we need to de ne the entities Person (Pessoa) and Enterprise (Empresa). Figure 4 presets the entity Enterprise (Empresa) with its attributes, goals and hypothesis de ned as backtraking elements, as well as traceability panel with its forward-tracking elements (attributes, rules, relationships, groups, etc).
Once the entities, its attributes, and relationships are de ned, we are able to de ne the rules for our PO. The panel for editing rules are really similar to the panel for editing entities. The di erence is that we can de ne what type of rule it is (deterministic or stochastic). Moreover, the backtraking panel allows the user to add elements from the previous step in the POMC cycle, i.e., entities, attributes, and relationships, as well as elements in the current step, i.e., other rules. Thus, the forward-tracking panel only allows elements from the current and future steps in the process, i.e., other rules and groups.
Finally, once the rules are de ned, the user can go to the nal step of the Analysis & Design discipline, which is to de ne the groups, which will facilitate the implementation of the PO. The panel for creating groups is similar to the panel for editing rules. The di erence is that the forward-tracking panel allows only other groups.
Figure 6 presents a list of groups created. Note that there is pretty much
a one-to-one correspondence to the Multi-Entity Bayesian Networks Fragments
(MFrags) created in [
This one-to-one mapping and the traceability feature help users deal with change and evolution of the PO. The traceability panel present when editing a goal shows all elements associated with the realization of that goal. Therefore, if a user needs to change a speci c goal he/she knows where it is going to impact, all the way to the implementation. Without the UMP-ST plug-in this would be infeasible. 6
This paper presented the UMP-ST plug-in. A GUI tool for designing, maintaining, and evolving POs. To the best of our knowledge, this is not only the rst implementation in the world of the UMP-ST process, but also the rst tool to support the design of POs.
The UMP-ST plug-in provides a step by step guidance in designing POs, which allows the user to overcome the complexity in creating POs. Moreover, the plug-in also provides a centralized tool for documenting POs, whereas before the documentation was spread in di erent documents (word documents with requirements, UML diagrams with entities, attributes, and relations, etc).
Finally, the di culty in maintaining and evolving existing POs is addressed mainly by the traceability feature. The implementation of both forward-tracking and back-tracking provide a constant attention to where and what your changes might impact, which facilitates maintainability and evolution of existing POs. Although this traceability can be achieved by a simple implementation of RTM in tools like spreadsheets, as the PO becomes larger this manual traceability becomes infeasible and error prone.
The UMP-ST plug-in is still in beta phase. Some of the features that should be included in the future are: exporting all documentation to a single PDF of HTML le; and generating MFrags automatically based on the groups de ned in the last step of the Analysis & Design discipline, in order to facilitate the creation of a MEBN model (i.e., PR-OWL PO) during the Implementation discipline. Acknowledgments. The authors gratefully acknowledge full support from the Brazilian O ce of the Comptroller General (CGU) for the research reported in this paper.