A Planner Infrastructure for Semantic Web Enabled Agents Erdem Eser Ekinci, Ali Murat Tiryaki, Önder Gürcan, and Oguz Dikenelli Ege University, Department of Computer Engineering, 35100 Bornova, Izmir, Turkey
[email protected], {ali.tiryaki,onder.gurcan,oguz.dikenelli}@ege.edu.tr
Abstract. Web services and agents are two important software development technologies that are affected from the semantic web innovation. Researches for attuning these topics to the semantic web prepare a ground for integration of them. In this paper, a planner infrastructure1 is introduced that provides the integration of these two topics on the semantic web ground. Our approach is to support the semantic web service usage during agent planning process. Hence, agent can select required external semantic services to satisfy a goal and can interact with the selected services during the plan execution.
1
Introduction
The semantic web brings significant innovation to the software development society by enabling the development of loosely coupled and independently evolving applications. In particularly, this innovation affects the distributed application development technologies. Web services and agents are two of important distributed application development technologies that must be improved according to the semantic web capabilities. Web services are self-defined and distributed web applications. The semantic web evolution of web services intends to dynamic and more global service execution. This evolution initiated a new generation service technology, which is called semantic web services. Semantic web services provide dynamic discovery and more global execution. Currently efforts such as OWL-S2 , WSMF[6] and SWSA[3] are working for adapting web service environment to the semantic web service architecture. On the agent research direction, researchers have been attempting to develop agent infrastructures working on semantic web environment. These efforts reinforce some of the agents’ core capabilities such as autonomy, intelligency and 1
2
This work is supported by The Scientific and Technological Research Council of Turkey (TÜBiTAK) Electric, Electronic and Informatics Research Group (EEEAG) under grant 106E008. Web Ontology Language-Service, http://www.daml.org/services/owl-s/1.1/
R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM 2007 Ws, Part I, LNCS 4805, pp. 95–104, 2007. c Springer-Verlag Berlin Heidelberg 2007
96
E.E. Ekinci et al.
interoperability. On this direction some semantic web enabled multi-agent system frameworks such as [5], [4] have proposed in the literature. Actually, the core capabilities of an agent are provided by its planner infrastructure. Hence, semantic web agents need specially designed planner that utilize the capabilities of the semantic web environment. Such a planner first of all should be able to use explicit ontologies during decision making process. Moreover, it should have ability to use external semantic web services to satisfy its goal(s). In this paper, we propose a planner architecture for agents working the semantic web environment. This planner is based on the Hierarchical Task Network (HTN) paradigm[15] and specially designed HTN Ontology to present its plan’s meta information. Moreover, explicit knowledge of the external semantic services are stored using the well-known OWL-S ontology. So, the planner has an ability to select HTN structures or external semantic services during decision making process to satisfy the agent’s goal and its graph based execution environment can execute any ontological representation (HTN or OWL-S) for goal satisfaction. The main design principle of the proposed architecture is the extensibility of the infrastructure in a way that external services modelled with different ontologies (such as WSMO[1]) can be easily integrated to the infrastructure since planner is based on the explicit ontologies in selection and execution processes. The rest of the paper is organized as follows: first, we define the concept of semantic web agent and requirements of its planner in section 2, then the extensible architecture of the proposed planner is introduced in section 3, the proposed planner has been implemented and used within the SEAGENT framework[5], hence a case study is introduced in section 4 to describe planer’s capabilities within the SEAGENT framework.
2
Planner Requirements for Semantic Web Enabled Agents
An agent can be classified as goal-governed or goal-oriented based on the conceptual framework described in [12]. Goal-governed agents have some form of cognitive capabilities to explicitly represent their goals, driving the selection of agent’s actions. On the other hand, behaviors of goal-oriented agents are directly designed and programmed to achieve some goals[13]. Based on this classification, semantic web enabled agents (SWEA) are goalgoverned agents in which their goals and believes explicitly defined using the pre-defined ontologies to drive the action selection process. Of course, a SWEA can satisfy a goal using the semantic services situated in the semantic web environment. So, a SWEA must be capable of selecting internal behavior or an external semantic service to satisfy its goals. Semantic web services are represented using ontology description languages such as OWL-S. So, planner of SWEA should have the ability of using service ontologies that are created using these languages. Moreover, the internal knowledge of the agent has to be held using the ontologies to provide integration with the semantic web and enhance inference capabilities.
A Planner Infrastructure for Semantic Web Enabled Agents
97
Internal knowledge of SWEA can be represented by two related ontologies. First one is called the Agent Management Ontology, consists of agent’s goals and believes. The other one called Task Ontology is used to define the structures of the agent internal tasks. Since the proposed planner is based on the HTN formalism, our task ontology defines the HTN structure used in our plans and is entitled as HTN Ontology. The Agent Management Ontology depends on the HTN Ontology. When an agent takes an objective, the planner queries the Agent Management Ontology and decides how to react. The result of the query can be a task, which is defined in the HTN Ontology. To transform traditional agents to semantic web enabled agents, the decision phase mentioned above had to be semantic web enabled either. Therefore, we extended our Agent Management Ontology to support semantic web services by associating it with ontologies defined using OWL-S. By using this extension, an HTN task or an OWL-S based semantic web service can be returned as the answer of a planner query. Therefore, this extension can be said to enable the agent to react against an objective by invoking a semantic web service or running an HTN task. To execute different workflow paradigmas such as HTN, OWL-S and WSMO, the planner should have an infrastructure that is abstracted from those technologies’ details. This abstraction can be supplied basically by a graph structure. Moreover, the former AI planning researches depict the graph based planners’ successful results on the planning problems [2]. In [10], it was introduced reducting HTN structures on graph structure. This approach is also used in the proposed infrastructure. But, our design decouples graph constructing from graph execution. So, a new model (such as OWL-S) reductor, that transforms the model ontology to the graph can be easily pluged to the infrastructure. In the literature, there are some efforts on executing semantic web services by planners such as [14],[9]. In [14], Sirin and Parsia try to execute semantic web service by an HTN based Shop2 [11] planner. In this research, the planner execute OWL-S structures by mapping them to the HTN structures. Another work, [9] converts OWL-S semantics to PDDL[7]. In both researches, the planners achieve service execution by mapping service semantics to their internall plan models. Similar to [14,9], previous implementation of SEAGENT planner[8] was based on the HTN structures to achieve semantic service execution. This version’s internall representation was hold using data structures instead of ontology. The planner is refactored separating goal selection and goal execution using their reductors to executing different representation frameworks in the same environment. By the way, semantically execution ability is gained by the planner. In the following section, current version of the planner detailed to express how the requirements for semantically executing planner are supported.
3
The Architecture of Semantic Web Enabled Agent Planner
The implementation of the proposed architecture is represented in Figure 1 with two vertical layers. First layer named as the semantic web layer consists
98
E.E. Ekinci et al.
of HTN, OWL-S and Agent Management Ontology. Second layer includes the implemented planner modules which work by using the ontologies defined in the semantic web layer. The Figure 1 depicts modules, ontologies and their relations in our planner architecture. As seen in this figure, the planner consists of two modules and four ontologies that are used by these two modules.
Fig. 1. SEAGENT Planner Architecture
The PlanningBase module is responsible for primitive execution of task graphs and coordinating the execution flow according to the agent knowledge base which includes instances of the classes in the system ontologies. All behaviors of the agents are decided by querying this knowledge base. In this way, the planner processes semantically at the run-time. After the behavior decision process, PlanningBase creates a graph from the tasks which are selected according to the knowledge base. The Extension module is upper level and can be thought as an application layer for the PlanningBase. Main contribution of this module is that it provides a means for executing HTN tasks and Semantic Web services together. This capability is provided by the HTN and OWL-S sub-packages in the Extension module. Each module of the planner uses SEAGENT Knowledge Management API (SEKMA) for handling the ontology instances. The SEKMA handled knowledge base consists of the individuals derived from the combination of four main system ontologies. The system packages work analogously with these ontologies. The following sub-sections contain brief descriptions of sub-packages and execution mechanism of the planner. 3.1
PlanningBase Module
The PlanningBase module forms the basis for planning on a graph structure. The graph structure consists of the nodes that represent tasks. The planner works on the graph by executing linked nodes and adding new ones. This function is
A Planner Infrastructure for Semantic Web Enabled Agents
99
the most important and primitive one of the PlanningBase, and is realized by the Core package. The Core package traces and executes the task graph. When the Core package starts to execute a plan, the initial node is executed first. After this node, execution continuous with the following nodes by tracing the graph over the links until the last node is reached and executed. A node always generates an outcome state and may produce outcome(s) as a result of its execution. Core follows convenient links with the guidance of generated outcome state and outcomes of each node. If a link lets the Core to run a task, none of whose provisions are ready, this node is moved to the waiting task queue. The Task sub-package in the PlanningBase consists of the classes that are used to represent components in graph structure mentioned above. In the Task sub-package, there are three important classes for creating graphs: TaskImpl, LinkImpl and ParameterImpl classes. All nodes of a task graph should be derived from the abstract TaskImpl class. TaskImpl has the properties required for execution management such as isCyclic, priority, period and failed. This class has composition relation with ParameterImpl class. The ParameterImpl is used to define outcomes and provisions. Another critical relationship of TaskImpl class is with LinkImpl class. Using this relationship, instances of the TaskImpl class are linked to each other. Tasks can be linked to each other in two ways: by using the OrderedLinkImpl class, and the ParameterLink class. While the OrderedLinkImpl class is used to order tasks, ParameterLink class is used to provide information flow between parameters. Whole execution mechanism of the planner is based on the two sub-packages mentioned previously. We implemented all of the functionality that may be required during agent life cycle by extending the TaskImpl class, and placed these critical tasks into the SystemPlans package. This package includes the system plans that are responsible for the execution of general tasks like, tracking the execution flow of task graphs, listening for incoming objectives, sending and receiving messages between agents. So, agent’s system activities are achieved by these tasks, Matcher and Dispatcher. By this way, agent’s behavior mechanism can be easily extended and modified. At the start up, PlanningBase looks up the knowledge base and loads the initial tasks (system plans/tasks) that are necessary for agent life cycle. After the initialization phase, system tasks listen to system resources such as objective queue and message queue consistently. When an objective is put into the objective queue by the Dispatcher, Matcher gets it and queries the knowledge base to find a proper individual of the Goal concept, which is defined in the management ontology. The model of management ontology is shown in figure 2. In this ontology, the Goal concept has the hasAchiever property. This property may have Task concept from the HTN ontology or service concept from the OWL-S ontology as its range. The range of the Goal individuals is required for deciding for what behavior should be reacted for an objective. When the objective arrived to the planner the Matcher queries the Agent Management Ontology for achieving the goal and
100
E.E. Ekinci et al.
Fig. 2. Agent Platform Management Ontology
according to the achiever, the Matcher again queries to the knowledge base for finding proper task that has the capability of reducting the achiever individual. In current implementation of the planner achiever of a goal may be an HTN task or semantic web service. Furthermore, the Matcher loads a resolver task for parsing the the HTN plan or OWL-S service individual and forming a task graph. 3.2
Planner Extension
Extension module is a gateway for the planner to the Semantic Web by combining Semantic Web Services and HTN planning. This integration is provided by the HTN and OWL-S sub-packages. Internal structures of each of these two sub-packages are similar, since HTN sub-package parses the HTN ontology and OWL-S sub-package parses the OWL-S ontology to form a task graph that can be executed by the PlanningBase package. HTN Sub-Package. The HTN sub-package has two important task HTNReductor and ActionExecutor. The HTNReductor is derived from the system task and has responsibility of reducting a graph according to the HTN ontology. When the Matcher decides to execute an HTN task, then creates and puts the HTNReductor to the task queue by setting provision by the achiever individual, which is found by the result individual of the previous query’s. HTNReductor parses the provision and generates a graph which’s nodes are instances of the ActionExecutor tasks. ActionExecutor is inherited from TaskImpl, located in Task package, and each ActionExecutor instances’ knowledge are set by parsing plan according to the HTN Ontology. The HTN ontology resembles the HTN structure presented in Sycara et. al [15]. In the HTN formalism, there are two types of tasks: complex tasks called as behaviors and primitive tasks called as actions. Each plan has a root task which is a behavior itself consisting of sub-tasks that are composed to achieve a
A Planner Infrastructure for Semantic Web Enabled Agents
101
predefined goal. Behaviors hold a ’reduction schema’ data structure that defines the decomposition of the complex task to sub-tasks, and the information flow between these sub tasks and their parent task. Actions, on the other hand, are primitive tasks that can be executed by the planner using the Java Reflection API. Each provision represents a datum which is needed by a task in order to execute. Each task produces an outcome state after its execution. Outcome state is usually used to route the information flow between tasks. Information flow is achieved by the provision-outcome links between tasks. Additionally, there are two other link types, called as inheritance and disinheritance. Inheritance and disinheritance links are used for representing the information flow between a parent task and its sub tasks. The reductor resolves an individual derived from the HTN Ontology with the help of the HTNOntologyParser, and creates a graph. The graph consists of the instances of three classes named as InitialNode, FinalNode and ActionExecutor. InitialNode and FinalNode are the first and last nodes of the graph. The ActionExecutor executes Actions which are the basic units implemented by the developers. The HTNReductor creates ActionExecutor instances for each individual of the Action concept as necessary to form a task graph. Each ActionExecutor creates an instance of the Action whose name is given as a parameter, and sets the local variables that match with the provisions of the Action. Finally, an ActionExecutor binds the values of the local variables to the outcomes defined for the action. Figure 3 depicts how a behavior can be represented as the graph.
Fig. 3. HTN to graph convertion sample
OWL-S Sub-package. Structure of the OWL-S sub-package is very similar to the structure of the HTN sub-package. OWL-S sub-package consists of a reductor class and specialized node classes. The OWL-SReductor is initialized in the same way as the HTNReductor; if the achiever of a goal is recorded as a Semantic Web service in the knowledge base, then the Matcher awakes the OWL-SReductor by setting its provision with the service profile of the service. OWL-SReductor parses a semantic service profile and process model generates a graph like the HTNReductor. However, service execution is more complex
102
E.E. Ekinci et al.
than HTN execution. If the service to be executed is a composite service, it is broken down into atomic services. During the execution of such a composite service, discovering and engaging phases have to be fulfilled for each atomic service that is to be executed. OWL-SReductor adds three different kinds of nodes per atomic service to the graph for discovering, engaging and executing phases sequentially. These nodes are called ServiceFinder, ServiceEngager and ServiceExecutor nodes, and are equipped with the knowledge of the atomic service. ServiceFinder task gets the service profile as a provision from the OWL-SReductor. ServiceEngager and ServiceExecutor nodes are connected to the prior node to themselves through ParameterLinks. Later, these three nodes are executed sequentially by the planner. ServiceFinder finds a service that corresponds to the service profile. The ServiceEngager negotiates over the service with the host agent and transmits the engagement information to the ServiceExector. Consequently, the ServiceExecutor creates a SOAP message, invokes the web service and reversely produces outcomes from the response SOAP message.
4
Case Study
A tourism application was implemented as a case study with SEAGENT Multi Agent Framework. In this application, base scenario is achieved by the broker agent and the user agents. The broker agent is responsible for hosting the hotel reservation and car renting services to the user agents. However, the broker agent uses different resources for serving hotel reservation and car renting. Hotel reservation is supplied by semantic web services, which are published by hotels and car renting is provided by local HTN tasks of the broker agent. The part
Fig. 4. Individuals of Agent Management Ontology
A Planner Infrastructure for Semantic Web Enabled Agents
103
of the broker agent’s internal knowledge that contains derived individuals from Agent Management ontology and illustrates these two goals is shown in figure 4. When an user agent sends a request message for reserving a hotel room to the broker agent, its planner queries the local Agent Management Ontology individuals according to the request. By this query, achiever of the hotel room reservation goal is looked for. As mention before, this goal achiever is a semantic web service. The planner reducts the special tasks for execution such as ServiceFinder, ServiceEngager and ServiceExecutor. After the reduction, the planner executes these tasks, and the tasks sequentially find a service, engage on it if required then calls the service and gets the response message. The broker agent returns the service response message to the user agent. On the other hand, when the broker agent receives a message that includes the request for car renting, its planner queries the local Agent Management Ontology individuals according to this request likewise reserving a hotel. But the achiever that is result of this query is one of the local HTN tasks. The planner reducts this task and executes sub task according to its reduction shema and current state. At the end of this task, the broker agent returns the service response message to the user agent.
5
Conclusion
In this paper, a planner architecture for semantic web enabled agents is proposed. We realized a semantically executing and graph based planner for SEAGENT Multi Agent System development framework by implementing the components in this architecture. This planner has the capability of executing local HTN tasks and/or invoking external semantic web services in the same plan to achieve the owner agent’s goals. The implemented planner has been used in the some SEAGENT applications that require usage of semantic web services and agents. One of these applications, which is in the tourism domain, is represented in section 4. During the development of this application we observed that developer easily integrated external services using the planner internal support that executes OWL-S services from their semantic description. The current version of the planner doesn’t support all workflow types -such as iterate, repeat-until and choice- that are defined in the process model of OWL-S. To overcome this problem, some special tasks, which enable the execution of these workflow types, were added into the PlanningBase package. Currently, we are working on a means for adding the missing parts of the OWL-S process model to the PlanningBase package without using any special tasks.
References 1. Web service modeling ontology (wsmo): W3C Member Submission (June 2005) 2. Blum, A.L., Furst, M.L.: Fast planning through planning graph analysis. Artif. Intell. 90(1-2), 281–300 (1997)
104
E.E. Ekinci et al.
3. Burstein, M., Bussler, C., Zaremba, M., Finin, T., Huhns, M.N., Paolucci, M., Sheth, A.P., Williams, S.: A semantic web services architecture. IEEE Internet Computing 9(5), 72–81 (2005) 4. Dickinson, I., Wooldridge, M.: Towards practical reasoning agents for the semantic web. In: AAMAS 2003. Proceedings of the second international joint conference on Autonomous agents and multiagent systems, pp. 827–834. ACM Press, New York, NY, USA (2003) 5. Dikenelli, O., Erdur, R.C., Gumus, O., Ekinci, E.E., Gurcan, O., Kardas, G., Seylan, I., Tiryaki, A.M.: Seagent: A platform for developing semantic web based multi agent systems. In: AAMAS, pp. 1271–1272. ACM Press, New York (2005) 6. Fensel, D., Bussler, C.: The web service modeling framework wsmf. Electronic Commerce Research and Applications 1(2), 113–137 (2002) 7. Ghallab, M., Howe, A., Knoblock, C., McDermott, D., Ram, A., Veloso, M., Weld, D., Wilkins, D.: Pddl—the planning domain definition language (1998) 8. Gurcan, O., Kardas, G., Gumus, O., Ekinci, E.E., Dikenelli, O.: An mas infrastructure for implementing swsa based semantic services. In: Service-Oriented Computing: Agents, Semantics, and Engineering. LNCS, vol. 4504, pp. 118–131. Springer, Heidelberg (2007) 9. Klusch, M., Gerber, A.: Evaluation of service composition planning with owlsxplan. In: IAT Workshops, pp. 117–120 (2006) 10. Lotem, A., Nau, D.S., Hendler, J.A.: Using planning graphs for solving htn planning problems. In: Proceedings of AAAI 1999/IAAI 1999, Menlo Park, CA, USA, pp. 534–540. American Association for Artificial Intelligence (1999) 11. Nau, D.N.: Shop2: An htn planning system. Journal of artificial intelligence research 20, 379–404 (2003) 12. Conte, R., Castelfranchi, C.: Cognitive and social action. London University College of London Press, Londra (1995) 13. Ricci, A., Viroli, M., Omicini, A.: Programming mas with artifacts, pp. 206–221 (2006) 14. Sirin, E., Parsia, B.: Planning for semantic web services. In: Semantic Web Services Workshop at 3rd International Semantic Web Conference (2004) 15. Sycara, K., Williamson, M., Decker, K.: Unified information and control flow in hierarchical task networks. In: Working Notes of the AAAI-96 workshop Theories of Action, Planning, and Control (August 1996)
