FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

 

 

FIPA Audio/Visual Entertainment
and Broadcasting Specification

 

 

Document title

FIPA Audio/Visual Entertainment and Broadcasting Specification

Document number

XC00081A

Document source

FIPA Architecture Board

Document status

Experimental

Date of this status

2000/10/17

Supersedes

FIPA00015

Contact

fab@fipa.org

Change history

2000/10/17

Approved for Experimental

 

 

 

 

 

 

 

 

 

İ 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

1     Scope. 1

2     General Analysis. 2

2.1      Assumptions. 2

2.2      Required Functionality. 3

2.3      Actors, Roles and Domains. 3

2.3.1      Agents. 3

2.3.2      Wrapper Agents. 3

2.3.3      Domains. 4

2.4      Generic Model 4

2.4.1      Detailed Functions of Agents. 4

2.4.2      Agent Interactions. 5

2.5      Scenarios. 8

2.5.1      Scenario 1. 8

2.5.2      Scenario 2. 8

2.5.3      Scenario 3. 9

2.5.4      Scenario 4. 9

3     Audio/Visual Entertainment and Broadcasting Ontology. 10

3.1      Object Descriptions. 10

3.1.1      Service Description. 10

3.1.2      User Profile. 11

3.1.3      Personal Property. 11

3.1.4      Preferences. 12

3.1.5      Audio/Visual Object Description. 12

3.1.6      Parental Rating. 13

3.1.7      Critic Rating. 13

3.1.8      TV Programme Properties. 13

3.1.9      Film Properties. 14

3.1.10    Music Properties. 14

3.1.11    Game Properties. 14

3.2      Interaction Protocols. 15

3.2.1      Reactive Contract Net 15

4     References. 16


1         Scope

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 user’s 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:

 

·         Information filtering and retrieval,

 

·         Information customisation,

 

·         User friendliness,

 

·         Home automation, education and entertainment, and,

 

·         Information compatibility.


2         General Analysis

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.

 

2.1        Assumptions

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.


2.2        Required Functionality

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.

 

2.3        Actors, Roles and Domains

2.3.1          Agents

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 user’s requests into ACL and presents information to the user in a user-friendly manner.

 

·         User Profile Agent (UPA)

      This agent maintains the user’s profile, provides information on user’s 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.

 

2.3.2          Wrapper Agents

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.

 

2.3.3          Domains

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

 

2.4        Generic Model

2.4.1          Detailed Functions of Agents

2.4.1.1         Interface Agent

·         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.

 

2.4.1.2         Control Agent

·         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.

 

2.4.1.3         User Profile Agent

·         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 user’s 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).

 

2.4.1.4         Guide Agent

·         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.

 

2.4.2          Agent Interactions

2.4.2.1         User Profile Agent to Interface Agent

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))>  

 

2.4.2.2         User Profile Agent to User Profile Agent

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.

 

2.4.2.3         User Profile Agent to Control Agent

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, John’s 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).

 

2.4.2.4         Interface 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)>

 

2.4.2.5         Control Agent to Tuner Wrapper and Video-On-Demand Control Wrapper Agents

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"))>

 

2.4.2.6         Control Agent to Digital Storage Medium Wrapper Agent

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"))>

 

2.4.2.7         Guide Agent to Control Agent

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))>

 

2.4.2.8         Interface Agent to User

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.

 

2.5        Scenarios

2.5.1          Scenario 1

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 user’s 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 user’s name, the CA asks for the user’s 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 user’s 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 user’s 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 user’s IA becomes suspended.

 

2.5.2          Scenario 2

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 user’s 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.

 

2.5.3          Scenario 3

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.

 

2.5.4          Scenario 4

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.

 


3         Audio/Visual Entertainment and Broadcasting Ontology

3.1        Object Descriptions

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.

 

3.1.1          Service Description

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

 

 


3.1.2          User Profile

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

 

 

3.1.3          Personal Property

This object contains static parameters describing the user’s 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

 

 


3.1.4          Preferences

This object contains static parameters describing about the user’s 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

 

 

3.1.5          Audio/Visual Object Description

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
parental-rating

 

critic-ratings

A list of critics' ratings associated with the content.

Optional

Set of
critic-rating

 

provider

The provider of the content.

Optional

String

 

cost

The cost of obtaining the content.

Optional

String

 

 


3.1.6          Parental Rating

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

 

 

3.1.7          Critic Rating

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

 

 

3.1.8          TV Programme Properties

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

 

 


3.1.9          Film Properties

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

 

 

3.1.10      Music Properties

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

 

 

3.1.11      Game Properties

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

 

 


3.2        Interaction Protocols

3.2.1          Reactive Contract Net

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


4         References

[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.