|
|
|
This document consists of the following sections:
The World Wide Web is steadily evolving towards an open service market. If service providers and service requesters are modeled by objects, references between these induce a "knows-about-relation". A snapshot of such an environment may be visualized by an object graph. There is not necessarily a one to one correspondence between objects and WWW-pages, as one service provider object may consist as a set of WWW-pages (just consider a library interface with a query template page and separate "hit"-pages for the query). It is also clear that without appropriate support from an underlying infrastructure a service requester can't "see" beyond the references it holds.
A client object therefore has only a limited view on the object graph, as global knowledge of its structure is generally impossible to acquire. System components called traders serve as mediators between service requesters and service providers and therefore bridge the knowledge/visibility gap. A trader matches service requests with previously stored service offers and thereby helps to establish references in the object graph. The match process heavily depends on the way services are typed.
It is important to think about the role of a type in such an environment. In order for the match algorithm within the trader to succeed, a type description must conform to a kind of "standard", which all participating parties have to agree upon a priori. This standard has to be defined well enough to be matched unambiguously against other types. Current traders, like the ODP Trader, base their match algorithm mainly upon syntactic features. The implication is that the exact syntactic structure of a particular service type must be communicated to all parties.
With the emergence of high level services as found in the World Wide Web the need for an appropriate typing mechanism becomes evident. An application user (i.e. not a programmer) must deal with service types to lookup matching service providers. So far there exist only simple keyword based traders which allow only for a limited expressiveness of service types. We have chosen to develop a type specification based on conceptual graphs which are particularly useful to support the cognitive domain of the users.
Conceptual graphs have been developed to model the semantics of natural language. Service descriptions based on conceptual graphs are therefore intuitive in the sense that there is a close relationship to the way human beings represent and organize their knowledge. From an abstract point of view a conceptual graph is a finite, connected, directed, bipartite graph. The nodes of the graph are either concept or relation nodes. Due to the bipartite nature of the graphs, two concept nodes may only be connected via a relation node.
A concept node represents either a concrete or an abstract object in the
world of discourse. As for the context of service types a concept may be
a concrete object such as PRINTER, COMPILER or
DATABASE including specific instances
(e.g. HP-Laserjet, GCC, Ingres,
etc), as well as an abstract object such as PRINTING-SPEED
or PROGRAMMING-LANGUAGE with no physical
representation. Whereas concepts model objects of our perception, a
relation node expresses a specific relationship between concept nodes.
The following conceptual graph describes an object oriented language called C++ (concept nodes are surrounded by square brackets and relations by round brackets, respectively). The informal semantic of the concept is: Something which is a superset of a programming language called C, supports classes which themself consist of methods and a state.
Within the AI-Trader Project we have developed a trader capable of processing service descriptions based on conceptual graphs. The implementation (including the complete sources) are freely available. A Tcl/Tk-based frontend makes editing of conceptual graphs easy (the screenshot above came from this frontend). Some publications describe the philosophy behind the AI-Trader.
Abstract: An open distributed environment can be perceived as a service market where services are freely offered and requested. Any infrastructure which seeks to provide appropriate mechanisms for such an environment has to include some mediator functionality to bring together matching service requests and service offers. The matching algorithm that the mediator must perform commonly builds upon an IDL-based type definition for service specification. In order for the matching algorithm embedded in this mediator to succeed, the types of various services have to be standardized and distributed to all interested parties. We argue that those well defined "standards" are too inflexible and even contradict the idea of an open service market. Therefore we propose a new way to augment an arbitrary IDL-based type definition by a semantic tag. Whereas several other authors have used pre- and post-conditions to add the notion of behavior description, we use the well established field of Horn clauses as a semantic extension. The advantage lies in the nature of the declarative semantic and it will be shown that the need for a well defined standard is abolished within so called type families.Keywords: Open Systems, Trading, Subtyping, IDL, Declarative Semantics
Appeared in International Conference on Object Oriented Information Systems (OOIS'94). Springer
Abstract: An open distributed environment can be perceived as a service market where services are freely offered and requested. Any infrastructure which seeks to provide appropriate mechanisms for such an environment has to include mediator functionality (i.e. a trader) that matches service requests and service offers. Commonly, the matching process is based upon some IDL-based service type definition, and the types of the various services have to be "standardized" and distributed a priori to all potential participants. We argue that such well defined "standards" are too inflexible and even contradict the idea of an open service market. Therefore we propose a new type notation based on conceptual graphs. The trader maintains a knowledge base about service types in form of conceptual graphs. During the trader operations the service type knowledge evolves as it is continuously refined and extended. Users of the trading service interact with the trader and formulate queries in a corresponding notation that allows for a conceptual specification of the desired service type. Adequate matching algorithms and protocols have been implemented.Keywords: Trading, type specification, conceptual graphs.
Appeared in International Conference on Open Distributed Processing (ICODP'95). Chapman and Hall
Abstract: An open distributed environment can be perceived as a service market where services are freely offered and requested. Any infrastructure which seeks to provide appropriate mechanisms for such environments has to include some mediator functionality to bring together matching service requests and service offers. The matching algorithm that the mediator must perform commonly builds upon an IDL-based type definition for service specification. We propose a type specification notation based upon conceptual graphs to support the cognitive domain of application users. In our framework the trader implements a matching algorithm as well as a learning algorithm which are tailored to service trading in open environments.Keywords: Open distributed environments, type graphs, trading, service matching, service knowledge base, conceptual graphs.
Appeared in International Conference on Conceptual Structures (ICCS'95). Springer
Abstract: Traders serve as mediators between service providers and users. The trader returns to a service requester by delivering a set of suitable providers that satisfy the request. Because of the size and complexity of distributed systems, one trader manages a certain part of the whole set of providers only. To enlarge this restricted set of potential service providers, a lightweight form of cooperation (called interworking) between two or more traders was introduced. Therefore, the main purpose of such cooperations was concerned with quantitative aspects, neglecting the possibilities of more general concepts of cooperation. A need for qualitative trader cooperations arises. Traditional trader approaches focus upon the operational interface of providers as a basis for type descriptions. But in general, application users in an open electronic market require mediation at different levels of abstraction. Suitable traders are specialized in one of these levels. By combining these isolated solutions, a qualitative trader cooperation can be achieved.In the following, we take a closer look at type descriptions at different levels of abstraction. Similarities will be discovered that can be used to derive appropriate mappings. In particular we demonstrate that ODP-types based on an arbitrary interface definition language can be described in terms of conceptual graphs that are used in knowledge-based trading. From this relationship, a general type manager can be derived, coping with both type concepts. As a consequence, the trading of operational interfaces and the trading based on a knowledge representation scheme can be combined. Together they exhibit a more powerful trading service by offering different interfaces to different kinds of users.
Keywords: Trading, type manager, cooperation.
Appeared in International Conference on Distributed Platforms (ICDP'96).
Kurzfassung: In offenen verteilten Umgebungen erlangt die Vermittlung von Diensten eine besondere Bedeutung. Bisherige Ansätze konzentrieren sich jedoch auf die Vermittlung von Instanzen dieser Dienste zur Laufzeit. Dabei wird vernachlässigt, wie zur übersetzungszeit Kenntnis über einen Diensttyp erlangt werden kann. Eine bisher vorausgesetzte Lösung dieses Problems sind a priori Absprachen aller Teilnehmer einer offenen verteilten Umgebung. Um einen solchen Vorgang zu automatisieren, wird in dieser Arbeit ein wissensbasierter Vermittlungsdienst vorgeschlagen, der sich insbesondere durch eine auf Konzeptgraphen beruhende Dienstbeschreibungsmethodik und einen maschinellen Lernalgorithmus für Import- und Export-Operationen auszeichnet. Charakteristisch für diesen Lösungsansatz ist die Tatsache, daß sowohl für einen Import, als auch einen Export Vorgang, u.U. mehrere Interaktionen mit einem Dienstnutzer und Dienstanbieter notwendig sind. In dieser Arbeit werden die Voraussetzungen für dieses mehrere Phasen umfassende Vermittlungsprotokoll erarbeitet.Schlüsselwörter: Meta-Trading, Maschinelles Lernen, ODP.
Erschienen in Entwicklung und Management verteilter Anwendungssysteme (EMVA'95). Krehl Verlag
Abstract: An open distributed environment can be perceived as a service market where services are freely offered and requested. Any infrastructure which seeks to provide appropriate mechanisms for such environments has to include some mediator functionality to bring together matching service requests and service offers. We propose a type specification notation based upon conceptual graphs to support the cognitive domain of application users. Furthermore, they help to cope with the problem of different extensions for the same intension of a service type. Conceptual graphs, which can easily be visualized, originate from a perception model in psychology. In this paper we present a formal model and a new standard interpretation for conceptual graphs.Keywords: Open service markets, trading, service types, conceptual graphs.
Appeared in Workshop on Visual Reasoning, Rutgers University, 1996
Abstract: An open distributed service environment can be perceived as a service market where services are freely offered and requested. Any infrastructure which seeks to provide appropriate mechanisms for such an environment has to include some mediator functionality to bring together matching service requests and service offers. The matching algorithm that the mediator must perform commonly builds upon an IDL-based type definition for service specification. We propose a type specification notation based upon conceptual graphs that supports the openness of the service environment, since it is more flexible than IDL-based definitions, and since it is closer to the cognitive domain of application users. In our framework, the trader implements a matching algorithm as well as a learning algorithm which are tailored to service trading in open environments.Keywords: Open distributed environments, type graphs, trading, service matching, service knowledge base, conceptual graphs.
Appeared in 7th European SIGOPS Workshop (SIGOPS'96).
A prototype of the AI-Trader is freely available via anonymous ftp. The current version 2.2 runs on SunSparcs, IBM RS/6000 and Linux and it shouldn't be too difficult to port it to other platforms. Please send bug reports or comments to aitrader@informatik.uni-frankfurt.de.
The following packages are available:
There exist various Java-applets to access the AI-Trader. The applets resemble those from the binary package of the implementation. Naturally you'll need a web browser with a build-in Java interpreter (like Netscape 2.0 or above). The Java applet will connect to an AI-Trader running on our machines. You'll get an error message if this server should not be available. The following applets are available:
The interface of the AI-Trader is defined via simple ASCII-based commands. Although the graphical user interface masks these internal implementation details, the following sample session provides a good insight of the AI-Trader's capabilities. The script presented below runs without modification with the text based version of the AI-Trader.
/*
* STEP 1
* ------
* Define a few relations on words and their mathematical properties
* as well as the top and bottom element of the concept type lattice.
*/
@register-relation 'SYNONYM' : @reflexive, @transitive, @symmetric
@register-relation 'ANTONYM' : @symmetric
@register-relation 'IS_A' : @reflexive, @transitive, @acyclic
@add-word something
/*
* STEP 2
* ------
* Define a matching rule which matches graphs based on
* syntactical equivalence.
*/
@define-matching-rule 'Specialization'
isa(Node1, Node2) :-
cg_getname(Node1, Name1), cg_getname(Node2, Name2),
cg_matchword(Name1, ['IS_A', 'SYNONYM'], Name2).
match(Qcon, Tcon, Res) :-
isa(Tcon, Qcon),
cg_getsucc(Tcon, TrelList), cg_getsucc(Qcon, QrelList),
matchLists(QrelList, TrelList, Res).
matchLists([], _, accept) :- !.
matchLists(QrelList, TrelList, accept) :-
member(Qrel, QrelList), member(Trel, TrelList),
cg_match(Qrel, Trel, accept),
!.
matchLists(QrelList, TrelList, reject) :-
member(Qrel, QrelList), member(Trel, TrelList),
cg_match(Qrel, Trel, reject).
@end
/*
* STEP 3
* ------
* Define a matching rule for negation
*/
@define-matching-rule 'Negation'
isa(Node1, Node2) :-
cg_getname(Node1, Name1), cg_getname(Node2, Name2),
cg_matchword(Name1, ['IS_A', 'SYNONYM'], Name2).
antonym(Node1, Node2) :-
cg_getname(Node1, Name1), cg_getname(Node2, Name2),
cg_matchword(Name1, ['ANTONYM'], Name2).
match(Qcon, Tcon, reject) :-
cg_gettype(Qcon, concept),
isa(Tcon, Qcon),
cg_getsucc(Qcon, QrelList), cg_getsucc(Tcon, TrelList),
member(Qrel, QrelList), member(Trel, TrelList),
antonym(Trel, Qrel),
cg_getsucc(Qrel, QconList), cg_getsucc(Trel, TconList),
member(Qcon2, QconList), member(Tcon2, TconList),
isa(Tcon2, Qcon2).
@end
/*
* STEP 4
* ------
* Add the first conceptual graph describing 'vacation'.
* Before adding the graph, add the necessary words and relations
* (assume that our knowledge base already cantains 'culture', 'concert',
* 'exhibition', 'sightseeing' and 'characteristic').
*
* AI-Trader will return the unique service database key $0
* (output of the AI-Trader is not shown).
*
*/
@add-word vacation
@add-word activity
@add-relation vacation : 'IS_A' : something
@add-relation activity : 'IS_A' : human_activity
@add [vacation] -> (characteristic) -> [culture] -
-> (activity) -> [concert] ,
-> (activity) -> [exhibition] ,
-> (activity) -> [sightseeing] .
/*
* STEP 5
* ------
* A lookup which succeeds. It matches with vacation from STEP 4.
*/
@match 'Specialization', 'Negation' :
[something] -> (characteristic) -> [human_activity]
/*
* STEP 6
* ------
* A lookup which does not succeed.
*/
@match 'Specialization', 'Negation' :
[something] -> (location) -> [town]
/*
* STEP 7
* ------
* Learn the new features of vacation. The query from STEP 6
* will now succeed:
* 'vacation' is a specialization of 'something' and
* 'city' is a synonym for 'town' ('town' is already known).
*/
@add-word city
@add-relation city : 'SYNONYM' : town
@join $0 : [vacation] -> (location) -> [city]
/*
* STEP 8
* ------
* A new service is to be exported. The conceptual graph which
* the service provider has chosen to "explain" his service is
* as follows:
* [vacation] -> (characteristic) -> [human_activity]
*
* First check if another graph resembles this one via the
* "@match" command.
*/
@match 'Specialization', 'Negation' :
[vacation] -> (characteristic) -> [human_activity]
/*
* STEP 9
* ------
* The description of a vacation from STEP 7 is too similar, the
* service provider decides to augment his inital description.
* He refines the definition of 'human_activity' und replaces it
* with `relaxation'.
* (assume that our knowledge base already cantains 'relaxation',
* 'beach', 'sport' and 'characteristic').
*
* AI-Trader will assign this graph the unique service database
* key $1.
*/
@add-word non_location
@add-relation location : 'ANTONYM' : non_location
@add [vacation] -
-> (characteristic) -> [relaxation] ,
-> (non_location) -> [city] ,
-> (location) -> [beach] ,
-> (activity) -> [sport] .
/*
* STEP 10
* -------
* The description of beach vacation is forwarded to the service
* provider offering a cultural vacation, where upon he decides to
* add a few describtion to his graph to refine it.
*
*/
@join $0 : [vacation] -
-> (accommodation) -> [hotel] ,
-> (duration) -> ['day' : 7] .
/*
* STEP 11
* -------
* The first query will *only* match "culture vacation" and the
* second *only* 'beach vacation'.
* The third query will match *both* graphs (i.e. $0 and $1).
*
*/
@match 'Specialization', 'Negation' :
[something] -> (location) -> [city]
@match 'Specialization', 'Negation' :
[something] -> (non_location) -> [town]
@match 'Specialization' :
[something] -> (characteristic) -> [human_activity]
/*
* STEP 12
* -------
* Add the addresses of the service providers and do a checkpoint of
* the trader's database.
*/
@add-provider $0 : 'Happy Holiday', 'hh@foo1.bar1'
@add-provider $1 : 'Our World', 'OurWorld@foo2.bar2'
@save 'checkpoint.kb'
The following people have been actively involved in the AI-Trader project: