FOUNDATION FOR INTELLIGENT
PHYSICAL AGENTS
FIPA Audio-Visual Entertainment
and Broadcasting Specification
Document title |
FIPA Audio-Visual Entertainment and Broadcasting Specification |
||
Document number |
PC00081 |
Document source |
FIPA Architecture Board |
Document status |
Preliminary |
Date of this status |
2000/06/27 |
Supersedes |
OC00015 |
||
Contact |
fab@fipa.org |
||
Change history |
|||
2000/06/27 |
Carried forward from FIPA 1997 Specification 6 V1.0 |
İ 2000 Foundation for Intelligent Physical Agents - http://www.fipa.org/
Geneva, Switzerland
Notice |
Use of the technologies described in this specification may infringe
patents, copyrights or other intellectual property rights of FIPA Members and
non-members. Nothing in this specification should be construed as granting
permission to use any of the technologies described. Anyone planning to make
use of technology covered by the intellectual property rights of others
should first obtain permission from the holder(s) of the rights. FIPA
strongly encourages anyone implementing
any part of this specification to determine first whether part(s)
sought to be implemented are covered by the intellectual property of others,
and, if so, to obtain appropriate licenses or other permission from the
holder(s) of such intellectual property prior to implementation. This
specification is subject to change without notice. Neither FIPA nor any of
its Members accept any responsibility whatsoever for damages or liability,
direct or consequential, which may result from the use of this specification. |
Foreword
The Foundation for Intelligent
Physical Agents (FIPA) is an international organization that is dedicated to
promoting the industry of intelligent agents by openly developing
specifications supporting interoperability among agents and agent-based
applications. This occurs through open collaboration among its member
organizations, which are companies and universities that are active in the
field of agents. FIPA makes the results of its activities available to all
interested parties and intends to contribute its results to the appropriate
formal standards bodies.
The members of FIPA are individually
and collectively committed to open competition in the development of
agent-based applications, services and equipment. Membership in FIPA is open to
any corporation and individual firm, partnership, governmental body or
international organization without restriction. In particular, members are not
bound to implement or use specific agent-based standards, recommendations and
FIPA specifications by virtue of their participation in FIPA.
The FIPA specifications are
developed through direct involvement of the FIPA membership. The status of a
specification can be either Preliminary, Experimental, Standard, Deprecated or
Obsolete. More detail about the
process of specification may be found in the FIPA Procedures for Technical
Work. A complete overview of the FIPA specifications and their current status
may be found in the FIPA List of Specifications. A list of terms and
abbreviations used in the FIPA specifications may be found in the FIPA
Glossary.
FIPA is a non-profit association
registered in Geneva, Switzerland. As of January 2000, the 56 members of FIPA
represented 17 countries worldwide.
Further information about FIPA as an organization, membership information, FIPA
specifications and upcoming meetings may be found at http://www.fipa.org/.
Contents
2.4.1 Detailed Functions
of Agents
3 Audio-Visual Entertainment and Broadcasting Ontology
3.1.5 Audio-Visual
Object Description
Today more than ever, there is a perceived need for an effective means of information filtering and retrieval, in particular for digital broadcasting networks. The selection and storage of a viewer's personal preferences from the plenty of programmes on offer can be very impractical; such information has to be provided in a customized manner, to better suit the users personal preferences. In order to implement information filtering and retrieval, the semantic and syntactic content of the broadcast data streams need to be made compatible to allow a consistent method for selection. It is crucial that human interaction with such a system is as simple and intuitive as possible. Key functionalities such as profiling, filtering, retrieving and interfacing can be made more effective and reliable by introducing agent technology.
Foreseeable applications in this field are: TV, radio and data broadcasting, electronic newspapers, commercial database services, Internet services, computer aided education, video- and multimedia-on-demand services, entertainment, home automation, etc.
This specification describes the assessment of FIPA specifications against a prototypical Audio-Video Broadcasting and Entertainment application. The identified necessity for this application is as follows:
The reference model for the Audio-Visual Entertainment and Broadcasting (AVEB) application is given in Figure 1. The application being considered is a simplified one: a digital TV set equipped with a tuner and connected to a Digital Storage Media (DSM) is installed in a one-family house. Through the system, the members of the family can access a variety of AV services such as TV broadcast (Type 1) and video-on-demand server (Type 2), expressing their own preferences and making suitable selections.
Figure 1: Reference Model for the AVEB Application
Given this simple set-up, only one User Profile Agent (UPA) maintains information about all the users and only one Control Agent (CA) manages the interaction with the broadcast services. Each user has their personal Interface Agent (IA) and for each home system a user domain is established which collects all agents and wrappers that are needed. Information pertaining to the profile of users can be exchanged among different home systems to get better recommendations from similar preferences through another user group domain).
Type 1 and Type 2 content providers maintain content descriptions about available Type 1 and Type 2 streams. A Guide Agent (GA) watches these descriptions and informs the CA of the required AV services and it also notifies the new services and/or the modification to CA automatically.
1. That there exist content description providers for all contents,
2. That the AV streams are transmitted through non-Message Transport System (MTS) channels,
3. That there is some mechanism to login and logout the home system,
4. That no user may move to another Home System, and,
5. That the storage limits of the DSM and charging for programs are not considered.
The following key functionalities are identified as necessary for the application:
1. Building and maintaining the profile of users,
2. Filtering the incoming AV programs according to users profile information,
3. Autonomously querying and replying,
4. Controlling hardware (for example, DSM),
5. Being able to recognize/identify the user(s),
6. Being able to interact with the users in a multi-modal fashion,
7. Discovering users with similar preferences (inside and outside the user domain) and sharing recommendations among them,
8. Protecting the home system from misuse and abuse,
9. Featuring different classes of time-constrained behaviour, and,
Negotiating queries and quality of service should be considered in the future version of the specification.
With respect to Figure 1, four types of agents have been identified with the AVEB application:
·
Interface Agent (IA)
This agent interacts directly with user via natural language dialogue, browser and other modalities, interprets the users requests into ACL and presents information to the user in a user-friendly manner.
·
User Profile Agent (UPA)
This agent maintains the users profile, provides information on users preferences (with content regulation) for filtering and retrieval functions and exchanges the preferences within user group domain.
·
Control Agent (CA)
This agent promotes interaction with other agents to accomplish a given goal including getting user's interaction through the IA, consulting user's preference with the UPA and collaborating with the GA to search content matching the user's preference and it controls hardware devices through wrapper agents.
·
Guide Agent (GA)
This agent maintains a list of AV programs, advertises its contents and answer queries from the control agent. It also collaborates with the CA for filtering the content list for the purpose of presenting to the user in a user-friendly and customised way.
Additionally, three types of wrapper agents have been identified:
·
Digital Storage Media Wrapper
(DSMW)
This agent interfaces with a DSM.
·
Tuner Wrapper (TW)
This agent interfaces with a tuner which controls Type 1 streams.
·
VOD Controller Wrapper (VCW)
This agent interfaces with the video-on-demand controller which controls Type 2 streams.
Table 1 describes the domains that exist within the AVEB application and the agents that register with them. A UPA must register with a DF in a user domain in order to communicate with IAs and CAs. It must also register with a DF in a user group domain in order to communicate with other UPAs.
Domain |
Description |
Registered Agent |
Wrapper Agent |
User Domain |
These domains present AV programmes to users. Agents in this domain cooperate to retrieve and filter AV programmes by user request or preference using the index data attached to the programmes. |
CA UPA IA |
TW DSMW VCW |
User Group Domain |
These domains allow groups of users to share information and preferences about programmes |
UPA |
|
Content Provider Domain |
These domains provide the content descriptions of AV streams from all content providers. |
Type 1 GA Type 2 GA |
|
Table 1: Agent Registrations in Domains
· Translates the user request into ACL, for example, template-based natural language, search engine-like Boolean logic plus keywords, menu-based composition, etc.
· Passes user requests to the CA and receives answers from the CA.
· Passes user requests to the UPA and receives answers from the UPA.
· Translates ACL into the user language.
· Displays recommendations autonomously retrieved by the CA.
· Receives user preferred interaction modalities from the user and changes the mode accordingly.
· Senses the presence of user (for example, initiating dialogue with the user when they move the mouse).
· Logs the user into and out of the system.
· Contacts GAs to locate specific programmes.
· Contacts GAs to acquire unspecific programme listings.
· Receives user request from the IA.
· Requests information about user characteristics from the UPA.
· Receives user characteristics information from the UPA.
· Presents to the IA the selection of available programmes.
· Formulates appropriate queries to the UPA and the GA.
· Engages in a collaborative dialogue with the GA for the purpose of refining the list of programmes.
· Controls the DSM via the DSMW so that the DSM can have access to the content.
· Controls what is played on the tuner by relaying commands through the TW.
· Receives user request in ACL form from the IA and analyses it to update the user profile.
· Sends information regarding the preferred method of presentation or interaction of the user based on the user profile to the IA.
· Receives requests from the CA and returns the proper information about users preferences. The UPA does not give the entire profile, but gives user-related answers in collaborative and cooperating manner.
· Manages the user profile database.
· Requests other UPAs to inform it about other users' characteristics.
· Receives request from other UPAs about user characteristics (and returns them).
· Gets requests from the CA and returns the desired contents list.
· Controls and monitors the creation and update of the content index.
· It engages in a collaborative dialogue with the CA for further restricting and refining the content index.
The
interaction between these two agents is aimed at exchanging information
relevant for user profiling.
1.
The
IA informs the UPA when a user logs in, for example, John logs in:
<IA, inform (UPA, login (John))>
2.
The
IA informs the UPA of users selections and preferences, for example, John
selects the program, Indiana Jones and the Temple of Doom:
<IA, inform(UPA, select (John,
Indiana-Jones-and-the-Temple-of-Doom))>
John scores Indiana Jones and the Temple of Doom with 0.4:
<IA, inform(UPA, prefer (John,
Indiana-Jones-and-the-Temple-of-Doom, 0.4))>
And, John likes sport programmes with preference score of at least 0.4:
<IA, inform(UPA, forall ?prg (genre
(?prg) = Sport => prefer (John, ?prg, 0.4))>
3.
The
UPA informs the IA of user's preferred interaction modalities, for example,
John likes the keyboard with a preference score of 1:
<IA, query-ref (UPA, iota ?x (modality
(?x) and prefer (John, ?x, 1))>
<UPA, inform (IA, iota ?x (modality (?x)
and prefer (John, ?x, 1)) = Keyboard)>
4.
The
IA informs the UPA that the user has logged out, for example, John logs out:
<IA, disconfirm (UPA, login (John))>
The
interaction between these two agents is aimed at sharing user profile
information across different home systems.
1.
UPA1
requests whether UPA2 can make accessible a specific piece of information, P, concerning the profile of the
users it serves[1]:
<UPA1, query-if (UPA2, available (P,
UPA1))>
2.
UPA2
informs UPA1 about the accessibility of P[2]:
<UPA2, inform (UPA1, available (P,
UPA1))>
3.
When
accessibility of P is agreed
upon, UPA1 requests it.
4.
UPA2
sends P to UPA1.
The
interaction of these two agents is aimed at informing the CA about the user's
characteristics.
1.
The
CA requests information from the UPA about the characteristics of users, for
example, Johns date of birth and occupation:
<CA, query-ref (UPA, iota ?x birthdate (John) = ?x);
query-ref (UPA, iota ?x occupation
(John) = ?x)>
2.
The
UPA sends requested information to CA (if available and accessible using the
same scheme as in points 2 to 4 in section 2.4.2.3, User
Profile Agent to Control Agent).
The
interaction between these two agents is aimed at delivering to the CA the
requests of the users.
1.
The
IA informs the CA whenever the users log in and log out, for example, John
logging in:
<IA, inform (CA, login (John))>
2.
The
IA informs the CA what are the current requests of the user, for example, John wants to watch Indiana Jones and the
Temple of Doom:
<IA, inform(CA, like-to-watch (John,
Indiana-Jones, Now)>
3.
The
CA sends to the IA the information about available programmes (as collected
from the content providers domains and the local DSM), for example, Indiana Jones and the
Temple of Doom
will be broadcast on TV on P1 and is stored in the video-on-demand stream V1:
<CA,
inform (IA, broadcast (Indiana-Jones, P1) and
vod
(Indiana-Jones-and-the-temple-of-doom, V1)>
The CA
controls the tuner (for Type 1 streams) and video-on-demand controller (for
Type 2 streams) through the tuner and video-on-demand wrapper agents to
initiate viewing. The TW and VCW agents translate the commands issued by an
agent into hardware-dependent commands.
1.
The
CA issues a command to the devices through the TW and VCW agents, for example,
setting tuner 1 (already on channel 3)
to switch to channel 2:
<CA, request (TW, invoke (Tuner1,
"switch to channel 2"))>
The CA
controls the DSM through the DSMW agent to record AV streams. It can possibly
control the DSM to playback the recorded contents corresponding to the users'
requests, however, this functionality is an open issue in this version of the
application.
1.
The
CA issues a command to the DSM through the DSMW agent, for example, playing
back programme P1:
<CA, request (TW, invoke (DSM1,
"playback programme p1"))>
The
interaction between these two agents is aimed at getting information about
content descriptions.
1.
The
CA requests content descriptions from the GA, for example, the genre of
programme P1:
<CA, query-ref (GA, iota ?x genre (P1) =
?x)>
2.
The
GA replies the appropriate content descriptions corresponding to the requests,
for example, the genre of P1 is sport:
<GA, inform (CA, (iota ?x genre (P1) =
?x) = Sport)>
3.
The
GA autonomously informs the CA of modifications to the content descriptions
(for example, a TV programme is postponed) and service categories (for example,
a new video-on-demand provider begins a service). For example, program P1 is delayed from 9pm until 10pm:
<GA, disconfirm (CA, start-time (P1) =
9pm);
inform (CA, start-time (P1) =10pm)>
4.
The
CA and GA collaborate for better filtering, for example, John watched Indiana Jones and the
Temple of Doom
and rated it 0.9:
<CA, inform (GA, rate (John,
Indiana-Jones-and-the-Temple-of-Doom, 0.9))>
Another example could be that average rating of Indiana Jones and the
Temple of Doom
is 0.8:
<GA, inform (CA, average-rate (Indiana-Jones-and-the-Temple-of-Doom,
0.8))>
The
interaction between this two entities allows the user to access the home system
(user recognition, authentication and log-in) and then to express their own
preferences and requests.
1.
The
user makes the home system aware of their intention to access it.
2.
The
IA requests the user prove their identity.
3.
The
IA requests the user to enter profile information.
4.
The
IA informs the user of a suggested set of programmes that are available.
5.
The
user makes selections from given (possibly displayed) material which may
contain help or guidance for the user.
The home
system offers selected programmes to a user based on their preference. In this
scenario, a member of the family logs in the system and the system retrieves
the user profile that describes their preferences, gender, age, etc. Then, it
recommends to the user a set of programmes to be viewed and when the user
selects one programme, the IA informs the UPA of their choice so that it can
appropriately update the user profile, if necessary. The IA then asks the CA to
retrieve the programme by controlling devices through the TW, VCW or DSMW
agents.
1.
In
the initial situation, the user domain is established and the UPA and CA are active while the IA is suspended. The DF knows the
agent-identifier of DFs in the content provider domain.
2.
When
a new user registers with the user domain, an IA for the user is created and
suspended and a new user profile is created by the UPA.
3.
When
a user logs in, the users IA becomes active and the IA, UPA and CA start to
communicate.
4.
When
the IA recommends to the user a set of AV programmes, the IA informs the CA
about users name, the CA asks for the users profile from the UPA, the CA
retrieves the candidate programme IDs from the GA and the CA then informs the
IA of the results. Finally, the IA asks
for the users profile from the UPA and then builds a menu and displays it for
the user.
5.
When
the IA offers a selected programme to the user, it informs the UPA of the
users choice, asks the CA to control the video-on-demand controller to receive
the Type 2 stream, control the tuner to filter the Type 1 stream as it begins
and control the DSM to store the AV stream.
6.
When
the user logs out, the system stops the service and the users IA becomes suspended.
The home
system automatically stores selected programmes for a user. The CA evaluates an
incoming content descriptions from the GA and consults the UPA; if there are
any matches with the user's preference, then the CA stores the programme into
the DSM.
1.
In
the initial situation, the user domain is established and the UPA and CA are
initially active while the IA is suspended.
2.
When
a content provider delivers a new content description or modifies it, the GA
detects the modification and informs the CA.
3.
When
the CA receives the new content description of modification notice, it asks the
UPA whether the content matches the users preferences; if it does, then the CA
makes a plan to get the content and instructs the DSM to record the content
when it starts.
In this
scenario, when the user logs in, the home system automatically makes a viewing
plan appropriate to the user by consulting their profile. The plan consists of
a series of content including those recorded in the DSM.
1.
When
the user logs in, the IA informs the CA that the user wants to make a plan. The
CA obtains the content descriptions of the recorded streams in the DSM through
DSMW agent as well as the content description from the GA. From this is
constructs a viewing plan for the user.
2.
After
the CA makes the plan, the CA controls the DSM, video-on-demand controller and
tuner through the wrapper agents according to the plan.
The
schedule of the programme which the user plans to watch may be modified due to
special news or sport events that over-run. The modification should be notified
with the CA.
1.
When
the CA makes the plan according to Scenario 3 or the user directly asks CA to
reserve programs, the CA requests the GA to notify it when the schedule of the
programme is modified. The GA registers this request and watches the content
descriptions of registered programmes.
2.
When
the GA detects a modification to a registered programme, it informs CA of the
modification. The CA checks whether the new schedule conflicts with other
programmes in the plan and determines whether to hold or cancel the programme.
The CA informs the GA of the decision, which dismisses the registration if the
programme is cancelled or continues to watch if it being held.
3.
When
the program starts, the CA controls the tuner or DSM to view or record the
program.
4.
When
the program finishes the GA discards the registration.
This section describes a set of frames, that represent the classes of objects in the domain of discourse within the framework of the FIPA-AVEB ontology.
The following terms are used to describe the objects of the domain:
· Frame. This is the mandatory name of this entity, that must be used to represent each instance of this class.
· Ontology. This is the name of the ontology, whose domain of discourse includes the parameters described in the table.
· Parameter. This is the mandatory name of a parameter of this frame.
· Description. This is a natural language description of the semantics of each parameter.
· Presence. This indicates whether each parameter is mandatory or optional.
· Type. This is the type of the values of the parameter: Integer, Word, String, URL, Term, Set or Sequence.
· Reserved Values. This is a list of FIPA-defined constants that can assume values for this parameter.
This type of object represents the description of each service registered with the DF.
Frame Ontology |
service-description FIPA-Agent-Management |
|
||
Parameter |
Description |
Presence |
Type |
Reserved Values |
name |
The name of the service. |
Mandatory |
String |
|
type |
The type of the service. |
Mandatory |
String |
fipa-ia fipa-upa fipa-ca fipa-ga fipa-tw fipa-dsmw fipa-vcw |
ontology |
A list of ontologies supported by the service. |
Optional |
Set
of String |
FIPA-Agent-Management FIPA-AVEB |
protocol |
A list of protocols supported by the service. |
Optional |
Set
of String |
|
properties |
A list of properties that discriminate the service. |
Optional |
Set
of property |
|
This object represents an essential source of information on the AV objects for selection and classification that are likely to be of interest to the user. The user preference denotes dynamic properties of the user preferences or behaviour on the objects. Thus, values for those parameters in the user preference will change along with time by the learning process.
Frame Ontology |
user-profile FIPA-AVEB |
|
||
Parameter |
Description |
Presence |
Type |
Reserved
Values |
property |
The personal details of the user. |
Mandatory |
personal-property |
|
preferences |
The preferences of the user. |
Mandatory |
preferences |
|
This object contains static parameters describing the users general and personal information.
Frame Ontology |
personal-property FIPA-AVEB |
|
||
Parameter |
Description |
Presence |
Type |
Reserved
Values |
username |
The identifier of the user. |
Mandatory |
String |
|
gender |
The gender of the user. |
Optional |
String |
Male Female |
birthdate |
The date of birth of the user. |
Optional |
DateTime |
See [FIPA00070] |
birthplace |
The place of birth of the user. |
Optional |
String |
|
nationality |
The nationality of the user. |
Optional |
String |
See [ISO3166] |
languages |
A list of the languages understood by the user. |
Optional |
Set of String |
See [ISO639] |
address |
The address of the user. |
Optional |
String |
|
access-means |
A list of the access types preferred by the user. |
Optional |
Set of String |
|
occupation |
The occupation of the user. |
Optional |
String |
|
habits |
A list of habits known about the user. |
Optional |
Set of String |
Drinking Painting Smoking ... |
interests |
A list of interests known about the user. |
Optional |
Set of String |
Golf Basketball Running ... |
payment-means |
A list of payment means of the user. |
Optional |
Set of
String |
|
notes |
Additional information about the user. |
Optional |
Set of
String |
|
This object contains static parameters describing about the users general and personal information.
Frame Ontology |
preferences FIPA-AVEB |
|
||
Parameter |
Description |
Presence |
Type |
Reserved
Values |
modality |
A list of interaction modalities preferred by the user in descending order of preference. |
Mandatory |
Sequence
of String |
|
av-preferences |
A list of preferences for AV object descriptions. |
Optional |
Set of
Integer |
|
This object represents media content that are processed by the AVEB application.
Frame Ontology |
av-description FIPA-AVEB |
|
||
Parameter |
Description |
Presence |
Type |
Reserved
Values |
identifier |
The identifier of the content. |
Mandatory |
String |
|
genre |
A list of genres that classify the content. |
Optional |
Set of String |
Documentary Sport ... |
language |
A list of languages in which the content is represented |
Optional |
Set of String |
See [ISO639] |
title |
A list of titles of the content. |
Optional |
Set of String |
|
director |
The director of the content. |
Optional |
String |
|
cast |
A list of cast that appear in the content. |
Optional |
Set of String |
|
date |
The date of creation of the content. |
Optional |
String |
|
keywords |
A list of keywords which describe the content. |
Optional |
Set of String |
|
summary |
A summary of the content. |
Optional |
String |
|
parental-ratings |
A list of parental ratings associated with the content. |
Optional |
Set of |
|
critic-ratings |
A list of critics' ratings associated with the content. |
Optional |
Set of |
|
provider |
The provider of the content. |
Optional |
String |
|
cost |
The cost of obtaining the content. |
Optional |
String |
|
This object represents parental ratings that are associated with the av-description.
Frame Ontology |
parental-rating FIPA-AVEB |
|
||
Parameter |
Description |
Presence |
Type |
Reserved
Values |
country |
The country in which the rating was given to the content. |
Mandatory |
String |
See [ISO3166] |
rating |
The rating given to the content. |
Mandatory |
String |
|
This object represents ratings by critics that are associated with the av-description.
Frame Ontology |
critic-rating FIPA-AVEB |
|
||
Parameter |
Description |
Presence |
Type |
Reserved
Values |
name |
The name of the critic who reviewed the content. |
Mandatory |
String |
|
rating |
The rating that the critic gave to the content. |
Mandatory |
String |
|
This object represents specific TV programme information.
name |
Description |
Presence |
Type |
Reserved
Values |
av-description |
The AV information of the programme. |
Mandatory |
av-description |
|
start-time |
The start date and time of the programme. |
Mandatory |
DateTime |
|
duration |
The duration of the programme. |
Mandatory |
Number |
|
status |
The running status of the programme. |
Mandatory |
Boolean |
|
scramble |
The scramble status of the programme. |
Optional |
Boolean |
|
bit-rate |
The bit-rate at which the programme is transmitted. |
Optional |
String |
|
encoding |
The mechanism used to encode the programme. |
Mandatory |
String |
|
This object represents specific film information.
name |
Description |
Presence |
Type |
Reserved
Values |
av-description |
The AV information of the film. |
Mandatory |
av-description |
|
duration |
The duration of the film. |
Mandatory |
Number |
|
scramble |
The scramble status of the film. |
Optional |
Boolean |
|
bit-rate |
The bit-rate at which the film is transmitted. |
Optional |
String |
|
encoding |
The mechanism used to encode the film. |
Mandatory |
String |
|
This object represents specific music information.
name |
Description |
Presence |
Type |
Reserved
Values |
av-description |
The AV information of the music. |
Mandatory |
av-description |
|
composer |
A list of composers of the music. |
Mandatory |
Set of String |
|
duration |
The duration of the music. |
Mandatory |
Number |
|
bit-rate |
The bit-rate at which the music is transmitted. |
Optional |
String |
|
encoding |
The mechanism used to encode the music. |
Mandatory |
String |
|
This object represents specific game information.
name |
Description |
Presence |
Type |
Reserved
Values |
av-description |
The AV information of the game. |
Mandatory |
av-description |
|
machines |
A list of machines on which the game will run. |
Mandatory |
Set of String |
|
devices |
A list of devices required to play the game. |
Mandatory |
Set of
String |
|
The FIPA-Reactive-Contract-Net interaction protocol given in Figure 2 is used between the CA and the GA to obtain the notification about the change in a programme as described in section 2.5.4, Scenario 4. This interaction protocol is a modification of the FIPA-Contract-Net interaction protocol (see [FIPA00029]).
Figure 2: Reactive Contract Net Interaction Protocol
[FIPA00023] FIPA Agent
Management Specification. Foundation for Intelligent
Physical Agents, 2000. http://www.fipa.org/specs/fipa00023/
[FIPA00029] FIPA Contract Net
Interaction Protocol Specification. Foundation for
Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00029/
[FIPA00070] FIPA ACL Message
Representation in String Specification. Foundation
for Intelligent Physical Agents, 2000.
http://www.fipa.org/specs/fipa00070/
[ISO639] Codes for the Representation of Names of Languages. International Standards Organisation, 1988. http://www.iso.ch/cate/d4766.html
[ISO3166] Codes for the Representation of Names of Countries and Their Subdivisions, Part 1: Country Codes. International Standards Organisation, 1997.
http://www.iso.ch/cate/d24591.html
[1] This cannot currently be expressed in FIPA ACL since P is a proposition which occurs as an argument of a predicate. An approximation would be <UPA1, query-if (UPA2, P)>.
[2] Again, this cannot currently be expressed in FIPA ACL. An approximation which includes points 3 and 4 would be <UPA2, inform-if (UPA1, P)> when P is available, and, <UPA2, refuse (UPA1, inform-if (UPA1, P), Not-Available)> when P is not available.