# SEWASIE Prototype

This page describes briefly the prototype that has been developed in the SEWASIE project.

An online version of the query interface is available here. All end user interfaces of the system are shown in an interactive presentation of screen-captured videos.

## Introduction

Sewasie has implemented an advanced search engine that provides intelligent access to heterogeneous data sources on the internet through semantic enrichment to provide the basis for structured internet communication. The prototype provides users with a search client that has an easy-to-use query interface for defining semantic queries. The query is executed by a complex query engine that takes into account semantic comparisons between ontologies and data sources and extracts the necessary information from heterogeneous sources. In the end, the result is visualized in a convenient and user-friendly format that allows you to identify semantically related clusters in the found documents. From an architectural point of view, the prototype is based on agent technology, i.e. individual components of the system are implemented as agents that are distributed over the network and interact with each other using the standard agent protocol (FIPA).

Smart search requirements are imposed by small and medium-sized enterprises (SMEs), which are threatened by globalisation. One of the keys to sustainability and success is the ability to access information. This can be a cheaper supplier, an innovative method of work, a new market, potential customers, partners, sponsors and so on. Modern internet search tools are inadequate because not only are they difficult to use, but the search results are often of little use with their pages and page reviews.

Suppose an SME needs to find out about a topic -- a product, a supplier, a fashion trend, a standard, etc. For example, a search is made for fabric dyeing processes' for the purpose of finding out about the disposal of the dyeing waste material. A query to www.google.com for fabric dyeing' listed 44.600 hits at the time of writing, which related not only manufacturers of fabric dyeing equipment, but also the history of dyeing, the dyeing technology, and so on. Eventually, a useful contact may be found, and the search can continue for relevant laws and standards concerning waste disposal. But is it law or the interpretation of the law? What if the laws are of a different country where the practices and terminologies are different? Thus, intelligent tools to support the business of SMEs in the Internet age are necessary.

## SEWASIE Architecture

Figure 1 gives an overview of the architecture of the SEWASIE system. A user is able to access the system through a central user interface where (s)he is provided with tools for query composition, for visualizing and monitoring query results, and for communicating with other business partners in electronic negotiations. The tools are integrated with other web-based applications such as an OLAP tool. This enables the annotation of multidimensional OLAP reports with semantically related documents, which have been found by the search engine.

Figure 1: SEWASIE Architecture

SEWASIE Information Nodes (SINodes) are mediator-based systems, providing a virtual view of the information sources managed within a SINode. The system may contain multiple SINodes, each integrating several data sources of an organization. Within a SINode, wrappers are used to extract the data and metadata from the sources. The Ontology Builder is a semi- automatic tool to create an integrated ontology (the "Global Virtual View", GVV) from the source schemas. The GVV is exported as ontology to the other components of the SEWASIE architecture, and queries expressed in terms of the GVV can be processed by the query manager of the SINode.

Brokering Agents (BAs) integrate several GVVs from different SINodes into a Brokering Agent Ontology (BA Ontology). The BA ontology is of central importance to the SEWASIE system. On the one hand, the user formulates the queries using this ontology. On the other hand, it is used to guide the Query Agents to the SINodes providing data for a query. The SEWASIE network can have multiple BAs, each one representing a collection of SINodes for a specific domain. Mappings between different BAs may be established. Thus, the SEWASIE system realizes a super peer architecture in which the BAs act as super peers, and SINodes are peers providing the data.

A Query Agent receives the queries (expressed in terms of a specific BA ontology) from the user interface, rewrites the query in terms of the GVVs of the SINodes (in cooperation with the BA) and sends the queries to the SINodes.

Monitoring Agents can be used to store a query result in a permanent repository. The monitoring agent will then execute the query repeatedly, and compare the new results with previous results. The user will be notified if a document has changed that fits her monitoring profile. Furthermore, the monitoring agent can link multidimensional OLAP reports with ontology based information by maintaining a mapping between OLAP models and ontologies.

Finally, the Communication Tool provides the means for ontology based negotiations. It uses query results, the ontologies of the BAs, and specific negotiation ontologies as the basis for a negotiation about a business contract. In addition, it uses several agents to support the negotiators in their decision process (e.g. by filter and ranking offers of potential business partners).

## Demonstration Scenario

The demonstration is based on the scenario indicated in figure 2. In the following, we will describe the system using this scenario from different perspectives: the end-user perspective (what the user sees of the system), the operational perspective (how the system works), and the design perspective (what ontology designers and administrators have to do to make the system operational). Note that also other execution flows'' are possible as it is indicated by the arrows in figure 2.

Figure 2: Demonstration Scenario

## End-User Perspective

Suppose that a manager of a company starts her working day with the observation of business-critical information, such as trade press or news ticker articles (step 1). She switches to the OLAP tool to analyze the company's performance (step 2). The data of the OLAP tool represents only internal information of the company and therefore needs to be related to external information, e.g. number of sales is related to the market situation (step 3). This task is supported by the monitoring and visualization interface (figure 3), which provides an aggregated view of documents, which have been monitored or found by a query. The tool visualizes a list of documents (upper right corner) in a document map (upper left corner). Documents which are semantically close are shown in the same cluster of the map. Furthermore, the tool links the dimensions of the OLAP model (lower right corner) to the concepts of an ontology (lower left corner). Thereby, it enables direct semantic queries from the OLAP tool, i.e. find all documents related to an OLAP report (step 4).

Figure 3: Monitoring & Visualization Interface

In the scenario, the user might have noticed that the decreasing sales are caused by lower prices of the competitors. Therefore, the manager starts a search for new suppliers delivering products of a specific type (step 5). The screenshot in figure 4 shows the query interface with a query for suppliers delivering trousers with a price lower than 80 Euros. This query can be composed interactively by the user by browsing the ontology in a tree-like structure, and selecting relevant items for the query. The query interface is intelligent as it contains an online reasoning functionality, i.e. it allows only a combination of items which is consistent w.r.t. the ontology.

Figure 4: Query Interface

If the query returns a list of suppliers, the user can select a subset of them and start a negotiation (step 6). The negotiation is integrated into the system in several ways. Firstly, the information of the query (e.g. products and their constraints) are transferred to the negotiation tool and are integrated into the first version of the business contract. Secondly, the negotiation is structured and ontology based, i.e. the exchange of message follows a specific protocol and the contents of the messages is semantically enriched by relating it to concepts of an ontology (left part of figure 5). Finally, the content of contract is further formalized by adding rules to the contract. These rules represent contractual conditions which have to be applied if certain exceptions occur (e.g. reduced price in case of late delivery).

Figure 5: Ontology Based Negotiation

## Operational Perspective

The scenario uses the monitoring interface as entry point to the system. Monitoring is done either for a query that has been defined by the user, or it is based on the monitoring profile (i.e. concepts of interest) of the user. In the latter case, the monitoring agent generates queries which have to be answered by a query agent. The monitoring agent uses diff and patch algorithms to detect and highlight the differences in updated documents. The query frequency is automatically adjusted to the update frequency of the documents, i.e. queries are posed less often if documents are changed infrequently.

The query processing takes into account two different levels of mappings (figure 6): the first mapping is done within a SINode and maps the data sources to the GVV of the SINode. The second type of mapping is at the BA level and maps several GVVs of SINodes to one ontology of a BA. In general, the mapping from the data sources to the BA ontology is not simply the composition of the two mappings. We have shown that (in the case that the mappings are defined as global-as-view mappings) the mappings can be indeed composed, and the reformulation of a query to the BA ontology can be done in two steps (figure 6): first, the query is expanded and unfolded w.r.t. constraints and mappings of the BA ontology, and then a similar process is done within a SINode w.r.t. the SINode ontology. The Play Maker component of the BA is in charge of expanding and unfolding the user query w.r.t. the BA Ontology. The result of this process is an expanded query and a set of unfolded queries against the SINodes. Then the query agent is in charge of the execution of these unfolded queries and of the fusion of the answers to obtain the final result. This fusion is based on a full-disjunction operator.

Figure 6: Query Processing in SEWASIE

## Design Perspective

The various mappings between the data sources and ontologies have to be defined at design time by an administrator or ontology designer. The SEWASIE system provides several tools to support this task.

First, the data sources have to be mapped to the GVV of a SINode. This is done by using the Ontology Builder, built upon the MOMIS framework \cite{momis}, which supports the tasks of mapping and integrating data sources in a semi-automatic way. Similarities between the schemas of the sources are detected automatically. By using such similarities, the system generates global classes'' and relates these classes to local classes'' of the sources. We use the language ODLI3 (Object Definition Language with extensions for information integration) to formalize the GVV and the mappings to the data sources. The mapping which has been created by the system automatically can be fine tuned by an ontology designer using the graphical interface shown in figure \ref{fig:momis}.

Figure 7: Mapping Definition in MOMIS

A similar process is repeated at the BA level. A first version of the BA ontology is bootstrapped using the same techniques as within a SINode. However, the BA ontology needs much more careful design as it integrates several ontologies from different SINodes. Therefore, the SEWASIE system provides an ontology design tool (a successor of the i.com-tool, see figure 8). The tool provides the usual features of ontology editors (adding/removing of concepts and relationships). In addition, it is connected to a reasoner which enables consistency checks or the deduction of implicit relationships.

Figure 8: Ontology Design Tool