[PDF] Un dialogue de persuasion pour laccès et lobtention dinformations

View - Download Un dialogue de persuasion pour laccès et lobtention dinformations

Previous PDF

Next PDF

Un dialogue de persuasion pour l"accès et l"obtention d"informations

L. Perrussel

?S. Doutre?J.-M. Thévenin?P. McBurney†?

IRIT - Université Toulouse 12 rue du doyen Gabriel Marty - 31042 Toulouse Cedex 9 - France{laurent.perrussel,sylvie.doutre,jean-marc.thevenin}@univ-tlse1.fr

†Dpt. of Computer Science - University of LiverpoolLiverpool L693BX - United Kingdomp.j.mcburney@csc.liv.ac.ukRésumé :

Obtenir une information peut s"avérer essentielpourdesagentsautonomesdansl"accomplissementde leurs buts. Les agents sont pour cela amenés àdialoguer avec d"autres agents pour demander etobtenir cette information. Or son accès peut êtrecontrôléetnécessiterunepermission,queseulscer-tains agents sont autorisés à donner ou non. Dansle cas où un agent n"a pas l"autorisation d"accé-der à une information, il doit pouvoir essayer deconvaincre l"agent contrôleur de l"accès de chan-ger de position et de lui donner cette autorisation.Pour représenter une telle situation, nous propo-sons un protocole de dialogue de recherche d"infor-mation faisant appel à de la persuasion basée surl"argumentation pour obtenir une permission. Ceprotocole est basé sur un système d"argumentationoù chaque agent possède une notion d"acceptabilitéspécifique.

Mots-clés :Dialogue, argumentation, permission

Abstract:

Obtaining relevant information is essential foragents engaged in autonomous, goal-directed beha-vior. To this end, agents have to dialog with otheragents to request and get this information. Howe-ver, access to information is usually controlled byother agents. In the situation where an agent isnot allowed to access some information, it may tryto convince the agent that controls the access tochange its mind and give it the permission. To re-present such situations, we design a protocol fordialogs between two autonomous agents for see-king and granting authorization to access some in-formation. This protocol uses argumentation-basedpersuasion. It is based on an argumentation fra-mework where agents handle specific acceptabilityover arguments.

Keywords:Dialogue, argumentation, permission1 Introduction

Cet article montre comment deux agents,

un client et un serveur, peuvent dialoguerde telle sorte que le client essaie d"ob-

tenir l"accès à une information possédéepar le serveur, alors que le serveur essaiede convaincre le client qu"il ne peut paslui donner cet accès. Un dialogue dans cecontexte peut être vu comme étant basé

sur l"échange d"arguments et de contre-arguments dans le but de déterminer si unepermission d"accès peut être octroyée ounon. Les arguments avancés par un agentreprésentent son propre point de vue, au-trement dit ce sont des arguments qu"il

juge acceptables.

Des systèmes d"argumentation permettant

de prendre en compte des points de vue

multiples ont déjà été proposés ([1, 2] parexemple), et les dialogues basés sur l"ar-gumentation pour la recherche d"informa-tion et la persuasion ont déjà fait l"ob-jet de nombreuses études ([11, 9, 12, 13]

par exemple). Par contre, très peu de tra-vaux se sont intéressés au problème derecherche d"information dans le cas oùl"accès à celle-ci requiert une permission([3, 5]). De plus, parmi ces travaux, au-cun ne décrit un lien explicite entre per-

missions et arguments pour ou contre cespermissions. Ce lien est pourtant essentielpour justifier pourquoi l"accès à une infor-mation est ou n"est pas autorisé.

Dans cet article, nous décrivons de ma-

nière informelle un protocole de recherche

d"information qui fait appel à un proto-cole de persuasion pour obtenir la permis-sion d"accéder à l"information (voir [10]pour une description formelle). Ce proto-cole fait apparaître un lien explicite entre

permissions et arguments. De plus, les ar-guments échangés par le client et le ser-veur sont sélectionnés et évalués en fonc-tion de leur propre notion d"acceptabilité.

L"article est organisé comme suit : la sec-

tion 2 présente comment lier permissionset arguments. La section 3 décrit la syn-taxe et les règles du protocole de dialogue.Nous concluons l"article en section 4.

2 Permissions et arguments

Dans cette section, nous présentons les

concepts de droit d"accès (ou permissions)et d"argumentation, sur lequels se basenotre protocole de dialogue.

Nous introduisons quelques notations pré-

liminaires. SoitAgl"ensemble des identi-fiants (id) d"agents. Un id d"agent est re-présenté par une lettre romaine en minus-cule (x,y, ...). L"information demandée estreprésentée par une lettre grecque en mi-nuscule (φ,ψ...).Infdénote l"ensemble de

toutes les informations possibles. Un argu-ment est représenté par une lettre romaineen majuscule (A,B...).

2.1 Permissions d"accès

Lapermissionqu"un agentxa d"accéderà une informationφest dénotée par unefonctionperm(y,x,φ):perm(y,x,φ) =1(resp.0) signifie que l"agentypeut don-

ner (resp. ne peut pas donner) accès àl"agentxau contenu de l"informationφ.

La notion de permission est intimementliée à celle decontrôle. Un agent ne peutdéfinir une permission sur une information

φque s"il en contrôle effectivement l"ac-cès. Si tel n"était pas le cas, un agent pour-rait se donner à lui-même (ou à d"autres

agents) des permissions sur des informa-tions sur lesquelles il n"a aucun contrôle.Nous représentons cette notion de contrôle

par une fonctioncontrolqui associe agents et informations :control :Ag?→2Inf.

Formellement, le lien entre permission et

2.2 Système d"argumentation

Le système d"argumentation sur lequel

vont se baser nos dialogues doit per-mettre aux agents de partager un même en-semble d"arguments, et une même vision

des interactions entre arguments. L"inter-action considérée ici est une relation decontrariété. De plus, chaque agentzdoitêtre capable de déterminer quels sont,de son point du vue, les arguments ac-

ceptables (caractérisés par une fonctionacceptable(z)); ce sont ces arguments quezutilisera pour contrer, si nécessaire, lesarguments avancés par les autres agentsdans un dialogue.

Les arguments et la relation de contra-

riété peuvent être représentés de manièreclassique en utilisant le système d"argu-mentation de Dung [7]. Dans ce système,la structure interne et l"origine des argu-ments, tout comme la relation de contra-riété, sont abstraites. Ce niveau d"abs-

traction rend le système suffisamment gé-néral pour être instancié dans différentscontextes (voir par exemple [4]).

Pour représenter les différents points devue concernant l"acceptabilité des argu-

ments, un manière simple consiste à uti-liser différentes relations de préférenceentre arguments. Le travail de [1] est uneextension du système de Dung qui montrecomment combiner plusieurs relations depréférence en une seule, dans le but de

caractériser les arguments acceptables dusystème résultant. Ne cherchant pas à uni-fier les différents points de vue des agents,

cette approche n"est pas appropriée pour

nos dialogues. [2] a présenté une autre ex-tension du système de Dung où des valeurs(au sens de valeur morale, éthique, ...)sont associées aux arguments et où chaqueagent définit sa propre relation de préfé-

rence entre les valeurs (et ainsi entre lesarguments); chaque agent détermine en-suite quels sont ses arguments acceptablesen fonction de ses préférences. L"utilisa-tion des valeurs donne indéniablement du

sens à l"origine des préférences des agents,mais ce besoin de sens n"est pas nécessairedans notre approche.

De manière générale, la définition de l"ac-ceptabilité pour un agent dépendra despolitiques d"accès. Par exemple, dans uncontexte où l"information est sensible, lanotion d"acceptabilité sera restrictive (lasémantique d"acceptabilité basique de [7]

irait dans ce sens), alors que des notionsd"acceptabilité plus souples (par exemplela sémantique préférée de [7]) pourrontêtre considérées dans d"autres contextes.

Dans cet article, nous ne présentons pas endétail un système d"argumentation et unenotion d"acceptabilité qui satisfont les spé-cifications énoncées ci-dessus; nous invi-

tons le lecteur à consulter [10] pour uneprésentation détaillée.

2.3 Lier arguments et permissions

Le lien entre permission et argument est

défini comme suit : unepermission argu-

mentéeest un tuple?A,y,x,φ,ι?oùAestun argument,yetxsont des ids d"agents,φest une information etιest une valeur depermission (ι? {0,1}).?A,y,x,φ,ι?si-gnifie que l"agentypossède l"argumentAen faveur de (ι= 1) ou contre (ι= 0) l"oc-

troi de la permission à l"agentxd"accéderà l"informationφ.

Unepermissiondéfinieparunagentypour

un agentxet une informationφestconsis-tanteavec un ensemble de permissions ar-gumentées si les deux conditions suivantes

sont satisfaites :

(i) deux argumentsAetBqui se contra-rient ne peuvent être simultanément enfaveur (ou contre) l"octroi de la permis-sion, et

(ii) il existe une permission argumentée?A,y,x,φ,ι?telle queAappartient àacceptable(y).

3 Dialogue de persuasion pour

l"octroi d"une permission

Dans cette section, nous décrivons un sys-

tème de dialogue pour l"obtention d"uneinformation qui nécessite une permission, et qui fera pour cela appel à de la persua-sion.

3.1 Définition

Nos dialogues impliquent deux partici-

pants : unClient(qui demande l"informa-tion), et unServeur(qui contrôle l"accès

à l"information). Avant qu"un dialogue nedébute, le Client a pour but d"obtenir duServeur toutes les informations dont il abesoin, en utilisant la persuasion si néces-saire. Le Serveur a lui pour but de fournirau Client l"information qu"il demande en

fonction des permissions qui lui sont asso-ciées. Le Client et le Serveur peuvent avoirdes bases de connaissances disjointes. Labase de connaissance du Serveur incluedes permissions argumentées relatives àchaque Client pour diverses informations.

L"ensemble deslocutionsd"un dialogue

doit permettre d"ouvrir et de fermer le dia-logue, de demander de l"information, defournir le contenu d"une information de-mandée, d"indiquer que le contenu d"uneinformation ne peut être fourni, et d"ar-gumenter sur les permissions relatives à

une information demandée. Ces locutionspeuvent être basées sur les standards de laFIPA [8].

Undialogueest une structure qui combinedes permissions, un système d"argumen-tation, un ensemble de permissions argu-mentées, et une séquence de locutions.

3.2 Protocole

Nous présentons maintenant de manière

informelleunprotocolepournosdialoguesde recherche d"information avec permis-sions (voir [10] pour une description for-

melle).

Après avoir ouvert le dialogue, le Client(idx) demande au Serveur (idy) une in-formationφ. Plusieurs cas de figure se pré-sentent :

- Si le Serveur contrôle effectivementl"accès àφ, et si le Client a la permis-sion d"y accéder, le Serveur doit fournir

le contenu deφau Client; le dialogueest ensuite fermé par le Client ou le Ser-veur.- Si le Serveur ne contrôle pas l"accès àφ,il doit fermer le dialogue.- Le cas qui nous intéresse le plus ici est

celui où le Serveur contrôle l"accès àφ,mais où le Client n"a pas la permissiond"accéderàφ;ilexistedoncdanslabasede connaissance du Serveur une permis-sion argumentée?A,y,x,φ,0?. Le Ser-

veur doit alors indiquer au Client qu"ilrefuse de lui fournir le contenu deφetexplique son refus en avançant l"argu-mentA.

Suite à ce dernier cas, une étape de persua-sion basée sur l"argumentation commence.Le Client va essayer de convaincre le Ser-

veur de lui donner la permission d"ac-cès, alors que le Serveur va essayer deconvaincre le Client qu"il ne peut changerla permission. Dans ce but, Client et Ser-veur vont présenter des arguments accep-tables selon leur point de vue pour contre-

carrer les arguments de leur opposant.

Concentrons-nous dans un premier tempssur l"attitude du Client lorsqu"il reçoit unargument du Serveur.

- Le Clientxconsidère tout d"abord tousles arguments deacceptable(x)qui at-taquent l"argument reçu et les présentecomme contre-arguments au Serveur.- Si l"argument reçu appartient àacceptable(x), et si pour tout argu-

ment envoyé par le Serveur, le Clientxa présenté tous les contre-argumentspossibles, alors le dialogue se termine;le Client n"a pas pu convaincre le Ser-veur de changer la permission, il ne

pourra donc pas accéder au contenu del"informationφ.

Concentrons-nous à présent sur l"attitude

du Serveur. Le principe est similaire à ce-lui du Client : le Serveur présente au Clienttous les arguments qu"il possède pour leconvaincre qu"il ne lui donnera pas la per-mission d"accéder à l"information. Plus

précisément : - Le Serveuryconsidère tous les argu-ments deacceptable(y)qui attaquent

l"argumentreçuetlesprésenteauClient.- Siyne peut présenter de tels arguments,il présente tous les argumentsAdes per-missions argumentées?A,y,x,φ,0?.

Une fois que tous les arguments des per-missions argumentées ont été présentés,que tous les arguments présentés par leClient ont été contrés, alors le Serveur doit

évaluer l"ensemble des arguments envoyéspar le Client. De cette évaluation, soit leServeur décide de changer la permission(et fournit le contenu de l"informationφauClient), soit il reste sur sa position. Le dia-

logue se termine ensuite.

3.3 Persuasion et mise-à-jour des per-

missions

Nous proposons deux manières pour le

Serveuryd"évaluer l"ensemble des argu-

ments envoyés par le Client :

PrudenceSi l"un des arguments avancé

par le Serveur n"a pas été contré par le

Client, alors le Serveur conserve uneraison de ne pas changer la permis-sion. Il reste sur sa position.

ConfianceSi l"un des arguments pré-senté par le Client appartient àacceptable(y), i.e. est acceptable pour

le Serveur, et si cet argument n"appa-raît dans aucune permission argumen-tée contre la permission, alors le Ser-veur considère qu"il a une bonne rai-son de changer la permission.

Dans ce dernier cas, le Serveur change

l"ensemble des permissions argumentéesde manière à ce que la permission qu"il

vient d"accorder soit consistante. Concrè-tement, tout argumentAenvoyé par leClient qui est acceptable du point devue du Serveur fait l"objet de l"ajoutd"une nouvelle permission argumentée?A,y,x,φ,1?.

3.4 Terminaison

Les règles qui viennent d"être décrites ga-

rantissent que les dialogues de notre sys-tème sont bien formés. A la fin de ces dia-logues, le contenu de l"informationφestdévoilé au Client :

- soit parce que le Client possédait la per-mission d"accéder au contenu deφavantmême le début du dialogue,- soit sinon parce que par l"échange d"ar-guments et de contre-arguments relatifs

à des permissions argumentées, le Ser-veur a été convaincu de changer la per-mission du Client pour qu"il accéde aucontenu deφ.

4 Conclusion

Nous avons présenté un système de dia-

logue pour l"obtention d"une informa-tion nécessitant une permission d"accès.

Notre contribution est double. Première-ment, nous avons représenté à travers unlien explicite entre arguments et permis-

sions pourquoi un agent accepte ou nonde donner une information sujette à per-mission. Deuxièmement, nous avons pro-

posé une classe de dialogues spécifique,les dialogues pour l"obtention d"une in-formation qui nécessite une permission;ces dialogues permettent de caractériserdeux modes de changement de permission(prudence et confiance). Ce protocole peut

être utilisé avec différents systèmes d"ar-gumentation. Une formalisation de ce pro-tocole, utilisant un système d"argumenta-tion basé sur des préférences multiples, estprésentée dans [10]. Un tel protocole pour-rait être implémenté suivant la méthode

proposée dans [6].

Pour la suite, nous envisageons de raffinerle protocole pour prendre en compte unenotion de confiance : si un client est ca-pable de convaincre un serveur de lui don-ner la permission d"accéder à une infor-

mation, alors ce résultat peut jouer le rôled"un argument en faveur du client pouraccéder à d"autres informations; le dia-logue de persuasion peut être vu commeune preuve de confiance.

Remerciements

Peter McBurney est reconnaissant pour le

soutien du projet européenArgumentationService Platform with Integrated Compo-nents (ASPIC)(IST-FP6-002307). LaurentPerrussel est reconnaissant pour le soutiendu projet ANRSocial trust analysis andformalization (ForTrust).

Références

[1] L. Amgoud, S. Parsons, and L. Per-russel. An Argumentation Fra- mework based on contextual Prefe-rences . InProc. of FAPR"00, Lon-don, pages 59-67, January 2000. [2] T. J. M. Bench-Capon. Persuasion inpractical argument using value-based argumentation frameworks.J. Log.Comput., 13(3) :429-448, 2003.

[3] G. Boella, J. Hulstijn, and L. van derTorre. Argument games for inter-active access control. InProc. ofWI 2005, pages 751-754. IEEE CS,

2005.

[4] A. Bondarenko, P. M. Dung, R. A.Kowalski, and F. Toni. An abstract,argumentation-theoretic approach todefault reasoning.Artif. Intell.,93 :63-101, 1997.

[5] P. Dijkstra, F.J. Bex, H. Prakken, and

C.N.J. De Vey Mestdagh. Towards amulti-agent system for regulated in-formation exchange in crime inves-tigations.Artificial Intelligence andLaw, 13 :133-151, 2005.

[6] S. Doutre, P. McBurney, and

M. Wooldridge. Law-governedlinda as a semantics for agent dia-logue protocols. InAAMAS, pages1257-1258, 2005.

[7] P.M. Dung. On the Acceptability ofArguments and its Fundamental Role

in Nonmonotonic Reasoning, LogicProgramming, and N-Person games.Artificial Intelligence, 77(32) :321-357, 1995.

[8] FIPA.FIPA, "Agent communica-tion language", FIPA 97 Specifica- tion, Foundation for Intelligent Phy-sical Agents edition, 1997.

[9] S. Parsons, M. Wooldridge, andL. Amgoud. Properties and com-plexity of some formal inter-agent dialogues.J. Log. Comput.,13(3) :347-376, 2003.

[10] L. Perrussel, S. Doutre, J.-M. Théve-nin, and P. McBurney. A PersuasionDialog for Gaining Access to Infor-mation. InArgMAS 2007, 2007.

[11] H. Prakken. Coherence and flexibi-lity in dialogue games for argumen- tation.J. Log. Comput., 15(6) :1009-1040, 2005.[12] I. Rahwan, S. Ramchurn, N. Jen- nings, P. McBurney, S. Parsons, andL. Sonenberg. Argumentation-basednegotiation.The Knowledge Engi- neering Review, 18 :343-375, 2003. [13] D. Walton and E. Krabbe.Commit- ments in Dialogue : Basic Conceptsof Interpersonal Reasoning. SUNYPress, 1995.quotesdbs_dbs12.pdfusesText_18

[PDF] convertir des minutes en heures

[PDF] convertir seconde en heure minute seconde

[PDF] convertir secondes en heures minutes secondes excel

[PDF] tableau de conversion de seconde

[PDF] 1h30 en seconde

[PDF] comment enregistrer une video de youtube

[PDF] comment enregistrer une video sur pc

[PDF] enregistrer video internet

[PDF] flash video downloader

[PDF] appreciation production ecrite

[PDF] exercices cahier du jour cp

[PDF] exemple cahier du jour cp

[PDF] appréciations sur les cahiers

[PDF] cahier du jour cp page de garde

[PDF] les remarques des profs sur les cahiers