Integrating Web Services into Ontology-based ... - Semantic Scholar

Integrating Web Services into Ontology-based Web Portal Jian Zhou, Yong Yu, Lei Zhang, Chenxi Lin, and Yin Yang APEX Data and Knowledge Management Lab Department of Computer Science and Engineering Shanghai JiaoTong University, 200030, China {priest,yyu,zhanglei,linchenxi,yini}@apex.sjtu.edu.cn

Abstract. With the explosive emerged Web services, the Web becomes a world of information and applications. So portals whose goal is presenting a structured view onto the Web should provide users with a single point access to multiple types of not only information but also services. Recently, many systems have been developed using ontology-driven approaches to automatically generate and manage Web portals. However, all of them lack the integration of Web services. In this paper, we describe SPortS, an OWL-DL(Web Ontology Language-Description Logics) based portal generation system that integrates semantic Web services into generated portals at the presentation level, the data level and the function level. We present the portal generation process, the query decomposition and the service recommendation algorithms through which semantic Web services are integrated tightly into the generated portal.

1

Introduction

Currently Web portals which try to weave loosely pieces of Web into a structured view for a special interested group of people have received much attention. Leading industry companies like Microsoft1 and IBM2 have developed products for automatically generating and maintaining portals. They provide an extensible framework that lets information and services be easily plugged in and allows the end user personalize and organize their own view of the portal. However the lack of semantics makes the generated portals difficult to be processed by machines. In order to solve the problems mentioned above, a lot of research has gone into ontology-based Web portal generation and maintenance. SEAL[1] provides a general framework for developing semantic portals. Numerous tools such as KAON portal[2], ODESeW[3], OntoWeaver[4], and OntoWebber[5] have been developed to help design, generate and maintain ontology-based Web portals. However, these systems lack the integration of Web services which may provide more dynamic information and richer functionalities. In this paper, we propose a novel approach to combine semantics and services into a portal. A software framework called SPortS(Semantic + Portal + Service) 1 2

see http://www.microsoft.com/sharepoint/ see http://www-106.ibm.com/developerworks/Websphere/zones/portal/proddoc.html

has been designed and implemented to automatically generate service-integrated Web portals based on declarative specifications. The generated portals can provide users and computer agents with convenient access to everything they need to get their tasks done. The major features of the system are the following: – Based on the common OWL-DL[6] formalism, semantic Web services[7] and domain knowledge are processed and presented uniformly in our system. – By decomposing complex queries until they can be answered using available Web services and domain knowledge, we unified the two information sources. The result is that, besides domain knowledge, information providing services which serve as an important extension can also transparently feed information to the portal. – Through capturing recently visited concepts to form a semantic context, SPortS can dynamically recommend services that users may be interested in under the current context. In this way, not only the portal’s functionalities are greatly enriched by these services but also the portal’s contextual knowledge is exploited to help users act in the portal. – In order for other programs and agents on the Semantic Web to visit the portal, SPortS exposes itself as Web services. – SPortS uses OWL-DL as the underlying knowledge representation formalism. Compared with RDFS, OWL-DL is more expressive in describing the constraints on and relationships among ontologies. Meanwhile, unlike OWLFULL, OWL-DL is decidable and computationally complete with support from many existing DL(Description Logics) reasoners (e.g. FaCT[8] and Racer[9]). The rest of the paper is organized as follows. Firstly, we give an overview of the SPortS system in section 2. By explaining the Web portal generation and presentation process, section 3 shows how Web services are integrated in the presentation level. Then in section 4, we describe the query decomposition algorithm that integrates information from both Web services and domain knowledge. This explains how data level integration with Web services is achieved. Section 5 describes the dynamic context-sensitive recommendation of Web services in the generated portal. By recommending services to the user, the generated portal integrates the functions of the services. Finally, we discuss related work in section 6 and conclude the paper in section 7.

2

Overview of the SPortS System

In the design of the SPortS architecture(Fig.1), the main objective is to integrate Web services at the presentation level, the data level, and the function level. Among them, the data level plays a central role of driving the integration on the other two levels. In SPortS, data is stored in four knowledge bases which are all based on the OWL-DL formalism.

Fig. 1. SPortS architecture

Domain Knowledge Base stores the domain classes, properties, and individuals. It serves as the primary knowledge source for the portal. Service Knowledge Base stores OWL-S3 descriptions of all available semantic Web services. Through this knowledge base, SPortS can retrieve services’ specifications to render or invoke them. Site Knowledge Base contains the site ontology used to model the portal at a conceptual level and stores the declarative specification of the portal as the instance of the site ontology. Meta Knowledge Base is designed to enable us to directly manipulate classes and properties in other knowledge bases as individuals. This capability is necessary in a semantic portal system because of the need to show and process both classes and individuals at the same time. The four knowledge bases are grouped into a virtual knowledge base with a unified ontology. Queries issued to the virtual knowledge base can be expressed in the unified ontology without caring how knowledge from different knowledge bases and services are composed to answer them. This task is actually accomplished by the Query Decomposition Engine. In this way, information from different sources are integrated and can be accessed transparently. The major task of the portal creation process is to prepare the four knowledge bases. The domain knowledge engineer builds the domain knowledge base from which the default site knowledge base is automatically generated by the site ontology default generator. After that, the portal designer uses a WYSIWYG tool to design the content, layout and navigational structure of the portal by changing the site knowledge base. At the same time, the service engineer is responsible for populating the service knowledge base with available semantic Web services. Then there will be a running daemon called Output Generator which dynamically constructs a Web page for the user’s request according to the virtual 3

http://www.daml.org/services/owl-s/1.0/

knowledge base. The construction process will be described in Section 3. The Query Decomposition Engine which is utilized by Output Generator to provide all data in the Web page is discussed in Section 4. Decomposed queries that can be answered by a single knowledge bases are ultimately processed with the help of the inference engine. When a user browses Web pages in the portal, the Recommendation Service intelligently analyzes context knowledge and recommends services that the user may be interested in. The recommended service can be presented in the portal for invocation, which achieves function level integration. Section 3.2 and Section 5 will give more details about this process. Recall that all Web pages are created on the fly based on the virtual knowledge base. So the change to the virtual knowledge base will simultaneously be reflected in the generated Web pages. It means that the maintenance work will only consist of updating the virtual knowledge base. This can greatly reduce the resources (manpower, money) for maintaining and editing the portal.

3 3.1

Portal Generation and Service Presentation Site Ontology and Portal Generation

Fig. 2. Overview of the Site Ontology

The site ontology is designed to model Web portals at a conceptual level. As shown in Fig.2, the site ontology includes the following core classes: Web page, container, class binding and navigation rule. The class Web Page models the static view of the portal as a tree of containers. It has a property hasRootContainer which specifies the entry point of the recursive construction process. In this paper, we use our lab’s internal portal, Apex-Lab-Portal, as an example. Fig.3 shows a Web page of the portal and the tree structure of its containers. The class Container models the structure unit of Web pages. Container has two sub classes Atomic container and Composite container. – Atomic Container are mainly used to present the concrete information. It has a property hasParameter which specifies a query over the virtual

Fig. 3. A Web page of the Apex-Lab-Portal example

knowledge base. The answer to the query then compose the atomic container. Currently, queries can only be expressed in the form of OWL-DL class descriptions. Hence, the content of an atomic container is the set of all individuals of the query class. – Composite Container are mainly used to group and layout basic containers which will be described by the property hasSubContainer. The class Class Binding models what properties of and how the individuals are displayed. Every class binding is attached to some containers and has a bound class. When an individual i in an atomic container O is to be presented, i must use a class binding B whose bound class C satisfies i ∈ C and B must be attached to O or O’s ancestors. For example, in Fig.3, the class binding of the DetailContainer determines that the names, date, place, etc. of the conference are displayed. Class binding has another two properties hasLayout and hasPresentation which will be described as follows: – A presentation is actually a piece of program that completely handles the rendering of the individual. So the portal designer can customize the presentation for specific set of individuals. In this way, SPortS can present semantic Web services. We further discuss this issue in Section3.2. – Layout models the algorithms which arrange the properties of the displayed individual and the values of these properties are presented recursively until a presentation can fully handle them. The class NavigationRule models the navigational structure of the portal. Recall that a Web page is modelled as a tree of containers. Thus the navigation from one page to another is modelled as a tree transformation that replaces a subtree with another one. A rule will be triggered when an item satisfying specific conditions is clicked. 3.2

Presentation of Semantic Web Services

Based on the common OWL-DL formalism, semantic Web services and domain knowledge are processed and presented uniformly in our system. In this sub-

section, we show in detail how Web services are presented in exactly the same manner using the mechanism mentioned above. In Fig.3, there is a RecommendationContainer that lists dynamically recommended Web services. The OWL-DL class description of its content is RecommendedService, whose individuals are retrieved by the Query Decomposition Engine (ref. Section 4) via the Recommendation Service (ref. Section 5). When the ”Borrow proceedings from library” service link is clicked, a navigation rule which replaces the content of the DetailContainer with the clicked individual is activated. Fig.4 illustrates the result page.

Fig. 4. Detailed View of the Borrow-Proceeding Service

We developed two specific presentations, ServiceInputPresentation and ServiceResultPresentation, to act as the proxy between the user and the Web service provider. The ServiceInputPresentation will generate a specific form according to every service’s Input in service knowledge base. Then the user can input service parameters by filling the form. After the form is submitted, a navigation rule is activated to use the ServiceResultPresentation to capture the input, invoke the Web service and display the result in a uniform way. In the future, the integration of Web services at presentation level can be more fantastic. There are some attempts to develop a standard for Web Services for Remote Portlets (WSRP)[10]. Its aim is to enable reuse of services at the presentation layer. So when it is being widely used, every WSRP-compliant Web service can be fully integrated into our portal without loss of even presentation details.

4

Query Decomposition on Virtual Knowledge Base

The primary motivation for designing the Query Decomposition Engine is to provide SPortS with the ability to get data from the virtual knowledge base without knowing whether it comes from domain knowledge bases or Web services. Then the data level integration which is at the core of the SPortS system can be achieved.

4.1

Problem Definition

Until now, there is no standard for how to query DL knowledge bases. In [11], a DL query language is proposed. However, just as [11] has stated, how to efficiently retrieve answer sets for the proposed query language is still an open problem. Besides, [11] showed that by rolling up role terms, many queries can be transformed into the form of a DL class expression. Then in order to make our system work, we formalize queries as OWL-DL class expressions in the unified ontology of the virtual knowledge base. An information providing service’s query answering capability can be described as the combination of its input/output class descriptions. Each input of a service will have an input class description to constrain its type. We simplify the output as another class of individuals, which is described as an output class O. Moreover, we require that the output class be constructed by inputs and constants with OWL-DL constructors. The O is called output class description which records the functional relationship between the output and the inputs. By the formalization above, the problem then can be described as how to compose all services to retrieve all individuals of the query’s class expression. In this sense, it is actually a problem of semantic composition of information providing services as we described in [12]. But besides normal services, there are also other information sources in the SPortS. The domain knowledge base with the support of a DL reasoning engine can answer any complex queries about it alone. So its capabilities can’t be easily be described by OWL-DL class expressions. However, it can be dealt with separately in the query decomposition algorithm. Whenever a query (or part of a query) is going to be decomposed, it is first checked against domain knowledge base to see whether it can be answered entirely . It will be further decomposed if the domain knowledge base cannot handle it alone. In the following, we thus focus on how normal information providing services are described and composed. 4.2

Basic Ideas

In this subsection, we give a brief description of the query decomposition algorithm. A more complete and detailed description of the the algorithm and some discussion are available in [12]. Queries and capabilities of information providing services are expressed as OWL-DL class expressions. Therefore, in theory, the query decomposition algorithm needs to find a semantically-equivalent logic combination of several OWLDL class expressions for a given OWL-DL query class. It is tightly related to the problem of DL query rewriting on views[13][14] . Currently in SPortS, we attack the problem through decomposing the query’s syntax tree with regard to its semantics. Any OWL-DL class expression can be parsed into a syntax tree. According to the OWL-DL abstract syntax definition in [6], the tree has 6 basic elements shown in Fig. 5. Note that in the figure union (⊔) is not regarded as a basic element of the syntax tree. Actually with the application of the De Morgan Law

Fig. 5. OWL-DL Syntax Tree Elements

A ⊔ B = ¬(¬A ⊓ ¬B), all union operations can be normalized into intersection and complement operations. Furthermore, we normalize the query expressions and service output class descriptions so that no intersection operations contain intersection class operands (e.g. (A ⊓ B) ⊓ C is normalized to A ⊓ B ⊓ C), and no complement operations contain complement class operands (i.e. ¬(¬A) is normalized to A). We will illustrate our basic ideas by our Apex-Lab-Portal example. In order to show a list of upcoming conferences focused by our lab in the IndexContainer, the query QA in the Apex-Lab-Portal example can be expressed as formula: ∃ focusedBy.{apexLab}⊓Conference⊓∃ hasDeadline. (∃ laterThan.{today}) (1) It can be parsed as a syntax tree shown in Fig.6. In the example, there is a service which has the capability to return a list of conferences whose paper submission deadlines are later than an input date. The input class description of the service’s capability is the class Date. The output class description O is: Conference ⊓ ∃ hasDeadline. (∃ laterThan.{input})

(2)

and its syntax tree is shown in Fig.7.

Fig. 6. Syntax Tree of Query

Fig. 7. Syntax Tree of Service Output

In addition, the Apex-Lab-Portal’s domain knowledge base knows what conferences are focused by the lab. That is, the class ∃ focusedBy.{apexLab} ⊓ Conference

(3)

can be answered by the domain knowledge base. We can see that the intersection (⊓) of (2) and (3) is equivalent to (1) – the query QA . It is more clear seen on the Fig.6. (3) is the central-left part of the tree and (2) is the central-right part of the tree. The query is then equivalent to the intersection of the two parts. This example shows how the information providing service SA and the domain knowledge base is composed together to answer a query. This idea can be seen as a horizontal decomposition. On the other hand, we also need a vertical decomposition method, i.e. query result of a sub-tree may be used as input to feed another service.

5

Recommendation of Services

In Web portals, especially E-Commerce portals, world changing services may play a pivotal role because they can perform real world (business) transactions. Many current semantic portals are limited to only presenting domain knowledge. Adding world changing services will greatly enrich the portal’s functionality and help user act based on contextual knowledge. However, simply listing all available services on the portal is far from an appropriate integration method. Users may be overloaded with lots of irrelevant or uninteresting services. SPortS solves the problem by listing only those services that are contextually relevant. The function is provided by another information providing service – Recommendation Service. Intuitively, the semantic context that determines which service is relevant includes the concepts/classes that the user recently visits. For instance, in our running Apex-Lab-Portal example, when the user clicks a conference link to show its details, he/she is probably interested in those services that involve related concepts, such as conferences, papers, proceedings, etc at that moment. However, with time, the user may gradually shift his/her focus to other concepts in the portal during his/her visit and the list of relevant services should change accordingly. We simulate this process by assigning temperatures to concepts that reflect their degrees of the user’s attention. “Hotter” concepts receive more visits and the temperature will be dropped if it is not visited by the user for a while. In SPortS, the semantic context is constructed based on an un-directional graph G = (V, E) where V is the set of all the classes in the unified ontology of the virtual knowledge base and the edges in E are the semantic relations between classes. The graph can be obtained by converting the OWL-DL descriptions of the virtual knowledge base into an RDF graph. Currently in SPortS, we obtain the graph using a special algorithm that analyzes the OWL-DL class descriptions. For each vertex c ∈ V , a temperature t(c) is assigned and for each edge r ∈ E a thermal conduction factor d(r) is assigned. All t(c) are initialized to 0 and d(r) are initialized according to the semantic types of r. For a path p consisting Qn of edges r0 , r1 , . . . rn in the graph, its thermal conduction factor d(p) = i=0 d(ri ). To measure the mutual influences between any pair of vertices c1 and c2 , we define the maximum thermal conduction factor between them as md(c1 , c2 ) = max{d(p) | p connects c1 and c2 } and we define md(c, c) = 1 for

any c. Whenever a user visits some concepts by browsing a Web page, the following procedure is used to update the temperatures of concepts: 0 void update temperature () { 1 let C be the set of the currently visited concepts; 2 let G = (V, E) be the entire graph; 3 for each v ∈ V , t(v) = α ∗ t(v); // α is a cooling coefficient. 4 for each c ∈ C do 5 for each v ∈ V do 6 t(v) = t(v) + ∆ ∗ md(c, v); // ∆ is the temperature increment. 7 for all v ∈ V normalize t(v) into the range of 0..1; 8 }

The semantic context then consists of all the concepts and their current temperatures. Based on this context, the relevance value of a semantic Web service s is calculated as t(c0 ) + t(c1 ) + . . . + t(cn−1 ) n where ci is the concept in the OWL-S description of s. The services are then ranked according to the relevance values rel(s) and recommended to the user. In addition to the dynamic recommendation, SPortS also supports static recommendation that always recommends specific services for certain concepts. System administrators can utilize this feature to enforce business policies on service recommendation. rel(s) =

6

Related Work

Recently, a great variety of technologies and systems have been developed to achieve the goal of automatic semantic Web portal generation. Similar to SPortS, they use ontologies to model a data-intensive Web site at a conceptual level. As a result, the portal designer can focus on the conceptual structure of the target portal and domain knowledge, independently of its realization. SEAL[1] proposed a generic architecture for developing, constructing and maintaining semantic portals, and extended the semantic modules to include a large diversity of intelligent means for accessing the Web site, like semantic ranking, machine accessing, etc. ODESeW[3] is an ontology-based application designed on the top of WebODE[15] ontology engineering platform that automatically generates and manages a knowledge portal. It provides functions for content provision, content visualization, and content search and querying. It also provides an easy-to-use tool suite for the administration of the generated knowledge portals. The OntoWebber[5] is a tool that was used to build the Semantic Web Community Portal as part of the OntoAgents project. It takes the sources from ontologies in RDF or semi-structured data like HTML with corresponding data translators.

IIPS[16] is another ontology based portal generating system. Similar to SPortS, It defines a site ontology to model the navigational structure and the compositional structure of a data-intensive Web site on the basis of pre-existing site modelling approaches. It provides explicit mapping mechanisms, which make it possible to generate quickly site implementations from the conceptual model. OntoWeaver[4] extends IIPS by proposing and introducing a customization framework into the ontology-based Web modelling approach to the design and maintenance of Web applications. The fundamental difference between the SPortS approach and previous approaches is that SPortS tightly integrates semantic Web services, both information providing services and world changing services, into generated portals. Semantic portals generated by previous approaches are mostly limited to only presenting and editing domain knowledge. By integrating information providing services into the portal, more dynamic and up-to-date information from services can be combined with domain knowledge to serve the users. By adding services to the generated portal and recommending them according to semantic contexts, the portal’s functionality is greatly enriched and the user can act on the contextual knowledge in the portal.

7

Conclusion and Future Work

In this paper, we have presented SPortS, an OWL-DL based semantic portal system that integrates semantic Web services into generated portals at the presentation level, the data level, and the function level. At the presentation level, semantic Web services can be uniformly presented as first class citizens with domain knowledge. At the data level, knowledge from information providing services can be retrieved and composed together with domain knowledge to answer complex queries. In this way, potentially broader and more up-to-date information from services can be synthesized. At the function level, the recommendation of services greatly enriches the generated portal’s functionality and can help users act in the portal based on contextual knowledge. Currently, the SPortS prototype system is limited in the following aspects. At the presentation level, the generated portal can only display Web services in a uniform way, so for those services which serve as desktop-applications, SPortS can only integrate their functions without presentation details. The WSRP standard can be used to solve this problem. At the data level, due to the lack of an appropriate OWL query language and the difficulties in decomposing queries, we cannot fully utilize the information to answer more queries with better results. At the function level, the portal personalization is not yet designed in the current prototype. For example, the semantic context used by the service recommendation does not include any personalization information. Our future work will be focused on these aspects.

References 1. Maedche, A., Staab, S., Stojanovic, N., Studer, R., Sure, Y.: SEAL – a framework for developing semantic web portals. In: Proceedings of the 18th British National Conference on Databases. Volume 2097 of LNCS. (2001) 1–22 2. R.Volz, D.Oberle, B.Motik, S.Staab: KAON server - a semantic web management system. In: Proceedings of the 12th International Conference on World Wide Web (WWW2003). Alternate Tracks - Practice and Experience, Budapest, Hungary (2003) 3. Corcho, O., G´ omez-P´erez, A., L´ opez-Cima, A., L´ opez-Garc´ıa, V., Su´ arez-Figueroa, M.: ODESeW: automatic generation of knowledge portals for intranets and extranets. In: Proceedings of 2nd International Semantic Web Conference. Volume 2870 of LNCS., Springer (2003) 4. Lei, Y., Motta, E., Domingue, J.: Design of customized web applications with OntoWeaver. In: Proceedings of the international conference on knowledge capture (KCAP03), ACM Press (2003) 54–61 5. Jin, Y., Decker, S., Wiederhold, G.: OntoWebber: model-driven ontology-based web site management. In: Proceedings of SWWS’01, The first Semantic Web Working Symposium, Stanford University, California, USA, July 30 - August 1, 2001. (2001) 6. F.Patel-Schneider, P., Hayes, P., Horrocks, I.: OWL Web Ontology Language semantics and abstract syntax. W3C Recommendation, W3C (2004) http://www.w3.org/TR/owl-semantics/. 7. McIlraith, S., Son, T., Zeng, H.: Semantic web services. IEEE Intelligent Systems (Special issus on the Semantic Web) 16 (2001) 46–53 8. Horrocks, I.: The FaCT system. In: Tableaux98. (1998) 307–312 9. Haarslev, V., Moller, R.: Racer system description. In: Proceedings of the First International Joint Conference on Automated Reasoning, Springer-Verlag (2001) 701–706 10. Kropp, A., Leue, C., Thompson, R.: Web services for remote portlets specification. Oasis specification, OASIS (2003) http://www.oasisopen.org/committees/download.php/3343/oasis-200304-wsrp-specification1.0.pdf. 11. Horrocks, I., Tessaris, S.: Querying the Semantic Web: A formal approach. In: Proceedings of the 1st International Semantic Web Conference (ISWC2002). LNCS 2342 (2002) 177–191 12. Lin, C., Yu, Y., Yang, Y., Zhang, L., Zhou, J.: Towards composing information providing services. In: Proceedings of the 2004 IEEE International Conference on Services Computing, IEEE Computer Society Press (2004) to appear. 13. Beeri, C., Levy, A.Y., Rousset, M.C.: Rewriting queries using views in description logics. In: Proceedings of PODS-97. (1997) 99–108 14. Goasdoue, F., Rousset, M.C.: Rewriting conjunctive queries using views in description logics with existential restrictions. In: Proceedings of the 2000 International Workshop on Description Logics. (2000) 113–122 15. Corcho, O., L´ opez, M.F., P´erez, A.G., Vicente, O.: WebODE: An integrated workbench for ontology representation, reasoning, and exchange. In: Proceedings of EKAW 2002. LNCS 2473 (2002) 138–153 16. Lei, Y., Motta, E., Domingue, J.: An ontology-driven approach to Web site generation and maintenance. Lecture Notes in Computer Science 2473 (2002) 219–234