Source: A. Mamdani - D. Steiner
FIPAs Fifth Call for Proposals
The Fifth Call for Proposals of the Foundation for Intelligent Physical Agents (FIPA) is an invitation to submit proposals for technologies to be used in extending the FIPA 97 and 98 specifications as well as creating new specifications for agent-based applications, services and equipment.
These proposed technologies are intended to be utilized in the development of specifications of component technologies that may be used by application developers. Specification development is to be completed by October, 1999.
Rapid developments in agent technology are creating conditions for the deployment of applications, services, and products that are attractive to users by virtue of their ability to offer improved functionalities compared to those of existing technologies. FIPA has been established to promote a larger deployment of interoperable agent systems. This is accomplished through the standardization of component technologies that may be used by application developers across a wide variety of applications and providing a high level of interoperability across those applications. Currently, FIPA has produced two sets of specifications whose field trials are being carried out by FIPA members since early 1998.
FIPA has so far provided four reference applications on which FIPA normative specifications can be tested during the field trials. (A fifth application is currently under preparation and will appear early in 1999.) Clearly the wider community that has been following the work taking place in FIPA (and at whom this call is aimed), has an interest in many more applications of the kind of intelligent software agent technology than those targetted by FIPA. FIPA needs to be made aware of such additional applications areas for two reasons. Firstly, FIPA is aware that the specifications have a much wider applicability and so FIPA work can be of service to a correspondingly wider commercial community. Secondly because FIPA members are also aware that there are applications of intelligent software agents that have additional requirements (for example, where the applications have real-time constraints) that need appropriate extensions. It would obviously be beneficial to produce such extensions in a manner that is consistent with the specifications that have been produced so far.
It should be realized, however, that FIPA is not attempting to specify applications but only uses models of existing or possible applications to identify and assist in specifying the agent component technologies required to implement them. This enables the assembly of applications which would not have otherwise been feasible without standardization.
FIPA members are of the opinion that the current specifications are already a great advance and a remarkable achievement for two years' effort. FIPA has therefore resolved to continue its activities and launch a new initiative for a further standardization effort. The FIPA specifications themselves are perceived to be valuable in building commercial level applications. However, in the course of producing the various parts of these specifications the members have felt that there are additional items on which FIPA can begin a consensus forming work on in 1999 using its well proven FIPA process. The purpose of this call is to define and explain these additional items. This is given in Chapter 4 of this call.
Those intending to submit a proposal(s) should consult Chapter 5 of this Call for Proposals.
FIPA is concerned only with specifications of interfaces and protocols associated with component technologies, but it may nevertheless be necessary to be made aware of certain technological solutions and to understand their technical operations sufficiently for the purpose of accurately capturing their operation as a black box specification.
It is the intention to have the FIPA specifications considered by formal standards bodies for endorsement wherever appropriate.
FIPA meetings may be attended by member institutions only, however, organization who have submitted proposals but are not FIPA members will be allowed and invited to attend the January 1999 meeting for the purpose of introducing their proposals.
FIPA is an open organization and expressly encourages any entity to become a member. Inquiries on membership should be directed to the address given in Chapter 5.
The new FIPA homepage
includes further details about FIPA, including the FIPA process, governing statutes and the application for membership.
While FIPA plans to have a series of Calls for Proposals concerning different aspects of agent technology, there is currently no plan to have a further call on the specific subject of this document. Therefore, proponents should ensure that their contributions are submitted during this opportunity and comply with the deadlines specified. However, FIPA recognizes the evolution of technology and plans to issue further Calls for Proposals in order to:
An outline of the FIPA '99 specifications, based on the submissions received, will be produced at the12th meeting in January 1999. First and second drafts will be produced at the following two meetings, and a final specification approved and issued at the 15th meeting in October 1999. While FIPA intends to work by consensus, this very aggressive schedule may require the use of membership voting. It is possible that the 1999 output will be output in two separate phases, one affecting the informative application-specific specifications and the other affecting the normative technological specifications.
2. Structure of this Call for Proposals
Unlike other bodies which issue specifications targeted to specific applications, FIPA only uses applications for the purpose of identifying requirements for component technologies ("tools" in FIPA language) that are needed to implement the applications. This approach makes it possible to use standardized tools for building applications serving different needs with a high degree of interoperability. This point must be borne in mind to understand the structure of the document.
Chapter 3 provides the background to this call. FIPA has recently completed its second set of specifications and most of the items of this call arise from the work that has been carried out so far in FIPA.
Chapter 4 contains the list of component technologies that are the target of this call. This has been produced based on experience gained so far within FIPA, and considerations of future needs.
Chapter 5 presents the guideline for responding to this call.
3. Background to the Third Call
The two FIPA specifications of October 1997 and October 1998 form the starting point for this call. This chapter gives the summary of the FIPA Specifications and the scope beyond it. The full document of the FIPA specifications can be obtained from the FIPA home page: http://www.fipa.org
3.1 Summary of the FIPA Specifications
The FIPA specification is the main output of FIPA. It is again important to appreciate that these specifications do not provide means to address the requirements for all kinds of software agents. They satisfy the requirements for the four applications targetted by FIPA so far. These applications appear in parts 4, 5, 6, and 7 of the FIPA 97 specifications. Work has started in 1998 on a fifth application concerning manufacturing, this specification is expected to appear early 1999.
Furthermore, FIPA does not define a software agent. What FIPA members understand by a software agent is implicit in how they intend to use them as is described in the specifications of these five applications. However, FIPA expects that what will fit the needs of these five applications will also extend to agents to be deployed in other applications; and, that these provide the specifications of basic agent technologies that can be integrated by agent systems developers to make their own complex systems with a high degree of interoperability.
FIPA specifies the interfaces of the different components in the environment with which an agent can interact, i.e. humans, other agents, non-agent software and the physical world. FIPA produces two kinds of specification:
The current set of specifications has twelve parts:
Overall, these seven FIPA technologies allow:
In October 1997, FIPA released its first set of specifications, called FIPA 97, Version 1.0. During 1998, comments on this specification were received. Based upon these comments, parts of FIPA 97 were superseded by a second version released in October 1998, introducing minor changes only.
Furthermore, in October 1998 FIPA released a new set of specifications, called FIPA 98, version 1.0, of which this document is a part.
The following tables provide an overview of the complete set of FIPA specifications.
Sorted by part:
|Released October 1997||Released October 1998|
|Part||FIPA 97 Version 1.0||FIPA 97 Version 2.0||FIPA 98 Version 1.0|
|1||N||Agent Management||Agent Management||Agent Management Extensions|
|3||N||Agent Software Integration|
|4||I||Personal Travel Assistant|
|6||I||Audio Visual Entertainment & Broadcasting|
|7||I||Network Management & Provision|
|10||N||Agent Security Management|
|11||N||Agent Management Support for Mobility|
N == normative; I == informative; M == methodology; Italicised == superseded
Sorted by topic:
|Topic||FIPA 97(Version 1.0, unless otherwise indicated)||FIPA 98 Version 1,0|
|Agent Management||1. Basic System (Version 2.0)||1. Extension to Basic System|
|10. Agent Security Management|
|11. Agent Management Support for Mobility|
||2. Agent Communication
|8. Human-Agent Interaction|
|12. Ontology Service|
|Agent S/W Integration
||3. Agent Software
|Reference Applications||4. Personal Travel Assistant|
|5. Personal Assistant|
|7. Network Management &
The parts of the FIPA 97 and 98 specifications are briefly described below.
Part 1 - Agent Management
This part provides a normative framework within which FIPA compliant agents can exist, operate and be managed. It defines an agent platform reference model containing such capabilities as white and yellow pages, message routing and life-cycle management. True to the FIPA approach, these capabilities are themselves intelligent agents using formally sound communicative acts based on special message sets. An appropriate ontology and content language allows agents to discover each others capabilities.
Part 2 - Agent Communication Language
The FIPA Agent Communication Language (ACL) is based on speech act theory: messages are actions, or communicative acts, as they are intended to perform some action by virtue of being sent. The specification consists of a set of message types and the description of their pragmatics, that is the effects on the mental attitudes of the sender and receiver agents. Every communicative act is described with both a narrative form and a formal semantics based on modal logic. The specification includes guidance to users who are already familiar with KQML in order to facilitate migration to the FIPA ACL. The specification also provides the normative description of a set of high-level interaction protocols, including requesting an action, contract net and several kinds of auctions etc.
Part 3 - Agent/Software Integration
This part applies to any other non-agentised software with which agents need to "connect". Such software includes legacy software, conventional database systems, middleware for all manners of interaction including hardware drivers. Because in most significant applications, non-agentised software may dominate software agents, part 3 provides important normative statements. It suggests ways by which Agents may connect to software via "wrappers" including specifications of the wrapper ontology and the software dynamic registration mechanism. For this purpose, an Agent Resource Broker (ARB) service is defined which allows advertisement of non-agent services in the agent domain and management of their use by other agents, such as negotiation of parameters (e.g. cost and priority), authentication and permission.
Part 4 - Personal Travel Assistance
This part demonstrates the use of agent technology in supporting individualised, automated access to travel services by providing informative specifications and examples based on the FIPA normative specifications. Travel services are provided by a heterogeneous range of content providers, brokers, and personalization services. Agents operating on behalf of their users can provide assistance in the pre-trip planning phase, as well as during the on-trip execution phase. A Personal Travel Assistance (PTA) system is composed of agents representing the user, available travel services and brokerage services between the two. The system is responsible for the configuration and delivery - at the right time, cost, Quality of Service, and appropriate security and privacy measures - of trip planning and guidance services.
Part 5 - Personal Assistant
The Personal Assistant (PA) represents a central class of intelligent agents which acts semi-autonomously for and on behalf of a user, modelling the interests of the user and providing services to the user or other people and PAs as and when required. This part provides a specification for managing a user's personal meeting schedule, in particular in determining time and place arrangements for meetings with several participants.
Part 6 - Audio/Video Entertainment & Broadcasting
This part promotes the use of agent technology for effectively negotiating, filtering, and retrieving audio-visual information, in particular for digital broadcasting networks, via collaboration between user agents with content/service provider agents. This allows considering the users personal preferences, providing the information in a customized manner, and for keeping the human interaction with the system as simple and intuitive as possible.
Part 7 - Network management & provisioning
Across the world, numerous service providers emerge that combine service elements from different network providers in order to provide a single service to the end customer. The ultimate goal of all parties involved is to find the best deals available in terms of Quality of Service and cost. This part utilizes agent technology to provide dynamic Virtual Private Network (VPN) services where a user wants to set up a multi-media connection with several other users. Agents representing the interests of human users, service providers and network providers facilitate automatic negotiation of appropriate deals and configuration of services at different levels.
Part 8 Human-Agent Interaction
This part deals with the human-agent interaction part of an agent system. It specifies two agent services: User Dialog Management Service (UDMS) and User Personalization Service (UPS). A UDMS wraps many types of software components for user interfaces allowing for ACL level of interaction between agents and human users. A UPS can maintain user models and supports their construction by either accepting explicit information about the user or by learning from observations of user behavior.
Part 10 Agent Security Management
Security risks exist throughout agent management: during registration, agent-agent interaction, agent configuration, agent-agent platform interaction, user-agent interaction and agent mobility. The Security Management specification identifies the key security threats in agent management and specifies facilities for securing agent-agent communication via the FIPA agent platform. This specification represents the minimal set of technologies required and is complementary to the existing FIPA 97 and FIPA 98, Part 1 specifications. This part does not mandate every FIPA-compliant agent platform to support agent security management.
Part 11 Agent Management Support for Mobility
This specification represents a normative framework for supporting software agent mobility using the FIPA agent platform. This framework represents the minimal set of technologies required and is complementary to the existing FIPA 97 and FIPA 98, Part 1 specifications. Wherever possible, it refers to existing standards in this area. The framework supports additional non-mobile agent management operations such as agent configuration. The specification does not mandate that every FIPA-compliant agent platform must support agent mobility, nor does it cover the specific requirements for agents on mobile devices with intermittent connectivity, which is covered by the scope of the existing FIPA Agent Management activity.
Part 12 Ontology Service
This part deals with technologies enabling agents to manage explicit, declaratively represented ontologies. It specifies an ontology service provided to a community of agents by a dedicated Ontology Agent. It allows for discovering public ontologies in order to access and maintain them; translating expressions between different ontologies and/or different content languages; responding to queries for relationships between terms or between ontologies; and, facilitating identification of a shared ontology for communication between two agents.
The specification deals only with the communicative interface to such a service while internal implementation and capabilities are left to developers. The interaction protocols, communicative acts and, in general, the vocabulary that agents must adopt when using this service are defined. The specification does not mandate the storage format of ontologies, but only the way the ontology service is accessed. However, in order to specify the service, an explicit representation formalism, or meta-ontology, has been specified allowing communication of knowledge between agents.
Part 13 FIPA 97 Developer's Guide
The Developers Guide is meant to be a companion document to the FIPA 97 specifications, and is intended to clarify areas of specific interest and potential confusion. Such areas include issues that span more than one of the normative parts of FIPA 97.
3.2 Beyond the FIPA 97 and 98 Specifications
The specifications produced in 1997 have been undergoing field trials during 1998 and the experience gained from this work has had an important influence both on the revisions that have been produced in 1998 as well as in the production of this call. In other words, the items in this call are based to a good extent after having subjected the FIPA 97 to close scrutiny. Thus, these revisions, deletions, clarifications and extensions are the consequence of the experience being gained.
In particular, the call below is concerned with extensions to be made to the standards produced so far. As interest in FIPA has grown in recent months, so has the desire of both members and non-members to see a range of new items to be included into the FIPA specifications. Many of the items described are of critical significance to the further enhancements to the consensus beginning to appear as a result of FIPAs activities. It may not be possible to cover all these items in a single year, and FIPA will need to exercise a judgement on what will actually be targetted given the human resources available within FIPA.
4. Technologies requested by this Call for Proposals
This chapter presents the essence of this Call. The following sections describe the areas of technology and applications proposed for specification in 1999.
Any examples and reference solutions given in this chapter are for clarification. FIPA neither requires nor endorses them for use in this call for proposals.
This call is for two distinct types of input. New areas of applications for agent technology which will be strictly informative and serve the purpose of illustrating and testing the agent functionalities being developed by FIPA; and, additional technological specifications which will be normative and constitute a consensus on how agent based systems may be implemented.
The following provides the call for new application areas to be developed in the FIPA 99 effort.
4.2.1 Integrated Commerce
Electronic commerce is a major application domain especially for the future exploitation of the Internet. It is also not currently directly addressed by any of FIPA 97 Technical Committees (although it was included in the Third Call for Proposals in 1997). Yet electronic commerce appears to be ideally suited for multi-agent and intelligent agent technologies.
Integrated commerce refers to the complete integration of a commercial processfrom on-line integrated catalogues to delivery monitoring. Such a concept would facilitate interoperability between organisations on a commercial level through the medium of agents. Of special interest is the possibility of integration between multiple organisations, where information and processing is being shared in a controlled fashion.
Responses to this call should specify how agents can be used in an integrated commerce environment. We expect that a specification would address matters such as:
4.2.2 Communication Assistant
This component of the call for proposals focuses on the theme of providing efficient and effective assistance for human communication. This application area recognizes the pervasive nature of communication, the expanding availability of intelligent telephones and communicators, and the growth in the telecommunications infrastructure.
Modern communication inherently involves a combination of modalities, such as voice, images, and video. A useful assistant would help a user manage those modalities and make the overall process smooth and coherent over a range of telecommunications infrastructure. In particular, it will have a special sensitivity to the issues of mobile telephony, especially low bandwidth, unreliability, and a potentially varying quality of service.
Proposals submitted in response to this call should consider agents applied as communication assistants. Agents can help reconcile the concerns of wireless connectivity with the increasing demands of end-user communicaitons. The following is a representative, but not exclusive, list of topics.
4.2.3 Real-time applications
Real time systems with high performance requirements are presently a challenge for all kinds of technologies. The characterisation and objectives/requirements of these systems is highly application dependent, but they may have in common one or more critical issues:
These systems may benefit from agent-based technologies, mainly due to its high degree of adaptability, reactivity, autonomy and intelligence. When using agent-based technologies additional issues have to be integrated. This call for proposals solicits technologies and solutions for agent distributed real-time applications, including but not limited to:
A set of possible applications that may take advantage of agent-based technology is (non-exhaustive):
Surveillance Systems - Today, more than ever, there is a need for effective systems that help humans in video surveillance and/or monitoring tasks. You can have lots of cameras along the main roads of a city (e.g. traffic surveillance) or in a number of critical points of your bank (e.g. security), but normally you do not have enough people to look, analyse, correlate and interpret this enormous quantity of images. Intelligent and cooperative agents for high level scene semantic interpretation for Audio/Video Objects characterisation, behaving, and tracking between cameras are only an example of a vast field of intelligent distributed problem solving activities for multimedia high level descriptions and reasoning. For instance, the surveillance can also take place via other methods than a camera (e.g. counting loops imbedded into the road), that also need high level interpretation. Here, a close relation between FIPA ongoing standardisations and other standardisation bodies such as MPEG7 may be a critical issue.
Network Management - Agent technology offers the opportunity both to deliver intelligence to the end-user and to organise intelligence in the network itself. Given that reactivity and proactivity are characteristics of multi-agent systems, the adoption of an agent based approach may offer a timely solution to a large set of problems, such as efficient load control strategies using active (intelligent) networks or distributed networked systems sharing CPU resources. In this context, proposed technologies should address the objectives and requirements towards the enhancement of the performance and management of complex distributed telecommunications network environments using agent-based systems.
Manufacturing Processing and Monitoring - Clearly, real time manufacturing control systems may take advantage of agent-based reactive systems. A number of agent-based architectures have in common a high degree of reactivity and adaptive conditions. The systems may be able to grow or adapt to new environmental conditions without direct reprogramming. Some useful and highly reactive architectures in manufacturing processing may be enumerated:
Multimodal Real Time Interfaces - While computers are becoming more powerful, current interaction devices, such as keyboards, mice and windows, still limit human-computer interaction. Research in virtual reality and immersive environments brings support to a broad expansion of interaction techniques. Users will be able to interact with their "computers" using touch, gestures, voice and 3D sound and video - separately or in any combination. If applications become multimodal at a high (abstract) level, they could exploit alternative or complementary sensory modalities as individual user needs and preferences, working environments, etc.
On line translation
Remote Cooperative Work
An e-mail reflector for discussing the requirements and critical issues in agent-based RT systems will be available at firstname.lastname@example.org.
4.3 Normative Specifications
A number of technological issues have been identified as a target for FIPA 99 consideration. This part of the Call for Proposals requests submissions for these issues to be adopted by FIPA 99 on a normative basis.
4.3.1 Agent Naming
FIPA requests proposals for agent naming schemes and associated services. Examples of desirable attributes include the following:
It is desirable that the naming scheme and associated services be consistent with emerging Internet standards such as LDAP.
The FIPA ACL was specified in the FIPA 97 Specification Part 2, whose first version was published in October 1997. A second version of the specification correcting typographical and other minor errors and improving the presentation was published in October 1998. During the last year, experience has been gained in implementing and using FIPA ACL for concrete applications. To this end, field trials have also been conducted.
It is expected that FIPA 99 will return its attention to FIPA ACL, drawing upon this experience and newly-recognised technologies to extend and improve FIPA ACL. This section outlines the specific topics of interest.
Responses should clearly outline the application-driven requirements for the proposed solutions. In particular, FIPA 99's charter includes consolidating previous experience. At the January 1999 meeting, the issues addressed by the responses will be prioritised and selected for further FIPA 99 development.
1 There may be a need to extend the current set of communicative acts (CAs) along the following lines:
Proposals should provide the reasons for the new CAs, and the semantics of the acts (either informally in English, as a composition of existing CAs or, formally in SL or other semantic specification language).
2 Classify, or develop an ontology of, performatives.
3 Define the framework for the fail, refuse and not-understood CAs more precisely. In particular, the reason parameters of these CAs are currently loosely specified.
4 Improve the FIPA 97 ACL semantics by extending or altering it, or suggesting completely new semantics. The reasons for doing so should be clearly identified. Potential reasons include
Proposals for new semantics may impose additional requirements, remove some existing requirements, or introduce additional concepts such as commitments.
5 Develop different kinds of syntax or lexical conventions for ACL messages to suit a wider range of applications than at present. Likely topics include XML, RDF, bit-efficient representations (e.g., to support wireless communications)
Proposals related to interaction protocols should also demonstrate the value of the proposed approach in applications, especially the applications being considered actively by FIPA.
4.3.3 Content Language
FIPA 97 Part 2, Agent Communication Language, defines the SL content language and its profiles in an informative annex. Some other parts of FIPA specification mandate the use of profiles of SL. The intention is that FIPA does not compel users to adopt the single content language, but a specific content language must be used for a specific task such as agent management or non-agent software integration. In other cases, choice of the content language depends on the application and communicating agents must make sure that they share the same content language and ontology.
Is this policy still acceptable? Do we need to specify a standard content language (or set of languages)? Like classic KQML had interoperability problems among different implementations, there is no compatibility between arbitrary subsets or supersets of KIF, for example. Even if the agents specify the same identifier in the :language slot, no guarantee is made that they actually speak the same language. Problems of this kind are quickly emerging as standard ACL and Ontology Service are used in the real applications. Proposals are therefore called for the specification of the content language including the following, but not limited to:
4.3.4 Agent Management
We identify a number of areas requiring standardization in agent management in FIPA99: agent configuration, base line protocols for inter-agent platform communications and agent security.
Proposals pertaining to agent management should consider emerging software technology, specifically active directories initiatives and frameworks, JINI, JAVA-based mediation/matchmaking framework for services, CORBA, Directory Enabled Networks, Microsoft DNA, and active networks.
18.104.22.168 Agent configuration
Agent configuration is a critical aspect of managing large agent systems, especially when this involves large numbers of agents distributed over many computers. We identify a number of issues that are related to agent configuration, and we also identify the scope and role of FIPA standardisation of agent configuration:
It is not the purpose of FIPA to provide standards for agent configuration, since the particular requirements for agent configuration will vary between applications. However, where FIPA standardisation does have a role is in specifying standard methods that would allow agents to be configured by a FIPA-compliant agent configuration system.
That is, rather than providing standard agent configurators or even agent configuration services, FIPA provides standard hooks that 3rd party agent configurators may use to allow agents to be configured and managed.
Use cases for agent configuration including example agent life cycles for particular scenarios.
22.214.171.124 Base model for agent management
Proposals are expected for the development of a base model, which describes the main concepts present in the FIPA Agent Management specifications. It is envisaged that such a base model may result in a more flexible and powerful way of extending future FIPA specifications and also allow for validation of FIPA messages and agent management related content against this model. For example, the model could state that both receiver and sender of a message are agents, agents can support one or more languages, can understand one or more ontologies, can send a message, and a message can only use one language and one ontology, agents can have addresses, types, maybe homepages etc. The level of detail considered for such a model may vary from defining the very basic concepts such as agents and messages towards more detailed ones, covering existing concepts in agent management ontology, mobility and security.
Proposals for such a base model may decouple this agent management model itself from possible syntactical representations (i.e. the serialization of the model). The latter has the advantage to allow the use of alternative languages to encode instances following those base concepts. Possible solutions for expressing the base model may use techniques such as for example entity-relationship based models, semantic networks, conceptual graphs, RDF Schemas, UML, etc. (including both visualization and possible syntax descriptions).
126.96.36.199 Base line protocol for interagent platform communication
The FIPA 97 and FIPA 98 specifications have both mandated that there should be a communication protocol which each Agent Communication Channel (ACC) should support to facilitate inter-operability between agents on different Agent Platforms (APs). In FIPA 97, this communication protocol was defined to be CORBAs Internet Inter-Orb Protocol (IIOP). However, during the development of the FIPA 98 specification, a number of issues surrounding FIPAs choice of IIOP and the description of its use within the FIPA 97 specification were raised. Therefore, the FIPA 98 specification introduced the notion of a baseline protocol which all ACCs should support (at the least) for the purpose of promoting interoperability amongst heterogeneous agents.
However, the FIPA 98 specification only identifies a set of characteristics and requirements that such a baseline protocol should possess; it did not describe how these features and requirements reflect upon the either the FIPA 97 or FIPA 98 specifications. The purpose of this CFP is to decide how inter-agent communication within FIPA is to be handled, in terms of requirements, functionality and readily available protocols and how this will impinge upon the FIPA specifications.
FIPA does not mandate how communication occurs between agents on the same AP; agents on different APs must communicate (initially, at least) through their respective ACCs either to exchange information or to negotiate a new communication protocol. These are the essential functions of the baseline protocol.
FIPA 98 provides specification to permit mobile agents and intermittently connected devices, however, it is apparent that a number of additional basic technologies are required over those envisaged. Briefly, these can be summarized as:
The FIPA 98 specification outlined a number of requirements (FIPA 98 Part 1) that a baseline protocol should possess (which will form the basis of this proposal):
188.8.131.52 Agent security management
4.3.5 Human Agent Interaction
In FIPA 98 part 8, agent services were defined that are supposed to support the Human-Agent Interaction process. During the development of this specifications, several issues were detected that are considered important but could not resolved within the FIPA 98 time frame. Proposals covering these issues are invited.
FIPA98 part 8 does not make any assumption about structure and possible contents of user models. Instead, the existance of user model types is assumed, which specify all relevant properties of user models. However, means for defining these types, referring to or extending existing type definitions are not specified. We encourage proposals dealing with this problem, perhaps utilizing FIPA98 ontology mechanisms.
Mechanisms for controlling access to user models are provided by FIPA98 part 8. However, these are fairly primitive and do not support sophisticated negotiation of access conditions. Hence, proposals dealing with privacy of user models are requested.
FIPA 98 part 8 assumes that userIDs exist in the agent world. This may not be the case in all scenarios. It should be possible to identify the user by other means like names, email addresses, etc. In particular, user dialog management processes need to find users without having user IDs available. A mechanism for registering users in the agent world might be helpful. We encourage the proposal of solutions to user identification and detection problems.
In FIPA98, the important requirement for well distributed selection sets was introduced. However, the optimal process and control of this functionality needs much more exploration and definition. In FIPA99, we would like to take the perspectives of information theory on one hand and decision making on the other to help us find principles that would create the selection of scope. There are at least four primary extensions:
We expect that specification of controlling scope (such as orthogonality of options), will have different approaches because of different application needs. Proposals should include both an informative part, addressing such application issues and general principles, as well as the engineering specification of the interface itself.
From the learning perspective, the agent wants to maximize recommendation quality while at the same time minimize uncertainty. Asking users for direct information to achieve both of these goals can help the agent have a much faster learning curve. Simply observing behavior might not always be efficient, and can be facilitated by asking probing questions. Asking questions might be particularly informative in situations where there is an expectancy mismatch or very rare behaviors. We expect proposals to also address the cautions required in asking questions of the user:
As well, there are a number of other integration possibilities, such as including issues of trust. We encourage proposals to address levels of autonomy between agents and users, a particularly important issue with a learning service.
This part addresses further issues of an informative basis, which help in designing FIPA-compliant systems.
Software engineering aspects of agent technology. Extension/modification of UML to handle agents or even introduction of new UML-like framework, in case UML is inappropriate. This will provide significant value for increasing industrial acceptance of agent technology as a software engineering paradigm.
There is need for a formal procedure for introducing new CAs. Justifications for introducing new CAs include application requirements and lack of derivability, and potential use for reification. Specific suggestions for managing this process will be considered.
4.4.2 Content Languages
FIPA does not mandate the usage of one particular content language, but instead allows applications to choose an appropriate one. However, in practice some content languages (such as SL0, KIF) are more obvious to be chosen as they are closer to the current FIPA specifications. When choosing less traditional content languages, such as for example RDF, OML/CKML, XML, one may need to enhance or to constrain (possibly even modify) those languages in order to better fulfill the requirements of a FIPA content language, i.e. being able to express actions, statements, objects, or concepts.
As an example, a proposal about RDF could specify how to encode actions in FIPA content (enhancement to RDF Schema), or which syntax model to choose (abbreviated or basic). As usual in an informative specification, as soon as a particular content language has been chosen, these proposals specify how it should be used as content language within a FIPA message.
4.4.3 Agents on the Web
Proposals in this area may show how FIPA agent technology can be combined with common Web practice.
Indeed, the Web is definitely the place to be for making real business of agent technology. However, up to now, there has been little usage of Web technologies in the FIPA community and both worlds are quite separated.
Some examples of problems which may be solved are:
Proposals may recommend the usage (or translation into) alternative syntaxes for both the ACL and content languages such as RDF, OML or XML in order to answer the above questions.
4.4.4 Reference Libraries
Proposals may suggest libraries of interaction protocols and other software aiding in agent-related development.
5. Guidelines for submission
Those intending to submit a proposal(s) should take note of the following important information.
1 Notify their intention to submit a proposal on or before 31 December 1998 to:
|FIPA Secretariat||Tel: +39 011 7720 294|
|Attn: Ms. Terese Marsico||Fax: +39 011 725679|
|c/o SIA Societa' Italiana Avionica Spa||E-mail: email@example.com|
|C.P. 3176 - Str. Antica di Collegno, 253|
2 Submit their proposal in electronic form, MS Word (V6.0x or above) or HTML (the latter is preferred) by 10 January 1999 to the above address.
3 Attend the meeting on 25-29 January 1999 in Seoul, South Korea. Additionally, proponents should be prepared to briefly (15 minutes) present their proposal in the event it is requested.
In the submission the proponent should
Proponents should be aware that all material presented to FIPA shall be deemed of a non-confidential nature and hence will be made available to FIPA members and participants in the January 99 meeting. Proposals received will be made available on the FIPA web site for consultation by FIPA members. The titles and abstracts (if supplied) of the proposals will be made publicly available.