Knowledge Broker Technology: Description of intro-image What's the Problem? The key to effective knowledge management lies in accessing the right knowledge at the right time. In the context of today's distributed information organisations this may not be a straightforward task. While a company intranet (and, more generally, the internet) would seem to present an ideal medium for delivering such knowledge 'services', the problem arises of just how these services are to be located in such an decentalised, fluid environment. Towards a Solution Some sort of brokering service is commonly proposed as a solution to this problem of locating and using disparate knowledge services in a distributed environment. The Knowledge Broker represents an attempt to provide such a service from an AKT, knowledge-centric persepective. Agents offering services advertise them to the broker, while agents with problems to solve pose queries to the broker; the role of the broker, then, is to match one or more of the available services with these queries, where possible, and to suggest these possibilities to the querying agent. The AKT broker operates at two complementary levels of abstraction: * knowledge services are specific 'functions' (or competences) advertised in terms of their preconditions, the roles fulfilled by their inputs and outputs, and, perhaps, particular dependencies on the availability of other, external services (all described in terms of a particular ontology). * knowledge services are described as more general 'knowledge transformations' of input knowledge into output knowledge. When operating at the first of these levels, the broker is able to formulate relatively precise 'chains' of agent interactions (which can often be automated, if the environment allows) to solve precise queries. At the second, more abstract level, the brokered solutions are, as might be expected, more abstract, but which allow progress to be made in situations where precise formulations of queries are, for whatever reason, not possible, or where more general explorations of the space of possible services are wanted. This broker is built upon a number of technologies.The brokering mechanisms themselves are written in Prolog, and make use of that language's peculiar backtracking capabilities to select alternatives and construct chains of individual competences into a global solution. Obviously, communications are fundamental to distributed inactions: the broker uses the AKTBus protocol and libraries, consisting of XML layered on conventional HTTP and TCP/IP protocols, to provide basic message-passing capabilities. These messages are further structured through the use of FIPA and RDF/S to allow the unambiguous specification of their components in a manner independent of any particular programming language or paradigm. Take a Guided Tour Forthcoming. Try a Demonstration Forthcoming. Technical requirements: For running the broker: Sicstus Prolog v.3.8+ (including Jasper and Linda modules), Java (with AktBus and Jena libraries), HTTP/TCP/IP connectivity for handling remote broker communications. For querying and advertising services to the broker, Java (with AktBus and Jena libraries) pllus HTTP/TCP/IP connectivity. Example Applications Forthcoming. Further Reading Key document: Schorlemmer, Dr Marco and Potter, Dr Stephen and Robertson, Dr David and Sleeman, Prof Derek (2002) [1]Formal Knowledge Management in Distributed Environments. References 1. http://eprints.aktors.org/archive/00000062/ Stephen Potter c8e4e1dcf96e1e783c043831ef8793449d67ee06 Marco Schorlemmer c4d34efe2d161d881fe55845b918e4b4fd74d05b Dave Robertson eae05bf788a35707ab3ef98a30030c98b66757f3