SP4: Ontological Infrastructure

This Subproject comprises the development of an infrastructure for the definition, implementation, and application of ontologies in the area of both the automatic generation of semantic web pages and the analysis and handling of user requests. The most important topics concern questions of representation (knowledge representation language), of content ("top-level, domain, task/system"), of access (inferences, data bases, "mapping") and of maintenance ("integration, extension").

Motivation

Ontologies enable the formalization of concepts that are understood and accepted by a wide user basis. Thus, they lay the foundation for the dialogue with the user as well as for the flexible communication between applications from various, wide-ranging areas. From a practical point of view an ontology structure is essential. This layer offers many basic services such as structural queries to the ontology or interference functionality.

The above section shows clearly the added value achieved through the ontologies. The question thus arises which requirements result from the application of this paradigm.

Requirements

A. Defining ontology and rule language: Initially, it has to be clarified which languages are going to be used for the exchange of data and knowledge in the system. To this end, we will first have a look at the status of the efforts made by the World Wide Web Consortium (W3C) to standardize ontologies. The layered architecture of the Semantic Web presented in figure 4.1 envisions five central levels: Data, Ontologies, Logic, Proof, and Trust. With the Resource Description Framework (RDF) and the Ontology Web Language (OWL) the two lower levels have been chosen as the official W3C standards since February 10th 2004. To ensure the sustainability and reusability of SmartWeb, the project has to be built upon these two foundations. It is generally known that the expressiveness of OWL is limited. This is manifest through the obvious fact that the logic layer is situated above the ontology layer. Thus, it has to be examined how these two layers can interact neatly and what kind of rule language should be applied.

Figure 4.1: Layered Architecture of the Semantic Web
Figure 4.1: Layered Architecture of the Semantic Web


B. Developing & administrating rules and ontologies: Besides the definition of the languages that are to be used, it has to be clarified which methods shall be applied for the construction of ontologies and rule bases. The question hereby arises, how automatic and semi-automatic tools can interact with conventional editors. Finally, it has to be ensured that ontologies and rules bases are managed within the project to ensure access for all project partners.

C. Inferences to and enquiries of ontologies: The application of ontologies is central to this project as a lot of components of other Work Packages have to access the infrastructure. Two cases can be roughly distinguished. On the one hand, the structure of the ontology itself can be requested. This functionality takes a central role for example when it comes to speech processing. It also has to be taken into account that such structural questions require inference ability. The second case refers to facts that are stored in the knowledge base. Queries posed to the knowledge base trigger a series of logical chains that are defined both through the ontology and through the stored rule bases.

Figure 4.2: Architecture of the Work Package Ontological Infrastructure
Figure 4.2: Architecture of the Work Package "Ontological Infrastructure"


D. Integrating Ontologies: Furthermore, a possibility has to be acquired to allow for transformations between the generated ontologies and the already existing ones. This is essential to a heterogeneous scenario that is built of many different data and knowledge sources. A scenario where only one central ontology is used is not realistic in the exemplary context of the 2006 FIFA World Cup. There will be a large number of providers who will refer to different ontologies.

Architecture

Figure 4.2 gives an overview of the planned architecture of this Work Package "Ontology Infrastructure". In the following, we will explain the individual components and will thereby show how they comply with the requirements defined in the section above. The architecture divides into two main areas: "runtime" and "design". The right hand side provides the design of ontologies with editors, various ontology learning strategies and ontology administration. On the left hand side, the runtime aspects are shown through various inference machines and data bases. This division into two parts is also reflected in the above-mentioned divided interface to other components that mirror cases of application mentioned under point C.

OWL + Xtriple

The first challenge lies in the different application of the languages. The ontology language OWL clearly has its strengths in the area of modeling. That is why it appears on the right hand side. There are, however, hardly any systems that can compute efficiently with OWL-instances. The first task therefore has to be to unite ontology and rule language within the runtime environment. This is clarified through the translation component in the middle. The project partners have already done a lot of preparatory work concerning the rule language that will be used. Within the consortium the consensus is held that the F-logic-based language Triple will be used and extended accordingly.

Architecture for the Generation and Administration of Ontologies and Rule Bases

SmartWeb lays at its foundation a very heterogeneous scenario. Furthermore, the application of open, internet-based languages implies that a standardization of those tools that are to be applied is not very sensible. Instead, the interoperation ability is ensured through ontology and rule languages that are supported by different editors. Moreover, figure 4.2 shows that learning methods can automatically produce ontologies that can afterwards be manually refined with editors. The same holds for methods for the definition of mappings between ontologies.

Inference Architecture

As mentioned at the beginning, access to external components via API is imaginable in two different modes. These are on the one hand structural queries to the ontology and on the other hand inferences via the instances. Both methods of access have to be supported by the inference component. Regarding the access to instances, the following criteria have to be considered. Because of the wide-ranging scenario of the 2006 FIFA World Cup, it is mandatory that the infrastructure is extremely scalable. Furthermore, it has to be expected that a huge number of data and information will be available in relational databases. It is hereby also very well possible that parts of the computation will be processed directly within the database in order to be able to fall back on the optimization implemented there. A further important component is the ranking component. Its task is to sensibly assess the incoming query results that are generated with the help of background knowledge from queries demanded beforehand.

Architecture for the Integration of Ontologies

Requirement D is covered by components on the development (design) and runtime side. The ontology mappings created with the help of editors have to be carried out by an adequate runtime environment. Thereby, a representation via rules is imaginable in order to optimally link mappings to the machinery of ontology and rules.


© Webmaster
Last modified: Tue Mar 8 13:31:33 CET