do software agents know what they talk about? agents and ontology patdc patrick de causmaecker,...

Do software agents know what they talk about?

Agents and Ontologyhttp://allserv.kahosl.be/

~patdc Patrick De Causmaecker,

April 2004

April 2004 Agents and Ontology [email protected] 2

Overview Agents Ontology Communication RDF Semantic Web Sample Implementations


Where to apply User interface

Personal representative for the user, Metaphorically enforced image of functionality

Distributed systems Asynchronicity, autonomy, unreliable

communication Algorithmic paradigm

E.g. optimization problem, agents incorporate separate strategies

E.g. heat distribution in a plate


Co-ordination techniques Organisational structuring

Structure a priory Master-slave through dispatching model Master-slave with a blackboard

Highly controlled, lower autonomy May detoriate speed, reliability,

robustness, graceful decay, bottleneck characteristics, concurrency

Blackboard is a potential bottleneck


Master-slave models(Dispatching)

Master

Slave Slave

BlackboardPost

Read


Contracting Two interchangable roles:

Manager defines subproblems, co-ordinates the whole problem

Contractor executes subtask (evt subcontractors) Bidding proces to find a solution

Task announcement (manager) Task evaluation (contractors) Proposal (contractors) Evaluation of proposal and assignment (manager) Co-ordination and evaluation of whole (manager)


Contract Net Protocol (CNP) Advantages

Dynamic task allocation for better contracts Agent population is arbitrarily dynamic Load balancing is natural through bidding Fault tolerance is high

Restrictions No conflict resolution Passive, generous, honest agents Communication intensive, high network load


Multi agent planning Determine all actions of agents before startup Conflicts and redundancy are removed in the

planning process Centralised planning by a coordinating agent

Resembles master slave approach Distributed planning by agent negotiation

High communication and information needs in the agents

Continuous trade off between complexity, sophistication and emergent behaviour


Ontology Communication Logic, Psychology and Language Examples Expression of Ontology KIF, KQML


Communication


Communication Between Agents Light weight

Telescript, Java, Limbo, Tcl, Python Sufficient for state info and messaging Do not support rules and ontology

Agent Communication Languages Performative Service Content Controll add-in


Agent Communication Languages (ACL) Performative

Protocols for information interchange Service

Requires basic mutual understanding Content

Domain dependent Ontology support Domain knowledge Complex semantics

Request-service

Buy(Flowers)

#$US-DollarIsa:#$UnitOfMoney#$FlowerPlant#$BiologicalTaxonIsa:#$ExistingObjectType…


Agent Communication Languages (ACL) Control add-ins

Which resources What code What language Mobile or not? Allow agents to think about their own

situation.


Example ACL: KQML

(ask-one : sender joe: content (PRICE IBM ?price): receiver stock-server: reply-with ibm-stock: language LPROLOG: ontology NYSE-TICKS)

(tell: sender stock-server: content (PRICE IBM 14): receiver joe: in-reply-to ibm-stock: language LPROLOG: ontology NYSE-TICKS)


Example ACL: KQMLClass NameBasisquery Evaluate, ask-if, ask-about, ask-one, ask-

all

Mutli-response Stream-about, stream-all, eos

Answer Reply, sorry

Generic info Tell, achieve, cancel, untell, unachieve

Generator Standby, ready, next, rest, discard, generator

Ability Advertise, subscribe, monitor, import, export

Network Register, unregister, forward, broadcast, route

Performatives in KQML


Example ACL: KIF(salary 015-46-3946 civil-eng 42000)(salary 026-40-9152 comp-sc 36000)(> (*(width chip1) (length chip1)) (*(width chip2)(length chip2)))(=>(and (real-number ?x) (even number ?n)) (>(exp ?x ?n) 0))(interested Peter ‘(salary ,?x ,?y ,?z))(progn (fresh line t) (print “Hello”)(fresh line t))

Simple information

Relationship

Logical statement

Meta knowledge (‘,)Program code


Standards: FIPA Foundation for Intelligent Physical

Agents (http://www.fipa.org)

Agent management

IA

IAUser

Interface

API

UserFIPAACL

FIPA Agent-software

FIPA UI FIPA


FIPA ACL(ask-if:sender I:receiver J:content (=(weather Belgium (May 2001)) cold):ontology meteorology:reply-with query-17) (inform

:sender J:receiver I:content true:in-reply-to query-17)


FIPA ACL

(inform:sender coala-agent:receiver speaker-agent:content (Line_quote(coalaspeaker,5),10):in-reply-to first-conference:ontology coala-conference:language prolog)


FIPA Agent Management

Internal Message Transport

Agent

Agent Communication

Channel

DirectoryFacilitator

AgentManagement

System

Software

Agent Platform


FIPA Software Integration

LegacyDatabase

SQLDatabase

Webserver

WrapperAgent

WrapperAgent

ClientAgent

ARB query

Execute

Dedicatedmapping

Http

ORB


Communication HTML

Hyper Text Markup Language (Human Transfer of Meaningfull

Layout) XML

eXtensible Markup Language (eXclusively Meaning, no Layout)

(“Meaning” should be “Content”)


Logic, Psychology and Language (Sowa) Databases contain numbers,

strings, BLOB’s (Binary Large Objects)

Catalogs contain part numbers Directories contain addresses Terminologies contain terms (Ontologies contain categories)


Semiotics Theorie of signs

Charles Sanders Peirce Ferdinand de Saussure

Signs are closely interconnected One can introduce metasigns,

metametasigns,… But the real meaning is in the real

world


Semiotics Markup languages: SGML family

Clean separation between formatting and meaning

XML (successor of SGML) tags represent semantics

Formatting is put in style sheets (CSS, XSL, Xschema)

XML still lacks guidelines for representing semantics


Semiotics “A resource can be anything that has identity.

Familiar examples include an electronic document, an image, a service (e.g. “today’s weather report for Los Angeles”), and a collection of other resources. Not all resources are network “retrievable”; e.g., human beings, corporations, bound books in a library can also be considered resources (Berners-Lee, 1998).

Familiar resources are electronic documents, images,… Humans are “unfamiliar”

Processes, people, intentions should be included in the ontologies for the web.


Semiotics Resource Description Framework:

PropertyTypes do not stand by themselves (Author, Title, Date,…) form packages

Can be elaborated upon by competing agents (OCLC, LOC,…)

Packages will be called “Vocabularies” Problem: Date on a book is the same as the date

on a bottle of wine, or the date of an event like the murder on president Kennedy. Human readers will immediately know that

these dates can be compared, but how will machines “know”?


Semiotics “The RDF should define a marketplace

for vocabularies. They can be invented, advertised, sold. The good ones will survive and prosper” (Bray 1998)

Important: catalogs on paper could be compared by humans, computer catalogs must be compared by machines!


Semiotics XML and RDF are just a first step

XML makes things a lot easier But standardisation of vocabularies will not

automatically bring interoperability Realities and differences of meanings must

be taken into account Needed are methods for defining and

translating vocabularies


Example “largest” is used for alphabetic

comparison

Meant was numerical comp or aria or population.

Q: What is the largest state of the US?A: Wyoming!


Logic Second branch of semiotics:

semantics (Peirce’s “logic proper”) When is a pattern of signs

representing a true proposition about the things the signs represent?

From syntactic relations between signs to semantic relations between signs and the world: five primitives


Five primitivesTable 1. Five semantic primitives

Prim. Informal Meaning English Example

Existence Something exists. There is a dog.

Co-reference

Something is the same as something.

The dog is my pet.

Relation Something is related to something.

The dog has fleas.

Con-junction

A and B. The dog is running, and the dog is barking.

Negation Not A. The dog is not sleeping.


Other operatorsTable 2. Three defined logical operators

Oprtr. English Example Translation to Primitives

Uni-versal

Every dog is barking. not(there is a dog and not(it is barking))

Impli-cation

If there is a dog, then it is barking.

not(there is a dog and not(it is barking))

Disjunction

A dog is barking, or a cat is eating.

not(not(a dog is barking) and not(a cat is eating))


Other operators These operators are not primitive

because not observable SQL contains an or but not an

implication and not “for all” For all must be expressed by using

two times “not exists”


Existential graphs Every human has two distinct parents who are also

humans First study the simpler

Some human has a parent who is also human

(x)(y)(Human(x) HasParent(x,y) Human(y))


Existential Graphs Some human has one parent who is human and another parent who is human and the two

are not identical

(x)(y)(z) (Human(x) HasParent(x,y) Human(y) HasParent(x,z) Human(z) yz)


Existential Graphs Every human has two distinct parents

who are human There is no human who has not two

distinct parents who are also human ~(x)(Human(x) ~(y)(z) (HasParent(x,y)

Human(y) HasParent(x,z) Human(z) yz))

(x)(Human(x) (y)(z) (HasParent(x,y) Human(y) HasParent(x,z) Human(z) yz)).


Existential graphs


Conceptual graphs

Box: quantification

(concept node)

Relation node

Dotted line: Coreference

Solid line: relation


Conceptual graphs


Conceptual graphs (x:Human)(s:Set)(ys) (Count(s,2) HasParent(x,y) Human(y)).

{*}@2 maps to two variables: s, ranging over sets, and y ranging over elements of s


Conceptual graphs Simpler and more natural is the

introduction of “has”

Parent is a “role” word such as spouse, pilot, teacher…


Conceptual graphs The definition of the HasParent

relation requires two formal parameters

The HasParent relation is defined as a relation between two humans; the first has a parent who is the second.


Logic, summary

1. Logic has a wide variety of graphic and linear notations (EG, CG, KIF, SQL, RDF)

2. Represent logic op’s in controlled natural languages

3. Logic has rules allowing to transfer a representation to another provided there is an ontology


Combining logic with ontology Logic makes no presumptions

about what exists. Knowledge about a domain needs

an ontology to express it in.

(x:Cat)(y:Chase)(z:Mouse) (name(x,"Yojo") agnt(y,x) thme(y,z))


Combining logic with ontology Alternatively: (x:Cat)(y:Mouse)

(name(x,"Yojo") chases(x,y)) (using the linear notation for CG’s)

Chases ::= [Animate: 1](Agnt)[Chase](Thme)[MobileEntity: 2]

[Cat: Yojo](Chases)[Mouse].


Combining logic with ontology


Combining logic with ontology Sowa developed CG in 1984 Independently Kamp had

developed his “Discourse Representation Structures” (1981)

Sowa and Way proved them semantically equivalent


Where are we?


Further reading See “Handouts”

Ontology, Metadata and Semiotics (Sowa)


Introduction Tim Berners-Lee’s vision of the

future of the WWW Until now: human-readable Web T B-L: “The Semantic Web

approach develops languages for expressing information in a machine processable form”


Aim of the Semantic Web To solve real problems in

communication: Radically improving our ability to find,

sort and classify information To make Web information practically

processable by a computer


Architecture of the SW


XML

Markup language (like HTML) Designed to describe data XML does NOT do ANYTHING: just stores

information in a structured way. Tags are not predefined (unlike HTML

tags) Uses a DTD (Document Type Definition) to

describe the data.


HTML versus XML

XML & HTML were designed with different goals: XML was designed to describe data &

to focus on what data is HTML was designed to display data &

to focus on how data looks

XML is NOT a replacement for HTML


XML: architecture

Description of things (resources) & their

types

Describing relationships between types & things


XML (http://www.w3.org/XML/)

eXtensible Markup Language: document mark-up language encodes the text

&

defines the document structure (provides meta-information)


Resource Description Framework

GOAL: “machine-readable” to “machine-understandable”

Documents + information: modelled as resources

Information about these resources: modelled as properties.

XML: is used as its encoding syntax


RDF: application areas Resource discovery (provide better

search engine capabilities) Cataloging (describing content & content

relationships available at a web site) Facilitate knowledge sharing & exchange

(by intelligent software agents) Content rating …


RDF: example Article X has creator Albert

Einsteinhttp://www.kahosl.be/ArticleX.dml

Albert Einstein

creator

<rdf:RDFxmlns:rdf=http://w3.org/TR/1999/PR-rdf-syntax-19990105#xmlns:s=http://www.kahosl.be/rdfschema>

<rdf:Description about=http://www.kahosl.be/ArticleX.dml><s:Creator>Albert Einstein</s:Creator>

</rdf:Description></rdf:RDF>

resource valueproperty


Multiple Properties and Statementshttp://www.kahosl.be/ArticleX.dml

Albert Einstein

CREATOR

On the motion of objects in a fluid

TITLE

ArticleX has creator A.E. and the title On th

motion…


Multiple Properties and Statements

<RDFxmlns=http://w3.org/TR/1999/PR-rdf-syntax-19990105#xmlns:dc=http://purl/org/DC/> <Description about=http://www.kahosl.be/ArticleX.dml>

<dc:CREATOR>Albert Einstein</dc:CREATOR><dc:TITLE>On the motion of objects in a

fluid</dc:TITLE> </Description></RDF>


Multiple statements

http://www.kahosl.be/ArticleX.dml

Albert Einstein

CREATOR

http://www.kahosl.be/ArticleY.dml

CREATOR


Multiple Statements <RDF

xmlns=http://w3.org/TR/1999/PR-rdf-syntax-19990105#xmlns:dc=http://purl/org/DC/> <Description about=http://www.kahosl.be/ArticleX.dml>

<dc:CREATOR>Albert Einstein</dc:CREATOR> </Description>

<Description about=http://www.kahosl.be/ArticleX.dml>

<dc:CREATOR>Albert Einstein</dc:CREATOR> </Description></RDF>


Resource valued properties

http://www.kahosl.be/ArticleX.dml CREATOR

On the motion of objects in a fluid

TITLEAlbert Einstein

mailto:[email protected]

TITLE


Resource valued properties

<RDFxmlns=http://w3.org/TR/1999/PR-rdf-syntax-19990105#xmlns:dc=http://purl/org/DC/> <Description about=http://www.kahosl.be/ArticleX.dml> <dc:CREATOR>

<Description about=mailto:[email protected]>

<dc:TITLE>Albert Einstein</dc:TITLE>

</Description>

</dc:CREATOR><dc:TITLE>On the motion of objects in a

fluid</dc:TITLE> </Description>

</RDF>


Alternative using the resource attribute

<RDFxmlns=http://w3.org/TR/1999/PR-rdf-syntax-19990105#xmlns:dc=http://purl/org/DC/> <Description about=http://www.kahosl.be/ArticleX.dml> <dc:CREATOR resource=mailto:[email protected] />

<dc:TITLE>On the motion of objects in a fluid</dc:TITLE>

</Description> <Description about=mailto:[email protected]>

<dc:TITLE>Albert Einstein</dc:TITLE> </Description>

</RDF>


This method offers new possibilities

http://www.kahosl.be/ArticleX.dml CREATOR

Albert Einstein

mailto:[email protected]

TITLE


CREATOR


This method offers new possibilities<RDF

xmlns="http://w3.org/TR/1999/PR-rdf-syntax-19990105#" xmlns:dc="http://purl/org/DC/">

<Description about="http://www.kahosl.be/ArticleX.dml"> <dc:CREATOR resource="mailto:[email protected]"/>

</Description>

<Description about="http://www.kahosl.be/ArticleY.dml"> <dc:CREATOR resource="mailto:[email protected]"/>

</Description>

<Description about="mailto:[email protected]"> <dc:TITLE>Albert Einstein</dc:TITLE>

</Description>

</RDF>


RDF Containers RDF has facilities to put elemens into

bags (Bag), sequences (Seq) and alternatives (Alt)

Can be used to indicate that a document was written by a number of people, that the musicians on the disc are the laureates of the Q.E. competition for violin of 2001 or that one of a list of mirrorsites should be chosen.


A Bag


Julian Schwingercreator

Infinities in QED

TITLERichard Feynman


A Bag with two members

<RDFxmlns=http://w3.org/TR/1999/PR-rdf-syntax-19990105#xmlns:dc=http://purl/org/DC/> <Description about=http://www.kahosl.be/ArticleY.dml>

<dc:CREATOR> <Bag> <li>Julian Schwinger</li> <li>Richard Feynman</li> </Bag> </dc:CREATOR>

<dc:TITLE>Infinities in QED</dc:TITLE> </Description></RDF>


A Seqhttp://www.kahosl.be/QECompetition.org

Laureate 1

CONTRIBUTOR

Violin 2001

TITLE

Laureate 2

Laureate 3

Laureate 4

Laureate 5

Laureate 6


A Seq with six members <RDF

xmlns=http://w3.org/TR/1999/PR-rdf-syntax-19990105#xmlns:dc=http://purl/org/DC/> <Description about=http://www.kahosl.be/QECompetition.org>

<dc:CREATOR> <Seq>

<li>Laureate 1</li><li>Laureate 2</li><li>Laureate 3</li><li>Laureate 4</li><li>Laureate 5</li><li>Laureate 6</li>

</Seq> </dc:CREATOR>

<dc:TITLE>Violin 2001</dc:TITLE> </Description></RDF>


Alternatives

http://www.kahosl.be/QECompetition.org

PUBLISHER

Violin 2001

TITLE

http://www.fh-konstanz.de/QECompetition.org

http://www.eigsi.fr/QECompetition.org

PUBLISHER

W. Erben


An Alt with two elements<RDF xmlns=http://w3.org/TR/1999/PR-rdf-syntax-19990105# xmlns:dc=http://purl/org/DC/><Description about=http://www.kahosl.be/QECompetition.org> <dc:PUBLISHER> <Alt> <li resource=http://www.fh-konstanz.de/QECompetition.org/> <li resource=http://www.eigsi.fr/QECompetition.org/> </Alt> </dc:PUBLISHER> <dc:TITLE>Violin 2001</dc:TITLE></Description><Description about=http://www.fh-konstanz.de/QECompetition.org/> <dc:PUBLISHER>W. Erben</dc:PUBLISHER></Description></RDF>


Statements about containers


Julian SchwingerCREATOR

Richard Feynman

DESCRIPTION

Formed a famous team


Statements about containers


<dc:CREATOR> <Bag ID="FamousTeam"> <li>Julian Schwinger</li> <li>Richard Feynman</li> </Bag> </dc:CREATOR> </Description> <Description about="#FamousTeam">

<dc:DESCRIPTION>They formed a famous team</dc:DESCRIPTION> </Description></RDF>


Statements about all members in a container


Julian SchwingerCREATOR

Richard Feynman

Was at Los Alamos

DESCRIPTION


Statements about all members in a container


<dc:CREATOR> <Bag ID="FamousTeam"> <li>Julian Schwinger</li> <li>Richard Feynman</li> </Bag> </dc:CREATOR> </Description> <Description aboutEach="#FamousTeam">

<dc:DESCRIPTION>Was at Los Alamos</dc:DESCRIPTION> </Description></RDF>


RDF Exercise

Name


Julian Schwinger

Creator

Richard Feynman

1918 1994

19881918

Creator

Birth year Death year

Death yearBirth yearName

XOL: XML-based Ontology exchange Language

Pangea Systems Inc. & Artificial Intelligence Center

SRI International


XOL

Ontology definitions that XOL is designed to encode include: schema information (class def.) and non-schema information (object def.).

The syntax is based on XML and the semantics on OKBC-Lite

Design is generic: a single set of XML tags (defined in the DTD) can describe every ontology.

Simplified form of the Knowledge Model for the OKBC (http://www.ai.sri.com/~okbc/). This Knowledge Model provides definitions for concepts, relations, objects and constraints.

Structure of strings

Meaning of a string


XOL (Example)<class><name>person</name></class><slot>

<name>age</name><domain>person</domain><value-type>integer</value-type><numeric-max>150</numeric-max>

</slot><individual>

<name>fred</name><type>person</type><slot-values>

<name>age</name><value>35</value>

</slot-values></individual>


XOL Ontology Example<?xml version="1.0" ?><!DOCTYPE module SYSTEM "module.dtd"><module><name>genealogy</name><kb-type>ocelot-kb</kb-type><package>user</package>

<class><name>person</name><documentation>The class of all persons.

</documentation></class>


XOL Ontology Example<class><name>man</name><documentation>The class of all persons who define

their gender as male.</documentation><subclass-of>person</subclass-of></class><class><name>woman</name><documentation>The class of all persons who define

their gender as female. </documentation><subclass-of>person</subclass-of></class>


XOL Ontology Example<slot><name>year-of-birth</name><documentation>An integer that represents the year

the person was born.</documentation><domain>person</domain><slot-cardinality>1</slot-cardinality><slot-numeric-min>1800</slot-numeric-min><slot-value-type>integer</slot-value-type></slot><slot><name>brothers</name>


References XML & RDF

XML Bible by Eliotte Rusty Harold http://metalab.unc.edu/xml

Ontology http://www.diffuse.org/reports.html http://www.ontology.org/

OIL http://www.ontoknowledge.org/oil/

DAML http://www.daml.org http://www.ksl.stanford.edu/projects/DAML/


Timetabling: The Initial Problem Lectures in a school or university have

to be scheduled (rostered). In each session a teacher must meet a class in a room and teach them a subject:

No teacher can teach two lectures at the same time, no class can take two subjects at the same time, no room can accommodate two sessions at the same time.


The Initial Problem Furthermore, each class must have a

predfined set of lectures each week, each teacher can teach a set of subjects, each teacher has a maximum number of lectures/week, each room can accommodate a maximum number of students, each room has facilities for a number of subjecte, each student should have one free day, a teacher should not be scheduled first and last timeslot of the day,….


Related Problems Timetabling is an instance of the

more general class called rostering Nurse rostering Personnel Material resources Transportation Consultants


Initial Problem Solutions Exact methods: NP completeness

Mixed integer programming Heuristics: at each iteration step, select

the session that is likely to cause most problems and try to schedule it.

Meta heuristics: Tabu Search, Genetic Algorithms, Simulated

annealing, … Hyper heuristics:

Collect a set of heuristics and apply a meta heuristic to select the right heuristic at each stage


A Possible MAS Approach Represent each teacher, class,

room, by an agent Define a negotiation protocol along

Master slave Coalition formation …

Let the agents negotiate until a feasible timetable emerges


Advantages of a MAS Constraints are naturally build into

the individual agents Distribution is easy which makes it

possible to use available computing power (e.g. all idle PC's)

The system is flexible, introduction of a new teacher, class, subject… is achieved by adding new agents


Possible Drawbacks of a MAS The agent community must strive

towards a feasible timetable. The system should be continuous, a

small change (one new optional subject) cannot change the whole timetable

The system should be fair, integrated over time each of the teachers, classes,… must take equal shares of disadvantageous schedules


A Non-solution to the Drawbacks These drawbacks could be coded in a

global goal function representing the global good for the system.

Such approaches have been proposed (satisfycing games)

This global goal function is a centralised concept, contradictory to the decentralised approach in a MAS.

Agents should be considered myopic.


Sidepath: Centralised Concepts in a Distributed system Hardware: One computer

Contains all data Coordinates all processes Handles synchronisation Is resposible for the time keeping

Software: One algorithm Distributes all the work Oversees all processes and decides conflicts

Software: One table Describes all available diskspace Describes the structure of the network


Sidepath: Disadvantages of Centralised Concepts

Centralisation Causes bottlenecks Limits scalability Is a critical weak point in the system Slows down the concurrent operation


Sidepath: Alternatives for centralised concepts

Voting systems Task redistribution Mirroring Distributed directories Distributed filesystems Algorithms that can work with

incomplete information


Disadvantages of Centralised Concepts in a MAS Example: A central function evaluting how

'good' a timetable is. If a new agent is introduced (new class) the

mean value of the function may change. The function cannot be compared with

previous results. Its evaluations requires knowledge of the

complete situation. This means this information must be available at all times, especially during concurrent processing by the agents


Disadvantages of Centralised Concepts in a MAS

Example: A measure for continuity Evaluation of the measure is complex The concurrent agents will access it

independently. There is no control on the resulting

complexity.


Disadvantages of Centralised Concepts in a MAS

Example: Fairness It is very unnatural to build a fairness

measure into each individual agent. It requires historical information Fairness should be emergent


Myopic Agents In a really distributed MAS agents will not

have access to central information, intelligence.

They will not be allowed to execute algorithms that process all data in the system

The properties that refer to this kind of information must be emergent, they must intrinsically follow from the basic interactions and the behaviour of the agents.


Myopic agents: Emergent Behaviour Realising Goals

E-commerce application have no global goal. It is expected that the interactions between the agents, as defined by market mechanisms, lead to an economically well function global system.



Timetabling applications do have global goals or requirements. The emergent behaviour must meet these requirements.

So we will need an understanding of how the elementary interactions influence the system.



Difficult: Theory of democracy Game theory Human decision making versus

machine decision making.


Myopic agents: Emergent Behaviour Realising Goals Research, results, metaphors

available from Physics: sand heap Physics: cristal structure Physics: critical temperature Biology: swarms Biology: evolution Biology: bone growth


Myopic agents: Emergent Behaviour Realising Goals These results are all elementary

when compared to the complexity of a timetabling system.

At best, some results may be transferred.

At the least, the results may be used as metaphors, guidelines,… and empirical results may be generated.


Classical Solutions are ' ad hoc'

Constructs, architectures, techniques have been invented to relieve the problems

Typically, an approach has been proposed, criticised and empirically investigated


Back to Timetabling A MAS can work as an alternative

heuristic to solve timetabling problems Research issues:

Efficiency of such an approach Flexibility with respect to new constraints Scalability and extendability of the

systems Controllable emergent behaviour


Extended Timetabling Timetabling is not isolated from other

planning activities Typically a number of organisational

levels are present: Teachers and students Competence centers Departments Schools The university


Extended Timetabling At each level, separate units exist

and do interact. It is natural to model this

interaction in an agent architecture Distributed Myopic Preferences and constraints are

discussed in negotiations


Leveled Timetabling So we will consider several levels

in a timetabling application, corresponding to the organisational levels in the real world system.

At each level, the appropriate approach must be selected.

MAS is always a candidate and its behaviour must be investigated.


Timetabling At each level the basic research

questions will be the same: Performance Efficiency in the translation of the

requirements Flexibility Extendibility Scaling properties Emergent behaviour.


Technology These questions determine the

fitness of a technological solution for the problem at hand.

We will need OS support for ontology, communication, distribution, mobility, autonomy

On the other hands, standards may be too slow for our purposes (e.g. ACL)


Example Problem Model

Need Negotiation

Conclusion


Problem Loosely interconnected units

Departments in a university Hierarchy

Units, super units,… Level of detail goes down when one

goes up in the hierarchy Each level will have its own

constraints


Problem Lowest level

Timetabling algorithms produce rosters for students, teachers, rooms,…

“Teaching unit” level A unit is concerned with a subject, teaching

is in several student programmes Department level

Resources are shared between departments, e.G. Rooms, …

…


Reciprocal Benefits Timetabling as an example domain

Combinatorial complexity Optimisation domain Real world problems Benchmarks


Computational Model The aim is to set up a model that

can be used at all levels of the problem definition

We will start with simpleminded approaches and see how far we can get from the point of view of Modelling Optimisation


The Most Fine Grained Level

The smallest grains in a timetabling problem are the sessions

Design a model in which sessions are represented by agents

The main objective is to investigate a distributed computational model

This may not be the final representation; Its main advantage is its simplicity


Basic Problem Initially, only consider hard constraints

involving individual sessions, i.e. place and time conflicts

A sessions is characterised by A teacher A student group A room A timeslot …


Basic Problem Simplifying assertions

Rooms, teachers, student-groups have been assigned

Student-groups do not intersect The only free parameter left is the

timeslot So we arrive at:


Basic ProblemSession

Teacher t1, t2, t3, …

StudentGroup s1, s2, s3, …

Room r1, r2, r3, …

Timeslot 1, 2, 3, …

Assign timeslots to sessions subject to s1.Timeslot=s2.Timeslot=>s1.teacher <> s2.teacher,s1.room <> s2.room,s1.studentgroup <> s2.studentgroup


Generalised Basic Problem

Agent

Dimension1 Domain1

Dimension2 Domain2

Dimension3 Domain3

Position Field

…

Assign positions to agents subject to a1.Position=a2.Position=>a1.Dimension1 <> a2.Dimension,a1.Dimension2 <> a2.Dimension2,…


Basic Distributed Algorithm Each agent continuously

Contacts some other agents at random Checks with those on conflicts In case of conflict the contacted agent

generates some random positions and finds the position among those with the least conflicts

It moves to this position if the number of conflicts goes down

If the number of conflicts goes up, it moves only with a certain probability


Presupposed Is A centralised source of information

about the number of conflicts at a certain position A convenient way to store this

information is through a folding function :

(p,d,v) = number of agents at position p for which dimension d has value v


Surface In terms of the constraints can be

rephrased as

Let us define the surface covered by the agent population as

For every position p, dimension d and value v

(p,d,v) {}

Surface = number of position, dimension, value

triples (p,d,v) for which (p,d,v) > 0


Maximum Surface Since each agent has exactly one value for each

dimension, we have (Na agents, Nd dimensions)

Satisfaction of all constraints, (p,d,v) {}, is thus equivalent to

And we have reached a maximisation problem

Sum over all triples (p,d,v) of (p,d,v) = Na*Nd

Surface = Na*Nd


Trivial Cases If the number of dimensions is 0, the

constraints are satisfied iff at each position there is at most one agent The algorithm converges if there are

less agents than positions since the agents tend to move to empty positions

If there is only one dimension, the problem decomposes into the previous one for each value of the dimension


Nontrivial Cases If Nd > 1, situations may occur in

which none of the agents can move without decreasing the surface

Convergence of the algorithm will now critically depend upon the acceptance of worse positions

We may want to alternate between intensification and diversification regimes


Regime Change One can expect that the agents

could better be switching in group(s) than separately

One can use techniques of coalition formation here


Related Problems The dimensions of the agents create

links between them which define the constraints

The problem can be seen as a graph colouring problem

It was our goal to model this situation without globally defining this network

Distributed approaches to the graph colouring problem will be applicable here


Related Methods The ERA system of Liu, Jing and Tang is

based on a similar model and algorithm Our model is a special case In their 2001 Artificial Intelligence paper

the graph colouring problem is an example

Move selection is based on three probabilities: pleastmove, pbettermove, prandommove

There is no concept of a regime


Central Information Broker The information on the folding at

a certain position can be replaced by a coalition of agents informing each other about potential problems

Removes the need for a central component


The Network The relationships between the agents

define a network This can be kept dynamical and only

partly defined Each agent may keep a (finite size) list

of neighbours which he encountered before

The list is used primarily for conflict checking


Personalised Domains Thinking about sessions again, not

fixing rooms a priory this time Some sessions may have different

(overlapping) sets of available rooms The neighbour concept may then

lead to a situation in which a session has no position available where it does not conflict with any of its neighbours


Personalised Domains This is a non symmetrical conflict

since the neighbouring sessions may have larger room sets

The session discovering this situation may Simply do nothing and wait until the

algorithm solves the problem Send messages to the conflicting

neighbours to do something about this


More Complicated Constraints Soft constraints, capacity

constraints … Are of a different nature than the

ones considered here As long as they are sufficiently

local, they may still be checked by locally informed agents


Other Levels This model can be extended to the

other levels The move from one position to

another can be replaced by a more complicated rearrangement inside the agent

Informing its peers about possible changes

To be done…


Conclusions Agents are there to stay Questions remain to be answered These are fundamental questions

of 50 years of CS research, e.g. in Operating systems Languages Artificial intelligence

do software agents know what they talk about? agents and ontology patdc patrick de causmaecker,...

Documents

communication slide

actions of agents

software agents

ontology patrick

ontology communication

ontology http

manager slide

agents continuous trade