Gabriela Vis¸inari

Sistem semantic pentru monitorizarea contractelor electronice

Xxxxxxxx Xxx¸inari

Universitatea Tehnica˘ din Cluj-Napoca Departamentul de Calculatoare Xxxxxxxx.Xxxxxxxx@xx.xxxxxx.xx

Cluj-Napoca, Romania

REZUMAT

Propunem un sistem de gestiune a contractelor ˆıntre agen¸tii economici. Dupa˘ formalizarea contractelor, acestea sunt monitorizate s¸i la incalcarea lor se activeaza˘ mecanismul de remediere a disputelor. Platforma colaborativa˘ dezvoltata˘ permite generarea de explica¸tii privind cauzele ˆınca˘lca˘rii prin interogarea ontologiei pe baza ca˘reia contractele au fost instan¸tiate. Serviciile de ra¸tionare ale Logicii Descrip- tive sunt utilizate pentru verificarea formala˘ a consisten¸tei clauzelor contractuale.

INTRODUCERE

Nu ˆıntotdeauna un contract decurge conform regulilor sta- bilite. Adesea, un contract se executa˘ fa˘ra˘ a avea informa¸tii cu privire la alte contracte ale pa˘r¸tilor implicate [4]. In practica˘, agen¸tii economici se afla˘ ˆın diverse dependen¸te contractuale, ˆındeplinirea cu succes a unui contract fiind

Xxxxxx Xxxxx

Universitatea Tehnica˘ din Cluj-Napoca Departamentul de Calculatoare Xxxxxx.Xxxxx@xx.xxxxxx.xx

Cluj-Napoca, Romania

Figura 1. Concepte generale in ontogia contractelor.

condi¸tionata˘ de alte contracte. Prin analiza situa¸tiei de

ansamblu, obiectivul lucra˘rii este de a identifica cauzele ˆınca˘lca˘rii clauzelor s¸i de a genera explica¸tii pa˘r¸tilor cu privire la aceste cauze.

Sistemele multi-agent constituie instrumenta¸tia tehnica˘

adecvata˘ problemei adresate. Fiecare agent pa˘streaza˘ o baza˘ de cunos¸tin¸te iar apoi executa˘ ac¸tiuni. ˆIn momentul ˆın care se executa˘ o ac¸tiune, o regula˘ din contract este acti- vata˘. ˆIn caz ca˘ regula este ˆınca˘lcata˘, va rezulta o consecin¸ta datorita˘ ca˘reia una din pa˘r¸ti are de suferit. Agentul care reprezinta˘ partea victima˘ are dreptul de a cere o explica¸tie partenerului care a ˆınca˘lcat clauza. Explica¸tia este generata˘ pe baza istoricului evenimentelor petrecute de la momentul ini¸tierii contractului.

Avaˆnd propria baza˘ de cunos¸tiin¸te, cu informa¸tii la care ceilal¸ti agen¸ti nu au acces, agen¸tii pot sa˘ argumenteze sau sa˘ explice [3] validitatea sau invaliditatea ˆınca˘lca˘rii unei clauze contractuale. Similar, agentul acuzat aduce dovezi extrase din analiza propriei baze de cunos¸tin¸te s¸i poate sa˘- s¸i construiasca˘ argumente ˆın apa˘rarea lui. Agentul acuzator poate la raˆndul lui sa˘ ofere argumente care sa˘ dovedeasca˘ falsitatea argumentelor aduse anterior de agentul acuzat.

Figura 2. Instante de contracte.

pieselor. Urma˘rind firul de evenimente apa˘rute , se pot ex- trage explica¸tii complexe numai daca˘ pa˘r¸tile contractuale sunt legate printr-o re¸tea. De aici apare ideea modela˘rii pa˘r¸tilor cu ajutorul agen¸tilor s¸i urma˘rirea ac¸tiunilor dintre aces¸tia.

REPREZENTAREA CONTRACTELOR ˆIN LOGICA DE- SCRIPTIVA˘

Iˆn aceasta˘ sec¸tiune se prezinta˘ modul ˆın care contractele au fost formalizate ˆın sintaxa Racer [2]. Figura 1 arata˘ modul de reprezentate al conceptele s¸i rela¸tiile de la nivelul gen- eral al ontologiei. Figura!2 exemplifica˘ instan¸te la nivelul general al ontologiei. In plus, ˆın RacerPro se pot defini reguli cu ajutorul limbajului nRQL. Metoda dupa˘ care se aplica˘ o regula˘ este urma˘toarea: daca˘ pentru variabilele

Dialogul argumentativ continua˘ paˆna˘ caˆnd cei doi agen¸ti

din corpul regulii, precondi¸tia, exista˘ indivizi ˆın ABox

cad de comun acord asupra evenimentelor petrecute.

Un exemplu este cazul ˆın care o firma˘ care produce calcula- toare comanda˘ piese de la o alta˘ companie. Motivul pentru care un calculator nu a putut fi construit la timp poate fi faptul ca˘ piesele necesare nu au fost livrate ˆın timpul sta- bilit. Acest lucru poate fi cauzat fie de nerealizarea la timp a pieselor comandate, fie de cei responsabili cu livrarea

care se pot lega la variabile astfel ˆıncaˆt precondi¸tia sa˘ fie ˆındeplinita˘, atunci aser¸tia prezenta˘ ˆın capul regulii, con- cluzia este ada˘ugata˘ la ABox cu variabilele instan¸tiate cu indivizii care satisfac condi¸tiile din corpul regulii. Pentru fiecare regula˘ se procedeaza˘ la fel paˆna˘ caˆnd nu mai ra˘maˆne nimic de ada˘ugat ˆın ABox. Pentru sistemul automat de ex- ecutare a contracteor o regula˘ valida˘ este urma˘toarea:

(define-rule (?contract-var (= is-violated ”true”)) (?contract-var ?clause-var has-violated-clause))

Precondi¸tia regulii de mai sus este (?contract-var ?clause- var has-violated-clause)) iar concluzia regulii de mai sus este (?contract-var (= is-valid ”false”)), adica˘, ˆın limbaj natural, Un contract este ˆınca˘lcat daca˘ s¸i numai daca˘ are o clauza˘ ˆınca˘lcata˘. Se observa˘ ca˘ este vorba de o rela¸tie daca˘ s¸i numai daca˘, as¸adar regula definita˘ este incompleta˘, reprezentaˆnd numai prima parte a teoremei. ˆIn continuare se prezinta˘ o a doua regula˘ care sa˘ se asigure ca˘ teorema a fost declarata˘ ˆın totalitate.

(define-rule (?contract-var ?clause-var has-violated-clause))

(and (?contract-var ?clause-var has-clause) (?clause-var (= is-clause-violated ”true”)))

Aceasta˘ regula˘ reprezinta˘ urma˘toarea propozi¸tie: Daca˘

un timp de start s¸i unul de final, o parte contractanta˘ poate benefcia de bonusul pentru cincisprezece zile:

(define-event-rule ((valid-bonus ?actor ?contract) ?t1 ?t2) ((take-bonus ?actor) ?t1 ?t2)

((contract-executes ?contract) ?t1 ?t2 )

Pentru a se verifica daca˘ exista˘ un actor care sa˘ beneficieze de un bonus valid, se utilizeaza˘ urma˘toarea interogare:

(timener-retrieve ((valid-bonus ?actor ?contract) ?t1 ?t2)

Se retuneza˘ o lista˘ cu perechi(variabila˘, valoare-variabila˘) pentru a se sublinia instan¸tele ce pot fi asociate interoga˘rii ˆın caz ca˘ exista˘, sau nil ˆın caz ca interogarea nu ga˘ses¸te instan¸te ce pot lua locul variabliei.

GESTIUNEA COLABORATIVA˘ A CONTRACTELOR

Pentru stocarea s¸i vizualizarea contractelor ˆın limbaj nat-

o clauza˘ face parte dintr-un contract s¸i clauza a fost

ural s-a utilizat Google Drive. Google permite ada˘ugarea

ˆınca˘lcata˘, atunci contractul se considera˘ a fi violat.

Generare explicat¸ii. La acuza¸tia unui agent ca˘ o regula˘ a fost ˆınca˘lcata˘, agentul victima˘ ar putea cere o explica¸tie deoarce el nu considera˘ ca˘ ar fi violat contractul. Agentul acuzator va oferi o explica¸tie bazata˘ pe informa¸tiile de¸tinute ˆın baza proprie de cunos¸tin¸te s¸i anume ˆın ABox-ul per- sonal. Este posibil ca agentul victima˘ sa˘ nu dispuna˘ de informa¸tiile necesare pentru formarea explica¸tiei pe care agentul acuzator le de¸tine. ˆIn acest caz, pentru fiecare ax- ioma˘ pe care agentul victima˘ nu o poate deduce, acesta poate cere o noua˘ explca¸tie de la agentul acuzator:

(retrieve-with explanation (and Actor (some has-violated Contract) (some contracted X)))

Iˆn exemplul de mai sus se cere un ra˘spuns ˆınso¸tit de explica¸tii pentru a justifica de ce exista˘ un actor care a ˆıncheiat un contract cu X s¸i care a violat contractul.

Utilizarea de evenimente. ˆIn unele aplica¸tii se vrea ca anumite aser¸tii sa˘ fie valide numai ˆıntr-un anumit inter- val de timp. ˆIn cazul contractelor se poate men¸tiona ca˘ o parte contractanta˘, cumpa˘ratorul, beneficiaza˘ de o reduc-

de comentarii daca˘ se dores¸te purtarea unei conversa¸tii pe marginea unui document stocat pe Google Docs/ Google Drive, la care un utilizator poate lucra ˆın prezent. Mai multe comentarii sunt grupate ˆın discu¸tii. Astfel, comentariile ce apar¸tin unei discu¸tii anume pot fi adresate unui grup re- straˆns de utilizatori, pot avea o tema˘ specifica˘, pot avea lega˘tura˘ cu un grup restraˆns de documente. O discu¸tie poate urma˘ri comentariile ada˘ugate prin intermediul e-mailului.

ˆIn lucrearea [4] contractele sunt pa˘strate pe Google Docs ˆın format doc. Prin urmare, comentariile ar putea fi utilizate pentru a se purta o discu¸tie pe marginea contractelor. Un exemplu este cazul caˆnd un agent cere explica¸tii unui alt agent. Explica¸tiile ar putea fi redate ca s¸i comentarii. O vi- itoare direc¸tie ˆın dezvoltarea lucra˘rii de fa¸ta˘ este traducerea comentariilor din limbajul RacerPro ˆın limbaj natural.

Pa˘strarea comentariilor reprezinta˘ o sursa˘ pentru istoricul executa˘rii contractului. Pentru ada˘ugarea unui comentariu este nevoie de trei etape. ˆIn prima etapa˘ trebuie selectat tex- tul, pagina dintr-un document sau documentul pe marginea ca˘ruia se va face comentariul. ˆIn cea de a doua etapa˘ se alege sa˘ se insereaze comentariul. Iˆn cea de a treia etapa˘

ere de pre¸t sau un bonus din partea altei pa˘r¸ti contrac-

tante, vaˆnza˘torul, pe o perioada˘ de cincisprezece zile dintr- un abonament pe un an ˆın care se stipuleaza˘ ca˘ timp de un an vor fi achizi¸tionate bunuri de ca˘tre cumpa˘ra˘tor de la vaˆnza˘tor. RacerPro suporta˘ inferen¸ta˘ temporala˘ ca s¸i parte a sistemului nRQL. Se utilizeaza˘ comanda (define-event- assertion) care ia ca parametri aser¸tia ce trebuie facuta˘, timpii de start s¸i de final pentru care aser¸tia este valabila˘:

(implies Actor *top*) (instance X Actor)

(define-event-assertion (take-bonus X) 1 15)))

Aser¸tia subliniaza˘ faptul ca˘ un actor X poate beneficia de bonus de la timpul de start 1, prima zi, paˆna˘ la timpul de final 15, a cincisprezecea zi de la formarea abonamentu- lui. Pentru aplicarea de reguli bazate pe evenimente, se uti- lizeaza˘ comanda (define-event-rule). De exemplu, o regula˘ ar putea men¸tiona ca˘ atunci caˆnd contractul/abonamentul dintre doua˘ pa˘r¸ti nu a expirat ˆınca˘, adica˘ este valabil ˆıntre

se scrie comentariul ˆın caˆmpul care apare laˆnga˘ obiectul pe marginea ca˘ruia se comenteaza˘. Aces¸tia sunt pas¸ii de utilizare a comentariilor utilizaˆnd interfa¸ta grafica˘ oferita˘ de Google. La inserarea unui comentariu, se poate decide daca˘ acesta sa˘ fie trimis printr-un email unei persoane, prin introducerea unei adrese de email, exemplu: +contractA- xxxxX@xxxxxx.xxx. Se poate da reply la un comentariu, se poate s¸terge sau edita un comentariu anterior, acesta fi- ind un caz util pentru momentul caˆnd unul din agen¸ti, la primirea de noi informa¸tii, vrea sa˘ modifice o explica¸tie an- terioara˘. Dezavantajul ˆıl reprezinta˘ pierderea informa¸tiilor cu privire la istoricul executa˘rii contractului. ˆIn figura 3 se ilustreaza˘ modul ˆın care pot fi folosite comentariile. ˆIn partea staˆnga˘ apare contractul pe marginea ca˘ruia se dis- cuta˘. ˆIn partea dreapta˘ apare spa¸tiul ˆın care pot fi ada˘ugate comentarii s¸i op¸tiunea de setare de notifica˘ri, ˆın caz ca˘, de exemplu, la ada˘ugarea unui comentariu se vrea sa˘ se trimita˘ un email la de¸tina˘torul documentului. Se va real- iza integrarea comentariilor Google cu aplica¸tia deja ex-

Figura 3. Generarea de explicatii prin rationare semantica in plat- forma colaborativa Google Drive.

de achizi¸tionare de componente pentru calculator, termenii pentru definirea entita˘¸tilor din contract s¸i a rea¸tiilor dintre ele vor fi diferi¸ti de cei dintr-un contract de ˆınchiriere.

Verificarea daca˘ terminologia de la nivelulul general este consistenta˘: la definirea conceptelor, rela¸tiilor sau regulilor dintr-un contract este posibil sa˘ apara˘ inconsisten¸te. Astfel, unele defini¸tii ar putea sa˘ se afle ˆın rela¸tie de contradic¸tie. Detectarea erorilor de genul acesta trebuie fa˘cuta˘ automat prin verificarea consisten¸tei taxonomie definite la primul caz de utilizare.

Verificarea daca˘ terminologia de la nivelul specific este

Figura 4. Cazurile de utilizare ale sistemului.

istenta˘ descrisa˘ ˆın [4]. Google pune la dispozi¸tie un API care poate fi accesat din orice aplica¸tie pentru ada˘ugarea de comentarii prinr-un alt produs software. Utilizaˆnd Google Drive SDK[1] pot fi accesate servicii de inserare, s¸tergere sau modificare a unui comentariu, con¸tinutul cererilor fiind de tip JSON.

ARHITECTURA SISTEMULUI

In cele ce urmeaza˘ se va face o descriere completa˘ a fieca˘rui caz de utilizare din 4, detailindu-se ˆın ce consta˘ fiecare pas:

Definirea ontologiei de contracte generale: contractele ˆımpa˘rtas¸esc no¸tiuni comune precum cea de parte contrac- tanta˘, rol, clauza˘, date de contact pentru pa˘r¸tile contrac- tante, momentul caˆnd a ˆınceput executarea unui contract sau caˆnd acesta expira˘. To¸ti termenii comuni pentru toate tipurile de contract trebuie defini¸ti astfel ˆıncaˆt aceleas¸i reg- uli sa˘ poata˘ fi aplicate indiferent de tipul de contract.

Definirea ontologiei generice de contracte specifice: des¸i toate contractele au o parte comuna˘, as¸a cum s-a men¸tionat la cazul de utilizare anterior, partea specifica˘ este de cele mai multe ori mai complexa˘ cuprinzaˆnd detalii ˆın func¸tie de tipul de contract. De obicei partea de clauze este spe- cifica˘ fieca˘rui tip de contract. Asftel, pentru un contract

consistenta˘: la fel ca la cazul de utilizare anterior, s¸i termi- nologia specifica˘ tipului de contract care se executa˘ poate suferi inconsisten¸te. De aceea este nevoie de un verdict care sa˘ confirme sau sa˘ infirme consisten¸ta terminologiei s¸i eventual sa˘ returneze motivul pentru care terminologia s-a decis a fi inconsistenta˘.

Instan¸tierea unui contract: o data˘ ce no¸tiunile necesare pentru a descrie un contract au fost definite, se poate de- scrie un contract concret, utilizaˆnd ataˆt terminologia de la nivelul general caˆt s¸i pe cea de la nivelul specific. Ast- fel, fiecare din conceptele s¸i rela¸tiile definite anterior, vor fi instan¸tiate.

Verificarea daca˘ instan¸ta de contract este consistenta˘: ex- ista˘ posibilitatea sa˘ apara˘ inconsisten¸te s¸i la nivelul unei instan¸te de contract. De exemplu, se poate declara ca˘ un contract expira˘ la o data˘ anterioara˘ momentului de start a contractului. ˆIn acest caz se va semnala o eroare de inconsisten¸ta.

Executarea unei ac¸tiuni legate de contract: Fiecare ac¸tiune ce poate influen¸ta rezultatul final al executa˘rii contractu- lui trebuie sa˘ poata˘ fi executaa˘ ˆın acest context, astfel ˆıncaˆt rezultatul invoca˘rii ei sa˘ determine schimba˘ri ˆın evolu¸tia contractului. Pentru ob¸tinerea ulterioara˘ a unor explica¸tii complete care sa˘ justifice anumite fapte, ac¸tiunile trebuie pa˘strate ˆıntr-un istoric.

Detectarea regulilor ˆınca˘lcate: ˆInca˘lcarea unei reguli este evenimentul principal urma˘rit ˆın cadrul unui contract. O

data˘ cu violarea unei clauze, ˆıntreg contractul este nere- spectat. Pentru aceasta este nevoie ca orice ˆınca˘lcare de clauza˘ sa˘ fie detectata˘, iar conflictul generat de acest eveni- ment sa˘ fie rezolvat. Detectarea neregulilor se face pe baza axiomelor definite ˆın primele doua˘ cazuri de urilizare s¸i de- sigur, a valorilor concrete de la nivelul instan¸telor.

Cererea de explica¸tii pentru violarea contractului: La mo- mentul ˆınca˘lca˘rii unei reguli, agentul acuzator va cere o explica¸tie. Agentul care a ˆınca˘lcat regula va trebui sa˘ for- muleze o explica¸tie care sa˘ justifice ac¸tiunile executate sau ca sa˘ contrazica˘ acuza¸tia celeilate pa˘r¸ti cum ca˘ a ˆınca˘lcat o anumita˘ regula˘.

Furnizarea explica¸tiei pentru violarea contractului: gener- area unei explica¸tii pentru ˆınca˘lcarea unei clauze se va re- aliza prin consultarea propriei baze de cunos¸tiin¸te s¸i comu- nicarea cu agen¸tii colaboratori.

adauga˘ un comentariu pe Google asociat contractului: Re- zolvarea conflictelor ˆın cazul contractelor se face de multe ori prin comunicare. De exemplu, conflictele pot apa˘rea

Figura 5. Arhitectura sistemului.

ID	TIP	PARTEA 1	PARTEA 2
1	va˘nzare-cumpa˘rare	Xxxx Xxx	Xxxx Xxxxxx
2	ˆınchiriere	Xxxx Xxx	Xxxx Xxxxxx
3	va˘nzare-cumpa˘rare	Xxxx Xxx	Xxx Xxxxx

Table 1. Instant¸e de contracte.

din cauza lispei de informa¸tii. Asftel, o parte contractanta˘ ar putea crede ca˘ o regula˘ a fost ˆınca˘lcata˘ de partea cu care a ˆıncheiat contractul, acest lucru fiindu-i infirmat de partea acuzata˘ prin aducerea de argumente sau explica¸tii. ˆIn mo- mentul ˆın care se cere o explica¸tie sau se generaza˘ una, un nou comentariu Google va fi ada˘ugat.

Figura 6. Organizarea ontologiei multi-nivel pentru cazul concret al contractelor din tabelul 1.

MENTIUNI

Parte din cercetare s-a derulat in cadrul proiectului ”Ar- gumentare structurata pentru suport decizional cu con- strangeri normative”, programul PN-II Cooperari Bilaterale Romania-Republica Moldova, 2013-2014, UEFSCDI.

CONCLUZII

S-au implementat s¸abloane pentru diferite tipuri de con- tracte, fiind posibila˘ ˆın acelas¸i timp s¸i personalizarea lor. Prin ˆımpa˘r¸tirea ontologiei pe nivele s-a acordat importan¸ta˘ performan¸tei sistemului, fiind suficient ca TBox-ul s¸i ABox-ul general sa˘ fie ˆınca˘rcate o singura˘ data˘ ˆın RacerPro. Informa¸tiile din contracte au fost decuplate, ˆıncurajaˆndu-se reutilizarea lor iar cele confiden¸tiale nu au fost distribuite altor pri. Situa¸tiile conflictuale dintre pa˘r¸ti au fost rezol- vate cu ajutorul explica¸tiilor. S-a realizat un mediu colab- orativ pentru pa˘r¸tile contractante prin integrarea aplica¸tiei cu Google Drive. Cercetare in desfasurare se focalizeaza

listeaza˘ comentariile pentru un anumit contract: Pentru

pe monitorizarea excep¸tiilor apa˘rute ˆın sistem, construirea

ˆın¸telegera modului ˆın care a fost executat un contract s¸i a rezolva˘rii conflictelor, istoricul conversa¸tiilor purtate ˆın contextul contractului sunt relevante. De aici apare nevoia de a vizualiza toate comentariile ada˘ugate pe parcursul desfa˘s¸ura˘rii unui contract.

vizualizeaza˘ lista cu contractele violate pentru o parte contractanta˘: Orice agent are nevoie de o lista˘ cu con- tractele ˆınca˘lcate pentru a s¸tii ca˘ ˆın acele cazuri trebuie ini¸tializat protocolul de rezolvare a conflictelor cu ajutorul explica¸tiilor. ˆIn figura 5 se observa˘ ca˘ ABox-ul general s¸i TBox-ul general este stocat la nivelul fieca˘rei pa˘r¸ti contrac- tante. La fel, pentru fiecare tip de contract ˆın care este im- plicat, un agent pa˘streaza˘ s¸i un TBox specific. Desigur, pentru fiecare contract ˆıncheiat va exista un ABox specific. Motiva¸tia utiliza˘rii acestei arhitecturi este executarea pro- ceselor caˆt mai aproape de date pentru a reduce traficul, pa˘strarea confiden¸tialita˘¸tii, cunos¸tin¸tele de¸tinute de o parte fiind ferite de accesul unei ter¸te pa˘rˆı. Un ultim motiv, foarte important, este evitarea single point of failure. Accesul la serviciile RacerPro se face prin intermediul libriei Java, JRacer.

Iˆn figura 6 poate fi vizualizat modul ˆın care vor fi pa˘strate bazele de cunos¸tin¸te ˆın conformitate cu afirma¸tiile ante- rioare. Tabelul 1 exemplifica˘ un caz de utilizare pentru con- tracte.

unei taxonomii de excep¸tii s¸i luarea deciziilor ˆın func¸tie de tipul excep¸tiilor [5]. Astfel, ˆın anumite cazuri nu va mai fi necesara˘ interogarea agen¸tilor, tipul de excep¸tie fiind sufi- cient pentru diagnosticarea unei probleme.

REFERINT¸ E

1. Xxxxxxxxxx, X. Google drive sdk. xxxxx://xxxxxxxxxx.xxxxxx.xxx/xxxxx/x0/xxxxxxxxx/.

2. Xxxxxxxx, V., Xxxxx, K., Mo¨ller, R., and Xxxxxx, M. The RacerPro knowledge representation and reasoning system. Semantic Web 3, 3 (2012), 267–277.

3. Xxxxx, I. A., and Xxxxx, X. Interleaved argumentation and explanation in dialogue. In The 12th Workshop on Computational Models of Natural Argument CMNA@ECAI, Montpellier, France (2012), 44–52.

4. Xxxxxxxx, X., and Xxxxx, A. Builing an e-contracts management tool using google docs. In 12th IEEE International Symposium on Computational, Intelligence and Informatics, IEEE (21-22 November 2012).

5. Xx, D., Xxxxxxxxxxx, C., Xxxx, Y., and Xxxxxxx, X.

Outbound logistics exception monitoring: A

multi-perspective ontologies approach with intelligent agents. Expert Syst. Appl. 38, 11 (2011), 13604–13611.