You are on page 1of 69

Modele de reprezentare a contextului şi mecanisme de descoperire dinamică a elementelor de context

- Proiect “Idei” cod 1062 / 2008 -

Autori: Marcel Cremene, Anca Rarău, Iulian Benţa, Valeriu Todica, Costin Miron, Alin Drimuş

Data: 31.10.2008 Versiune: Finală

Cuprins: Modele de reprezentare a contextului şi mecanisme de descoperire dinamică a elementelor de context ........................................................................................................ 1 - Proiect “Idei” cod 1062 / 2008 -................................................................................... 1 1 Introducere .................................................................................................................. 4 1.1 Situarea raportului în contextul proiectului.......................................................... 4 1.2 Concepte utilizate................................................................................................. 4 1.3 Funcţiile unui sistem de descoperire automată a elementelor de context ............ 6 1.4 Organizarea raportului.......................................................................................... 7 2 Contextul: definire şi modelare................................................................................... 8 2.1 Modelarea contextului.......................................................................................... 8 2.2 Caracteristici ale modelelor de context ................................................................ 8 2.2.1 Compoziţia distribuită................................................................................... 9 2.2.2 Validarea ....................................................................................................... 9 2.2.3 Cantitatea şi calitatea informaţiei.................................................................. 9 2.2.4 Completitudinea.......................................................................................... 10 2.2.5 Suportul pentru raţionare ............................................................................ 10 2.3 Principalele clase de modele .............................................................................. 10 2.3.1 Modele bazate pe perechi atribut-valoare ................................................... 11 2.3.2 Modele bazate pe tehnologie web............................................................... 12 2.3.3 Modele ce folosesc scheme de marcare ...................................................... 13 2.3.4 Modele grafice ............................................................................................ 19 2.3.5 Modele bazate pe logică.............................................................................. 21 2.3.6 Modele orientate obiect............................................................................... 23 2.3.7 Modele bazate pe ontologii......................................................................... 24 2.4 Comparaţie între clasele de modele de context.................................................. 28 2.5 De ce sunt potrivite ontologiile în reprezentarea contextului?........................... 29 2.5.1 Raţionarea ontologică ................................................................................. 29 3 Mecanisme de descoperire a contextului .................................................................. 32 3.1 Protocoale de descoperire a contextului............................................................. 32 3.1.1 R-CDP......................................................................................................... 32 3.1.2 Directed diffusion ....................................................................................... 34 3.1.3 SPIN............................................................................................................ 37 3.1.4 Filtre Bloom ................................................................................................ 39 3.2 SOCAM (Service-Oriented Context-Aware Middleware)................................. 39 3.3 Context Toolkit .................................................................................................. 40 3.4 SCI...................................................................................................................... 40 3.5 Concluzii ............................................................................................................ 40 4 Observarea contextului în cazul aplicaţiilor adaptive implementate ........................ 42 4.1 Observarea contextului în cazul platformei SOA .............................................. 42 4.1.1 Scenariu....................................................................................................... 42 4.1.2 Reprezentarea contextului........................................................................... 42 4.1.3 Detectarea contextului ................................................................................ 43 4.1.4 Transmiterea contextului ............................................................................ 43 4.2 Observarea contextului în cazul platformei de agenţi........................................ 45 2

4.2.1 Reprezentarea preferinţelor utilizatorului ................................................... 45 4.2.2 Mecanisme de descoperire a preferinţelor .................................................. 46 4.2.3 Soluţii propuse ............................................................................................ 47 Folosirea unui sistem multiagent este justificată de faptul că există părţi componente cu roluri specifice, cu necesităţi de resurse de calcul diferite şi distribuite spaţial (chiar mobile), relativ autonome. ................................................................................................ 57 Limbajul de interogare Jadex (Jadex Query Language) ................................................... 57 4.3 Observarea contextului in cazul platformei WComp......................................... 57 4.3.1 Arhitectura aplicaţiei realizate .................................................................... 57 4.3.2 Modelarea şi observarea contextului .......................................................... 58 4.3.3 Înregistrarea dispozitivelor ......................................................................... 59 4.3.4 Observarea şi filtrarea contextului .............................................................. 60 4.3.5 Testarea aplicaţiei ....................................................................................... 60 5 Concluzii şi dezvoltări viitoare ................................................................................. 62 Bibliografie ....................................................................................................................... 64

3

3.3.2. acelaşi avion are o autonomie faţă de comenzile pilotului dar nu are libertatea de a-şi alege singur ruta. and technical complexity of computing systems. îşi propune ca prim obiectiv rezolvarea problemei gestiunii complexităţii sistemelor: „To deal with the increasing business. Utilitatea unui sistem autonom provine din aceea că acesta 4 . soluţiile propuse de noi vor fi comparate cu soluţiile existente la ora actuală în acest sens. Studiul de modele de reprezentare a contextului şi de soluţii de descoperire automată a contextului. Totodată. De exemplu. adică în principal obiectivul O2/2008 şi o partea din obiectivul O3/2008. Un sistem poate fi autonom în sine ci numai faţă de un anumit lucru (o anumită problemă). 1. Activităţile asociate acestui obiectiv sunt următoarele: 2. Interpretarea rezultatelor şi redactarea de articole.Ce probleme ridică modelarea contextului? Ce fel de modele de context există. În modul pilot automat. numit „Autonomic Computing”. 2. ce avantaje/dezavantaje prezintă acestea? . Propunerea unei metode de descoperire automată a contextului pe baza caracteristicilor serviciului.1 Situarea raportului în contextul proiectului Obiectivul acestui raport este stabilirea unui model de reprezentare a contextului şi a unor mecanisme de descoperire automată a acestuia. 3. Întrebările esenţiale legate de tema acestui raport sunt următoarele: . încă în curs de maturizare. Propuneri de optimizare pe baza rezultatelor obţinute.1. Domeniul. Implementarea metodei propuse şi integrarea acesteia în platforma de test realizată la obiectivul 1/ 2008.1 Introducere Acest raport îşi propune să prezinte o serie de soluţii propuse pentru problema modelării contextului.2 Concepte utilizate Sistem autonom.1. 3.3.Ce înţelegem prin context? Din ce este compus acesta? . Testarea de scenarii de adaptare complexe. un avion poate avea o autonomie de zbor de 6 ore (nu necesită alimentare) dar nu este neapărat autonom faţă de pilotul său (adică nu zboară unde vrea el).Care este problema ştiinţifică pe care o tratăm? În ce constă particularitatea şi originalitatea soluţiei noastre? 1. networks and applications must learn to manage themselves in accordance with high-level guidance from humans” (lozica conferinţei ICAC’08 pe tema „Autonomic Computing”). 2. respectiv a descoperirii dinamice a elementelor de context. devices. system.Ce înţelegem prin observarea dinamică a contextului? Ce metode/soluţii există la ora actuală? Ce inconveniente prezintă acestea? .2.

la limită.). specific umane. Sistem senzitiv în mod autonom la context.este capabil să rezolve fără intervenţie umană o anumită problemă. Există o submulţime a acestei părţi semnificative: partea semnificativă şi sesizabilă. de exemplu. şi nu de „nivel jos”. b) Scrierea şi modificarea de politici de adaptare (reguli şi strategii). 5 . Aceste elemente se selectează în general de către un operator uman pe baza semnificaţiei lor faţă de un sistem. luminozitate. Acest lucru este posibil. Senzitivitatea sistemului poate fi înţeleasă prin analogie cu senzitivitatea organismelor biologice. Descoperirea autonomă a contextului se poate înţelege. Activităţile principale care sunt rezolvate de către dezvoltator în cazul sistemelor senzitive la context neautonome sunt următoarele: a) Stabilirea şi modificarea contextului. aceeaşi problemă necesită intervenţia unui operator uman în cazul unui sistem neautonom. conceptul de „semnificaţie” trebuie să fie înţeles de către maşină. care achiziţionează date despre context. Prin descoperirea autonomă a contextului înţelegem automatizarea activităţii. Pentru ca acest lucru să fie posibil. Un sistem senzitiv la context posedă o senzitivitate autonomă dacă sistemul respectiv automatizează cel puţin parţial activităţile descrise mai sus. De exemplu. autonomia apare atunci când o problema care era rezolvată înainte de către un operator uman. printr-o analogie cu organismul uman care este dotat cu un set finit de senzori ce percep în mod egocentric universul. Un sistem senzitiv la context este un sistem compus din componente hardware şi software. b) Componente de analiză şi decizie (analog creierului) c) Componente-efector care permit efectuarea unor acţiuni interne (în sistem) şi/sau externe. de determinare a elementelor din univers care sunt semnificative pentru un sistem senzitiv la context. Din contră. Descoperire autonomă a contextului. ambianţă etc. contextul se reduce la câteva elemente care caracterizează mediul înconjurător (ex. este necesar ca operatorul uman să aibă control asupra sistemului dar prin interacţiune pe care o numim de „nivel înalt”. care reacţionează la mediul său înconjurător numit context. adică legat de detaliile interne ale sistemului. (analog muşchilor). de exemplu. în practică. O altă variantă este ca senzorii să fie distribuiţi în mediul înconjurător. dacă temperatura şi presiunea atmosferică sunt aspect semnificative pentru un sistem dar posedăm numai un senzor de temperatură atunci contextul este determinat numai de temperatură. este acum automatizată deci o rezolvă maşina de calcul fără intervenţie umană. asupra contextului. Gestiunea complexităţii este o consecinţă a faptului că anumite probleme sunt rezolvate fără intervenţie umană. Sistem senzitiv la context. ceea ce înseamnă determinarea acelei părţi din univers care este semnificativă pentru sistem. Context. apropiat de limbajul natural. În acelaşi timp. Contextul este. temperatură. poziţie. Conform definiţiei unui sistem autonom. întregul univers. Fiind imposibil să lucrăm practic un astfel de concept fără limite. Astfel. într-o casă inteligentă. disponibili în funcţie de localizare. un sistem senzitiv la context posedă anumite componente specializate cum ar fi: a) Componente-senzori (analog organelor de simţ).

se determină care dintre senzorii descoperiţi sunt semnificativi pentru sistemul respectiv. bazată pe ipoteza senzorilor distribuiţi.Senzorii emit atât informaţii despre mediu cât şi informaţii despre semnificaţia lor. EventCondition-Action) Abordarea bazată pe un model ServiciuContext. . probleme: P1. abordare model ServiciuContext) Bazată pe politici de adaptare definite a priori (ex.O posibilă metodă pentru descoperirea autonomă a contextului. Adaptare statică (la design sau implementare) System adaptiv CE? Adaptare dinamică (la runtime) CUM? Bazată pe un mecanism de generare de noi politici (ex. . Problema observării contextului în raport cu tema proiectului 6 . este necesar să reamintim justificarea introducerii acestei probleme în propunerea de proiect. Observarea ansamblului Serviciu-Context P2. . este următoarea: .1.Pe baza informaţiei semantice şi pe baza semanticii interne a sistemului (care se presupune a fi descrisă).p. .d.Se defineşte un protocol de descoperire a senzorilor disponibili din apropiere.3 Funcţiile unui sistem de descoperire automată a elementelor de context Pentru a înţelege mai clar modul particular în care privim problema observării contextului în raport cu tema proiectului. Găsirea de soluţii de adaptare a Serviciului la Context Figura 1. datele colectate se folosesc de către componentele de analiză şi decizie (creierul sistemului senzitiv). semantic.Se stabileşte conexiunea cu senzorii selectaţi ca fiind semnificativi şi se colectează date. 1.Se presupune că în mediu există senzori distribuiţi care pot fi accesaţi. altfel spus sunt descrişi d.v.

tocmai profilul unui serviciu este cel care face legătura dintre serviciu S şi contextul sau C. enunţate mai jos. Aşa cum putem observa din această figura. concluzia la care am ajuns este că autonomia adaptării presupune existenţa unui mecanism de generare de noi politici (reguli. Capitolul trei prezintă un studiu asupra descoperirii şi compunerii contextului. Acest lucru este necesar deoarece. servicii de observare) care pot furniza informaţii despre contextul indicat de către profilul P al serviciului S.4 Organizarea raportului Acest raport este organizat în felul următor: capitolul următor face o trecere în revistă a mai multor modele de context. a rezultat faptul că există două probleme esenţiale distincte legate de observarea contextului. O condiţie esenţială pentru ca această abordare să funcţioneze este ca acest ansamblu Serviciu-Context să poată fi observat în mod dinamic. dacă se cunosc arhitectura internă a serviciului şi profilele componentelor sale interne Ci. P1) Determinarea profilului P al unui serviciu S. În teza [Crem05phd] am propus o abordare care se baza pe modelul ansamblului Serviciu-Context. Această problema este una de compunere a profilelor şi implicit a contextelor mai multor componente. strategii) de adaptare. P1 şi P2 dar ea trebuie să faciliteze pe cât se poate rezolvarea acestora. conform abordării din [Crem05phd]. După studierea mai multor lucrări din domeniu. 1. P2) Identificarea surselor de informaţie (senzori. care se bazează pe un mecanism de generare de noi politici de adaptare. Din studiile efectuate asupra problemei descoperirii contextului. În teza [Crem05phd] sa propus un model de reprezentare a ansamblului Serviciu-Context bazat pe un graf dar este necesar să comparăm acest model cu alte modele existente pentru o eventuală îmbunătăţire a acestuia. 7 . în timpul execuţiei. Această problemă este apropiată de domeniul numit „Context Discovery”. Raportul se încheie cu discuţii şi concluzii. care este modelarea contextului. Această problemă este cvasi-independentă de celelalte evocate anterior. P3). Binenţeles. ne interesează sistemele adaptive în mod dinamic. Capitolul patru ilustrează modul în care observarea contextului intervine în aplicaţiile pe care le-am dezvoltat. care este propunerea unei platforme sau sistem de reconfigurare dinamică şi autonomă a serviciilor. astfel încât sistemul să poată să se adapteze şi la stări neprevăzute ale contextului. există şi o a treia problemă esenţială. propusă în teza [Crem05phd]. şi în conformitate cu aceeaşi abordare.1 ilustrează plasarea temei generale a proiectului.Figura 1. adică în timpul execuţiei.

pe lângă senzori şi "creier electronic" are nevoie de o reprezentare a contextului într-un mod pe care sistemul de calcul îl înţelege. întinsă pe pat. Spre deosebire de acesta.2 Contextul: definire şi modelare În acest capitol descriem caracteristicile principalelor modele de context. iar lumina din cameră este stinsă. • actualizat sau optimizat. compoziţia distribuită. validarea. cantitatea şi calitatea informaţiei. 3. În experienţa noastră de zi cu zi ca oameni. 8 . cu ideea de mediu înconjurător. În acest exemplu. prezentăm o comparaţie între aceste clase de modele de context pe baza unor criterii de analiză. pentru a căror definire este necesară informaţia de la mai mulţi senzori. Exemple de context de nivel ridicat sunt situaţiile din realitate. Aceste modele sunt grupate în clase. având ca punct de pornire lucrarea de referinţă [Thom04]: 1. contextul de nivel scăzut este preluat direct de la senzori. ţinem seama de context în cel puţin două situaţii: • când selectăm din mediu doar informaţiile de care avem nevoie la acel moment şi în acel loc şi • când dorim să acţionăm cât mai adecvat situaţiei în care ne aflăm. contextul poate fi: • completat cu informaţia preluată de la senzori. Pentru ca un astfel de sistem de calcul să se comporte adecvat informaţiilor din mediu. Odată modelat. • folosit pentru deducerea elementelor de context de nivel ridicat pentru a răspunde într-un mod cât mai apropiat de cel presupus de utilizator la situaţia dată. În această lucrare. De pildă. • stocat (pentru a i se analiza evoluţia în timp sau pentru utilizare ei ulterioară). 4. 2. prin context de nivel ridicat se înţelege contextul abstract. Noţiunea de context în cazul unui sistem de calcul a fost deja prezentată în subcapitolul 1. poziţie (întins pe pat) şi luminozitate. 2. În final. contextul de nivel scăzut este format din elementele localizare. În continuare descriem aceste clase şi prezentăm câteva exemple semnificative pentru fiecare din aceste clase. completitudinea. în timp ce activitatea (doarme) reprezintă contextul de nivel ridicat. în general. se poate deduce că o persoană doarme din faptul că se află în dormitor.1 Modelarea contextului Contextul este asociat.2.2 Caracteristici ale modelelor de context În continuare se face o comparaţie a modelelor de context din perspectiva următoarelor caracteristici. 2. 5. suportul pentru raţionare.

Ca urmare. atunci aceste resurse de memorie trebuie să fie actualizate în modelul de context. ambele reprezentate sub formă de fişier XML.2.3 Cantitatea şi calitatea informaţiei 9 . alimentare etc. La momentul iniţial. În acest caz avem de a face cu o validare de tip sintactic. De exemplu. se pune problema schimbării unui model de context cu unul nou. O cauză posibilă a acestei situaţii ar fi o transmisie de date cu erori. reţea.1 Compoziţia distribuită Compoziţia distribuită se referă la capabilitatea unui model de context de a facilita: • unificarea modelului (şi a datelor pe care le conţine) din părţi de model şi/sau • modificarea (suprascrierea) lui (şi/sau a datelor pe care le conţine) în diferitele noduri ale reţelei distribuite ale unui sistem omniprezent. care va avea o anumită dimensiune în biţi.2. 2.2 Validarea Validarea se referă la capabilitatea unui model de context de a permite verificarea consistenţei structurii lui şi a tipului de date şi a domeniului valorilor datelor din model. fie un sistem distribuit format dintr-un telefon mobil şi un calculator legate într-o reţea locală (prin wireless LAN). a debitului pe canalele de comunicaţii şi a alimentării cu energie. Mai mult. comparativ cu calculatoarele personale. Cu cât contextul pe care vrem să îl modelăm este mai complex (este compus din mai multe elemente de context legate între ele). De asemenea. De exemplu. Ne interesează elementul de context memorie_disponibilă pe telefon.2. O aplicaţie manager de memorie rulează pe telefon. Se pune problema locului de stocare a imaginii. Dispozitivele mobile au limitări importante a capacităţii de prelucrare şi stocare a datelor. trebuie actualizate valorile acestor resurse de memorie (ex. este important ca modelele de context să poată fi compuse şi valorile lor administrate în cadrul sistemului distribuit. Dacă adăugăm o memorie externă sau dacă accesăm memoria calculatorului prin wireless LAN de pe telefonul mobil. capacitate de memorare de 1GB pentru memoria externă) pentru ca aplicaţia de gestiune a resursei de memorie să decidă unde poate stoca imaginea în funcţie de spaţiul de memorie pe care îl ocupă în memorie. atunci noul model nu va putea fi considerat validat. Modelele de context pot să ajungă să fie inconsistente datorită evoluţiei în timp a modelului şi a valorilor lui cu atât mai mult cu cât acestea sunt compuse din mai multe părţi în nodurile sistemului distribuit. 2. Preluăm o imagine cu camera foto a telefonului mobil. cu atât validarea ne poate ajuta să evităm erorile de modelare şi utilizare a modelului. acestea sunt obligate să cunoască valorile actuale ale elementelor de context şi să facă faţă variaţiei în timp şi în spaţiu a resurselor disponibile de calcul. din cauza mobilităţii. în fiecare nod. în memorie_disponibilă este menţionată doar memoria internă cu o valoare de 64 MB. Dacă în fişierul cu modelul nou una dintre etichete (tag-uri) nu se închide.2.

din faptul că un sistem de localizare detectează o persoană într-o încăpere şi din faptul că încăperea este într-un anumit imobil. Sistemul de localizare din piaţă este considerat mai de încredere decât sistemul global de poziţionare (GPS) deoarece oferă o precizie mai mare. 2.5 Suportul pentru raţionare Suportul pentru raţionare se referă la capabilitatea unui model de context de a facilita determinarea de informaţii noi din informaţiile existente în modelul de context. la care adăugăm clasa de modele bazate pe tehnologie web [Bill93]. De exemplu. 2. Este posibil ca din diverse cauze informaţia să nu ajungă de la senzori la dispozititivul mobil.4 Completitudinea Completitudinea se referă la capabilitatea unui model de context de face faţă lipsei unor date din model. Este important ca modelul de context să exprime această lipsă. Modelul de reprezentare a contextului trebuie să ofere suport pentru rezolvarea acestor situaţii.Cantitatea şi calitatea informaţiei se referă la capabilitatea unui model de context de a exprima caracteristici ale cantităţii şi calităţii informaţiei. cum este cazul unei camere în care există un senzor care raportează poziţia unei persoane (parametru care se modifică rapid) şi un senzor de temperatură (parametru cu modificări lente). Facem analiza într-o ordine 10 . De asemenea. grad de încredere. fiecare dintre senzori are caracteristici ale calităţii cum ar fi: o anumită rezoluţie. se poate deduce.3 Principalele clase de modele În acest subcapitol analizăm clasele de modele prezentate în [Thom04]. care determină calitatea informaţiei de context. în unele modele se permite exprimarea diferitelor relaţii între elementele de context (ierarhice. Unii dintre aceştia produc o cantitate mai mare de informaţie decât alţii. De exemplu. De exemplu. o persoană care se plimbă într-un mare spaţiu expoziţional unde are loc un târg de carte caută o anumită editură cu ajutorul dispozitivului ei mobil. Pentru a ajuta la aceasta. încăperea fiind o parte a imobilului (relaţia de incluziune fiind indicată în modelul de context). de apartenenţă etc. Valorile pe care le au elementele de context din model sunt preluate de la senzori. durată de valabilitate a valorii citite. Putem considera o medie între ultima valoare de temperatură citită şi valorile de la senzorii de temperatură din proximitatea senzorului până la înlocuirea sursei de alimentare. energia electrică din bateria unui senzor de temperatură dintr-o reţea de senzori ce monitorizează o pădure s-a terminat. 2.). pe baza tranzitivităţii (reprezentată în mod specific în model).2.2. precizie. Putem distinge două tipuri de modelele: cele în care valorile provin doar din surse externe modelului (de la senzori prin detecţie sau de utilizatori prin declaraţie) şi cele în care valorile pot proveni şi din prelucrarea informaţiilor existente deja în modelul de context prin operaţii logice. că acea persoană se află şi în acel imobil.

Aceştia propun utilizarea de variabile de mediu pentru reprezentarea informaţiei de context ca o soluţie la cererea de adaptabilitate a aplicaţiei. încăperi. este 21°C. Precizăm că în urma analizării caracteristicilor. dispozitive. temperatură. Mai întâi. fapt pe care îl vom evidenţia prin formulări de genul "ar putea". deşi modelele nu au fost gândite în acest scop. echipamente.[Bill95]. în final rezultând o listă neierarhică de perechi atribut-valoare. Un exemplu ar fi pentru elementul de context temperatura. mai întâi aplicaţia citeşte datele de la un server (nod de reţea) la care dispozitivul mobil este conectat. Astfel. zgomot_ambiental = 50 dB.3. dar în lipsa unei structuri ierarhice este dificil de gestionat. Un exemplu este: temperatura = 21°C.1 Modele bazate pe perechi atribut-valoare Este cea mai simplă modalitate de reprezentare a contextului. care rezolvă aceste probleme. iar valoarea acestuia este un şir alfanumeric sau o listă de astfel de şiruri (cuprinse între ghilimele doar dacă în interiorul şirului se găseşte simbolul acoladă) între două acolade şi cu spaţii ca elemente de delimitare. Atunci acea nouă valoare ar putea deveni valoarea curentă pentru elementul de context temperatura.[Bill94].care merge de la simplu la complex. iar altele nu. Valoarea temperaturii. Detaliem modelul propus de Schilit în teza să de doctorat [Bill95]. Constă în reprezentarea fiecărui parametru ce descrie contextul ca o pereche atribut-valoare. el defineşte un obiect de date dinamic ca un container de informaţii care poate stoca informaţii din lumea reală sau abstracte: persoane. Dacă s-ar schimba serverul (aplicaţia s-ar conecta într-un alt nod din reţea) valoarea citită pentru temperatură ar fi 20°C. Este important ca datele despre context să fie sub un acelaşi format (în toate nodurile reţelei distribuite) şi să fie uşor de folosit de diverse unelte soft ce rulează pe platforme diferite. îi este atribuită în literatură lui Schilit şi colaboratorilor lui [Bill93]. Un exemplu ar fi situaţia în care valoarea elementului de context temperatura nu s-ar mai şti odată cu deconectarea temporară a senzorului de temperatură. se observă ca unele sunt satisfăcute. fără a se preciza tipul de date. urmărind cum au fost abordate caracteristicilor enunţate mai sus. debit. Validarea nu poate fi făcută. Cantitatea şi calitatea informaţiei pot fi considerate. deoarece lipseşte definirea termenilor şi a domeniilor de valori ai parametrilor. în acest nod. Exemple. ca în exemplul din [Bill95]: {Name Badge:802} {PublicKey "R0lGODdhDAMdAc}Yd"} {With {schilit spreitzer theimer}} 11 . Completitudinea se poate considera la nivelul instanţelor. caz în care se poate folosi ca valoare curentă ultima valoare citită de senzor. Numele fiecărui atribut este un text simplu. 2. Dar există câteva situaţii în care caracteristicile ar putea să fie satisfăcute. Compoziţia distribuită s-ar putea face doar la nivelul instanţelor. Una dintre primele propuneri de modelare a contextului cu perechi atribut valoare. deoarece nu se aplică conceptul de moştenire sau apelul de metode. nivel de luminozitate etc. Acest tip de obiect diferă de cel definit în programarea orientată obiect. Această soluţie de reprezentare nu prezintă suport pentru raţionare.

atributul operatori are ca valoare o listă de trei perechi atribut-valoare. unde date poate fi o valoare sau un alt DataObject. iar Location este variabila. loc. cu aceleaşi cuvinte cheie pentru a permite interoperabilitatea. O prezentare. u3.Location) unde bershad este mediul. vede contextul ca având entităţi (locuri. [Fabi04]. Mai departe. Din acest punct de vedere. el impune respectarea aceleiaşi convenţii de reprezentare. Modalitatea de reprezentare a contextului din Mobisaic [Voel94] porneşte de la ideea de variabile de mediu dinamice ce pot fi accesate şi modificate pentru a se adecva mediului mobil al utilizatorului. fiind modificabile doar de aplicaţiile ce deţin acest drept. Convenţia propusă de autor este ca atributele globale să se scrie începând cu literă mare. 2.3. Acest model se inspiră în modelarea informaţiei de context din mecanismele proiectării grafice de unde împrumută termenul de widget. considerate şi descrise în cadrul unei pagini web. aceste DataObject sunt codate XML şi trimise prin HTTP. Sintaxa propusă este $(mediu. • validarea conţinutului unei pagini web se poate face pe baza structurii specifice HTML.Atributele pot fi locale sau globale. Un exemplu este: http://www/offices/$(Location).2 Modele bazate pe tehnologie web Fiecare entitate (persoană. care se aplică atât utilizatorilor cât şi echipamentelor. Aceste variabile sunt atribuite utilizatorilor şi locaţiilor pe o perioadă nelimitată. celelalte atribute fiind notate cu litere mici. Ei mai propun utilizarea URL-urilor dinamice pentru a găsi informaţiile ce concordă cu contextul în care se află utilizatorul. lucru) din model are o anumită descriere web (pagini HTML) ce poate fi accesată la o adresă URL [Ghita04]. Deşi nu a fost prevăzut iniţial. de asemenea. iar un exemplu este: $(bershad. putem afirma că soluţia acesta beneficiază parţial şi din avantajele modelelor cu scheme de marcare şi cele orientate obiect. Cele globale îşi păstrează semnificaţia pentru mai multe obiecte. atributul fiind acelaşi (utilizator). oameni. discutat în [Anind00] şi [Anind01]. La nivelul acestuia. • cantitatea şi calitatea informaţiei pot fi. datele de context sunt sub formă de DataObject format din nume şi date. 12 . u2. poate fi susţinută într-o anumită cameră (atribut) şi la un anumit moment de timp (alt atribut).variabilă). Obiectele pot fi referenţiate în interiorul altora. Deşi este un model simplu şi flexibil. care este un lucru. folosind numele obiectului: {operatori {utilizator:u1 utilizator:u2 utilizator:u3}} Aici. acest tip de model poate răspunde la problemele formulate anterior astfel: • compoziţia distribuită şi completitudinea este rezolvabilă doar la nivel de instanţă (ca în exemplul cu temperatura de la clasa atribut-valoare). Context Toolkit. ca în exemplu de mai jos. putem spune că acest model face parţial parte şi din clasa de modele web. Un exemplu este Location. lucruri) şi atribute.html. valorile fiind: u1. Ca urmare.

Validarea este cea mai importantă trăsătură a acestor modele datorită existenţei schemelor de definire şi a uneltelor pentru validare ce permit verificarea tipului atributelor şi. iar apoi conţinutul de prezentare al fiecărui lucru. locurile şi persoanele să aibă fiecare o reprezentare web care oferă acces la alte pagini web sau la servicii. chiar a domeniului valorilor numerice a variabilei reprezentate. similar portalurilor web. acest criteriu trebuie să fie rezolvat de către aplicaţia care foloseşte modelul. accesul la servicii (tot prin intermediul unor pagini web). numite profile. O altă soluţie este înlocuirea DTD-ului cu XML Schema. În proiectul CoolTown de la HP [Tim00] ideea de bază este ca lucrurile. Locurile sunt modelate astfel încât ele oferă. 2. interesează să se ştie datele curente şi mijloacele prin care se poate comunica cu ele. Mijloacele pot varia în funcţie de locul în care se află persoana şi istoricul datelor. este comunicarea între două persoane. Exemplu. caz în care apelul (de tip telefonie prin Internet) va fi redirectat în funcţie de resursele de comunicare aflate la dispoziţia persoanei de contactat. Prezenţa schemelor de definire (XML Schema) ar permite parţial raţionarea pe baza relaţiilor ierarhice dintre elementele schemei de marcare. compoziţia distribuită este posibilă în unele dintre modele şi la nivel structural (de clase) prin separarea părţii stabile (implicite) de partea care este posibil să se modifice şi prin implementarea unui mecanism de actualizare bazat pe reguli ce sunt memorate în model (de exemplu cscp:resRule ale cărei valori pot indica o fuziune sau o suprascriere a subarborilor din structura modelului de context [Henri03]). datorită structurii ierarhice a schemelor de marcare. fie valorile acelui atribut.În cazul acestei clase de modele nu există suport pentru raţionare. de început şi sfârşit) fie alte atribute. Pentru persoane. memorat sub formă de pagină web. de obicei avem de-a face cu o structurare a părţilor componente ale modelului după anumite caracteristici comune.3. prezentat în [Tim00].). Alte soluţii de reprezentare sunt fie proprietare şi ca urmare nu putem cunoaşte detaliile de realizare. 13 . fie bazate pe un număr mic de elemente de context distincte. Un exemplu. O problemă a modelelor din această clasă este limitarea dată de utilizarea fişierelor DTD (Document Type Definitions). care nu permit redefinirea sau fuziunea noţiunilor din surse diferite. În cazul modelării contextului. Pentru completitudine aceste modele nu dau o soluţie. Avantajul acestei clase de modele faţă de cea atribut-valoare constă în faptul că se bazează pe tehnologia web de reprezentare (HTML) şi accesare a datelor (URL) şi pe unelte dedicate (editoare şi respectiv navigatoare web).3 Modele ce folosesc scheme de marcare Specificul schemelor de marcare este structurarea ierarhică a datelor cu ajutorul unor etichete ce numesc un atribut şi care cuprind (între cele două marcaje. RFID. într-o oarecare măsură. Un exemplu binecunoscut este limbajul de marcare XML. Lucrurile se identifică prin etichete electronice (iButton. este afişat. Totuşi. în plus faţă de lucruri. Cantitatea şi calitatea informaţiei poate fi precizată uşor în asociere cu sursa care a generat-o. coduri de bare etc.

Modelele de context bazate pe scheme de marcare concură pentru a răspunde la întrebările: 1.. detalii legate de persoanele implicate în activitate şi alte date relevante pentru activitatea curentă.org/CSCPProfileSyntax#" xmlns = "http://example. cea de descompunere şi extensibilitatea.org/NetworkProfileSyntax#"> <SessionProfile rdf:ID="Session"> <cscp:defaults rdf:resource= "http://localSessionContext/CSCPProfile/previous#Sessio n"/> 14 .w3.. z=. CSCP însă permite structurarea pe mai multe nivele şi are un mecanism de exprimare a preferinţelor utilizatorului ce are posibilitatea ataşării de condiţii şi priorităţi atributelor entităţilor. la fel ca CC/PP (Composite Capability/Preference Profile).>) şi solicită date cu privire la o dată numită landuse cu valoarea pasture: <context session="123" action="update"> <spatial proj="UTM" zone="33" datum="Euro 1950 (mean)"> <point x="281993" y="4686790" z="205" />> </spatial> <require> <note> <data name="landuse" value="pasture" /> </note> </require> </context> Elementele de context menţionate în [Nick] sunt: poziţia..org/DeviceProfileSyntax#" xmlns:net = "http://example. Eticheta <context> marchează o pereche de date de trimis de la client şi. respectiv. cum se ierarhizează contextul şi care sunt părţile principale ale acestuia? 2. Un exemplu de profil CSCP este următorul [Held02]: <?xml version="1. cerute de la server. Nu se pune problema actualizării modelului şi nici alinierea la vreun standard de reprezentare a datelor pentru context. cum se aliniază standardelor existente? ConteXtML [Nick] descrie contextul folosind mesaje descrise în documente de tip XML (eXtensible Markup Language). viteza.org/1999/02/22-rdf-syntax-ns#" xmlns:cscp = "http://example. Exemplul din [Nick] ilustrează o actualizare pe care o face un client mobil care îşi comunică poziţia în spaţiu (cu <spatial> şi subelementul <point x=.org/SessionProfileSyntax#" xmlns:dev = "http://example. cum se menţine la zi modelul? 3. Acest model este bazat pe RDF (Resource Description Framework)..Exemple. Un alt exemplu este Comprehensive Structured Context Profiles (CSCP) [Held02]. y=.0"?> <rdf:RDF xmlns:rdf = "http://www... de la care moşteneşte capacitatea de interschimbare.

în care observăm două modalităţi de căutare de elemente de 15 . IPAddress]] ] ] În [Indul03] se evidenţiază limitările pe care CC/PP le are atunci când este folosit pentru modelarea contextului. Disconnection Type. PPDL permite descrierea contextului n-dimensional sub formă XML ca profile. sesiunii curente. . public. În lucrarea citată se prezintă patru tipuri de profile: privat. Exemplele de extensie ale CC/PP se referă la reprezentarea poziţiei.]] [NetworkInterface [QoS [Bandwidth. InterfaceType.. • lipsa posibilităţii de a defini constrângeri relaţionale asupra existenţei sau absenţei mai multor atribute din profilul componentei. caracteristicilor reţelei. altele decât CC/PP. rezoluţie. În [Indul03] se concluzionează că limitările CC/PP nu îl recomandă ca cel mai potrivit pentru modelarea contextelor complexe pentru sistemele omniprezente. Pentru descrierea interesului se dă următorul exemplu. cerinţelor pentru aplicaţie. dar actualizarea modelului nu se tratează. relaţiilor şi dependenţelor. Tot CC/PP se află şi la baza propunerii din [Indul03]. .. considerând-l fixat.. Dintre acestea menţionăm: • lipsa unor caracteristici ale informaţiei de context (aspecte temporare.]. în care se defineşte un set de componente şi atribute care descriu contextul şi relaţiile dintre elementele sale componente. încredere în corectitudinea informaţiei.. tipuri diverse de informaţii). precizie. Pervasive Profile Description Language (PPDL) [Fers06] este o altă abordare bazată pe scheme de marcare.<device> <dev:DeviceProfile> <dev:hardware> <dev:Hardware> <dev:memory>9216</dev:memory> </dev:Hardware> </dev:hardware> </dev:DeviceProfile> </device> </SessionProfile> </rdf:RDF> În acest caz avem adecvare la standard. pentru a face faţă variabilităţii dinamice a autodescrierii caracteristicilor dispozitivelor mobile. interes şi schimb de roluri.. • lipsa posibilităţii de a defini constrângeri asupra metodei de actualizare a unui atribut sau a unei valori din profil. În continuare prezentăm o parte din extensia CC/PP propusă de autori pentru caracteristicile reţelei (am înlocuit cu ".." detalii ale acestei scheme): [DeviceProfile [NetworkCharacteristics [DisconnectionStatus [ConnectionStatus.

Fiecare dintre aceste profile au în componenţă subelemente. consideră patru tipuri de profile: utilizator (User). Figura 2. modelarea contextului urmează metodologia 3GPP (Generic User Profile) pentru profilul utilizatorului şi CC/PP pentru profilele dispozitivelor. Proiectul Simplicity [Enrico04] răspunde cel mai bine întrebărilor 1-3. dispozitiv (Device). foloseşte XML Schema care este mai flexibilă permiţând în plus faţă de DTD extinderi ulterioare şi transformări folosind XSLT.context. 2. 3. serviciu (Service). reţea (Network). contact. De exemplu.1 ilustrează gramaticile pentru diferitele profile şi componente de profile ca schema XML (Schema XML). Faptul că nu foloseşte un standard este un dezavantaj. organizaţie etc. În modelul de context folosit se propun următoarele soluţii: 1.76"/> <match element="FirstName" text="Mil*"/> </preferences> Avantajul PPDL este că permite o mai mare flexibilitate şi ca urmare modelul poate fi cu uşurinţă modificat. după similaritate şi după potrivire de text cu format parţial necunoscut (partea marcată cu "*"): <preferences> <match element="LastName" similarity="0. 16 . utilizator are: identitate.

org/GUP/Device"> …….Figura 2.org/GUP/Device xmlns="http://www.1. Exemplul pe care îl reproducem mai jos este detalierea părţii din schema XML pentru dispozitiv: <schema … targetNamespace=http://www.istsimplicity. dispozitivelor. serviciilor şi reţelei [Enrico04] Fiecare componentă a profilului se descrie prin atribute specifice.w3.ist-simplicity. Schema XML pentru descrierea utilizatorului. <complexType name="SoftwarePlatformType"> 17 . <element name="Device" type="device:DeviceType"/> <complexType name="DeviceType"> <sequence> <element name="HardwarePlatform" …/> <element name="SoftwarePlatform" …/> <element name="NetworkCharacteristics" …/> <element name="BrowserUA" …/> <element name="WapCharacteristics" …/> </sequence> </complexType> …….org/2001/XMLSchema" xmlns:device="http://www.

</complexType> ……. Alegerea acestor componente se bazează pe UAProf Schema de la WAP Forum.de</user:Email> <user:Homepage>http://www. SoftwarePlatform. WapCharacteristics şi mai apoi sunt detaliate componentele SoftwarePlatform.mimuc. NetworkCharacteristics. Aici sunt descrise profilele User şi Device în care apar identitatea (nume şi prenume).) ale dispozitivului: <Profile …> <user: User> <user:Identity> <user:FirstName>Enrico</user:FirstName> <user:LastName>Rukzio</user:LastName> </user:Identity> <user:Contact> <user:Email>Enrico. adresa paginii Internet. numărul de telefon) ale utilizatorului şi respectiv caracteristicile platformei hardware (dimensiunea ecranului. BrowserUA. informaţiile de contact (email.1. modelul etc. operating system.lmu. </documentation> </annotation> <all> <element name="AcceptDownloadableSoftware" type="boolean" inOccurs="0"/> </all> ……. Formatul XML permite transformarea cu uşurinţă a unui document UAProf într-o componentă de tip Device.<annotation> <documentation xml:lang="en">The SoftwarePlatform component contains properties of the device's application environment.Rukio@ifi.de</user:Homepage > <user:TelephoneWork>+49 89 21804656</user:TelephoneWork> </user:Contact> </user:User> <device:Device> <device:HardwarePlatform> <device:ScreenSize>101x80</device:ScreenSize> <device:Model>T68R1</device:Model> <device:ImageCapable>true</device:ImageCapable> <device:Keyboard>PhoneKeypad</device:Keyboard> 18 . Reproducem mai jos un exemplu de profil realizat după gramatica prezentată în figura 2. and installed software. </schema> Se observă că elementul Device este de tipul complex DeviceType compus din secvenţa de elemente HardwarePlatform.

<device:Vendor>Ericsson Mobile </device:Vendor> </device:HardwarePlatform> … </device:Device> …. • de tip profil (stabilesc relaţiile între un obiect şi utilizatorul lui).).2 nu pot fi aplicate. Un exemplu de model grafic. interogări etc.. [Rob07] în care autorii pleacă de la un model folosit pentru proiectarea grafică a bazelor de date ORM (Object-Role Modeling). criteriile 1-5 din subcapitolul 2. iar relaţiile leagă tipurile de fapte de roluri.4 Modele grafice Modelele grafice fac parte din categoria metamodelelor (modele despre modele). la implementare. dar nespecific modelării contextului. precizia (eroarea standard)) şi ambiguitatea (permite notarea gradului certitudinii unei relaţii).2. </Profile> 2. Mai apoi acestea sunt implementate fie în limbaj de programare sau marcare. • dependenţa faptică (stabileşte o legătură între două fapte). Într-o lucrare mai recentă [Rob07] autorii caută o soluţie de reprezentare a modelului grafic folosind fie ontologii (RDF-OWL). Modelele grafice facilitează crearea la nivel de concept (pe suport de hârtie sau folosind unelte software specializate) a modelelor sub formă vizuală.3. • de tip temporal (indică momentul la care se desfăşoară o activitate). Exemple. • specifice senzorilor (indică valoarea curentă a senzorului care măsoară un anumit element de context pentru un anumită persoană). • de tip derivare (deducerea unei anumite relaţii pe baza altor relaţii). • de tip adnotarea calităţii (având parametrii: prospeţimea datelor (momentul de timp al evaluării). Prin elipse se reprezintă tipuri de obiecte sau fapte. El este prezent într-o serie de articole (din care cităm doar [Sheng05]. Există posibilitatea ca în urma proiectării cu o unealtă grafică să se translateze modelul dintr-o reprezentare grafică către o reprezentare a contextului uşor de folosit de către un sistem de calcul (cum ar fi un fişier XML). relaţii. este UML (Unified Modeling Language) care foloseşte diagrame ca instrumente grafice de proiectare. fie ca elemente specifice bazelor de date (tabele. prin dreptunghiuri rolurile. Deoarece modelele din această clasă vor primi o formă concretă ulterior. 19 . CML extinde notaţiile iniţiale prin setul descris prin exemple în figura 2. fie XML. noul limbaj numindu-se XCML. Ei aleg XML arătând că translatarea CML la RDF/OWL s-ar face cu pierderi. Sunt astfel descrise următoarele relaţii abstracte: • de tip static (atribute ale unui obiect). Context Modelling Language (CML) este un model ORM extins pentru a fi utilizat în reprezentarea contextului.

Tip de fapt static is of type Device (id) Tip de fapt profil permitted to use Person (name) Device (id) s Device Type (code) Tip de fapt derivat Person (name) located at ∧∧ located at Location (name) Device (id) Dependenţă faptică ∧∧ Tip de fapt de la senzori located at Person (name) ∧∧ Tip de fapt temporal Person (name) engaged in Activity (name) Location (name) engaged in Activity (name) [] located at Location (name) ∧∧ Person (name) [] Adnotarea calităţii Production Time (timestamp) Freshness Accuracy Standard Error (nr)+ Person (name) ∧∧ located at Tip de fapt ambiguu sau alternativ Certainty Location (name) Probability (nr)+ a Device (id) ∧∧ located at Location (name) Figura 2. 20 . Exemple de modelare în Context Modelling Language [Henri03]. Ambele clase de mai sus au câte două clase derivate: AtomicContext şi CompositeContext.2. contextul este modelat prin clasa Context care poate să provină din mai multe surse ContextSource. ca în figura 2. respectiv ContextSource şi ContextServiceCommunity. [Henri06] ContextUML [Sheng05] constă într-un metamodel şi o notaţie ce descriu atât contextul cât şi modalitatea de răspuns la context a aplicaţiei. În continuare detaliem modelul ce defineşte sintaxa abstractă a limbajului şi notaţia ce defineşte formatul concret al limbajului pentru reprezentarea contextului.3. La nivel abstract.

. anumite valori ale altor elemente de context. acest model este prea simplu şi prea general pentru a fi utilizat în sisteme omniprezente. în funcţie de reguli.3. La apariţia unei 21 . Aceste modele ar putea permite compoziţia distribuită la nivelul instanţelor. Dintre modelele mai noi prezentăm LogicCAP (bazat pe Prolog) [Loke04]. [Loke06] pentru programarea aplicaţiilor senzitive la context în care situaţiile sunt entităţi de primă clasă. Lipsa mecanismelor de verificare a consistenţei definiţiilor din model face ca validarea să fie dificilă. dacă este atomic (adică nu mai poate fi desfăcut în părţi componente) şi cu conuml. spune autorul.atomicContext. Aici se descrie contextul abstract prin obiecte de prima clasă. Contextul atomic are două atribute: nume context şi sursă context. Exemple. deducţia valorii unui element de context). pe când contextul compus are doar un singur atribut. Cantitatea şi calitatea informaţiei şi completitudinea ar putea fi tratate. [McCar97]. însă soluţiile propuse până acum de către cercetătorii din domeniu nu au avut ca scop satisfacerea acestor caracteristici. Metamodelul contextului descris cu ContextUML [Sheng05] Notaţia pentru reprezentarea contextului se reprezintă tot cu clase UML prin stereotipul conuml. Loke propune o extensie a Prolog-ului numită LogicCAP [Loke04]. Elementele de context sunt reprezentate în dinamica evoluţiei lor ca luând noi valori (provenite de la senzori) care determină. [Loke06] şi un altul care descrie contextul prin situaţii exprimate prin operatori temporali [Brdi06]. 2. Suportul pentru raţionare este o caracteristică forte a acestei clase de modele de context deoarece reprezentarea contextului prin fapte legate între ele prin reguli şi expresii logice uşurează aplicarea unui demers logic (de exemplu.compositeContext dacă este compus.* ContextSource * ContextSource ContextServiceCommunity AtomicContext CompositeContext * Member * Figura 2. Chiar dacă are un mecanism de deducere a unui context din altul. regulile şi expresii logice sunt conceptele fundamentale ale unui model bazat pe logică. Regulile descriu în mod natural. situaţiile. S.W.3.p) arată că propoziţia p este adevărată în contextul c. Relaţia de bază ist(c. Unul dintre primele modele bazate pe logică este cel propus în [McCar93].5 Modele bazate pe logică Faptele.Context * * SourceAssignment 1.

Duration) ). entry(StartTime. Exemplu de context modelat cu operatori temporali [Brdi06] 22 . • constrângerile pe care situaţia (în exemplul de mai jos o întâlnire) le impune asupra valorilor citite de la senzorilor sunt descrise logic astfel: situation program meeting1: in_meeting_now(E) -e-> with_someone_now(E). .people in room*(L. N > 1.N). has_entry_for_meeting_in_diary(E). care la rândul lor sunt declarate ca fiind condiţionate de prezenţa entităţii E în locaţia L şi a unui număr de cel puţin două persoane în acea locaţie: location*(E.situaţii.N) – numărul de oameni N.4: meets Prezentare meets START meets meets END meets Formulare întrebare meets Figura 2. with_someone_now(E) -e-> location*(E. anumite condiţii şi constrângeri sunt activate. dintr-un loc L. .L) – poziţia entităţii E în variabila L. ca în exemplul de mai jos ce descrie o întâlnire care are loc acum: • predicatele senzorului sunt: .location*(E. Duration)) – intrările din jurnal pentru entitatea E şi care se potrivesc cu evenimentul Event. Duration). has_entry_for_meeting_in_diary(E) -e-> current_time*(T1).entry(StartTime. diary*(E.L). Autorii articolului [Brdi06] propun modelarea contextul ca situaţii exprimate prin operatori temporali şi apoi implementarea lor deterministă cu ajutorul reţelelor Petri şi probabilistică cu modele Marcov ascunse.’meeting’. within_interval(T1.diary*(E.L). Event. Ei definesc o situaţie ca o stare temporară a contextului şi exemplifică cu o prezentare în care se pun întrebări ca în figura 2.4. Înţelegem definirea situaţiei in_meeting_now ca fiind condiţionată de with_someone_now(E) şi has_entry_for_meeting_in_diary(E). . StartTime.N). people_in_room*(L. N>1.current time*(T) – timpul curent. people_in_room*(L.

Trăsă. Exemple.Trăsătura tura … tura n.2 1. Fiecare vector are o valoare simbolică prin care este descrisă situaţia şi o valoare numerică ce exprimă certitudinea cu care persoana sau utilizatorul se află în acea situaţie [Schm01]. Reprezentarea contextului constă aici dintr-un set de vectori bidimensionali.1 2. În proiectul TEA contextul este modelat pornind de la trăsături (cues) (vezi figura 2.1 n. care prelucrează datele brute obţinute de la senzori şi dau rezultatul spre utilizare către nivelul de mai sus. frecvenţa de bază.6 Modele orientate obiect Modelarea orientată obiect a contextului caută să exploateze avantajele date de încapsulare şi reutilizare. Aplicaţii şi scrípturi software Spaţiul de tuple ale contextului Context Spaţiul de tuple ale trăsăturilor Trăsă.2.2 n.Trăsă. iar a valorilor instanţiate la rulare de către mediul de execuţie. unde se găseşte reprezentarea abstractă a contextului.5).1 1.Trăsă.3. Compoziţia distribuită este facilitată de modelarea orientată obiect. Raţionarea se face în părţi ale programului (metode) unde instrucţiunile condiţionale (dacă – atunci) testează prin construcţii logice valorile atributelor obiectelor de context şi răspund prin apeluri la alte metode din program. Astfel încât detaliile procesării datelor de context sunt încapsulate la nivelul obiectului şi sunt ascunse altor componente care au acces la acele informaţii doar prin intermediul unei interfeţe. Dintre trăsăturile menţionate de autori ca exemple amintim: valoarea medie.n Senzor 1 Senzor 2 … Trăsă.n Senzor n Figura 2. deviaţia standard. Arhitectura pe nivele a sistemului senzitiv la context din proiectul TEA [Schm01] Modelul de obiect senzitiv la context propus în [Fitz02] vede contextul ca fiind un consumator de date de la senzori pe care le prelucrează.5. Cantitatea şi calitatea informaţiei şi completitudinea sunt rezolvate prin adăugarea de parametri specifici şi prelucrarea lor de către aplicaţia care foloseşte modelul. deoarece atât elementele de context (modelate sub formă de clase) cât şi instanţele acestora (obiectele) pot fi gestionate de un sistem distribuit.n 2. le reprezintă şi în final aplică un 23 .2 2. Validarea structurii se face de către compilator.Trăsă.Trăsătura tura … tura tura tura … tura 1.Trăsă. derivatele de ordinul întâi.

Reprezentarea contextului într-un obiect senzitiv se face ierarhic pe baza paradigmei CxBR (Context Based Reasoning).6.7 Modele bazate pe ontologii Ontologiile sunt folosite în sistemele de calcul pentru a reprezenta realitatea nu doar ca un set de concepte distincte.set de reguli de reacţie care produc o modificare a mediului înconjurător prin intermediul actuatorilor. Contextul unificat numit 5W1H este constituit din şase obiecte care sunt desemnate după partea din context pe care o acoperă.0 este un model de aplicaţie senzitivă la context unificat [Oh05] în care se propune un alt model orientat obiect al contextului. ci ca un ansamblu de concepte între care există relaţii diverse (nu doar ierarhice şi de apartenenţă). Mediu extern Senzor Preluarea Reprezen.y. a parametrilor acestora şi a legăturilor dintre ele şi permit 24 . Model de obiect senzitiv la context [Fitz02] ubi-UCAM 2. aşa cum se poate observa în figura 2. • Where (unde) indică locaţia (un exemplu este setul de coordonate x. În modelarea contextului. • What (ce) se referă la un obiect (un exemplu de atribut este numărul lui de identificare). • When (când) precizează momentul de timp absolut sau abstract. cum ar fi mâinile). astfel: • Who (cine) stochează datele despre utilizator (de exemplu numele utilizatorului).Motor de valorilor de tarea inferenţă la senzori Contextului Coordonare prin modificarea mediului Actuator Consumă Produce Senzor Obiect senzitiv Eveniment Actuator Figura 2.z). • Why (de ce) reprezintă starea utilizatorului. care afirmă că acţiunile pe care le face o entitate sunt în mare măsură dependente de contextul curent al acelei entităţi. 2.3. ontologiile facilitează o reprezentare precisă a elementelor de context. • How (cum) reprezintă gesturile utilizatorului (de exemplu poziţia corpului sau a unei părţi a corpului.6. Utilizarea CxBR face să scadă numărul de reguli de inferenţă necesare pentru a determina acţiunea de întreprins într-o anumită situaţie.

• reutilizarea contextului pentru alte tipuri de aplicaţii. Reprezentarea grafică a ontologiei SOUPA [perv04] 25 . compoziţia distribuită. completitudinea. locuri. Ca urmare. De aceea moştenesc caracteristicile acestor două tipuri de modele. dovedind în privinţa validării calităţile modelelor bazate pe scheme de marcare. Ea permite soluţionarea următoarelor probleme: • deducerea altor elemente de context din surse externe. Document [doc] Device [dev] Agent [agt] Region Conn Calc [rcc] BDI [bdi] Digital-Doc [ddc] ImgCapture [icap] Person [per] Policy [pol] Action [act] Meeting [mtg] Event [eve] Location [loc] Space [spc] Geo-M [geo] Knowledge [know] Schedule [sch] Time [tme] Legenda: owl:import Partea centrală a ontologiei SOUPA Extensia SOUPA [ ] Spaţiul de nume XML Figura 2. intenţii.raţionarea asupra conceptelor existente şi a relaţiilor dintre ele pentru a deduce noi valori ale elementelor de context şi pentru verificarea consistenţei modelului. • inconsistenţa informaţiilor de context. • controlul pentru păstrarea confidenţialităţii. [perv04] pentru a deveni un standard pentru aplicaţii omniprezente. SOUPA (Standard Ontology for Ubiquitous and Pervasive Applications) a fost definită [Chen04]. în acest caz. • descrierea conceptelor persoană. validarea.7. creşterea complexităţii. Ontologiile folosesc clase pentru a reprezenta concepte şi oferă suport pentru raţionare (ca cele bazate pe logică). • distribuirea cunoaşterii (datorită reutilizării unor ontologii existente). cantitatea şi calitatea informaţiei. Exemple. suportul pentru raţionare sunt cel mai bine rezolvate de această clasă. Preţul de plătit pentru aceste performanţe este însă.

string">Tim Finin</per:name> </per:Person> <ebm:EbiquityMember rdf:about="http://www.cs. SOUPA (vezi figura 2.cs. Redăm parte a unui exemplu de fişier OWL din [Gu05]: <rdf:RDF …> <owl:Ontology rdf:about="&cobra. Această reprezentare rezolvă următoarele: • reduce complexitatea reprezentării contextului prin separarea ontologiei într-o parte generală (care poate fi folosită de către orice aplicaţie) şi o parte specifică domeniului aplicaţiei.gl.cs.string">Gigi Yim</per:name> <per:knows rdf:resource="http://www. folosind OWL (Web Ontology Language).edu/~joshi"/> … </rdf:RDF> Un alt exemplu de reprezentare ontologică a contextului este SOCAM (Service Oriented Context Aware Middleware) [Gu05].cs.cs. declarat) şi a dependenţei între diferitele elemente de context. ontologiile FOAF (Friend-of-aFriend) pentru conceptul persoană. În SOUPA Core se refolosesc.umbc.umbc.edu/~finin"/> <ebm:EbiquityMember rdf:about="http://www.Menţionăm ca neajuns al SOUPA faptul că nu permite reprezentarea clasificării în tipuri de context (dedus.umbc.umbc.umbc.contextbroker"> <owl:imports rdf:resource="&soupa.edu/~finin"/> </per:Person> <per:Person rdf:about="http://www.ebiquity-meetings"/> </owl:Ontology> <per:Person rdf:about="http://www.edu/~finin"> <per:name rdf:datatype="&xsd.umbc. pe cât posibil. OpenCyc şi Open GIS pentru conceptul spaţiu.edu/~yim1"> <per:name rdf:datatype="&xsd. detectat. • permite deducerea valorilor contextului superior prin inferenţă asupra valorilor contextului inferior.edu/~hchen4"/> <ebm:EbiquityMember rdf:about="http://www.7) este proiectată din două părţi: una centrală (considerată a fi acoperitoare pentru toate aplicaţiile omniprezente) şi o extensie (unde se poate adăuga acel vocabular specific acelei aplicaţii particulare pe care o dezvoltăm).person"/> <owl:imports rdf:resource="&cobra. 26 . DAML-Time pentru conceptul timp. Fiecare din ontologiile componente este notată. de exemplu.

declarat) şi context indirect (dedus). Prezentăm un extras din ontologia de nivel general în care se defineşte clasa de bază ContextEntity şi din care se derivă clasa Activity (ca subClassOf). Ea este descrisă în OWL.comp...8) într-o anumită activitate (Activity): Ontologie generalizată în nivelul superior Comp Entity Application Network Service Device Agent … locatedIn Location Context Entity use own locatedIn engagedIn locatedIn IndoorSpace OutdoorSpace Person Activity ScheduledActivity DeducedActivity … … … … Ontologie a domeniului vehiculelor Ontologii specifice domeniului Ontologie a domeniului casei Legendă: owl:Class rdfs:subClassOf owl:Property Figura 2. ca în figura 2. Ontologia SOCAM este împărţită în două: o ontologie generală şi ontologii corespunzătoare domeniilor aplicaţie.• • • • permite rezolvarea conflictelor dintre diferitele surse de context.nus. xmlns:socam=http://www. detectează şi corectează inconsistenţele informaţiei de context pe baza mecanismului de inferenţă.8. de exemplu context direct (detectat. permite reprezentarea claselor de surse de informaţii de context.sg/socam/ConOnt# .edu.> <owl:Class rdf:ID="ContextEntity"/> 27 . Reprezentarea ontologiei SOCAM cu detalierea claselor din nivelul general [Gu05] <rdf:RDF xmlns=http://www. iar mai jos se arată că o entitate de calcul (CompEntity) va fi folosită (proprietatea use figurată ca o linie în figura 2.nus. la care au fost adăugate elementele proprietate rdfs:dependsOn şi owl:classifiedAs.sg/socam/ConOnt# .8.comp. facilitează menţinerea consistenţei bazei de cunoştinţe...edu.

Modelele bazate pe scheme de marcare sunt potrivite aplicaţiilor în care elementele de context sunt puternic ramificate. cu majoritatea relaţiilor între ele de tip ierarhic. 28 . între care nu se pot stabili uşor relaţii.<owl:Class rdf:ID="Activity"> <rdfs:subClassOf rdf:resource="#ContextEntity"/> </owl:Class> . Comparaţie între modele de context după criteriile 1-5 enunţate în secţiunea 2.2. Clasă de model de context Perechi atribut-valoare Web Scheme de marcare Grafice Logice Orientate obiect Ontologice Compoziţia distribuită + ++ ++ ++ Validarea + ++ + ++ Cantitatea şi calitatea informaţiilor + + + + Completitudinea + + Suportul pentru raţionare ++ + ++ Analizând acest tabel ne întreba când este recomandat să folosim un model dintr-o anumită clasă şi când dintr-o alta şi de ce? Răspundem la aceste întrebări în continuare.. două).2: Tabel 2. Acestea din urmă vin cu un mic avantaj. Lipsa suportului pentru raţionare nu este aici critic. dar care se bazează pe surse de informaţii de încredere şi care sunt relativ puţin distribuite în reţea..4 Comparaţie între clasele de modele de context În tabelul de mai jos sintetizăm modul în care clasele de modele de context răspund la caracteristicile enunţate în secţiunea 2. pot beneficia de simplitatea claselor de modele atributvaloare şi bazate pe web. </rdf:RDF> 2.. validarea conţinutului paginii web în care sunt prezente atributele modelului. într-o mică măsură. acela de a permite.. <owl:ObjectProperty rdf:ID="use"> <rdfs:domain rdf:resource="#Activity"/> <rdfs:range rdf:resource="#CompEntity"/> </owl:ObjectProperty> . Situaţiile simple de context nu cer acestei clase de modele de context suport pentru raţionare. Aplicaţiile simple cu un număr redus de elemente de context (unu. deoarece avem un număr redus de elemente de context care sunt independente.1.

contextul poate fi mărit. găsesc o fundaţie solidă în modelele de context ontologice. Aplicaţiile cu multe elemente de context care au relaţii complexe între ele.au independenţă faţă de limbajele de programare .5 De ce sunt potrivite ontologiile în reprezentarea contextului? În cazul reprezentării contextului ontologiile: i. Modelele orientate obiect sunt o soluţie bună când numărul elementelor de context este mediu sau mare cu reguli de comportament relativ puţine şi simple. structura modelului de context fiind uşor de gestionat de către proiectant. în articolul [Reto07] mai apare şi ideea că ontologiile de context: .au putere de expresie (OWL suportă restricţii de cardinalitate) . raţionarea asupra contextului pentru rezolvarea informaţiei imprecise sau parţiale).1 Raţionarea ontologică Pentru a prezenta mai clar cum se face raţionarea ontologică ne-am ghidat după următoarele întrebări: 1. raţionarea pentru cunoaştere implicită [Yau06]) ii.Modelele bazate pe grafică îşi găsesc utilitatea ca bază de proiectare a aplicaţiilor mai complexe.sunt standardizate . abstractizarea programării şi interoperabilitate iii.permit distribuirea cunoaşterii şi reutilizarea ei [Yau06] . Cum se face verificarea consistenţei? 2. susceptibile de a fi incomplete şi ca urmare cu reguli ce au mulţi parametri.5. distribuit.rezolvă problema heterogenităţii datelor. sintetizat. 2.permit reprezentarea formală a contextului [Xiao04] . Tot unealtă poate fi considerată clasa de modele bazate pe logică. calităţii şi validităţii datelor de context 2.folosind mecanismele de raţionare (inferenţa intra-context (ex. Cum se face raţionarea ontologică pentru clasificare a conceptelor şi a instanţelor? 29 . lucrare [Ejigu07] despre descrierea ontologică a contextului se dau argumentele: . în articolele [Xiao04][Yau06] se spune că: . definirea contextului de ordin superior). subsumarea. care provin din surse diferite ca debit şi calitate. îmbogăţit. ambiguităţii. referinţa [Luca06] spune că: . despre ontologii se spune în [Gu05] că: .permit organizarea ierarhică a informaţiei . v.oferă suport pentru raţionare eficientă. deoarece ele permit o testare în avans a regulilor ce descriu comportamentul aplicaţiei senzitive la context folosind limbaje dedicate.permit raţionarea logică asupra contextului (verificarea consistenţei.permit descrierea formală .permit analiza formală a domeniului cunoaşterii iv.

pentru o anumită proprietate. fiecare pizza are cel puţin un aluat) . intersecţie.necesare şi suficiente (clase definite): arată că dacă toţi indivizii clasei B îndeplinesc aceste condiţii necesare şi suficiente ale clasei A. Raţionarea ontologică pentru clasificarea instanţelor (indivizilor) se face prin determinarea tuturor claselor din ontologie. Ex.cardinalitate: proprietatea clasei ia exact (=). Între clase pot exista relaţii de: .necesare (clase primitive): arată că pentru ca un individ să aparţină unei clase el trebuie să îndeplinească anumite condiţii . este inconsistentă.subsumare (subclasă) . Cum se face raţionarea cu reguli utilizator? Iată în continuare răspunsurile la aceste întrebări: 1. Restricţii: . adică un fapt nu este fals până nu se dovedeşte aceasta.existenţială: clasa de indivizi care au cel puţin o (some) instanţă (individ) ca obiect al unei relaţii descrise printr-o proprietate (ex. pizza are_pizzar Luigi) Definirea claselor se face prin condiţii: .universală: clasa de indivizi care. au relaţii doar cu (only) indivizii clasei specificate (ex. universală. Într-o ontologie există clase primitive şi definite. cardinalitate şi are_valoare (hasValue)) aplicate asupra claselor de bază. pizza are_adaos exact 2) . care pe baza definiţiilor lor.disjuncţie Clasele se descriu folosind operatori logici (reuniune. Observaţie: OWL DL foloseşte logica de ordinul întâi (FOL) care operează pe baza presupunerii unei lumi deschise (open world assumption). toate pizzele cu adaos doar adaos_picant) . pot să aibă acea instanţă ca membru.3. este mai mică (<) sau mai mare (>) decât o valoare numerică (ex.are_valoare (hasValue): proprietatea clasei are_valoare o anumită instanţă (ex. Raţionarea ontologică pentru clasificarea conceptelor (claselor) se face prin determinarea tuturor relaţiilor de subsumare din ontologie. 30 . Cum se face raţionarea folosind caracteristicile proprietăţilor? 4. pe baza definiţiilor claselor definite. O clasă este inconsistentă dacă nu poate avea nici o instanţă. O ontologie care are o clasă care aparţine (este subclasă) simultan la două clase disjuncte. 2.Verificarea consistenţei unei ontologii se face astfel: pe baza descrierii claselor (condiţiilor) motorul de inferenţă verifică dacă este posibil ca o anumită clasă să aibă instanţe sau nu. complement) şi restricţii (existenţială. clasa B este subclasă a clasei A.

pre:Bedroom1). pre:hasLocation. (?lightSensor. (?user. indicând setul de necunoscute (variabile precedate de semnul „?”) şi un lanţ logic de proprietăţi şi valori ale proprietăţilor instanţelor claselor care determină o valoare a unei proprietăţi a unui individ dintr-o clasă. 31 .funcţională: are o valoare sau niciuna (ex. [USER_ACTIVITY_SLEEPING: (?user rdf:type pre:Human). pre:Bedroom1). Raţionarea folosind caracteristicile proprietăţilor se face folosind reguli generice în funcţie de specificul caracteristicii: . pre:Bedroom1). (?noiseSensor. Raţionarea cu reguli utilizator se face. pizza are_adaos adaos_pizza) (?a proprietate ?b)->(b? proprietate_inversa ?a) . -> (?user pre:hasActivity pre:Sleeping1). pre:hasLocation. (?lightSensor rdf:type pre:LightSensor). dacă orice senzor de zgomot din dormitorul 1 indică valoare „LOW” să fie impusă valoarea pre:Sleeping1 pentru activitatea curentă (pre:hasActivity) a acelui utilizator. print(?user)] Regula numită „USER_ACTIVITY_SLEEPING” stabileşte ca pentru fiecare utilizator (necunoscuta user) care este instanţă a lui pre:Human dacă se află (proprietatea pre:hasLocation) în dormitorul 1 (instanţa pre:Bedroom1) şi dacă orice senzor de lumină (necunoscuta lightSensor de tipul (aparţinând clasei) pre:LightSensor) situat în (proprietatea hasLocation) în dormitorul 1 are valoarea (proprietatea pre:sensorValue) „LOW” şi.tranzitivă (?a proprietate ?b) (?b proprietate ?c)->(a? proprietate ?c) 4. similar. (?noiseSensor pre:sensorValue "LOW"). adaos_pizza se_aşează_pe pizza) . similar celei cu caracteristici ale proprietăţilor. (?lightSensor pre:sensorValue "LOW").simetrică (?a proprietate ?b)->(b? proprietate ?a) .inversă (ex. pre:hasLocation.3. Ex. (?noiseSensor rdf:type pre:NoiseSensor).

agregarea etc. . Autonomia. 3. 3.) contextului. folosim în acest raport următoarea definiţie pentru protocolul de descoperire a contextului. se consideră că senzorii se găsesc pe dispozitivele mobile. într-o maniera proactivă. În aceste medii.3 Mecanisme de descoperire a contextului Unul dintre modulele arhitecturii unui sistem senzitiv la context este cel care se ocupă de colecţionarea şi procesarea (interpretarea. De asemenea R-CDP ştie să reducă răspunsurile (Result) redundante. Uneori modulului i se specifică. Pornind de la definiţia protocolului de descoperire a serviciilor. Jini. din faza de proiectare. tema principală a acestui proiect.1 Protocoale de descoperire a contextului Protocolul de descoperire a contextului este un protocol care permite detectarea automată a furnizorilor de context (senzori) într-un mediu pervasiv. de unde să colecţioneze elementele de context de interes. în acest raport.în funcţie de condiţiile reţelei R-CDP ştie să modifice intervalul la care se transmit cererile (Request) pentru aflarea contextului. În acest caz spunem ca modulul descoperă contextul.comunicare push şi pull pentru descoperirea şi extragerea contextului: un Requester descoperă contextul oferit de Provider folosind mecanismul pull. are ca premisă abilitatea sistemului de a descoperi contextul în timpul funcţionării. de către dezvoltator. Enumerăm câteva protocoale cunoscute de descoperire a serviciilor SLP. vom face o analiză a protocoalelor de descoperire a contextului existente. 32 . UPnP etc. Alteori modulului i se specifică numai elementul de context de care are nevoie sistemul (de exemplu sistemul are nevoie de temperatură). descoperirea contextului are la bază aceleaşi mecanisme ca descoperirea serviciilor. atunci când contextul se modifică. dar sursa acestui element de context trebuie descoperita de către modul în timpul funcţionării.1. Accentul se pune pe economisirea energiei şi pe solicitarea a cât mai puţin din resursele de calcul ale dispozitivelor. Protocolul urmăreşte descoperirea acelor dispozitive pe care există senzori care pot să furnizeze informaţii despre un anumit context. iar dispozitivele au resurse de energie şi de calcul limitate. În esenţă. De exemplu i se specifică adresa IP a senzorului care măsoară temperatura. De aceea. iar un Provider folosind mecanismul push diseminează contextul către Requester.1 R-CDP R-CDP [Steph04] este un protocol proiectat pentru mediile ubicomp în care conectivitatea între dispozitivele mobile se schimbă frecvent. Salutation. Câteva dintre caracteristicile protocolului R_CDP: . În continuare vom analiza câteva protocoale de descoperire a contextului precum şi câteva sisteme senzitive la context care au înglobate mecanisme de descoperire a contextului.

Dacă C este disponibil se trimite un mesaj Result care conţine C. R-CDP verifică în Context Repository dacă C este disponibil local. La înregistrare se specifica şi o marca de timp care indica momentul în care contextul devine invalid şi trebuie şters din Context Repository. La primirea unei astfel de înregistrări. La primirea unui Request. R-CDP actualizează Context Repository local. Requester v-a aştepta un interval de timp primirea unui mesaj Result care conţine valoarea contextului C. Descriere protocol din punctul de vedere al modului care cere informaţii despre context – Requester. Mesajele NVB conţin: numărul de Provider-i care furnizează contextul C. Mesajele NVB sunt trimise prin broadcast. Provider-ul va decide formarea şi trimiterea unui mesajul Result care conţine noua valoare a contextului C. iar aplicaţia nu primeşte valoarea contextului căutat. permiţând astfel Requester-ului să descopere noi dispozitive care pot constitui sursă de context C. toate valorile sunt agregate de Requester şi livrate apoi aplicaţiei. Requester trimite un Request prin care anunţă că are nevoie de valoarea pentru contextul C. Comparând valoarea RP cu T se determina dacă trebuie trimisa o actualizare a contexului pentru C la Requester. Acest lucru face ca şi dispozitivele care au intrat mai nou în reţea să primească mesaje NVB. R-CDP nu necesită putere de calcul mare pentru că implică numai operaţii simple de căutare şi întreţinere a Context Repository-ului. Context Repository stochează toate informaţiile despre contextele pe care le cunoaşte dispozitivul Requester. Altfel. Când o aplicaţie care se execută pe un dispozitiv Requester are nevoie de un element de context C anunţă la R-CDP acest lucru. R-CDP nu necesită multă energie pentru că foloseşte următoarele mecanisme: 33 . atunci protocolul se termină aici. Dacă contextul solicitat este disponibil local atunci acesta este livrat aplicaţiei. Provider-ul analizează periodic Context Repository calculând valoarea refresh priority RP pentru contextul C. metodele de achiziţionare a contextului precum şi frecvenţa cu care poate să achiziţioneze contextul. După aceea dispozitivul Requester trimite la intervale regulate mesaje Neighbor Validation Becon (NVB) la dispozitivul Provider pentru a-i spune ca are nevoie în continuare de actualizări ale lui C. iar pentru aceasta ia în considerare energia pe care o au Provider-ii. Dacă RP > T. Dacă timpul s-a scurs fără ca să se primească mesajul Result. Trimiterea mesajului Result mai este condiţionată şi de probabilitatea de transmisie (aşa cum se va explică mai jos) pe care o calculează pe baza valorii Np. dacă sunt mai mulţi Provider-i care furnizează contextul C. număr notat cu Np şi o valoare de prag T (threshold) prin care Requester-ul specifică Provider-ului faptul că doreşte să primească actualizări ale contexului atunci când contextul s-a modificat cu mai mult de T (de la ultima actualizare). Un nou senzor se înregistrează la R-CDP (de pe dispozitivul la care este conectat senzorul) anunţându-şi numele. Altfel. Descrierea protocolului din punctul de vedere al modului care oferă informaţii despre context– Provider.- R-CDP foloseşte funcţia Refresh Priority (RP) pentru a determina când trebuie să trimită Provider-ii actualizări ale contextului. un Provider caută în Context Repository contextul C. tipul de context pe care îl poate furniza.

Noţiunile de bază ale difuziei directe sunt: mesaj de interogare (interest). Mesajele de interogare 34 .1. Presupunem că un Requester are nevoie de intensitatea luminii dintr-o cameră. pentru un anumit context. Dacă N este mare atunci dispozitivele vor consuma multă energie. Ca urmare. Dacă mai mulţi Requester-i trimit simultan mesaje pot să apară coliziuni şi ca urmare pierderi de mesaje care vor trebui retransmise producând atât consum de energie cât şi întârzieri. atunci se trimite un mesaj Result de actualizare a valorii contexului către Requester. Dacă reducem probabilitatea ca Requester-ul să primească cel puţin un mesaj Result de la 100% (toţi cei trei Provider-i trimit Result) la 99% (fiecare Provider va trimite Result cu o probabilitate de [1-(1-0.991/3)] = 0. În cazul în care există N Provider-i care pot furnizeze contextul C atunci N mesaje Result care conţin valoarea contextului C se vor transmite prin reţea. care are în vedere difuzarea datelor în reţeaua de senzori. Pentru a explica această noţiune prezentăm un exemplu din [Steph04]. Dacă da. situaţie în care traficul prin reţeaua ar deveni foarte încărcat şi s-ar folosi mult din resursa de energie a dispozitivelor.Refresh priority.2 Directed diffusion Difuzia directă [Inta00. Mesajul de interogare este o cerere lansată de utilizator pentru îndeplinirea unui anumit task care presupune achiziţionarea de date de la senzori. 3. De asemenea situaţia în care orice modificare a contextului este trimisa către Provider trebuie evitată şi pentru ca unele aplicaţii sunt interesate numai de acele valori ale contextului care s-au stabilizat în timp. un Provider stabileşte când trebuie să trimită o actualizare de context către un Requester. În cazul în care mai multe actualizări de context trebuie trimise simultan. Pentru a reduce probabilitatea de coliziune în [Steph04] se propune modificarea intervalului de trimitere a mesajelor NVB. gradient şi reinforcement (determinarea căii de întoarcere a datelor de la senzori la nodul care a cerut datele). dacă valoarea contextului s-a modificat şi s-a stabilizat în timp peste valoarea de prag T. Probabilitate de transmisie adaptivă. Mesajele NVB sunt trimise prin broadcast. Selecţie adaptivă a intervalului de transmitere a mesajelor NVB. Soluţia propusă în [Steph04] pentru reducerea numărului de mesaje Result redundante se bazează pe noţiunea de probabilitate de transmitere: cu cât numărul de Provider-i este mai mare cu atât scade probabilitatea de transmitere. se calculează refresh priority şi pe baza lor se stabileşte ordinea de trimitere a actualizărilor de context. Expresia funcţiei este de aşa natură încât elimină situaţiile în care valoarea contextului variază brusc (pentru un interval foarte scurt de timp). Cu această funcţie. Funcţia calculează cât de stabilă este modificarea contextului într-un interval de timp. valoarea funcţiei refresh repository se foloseşte pentru a determina. mesaj de date. Inta03] este o paradigmă de comunicare propusă pentru reţelele de senzori. la un anumit moment de timp. Se evită astfel situaţia în care orice modificare a contextului este trimisă către Provider.78) se poate economisi 22% din energia consumată pentru transmiterea mesajelor Result. Un mecanism de coordonare prin care să se stabilească unul dintre Provider-i căruia să îi revină sarcina de a răspunde ar implica cel puţin tot atât consum de energie. iar intensitatea poate să îi fie oferită de trei Provider-i.

400] timestamp = 01 : 20 : 40 // hh:mm:ss expiresAt = 01 : 30 : 40 Fiecare nod al reţelei conţine un cache în care se păstrează interogările. gradient – există câte un astfel de câmp pentru fiecare vecin de la care s-a primit interogarea (aceeaşi interogare poate să fie primită de la mai mulţi vecini). Interogarea iniţială este văzută ca o interogare exploratorie care detectează dacă există senzorii capabili să furnizeze datele care să răspundă interogării. parametrii ei sunt calculaţi pe baza parametrilor interogării. Un mesaj de interogare este lansat de la un nod al reţelei (numit sink) de unde se propagă (se difuzează) mai departe în reţea. Gradientul specifică o direcţie care indică înspre nodul de la care s-a primit interogarea. Când un nod primeşte o interogare. Un gradient specifică pe lângă o direcţie de trimitere a datelor rezultate ca urmare a faptului că s-a răspuns la interogare şi o frecvenţă cu care se doreşte trimiterea datelor. Două interogări sunt considerate distincte dacă atributele lor type diferă sau dacă atributele lor rect indică zone (parţial) distincte. verifică dacă interogarea există în cache. Elementele nu conţin informaţii despre nodul de pornire a interogării ci numai despre nodul imediat anterior prin care a trecut interogarea. Gradientul 35 . 200. Fiecare gradient conţine câmpul datarate (derivat din atributul interval al interogării) şi câmpul duration (calculat pe baza atributelor timestamp şi expiresAt ale interogării). Dacă nu există se creează o intrare în cache pentru această interogare. iar numărul de gradienţi este egal cu unu. 200. Un element din cache are câteva câmpuri. şi anume: timestamp – indică ultimul momentul de timp la care s-a primit interogarea. 220] intensity = 0:6 intensity = 0:85 timestamp = 01 : 20 : 40 // // // // // // type of vehicle seen instance of this type node location signal amplitude measure confidence in the match event generation time. prima interogare poate să arate astfel: type = wheeled vehicle interval = 1 s rect = [-100. Pentru fiecare interogare există un element (o intrare) separat în cache. Un nume poate să fie dat de o listă de perechi atribut-valoare. Datele trimise ca răspuns la un mesaj de interogare sunt şi ele cu nume. Vom descrie în continuare cum se propagă o interogare şi respectiv cum se propagă datele răspuns la interogare. Nodul de plecare a interogării trimite interogarea periodic prin broadcast. De exemplu. Propagarea interogării. 200.sunt mesaje cu nume. De exemplu un senzor care detectează un vehicul va răspunde astfel [Inta03]: type = wheeled vehicle instance = truck location = [125. De exemplu un task de urmărire a unui vehicul poate fi descris astfel [Gu04]: type = wheeled vehicle interval = 20 ms duration = 10 s rect = [-100. adică sunt la rândul lor descrise prin perechi atribut-valoare. 100. 400] // // // // detect vehicle location send events every 20 ms for the next 10 s from sensors within rectangle.

Când un nod primeşte o interogare. nodul poate să decidă să o trimită mai departe unei submulţimi formate din o parte sau chiar din toate nodurile vecine. dar şi de la Nj la Ni. Nodul de plecare retrimite nodului selectat interogarea originală însă cu o valoare mai mică pentru atributul interval. Nj) se stabilesc gradienţi şi de la Ni la Nj. dar nu există un gradient pentru nodul care a trimis interogarea atunci se adaugă un astfel de gradient şi se actualizează timestamp şi duration. Întâi nodul va identifica cea mai mare frecvenţă de date a gradienţilor la care trebuie să trimită datele provenite de la senzori. iar când toţi gradienţii pentru o intrare expiră. el va selecta un vecin care urmează să colecteze datele. Dacă există o astfel de intrare în cache. Nodul trimite apoi la fiecare nod pentru care are un gradient valoarea obţinută de la senzor sub următoarea forma: type = wheeled vehicle // type of vehicle seen instance = truck // instance of this type location = [125. Interogarea iniţială se foloseşte în această fază de explorare în care se stabileşte dacă există noduri cu senzori care pot să răspundă la interogare. dar de data aceasta cu o frecvenţă mai mare (suficient de mare pentru ca datele obţinute să fie de folos pentru aplicaţie). aşa cum se arată mai jos: type = wheeled vehicles 36 .corespunde vecinului de la care a primit interogarea. Apoi va cere senzorului să genereze datele cu această frecvenţă. După ce nodul de pornire începe să primească răspunsuri. Răspunsurile pot să se întoarcă la nodul de plecare pe mai multe căi. nu ştie dacă aceasta este primită ca urmare a unei interogări pe care el a trimis-o mai devreme sau este o interogare identică trimisă de un alt nod. Stabilirea căii de transmitere a mesajului de răspuns Până acum s-a descris interogarea iniţială trimisă de un nod de plecare (sink) şi difuzată apoi în întreaga reţea. Gu05] se descrie situaţia în care nodul trimite interogarea la fiecare vecin. Un nod care are senzori şi care este în aria specificată prin atribute poate să prelucreze interogările care ajung la el. 220] // node location intensity = 0:6 // signal amplitude measure confidence = 0:85 // confidence in the match timestamp = 01 : 20 : 40 // local event generation time La primirea unui astfel de mesaj de răspuns care conţine date. Frecvenţa de transmitere a datelor din mesajul răspuns este adaptată la rata de transmitere a datelor specificată în gradienţi. datele sunt trimise către nodurile vecine pentru care intrarea conţine gradienţi. intrarea este ştearsă la rândul ei. Când un gradient expiră este şters din intrare. un nod va caută în cache o intrare care conţine interogarea care se potriveşte cu răspunsul. Dacă există intrare în cache pentru interogare. În lucrarea [Gu04. Ca urmare pentru fiecare pereche de vecini (Ni. Dacă există atât intrarea în cache cât şi gradientul atunci doar se actualizează timestamp şi duration. deci şi la nodul de la care a primit interogarea. Dacă nu exista o astfel de intrare în cache atunci mesajul de răspuns este abandonat. După ce primeşte interogarea. Un nod poate să decidă să nu mai trimită o interogare dacă recent a mai trimis una identică (chiar dacă aceasta are un alt nod iniţial de plecare). Propagarea datelor. Această interogarea specifică de obicei o frecvenţă de transmitere a datelor mică.

senzorii trebuie să poată să comunice între ei despre datele pe care le au deja şi despre cele de care au nevoie.interval = 10 ms rect = [-100. Un exemplu simplu de meta-data este ID-ul senzorilor astfel încât toate datele colectate de la un senzor sunt descrise de ID-ul lui. mesajul conţine de fapt nu datele în sine ci meta-data care le descrie REQ – mesaj prin care se formulează o cerere pentru date. y. Există două idei fundamentale ale protocolului SPIN: 1. un nod trimite un astfel de mesaj atunci când are nevoie de anumite date DATA – mesaj care conţine data. Un alt exemplu pe care îl prezentăm se referă la un senzor aparat de filmat. Mesajele SPIN Protocolul foloseşte trei tipuri de mesaje: ADV – mesaj prin care se anunţă că un nod doreşte să facă publice noi date. Meta-date Meta-datele sunt folosite pentru a descrie pe scurt.1. care primeşte interogarea. 200.3 SPIN SPIN (Sensor Protocols for Information via Negotiation) [Heinz99] este un protocol de diseminare eficientă a datelor între senzori. 200. va vedea că rata de transfer a datelor este mai mare decât înainte şi va verifica dacă are vreun gradient care să aibă o rată de transfer date mai mare sau egală cu cea din interogarea pe care a primit-o. eficienta din punctul de vedere al energiei consumate de reţeaua de senzori wireless. pentru a economisi energia reţelei. Negocierea bazată pe meta-date stă la baza transmiterea eficienta a datelor. Dacă nu are astfel de gradienţi va alege un vecin căruia îi va transmite interogarea cu noua frecvenţă de transfer. dar complet datele care sunt colectate de la senzori. Se construieşte astfel calea pe care va veni înapoi răspunsul la interogare. 2. meta-data poate consta din tripletul (x. 3. Ø) unde x şi y reprezintă coordonatele geografice ale poziţiei aparatului. Meta-data este de fapt o reprezentare succintă pentru o colecţie mare de informaţii. Protocolul SPIN nu specifică un format pentru meta-date revenindu-i aplicaţiei sarcina să specifice acest format. 400] timestamp = 01 : 22 : 35 expiresAt = 01 : 30 : 40 Nodul vecin. nodurile trebuie să fie capabile să monitorizeze nivelul de energie pe care îl au şi să acţioneze în conformitate cu acest nivel. Două date care nu se pot distinge una de alta vor fi descrise de aceeaşi meta-data. mesajul are ca header meta-data care descrie datele 37 . În acest caz. Ceea ce este specific pentru SPIN este faptul ca nodurile reţelei folosesc meta-date pentru a descrie datele. La două date diferite trebuie să le corespundă două meta-date diferite. Bineînţeles că meta-data care descrie o dată trebuie să aibă o lungime mai mică decât data în sine. iar Ø reprezintă orientarea lui.

el nu va trimite mesajul de cerere REQ numai dacă are suficientă energie nu numai să trimită mesajul. SPIN-1: Protocolul 3-Stage handshake SPIN-1 este un protocol handshake pentru diseminarea datelor printr-o reţea fără pierderi (lossless network) care foloseşte trei paşi: ADV-REQ-DATA. Aplicaţiile pot să interogheze resursele sistemului pentru a afla câtă energie mai este disponibilă. Nodurile pot să îşi facă în mod repetate publice datele (mesaj ADV) în felul acesta se rezolva problema mesajelor ADV care s-au pierdut. Vom descrie în continuare acest protocol. le poate agrega cu cele ale lui A şi va publica nu datele primite de la A ci datele lui agregate cu cele primite de la A. Însă SPIN-2 evită situaţiile în care un nod lucrează cu mesajul DATA având energia sub pragul specificat. SPIN nu furnizează o anumită politică de management a resurselor ci oferă aplicaţiilor interfeţe care pot să fie folosite pentru a interoga resursele sistemului. Aplicaţiile folosesc această librărie pentru a dezvolta propriile protocoale SPIN. La primirea acestor date.Managementul resurselor în SPIN Aplicaţiile SPIN sunt conştiente de resurse şi se pot adapta resurselor. atunci răspunde cu un mesaj REQ pe care îl trimite nodului A. atunci îşi reduce participarea la protocol pentru a conserva energie. el va iniţia protocolul cu cei trei paşi ai lui numai dacă are destulă energie pentru a termina protocolul cu toţi vecinii lui. Mai exact nodul va participa la o etapă a protocolului numai dacă crede că va putea termina şi ceilalţi paşi ai protocolului fără ca nivelul lui de energie să scadă sub pragul specificat. În aceeaşi abordare. Nodurile pot să ceara încă o dată datele dacă acestea nu sosesc într-un interval de timp specificat. SPIN-2 nu evită situaţiile în care un nod recepţionează (si ca urmare îşi consumă energia sub pragul specificat) ADV sau REQ. Reţelele mobile sunt caracterizate de faptul că topologia reţelei se schimbă frecvent. dar să şi primească datele răspuns la mesaj. SPIN este o librărie situată la nivel middleware. Protocolul continuă prin faptul că acum B va trimite la toţi vecinii lui (cu excepţia lui A) un mesaj ADV pentru aceste date. Un nod A care are date pe care doreşte să le facă publice trimite un mesaj ADV la vecini. fiecare vecin verifică dacă are aceste date. atunci nodul trimite din nou mesajul prin care face publice datele lui. în felul acesta se rezolvă problema pierderilor mesajelor REQ şi DATA. Dacă o modificare (locală) de topologie produce modificarea listei de vecini a unui nod. Deşi acest protocol a fost proiectat să lucreze în reţele fără pierderi el poate să fie uşor adaptat pentru reţele cu pierderi şi pentru reţele mobile. Când energia este suficientă atunci SPIN-2 se comportă ca SPIN-1. dacă un nod primeşte un mesaj ADV. 38 . Astfel dacă un nod primeşte date. Acesta va răspunde cu un mesajul DATA care conţine de fapt datele de la A. De asemenea ele pot să calculeze de câtă energie este nevoie pentru a efectua anumite calcule şi pentru a trimite sau primi date. SPIN-2: SPIN-1 cu prag de energie SPIN-2 adaugă o euristică de conservare a energiei protocolului SPIN-1. Când însă un nod observă că energia lui se apropie de un prag specificat. Prezentăm în continuare două variante ale protocolului SPIN. Dacă B nu are toate datele pe care A doreşte să le facă publice. Dacă nodul B are propriile lui date. să notăm cu B unul dintre vecinii lui A.

furnizorii interni colectează date de la senzorii de prezenţă. Datorită faptului că filtrele Bloom reprezintă datele într-un mod compact traficul prin reţea este redus. De asemenea. Diferenţa dintre cele două tipuri de module este dată de senzorii de la care se obţin datele. în cazul în care domeniul de interes este maşina aceşti senzori colectează date de la sistemul de navigare GPS sau de la alţi senzori din maşină. utilizatorii şi aplicaţiile descoperă furnizorii şi interpretorii de context. precum şi intrepretorii de context.4 Filtre Bloom Protocolul [Liu07] este folosit în reţetele ad-hoc. pe care o trimit nivelelor superioare ale arhitecturii.3. 39 .1. Furnizorii externi colectează informaţii despre contextul din afara domeniului de interes (de exemplu informaţii despre starea vremii care se pot colecta de la un senzor virtual de tipul servicii web). zgomot etc. Furnizorii interni achiziţionează datele de la senzorii fizici din interiorul domeniului de interes. La acest modul se înregistrează furnizorii de context. Un furnizor de context îşi poate anunţa setul de elemente de context de la care culege informaţie în mai multe moduri: prin şabloane sau prin expresii OWL. Descriem în continuare aceste două module. 3. Filtrele Bloom sunt folosite pentru a face publică informaţia de context la mai multe noduri (hop-uri) distanta şi pentru a ghida descoperirea informaţiei de context. Informaţia despre context se reprezintă prin structuri de date Bloom filter care au avantajul că au dimensiuni mici. furnizorii de context îşi pot modifica în timp elementele de context de la care pot să afle informaţie. Aceste module sunt de două tipuri: furnizori de context intern şi furnizori de context extern. Informaţia despre context (tipul contextului şi sursa lui) nu este trimisă prin broadcast ci se trimit numai filtre Bloom care conţin tipul contextului la toate nodurile aflate la o distanţă de câteva hop-uri. În arhitectura SOCAM. De exemplu. senzorii de temperatură. Gu05] mecanismul de descoperire a contextului este implementat în două module ale arhitecturii Furnizorii de context şi Serviciul de localizare. Ambele tipuri de furnizori obţin date de la senzori şi convertesc aceste date în reprezentare OWL. Modulele arhitecturii pot să descopere şi apoi să folosească acele componente care sunt înregistrate. Serviciul de localizare. tot de la un serviciul web se pot colecta date despre condiţiile de trafic. Interogările sunt trimise numai în direcţiile în care s-ar putea afla informaţia cerută. diseminarea contextului se face atât în modul push cât şi în modul pull. Serviciul de localizare oferă suport pentru ambele. Furnizorii de context. De asemenea. Dacă domeniul de interes este o casă. Şi în această situaţie serviciul de localizare oferă suport pentru administrarea acestor modificări. Tipic. serviciile senzitive la context.2 SOCAM (Service-Oriented Context-Aware Middleware) În SOCAM [Gu04.

Un alt exemplu este cel al unei componente interesate de Interpretori care au o anumită mulţime de atribute de intrare/ieşire. Nivelul superior se numeşte SCINET şi este responsabil cu interacţiunea care are loc între două sau mai multe Range cu scopul schimbului de informaţii de context. În literatura de specialitate au fost propuse foarte multe mecanisme pentru descoperirea contextului. CE produce şi consumă evenimente care au asociate tipuri. Nivelul inferior se numeşte Range. Când componentele Widget. numele staţiei gazdă. De exemplu. Un senzor este reprezentat de o entitate numită context entity CE al cărui profil este descris cu ajutorul meta-datelor. numele staţiei gazdă. va anunţa Componentei de descoperire identificatorul. CE se înregistrează la o entitate centrala Registrar de unde apoi pot să fie găsite de alte module care au nevoie de ele. atributele pe care le poate interpreta şi atributele pe care le poate genera ca şi ieşiri.3. Un element definitoriu pentru SCI este faptul ca informaţiei de context se agregă înainte de a ajunge la entitatea care a solicitat-o. atributele. ele se înregistrează la Componenta de descoperire. administrează şi utilizează informaţii de context. numărul portului. Entităţile care sunt într-un Range pot să fie interesate de informaţiile de context care pot să fie furnizate de entităţile dintr-un alt Range. o componentă poate fi interesată de un Widget sau de un Agregator care are o anumită mulţime de atribute şi/sau o anumită mulţime de atribute constante şi/sau o anumită mulţime de servicii. 3. va anunţa Componentei de descoperire identificatorul. Când un Widget sau un Agregator se înregistrează. În capitolul 3 al acestui raport s-a făcut o selecţie 40 . numărul portului. Dey01] mecanismul de descoperire a contextului este implementat în Componenta de descoperire. Aplicaţiile nu trebuie să cunoască de la început unde se găsesc componentele de care au nevoie.3 Context Toolkit În Context Toolkit [Dey00. Când aplicaţia porneşte. contactează Componenta de descoperire pentru a localiza componentele de care are nevoie. iar în interiorul ariei se produc. se combina CE (pe baza profilelor lor) într-un graf. La un moment dat un CE este înregistrat într-un Range. Când un Interpretor se înregistrează. Modulul principal din fiecare Range se numeşte Context Server CS. Rolul Componentei de descoperire este să localizeze în reţea componentele arhitecturii.5 Concluzii Descoperirea contextului trebuie să fie o caracteristica a sistemelor autonome senzitive la context. 3. callbackuri şi servicii. De fapt. şi este o arie care conţine noduri. aplicaţiile se pot adapta uşor pentru că ele pot cere Componentei de descoperire să le anunţe atunci când au loc astfel de evenimente. Dacă infrastructura care lucrează cu senzorii se modifică (adică apar sau dispar componente). Agregator şi Interpretor se instanţiază.4 SCI SCI [Glass03] este organizata în două nivele.

Protocolul nu specifică un format anume pentru meta-date ci lasă această sarcina dezvoltatorului de aplicaţii. exemple sunt SOCAM şi ContextToolkit. În SPIN sunt folosite meta-datele pentru a descrie complet şi succint informaţiile de context.analizându-se numai acele mecanisme care s-au considerat că sunt de interes pentru proiect. 41 . mediul pentru care au fost proiectate precum şi descrierea informaţiei de context. aşa cum este în cazul Directed diffusion şi SPIN. În astfel de medii se pune de asemenea problema optimizării consumului de energie. Din studiul acestor mecanisme se observă că ele diferă prin arhitectura. sau distribuită. ştie să reducă răspunsurile redundante şi ia în considerare energia pe care o au Provider-ii pentru a determina când trebuie să se trimită actualizări ale contextului. În acest sens protocolul R-CDP ştie să modifice intervalul la care se transmit cererile de context. În SPIN folosirea eficienta a resurselor de energie se face prin negocierea bazată pe meta-date. Protocolul Directed diffusion foloseşte mesajele cu nume pentru formularea interogărilor şi a răspunsurilor de la senzori. Ajungem astfel la descrierea informaţiei de context. În protocolul bazat pe filtre Bloom informaţia despre context se reprezintă prin structuri de date Bloom filter a căror avantaj este acela ca reprezintă informaţia într-un mod foarte compact. Se observă că arhitectura distribuită este folosită atunci când protocolul este proiectat pentru mediile ubicomp în care conectivitatea dintre dispozitivele implicate în interacţiune se schimbă des. Arhitectura poate să fie centralizată.

4 Observarea contextului în cazul aplicaţiilor adaptive implementate 4. Serviciul foloseşte limba engleză şi EURO ca şi moneda de specificare a preţurilor. Pentru modelarea contextului s-a ales o schemă simplistă bazată pe 42 .1 Observarea contextului în cazul platformei SOA În această secţiune este prezentat modul de interacţiune al platformei de test propuse cu elementele de context.2 Reprezentarea contextului După cum s-a specificat mai sus. rolul scenariului este de a realiza adaptarea unui serviciu la context.Aflarea detaliilor despre un anumit produs în funcţie de numele acestuia.Aflarea preţului unui produs în funcţie de numele acestuia. Figura 4. 4.1. O aplicaţie client se poate conecta la acest serviciu şi poate invoca.1 Scenariu Scopul acestui scenariu este de a ilustra modul de adaptare a serviciilor software considerând o arhitectură de genul celei din figura urmatoare.1. Acest serviciu oferă trei operaţii: .Aflarea produselor disponibile. 4. Dacă un client foloseşte o altă unitate monetară atunci apare o dezadaptare. . cele trei operaţii de mai sus. Considerăm adaptare returnarea preţului unui produs convertit la moneda clientului. numit Virtual Store Service. Această operaţie este cea care ne interesează şi pe care dorim să o adaptam în acest scenariu. Platforma de adaptarea a serviciilor – arhitectura de principiu Pentru scenariul propriu-zis considerăm un magazin virtual sub forma unui serviciu Web. .1.

Acest mesaj este transmis serviciului Web.org/2003/05/soap-envelope" xmlns:xsd="http://quickstart. Clientul dispune de un detector de context. clientul este responsabil de detectarea contextului în care evoluează şi de transmiterea acestuia la server. ilustrat în secţiunea precedentă.1. mesajul SOAP este prelucrat de către Observer/Controler.perechi cheie-valoare (key-value pairs).CurrencySymbol. NumberFormatInfo numberFormatInfo = currentCultureInfo. string currencySymbol = numberFormatInfo. Înainte de a ajunge la acesta.Globalization.1. Clientul a fost dezvoltat folosind tehnologia .NumberFormat.w3. în exemplul următor: <Context> <Currency>RON</Currency> </Context> 4.4 Transmiterea contextului Ideea de trasmitere a contextului este ilustrată în figura următoare. Modul de determinare a monedei (currency) curente pe o masină Windows este ilustrat în următoarea secvenţă de cod (folosind limbajul C#): using System. Contextul astfel detectat este încapsulat în mesajul SOAP folosit pentru invocarea metodelor serviciului.samples/xsd"> <soap:Header> <Context> <Currency>RON</Currency> </Context> 43 . Figura 4. în format XML.CurrentCulture.3 Detectarea contextului În cazul acestui scenariu. Acest mod de reprezentare este ilustrat. după care este mai departe trimis serviciului Web. CultureInfo currentCultureInfo = CultureInfo.2 Modul de trasmitere a contextului de la client la serviciu Întregul mesaj SOAP folosit pentru invocarea metodei de aflare a preţului unui anumit produs arată astfel: <soap:Envelope xmlns:soap="http://www. prin intermediul componentei ContextHandler. 4.NET.

Owl:Thing Software Entity Network Entity Software Operation Name Description Software Application Currency Language Transformation Operation Parameter IP Address Network Protocol Desktop Application Mobile Application Web Application TCP HTTP Conversion To Service EndPoint Service Operations From Web Service Figura 4. 44 . Serverul preia contextul transmis de către client şi consultă ontologia pe care o are la dispoziţie.</soap:Header> <soap:Body> <xsd:getPrice> <xsd:param0>product</xsd:param0> </xsd:getPrice> </soap:Body> </soap:Envelope> Contextul este încapsulat în header-ul mesajului SOAP şi poate fi ignorat de serviciile web care nu îl „inteleg” deorece nu este specificat ca fiind o secţiune obligatorie a mesajului (atributul mustUnderstand din specificaţiile SOAP este false în acest caz). Această ontologie este ilustrată în figura următoare. Ambele clase derivă din clasa SoftwareApplication care este caracterizată de atributul Currency. Ontologie pentru clasificarea serviciilor Web Din această ontologie se poate deduce faptul că VirtualStoreService este o instanţă a clasei WebService iar VirtualStoreClient (clientul care se conectează la serviciul web) este o instanţă a clasei DesktopApplication.3.

Acest model are dezavantajul de a avea doar două valori posibile (pozitiv sau negativ) pentru a indica relaţia dintre context şi preferinţe. o estimare pe care trebuie să o realizeze un operator uman la proiectarea sistemului sau la introducerea unui nou element de context. fie un scor special predefinit (veto. Clasa Preferences are relaţii cu toate clasele principale (Time. iar v este setul de variabile asociate. Noi ne focalizăm asupra reprezentarea acestor preferinţe în corespondenţă cu contextul. O reprezentare ontologică a preferinţelor este prezentată în [Kim05]. Modelul propus foloseşte o reprezentare neontologică a contextului. Această soluţie însă nu beneficiază nici de avantajele reprezentării ontologice a contextului şi nici de cele ale unui mecanism de readaptare a ponderilor folosind reacţia utilizatorului. Ea se bazează pe un mecanism de scoruri.1]. 4. Pe scurt.În acest mod se determină faptul că există o dezadaptare. adaptarea se realizează prin cautarea şi invocarea unui serviciu care să realizeze conversia necesară. nu există soluţii pentru a reprezenta aceste preferinţe în dependenţa lor faţă de context. Preferinţa poate fi pozitivă sau negativă.2.2 Observarea contextului în cazul platformei de agenţi 4. obligatoriu. C este contextul. în scopul adaptării comportamentului. Fiecărui element de context i se asociază toate cele N posibile aplicaţii pentru un utilizator dat. poate indica o alegere potrivită sau nepotrivită. În acest model elementele de context sunt considerate distincte. Un alt articol [Flan05] prezintă o soluţie cu reţele asociative context-aplicaţie. dar arată că pentru reprezentarea preferinţelor în scopul adaptării comportamentului.s. ceea ce este dificil de rezolvat pentru un număr mare de elemente de context. fiecărei posibile preferinţe i se alocă un scor ce poate fi fie o valoare numerică reală din intervalul [0. Mai mult considerând matricea tuturor ponderilor şi un context anume. unde p. care au ca fundament matematic probabilităţile condiţionate. nu avem o reprezentare ontologică. Activity). Există un prim studiu [Henri06’] care face o trecere în revistă a soluţiilor de până în acel moment (2006) pentru reprezentarea preferinţelor. Autorii articolului citat mai sus [Henri06’] propun ei înşişi o astfel de soluţie.C. fără relaţii între ele.1 Reprezentarea preferinţelor utilizatorului În momentul actual în literatura de specialitate există mai multe articole care tratează reprezentarea preferinţelor. dar propun un mecanism bazat pe meta-reţele Bayes şi considerarea reacţiei utilizatorului la deciziile sistemului. în cazul sistemelor omniprezente (senzitive la context).s este expresia scorului preferinţei p. Acest model se bazează pe relaţii ontologice între preferinţe şi elementele de context. Agent. Location. situaţie de eroare). Dacă un anumit context este prezent şi un set de variabile asociate sunt prezente. se poate estima care va fi aplicaţia pe care utilizatorul o va prefera. scorul va fi o funcţie score(p. 45 . altfel scorul este indiferent. Asocierea este modelată printr-o pondere variabilă w care indică tăria conexiunii dintre un anumit element de context şi aplicaţia cu care este asociat. O altă soluţie pentru reprezentarea preferinţelor vine din acelaşi colectiv de cercetători [Kamr06].v). Problema care apare aici este că probabilităţile apriori necesită un calcul iniţial. indiferent. Meta-reţelele Bayes sunt o structurare pe mai multe nivele a reţelelor Bayes.

antrenarea sistemului făcându-se doar înainte de rulare. cum?. a modificării preferinţelor în funcţie de nevoile utilizatorului. servicii şi parametri ai seviciilor. Totuşi această posibilitate este utilizată de autori doar parţial. În tabelul 4. Se folosesc perceptroni multistrat cu un nivel ascuns. dar mai ales la rulare. 46 .1 avem o comparaţie sintetică a diferitelor soluţii de reprezentare a preferinţelor: Tabel 4. Soluţia cu meta-reţele Bayes este cea mai apropiată de obiectivul precizat mai sus. Dezavantajul ce apare la nivelul reprezentării la această soluţie este că aici modelul contextului nu este ontologic. Comparaţie a diferitelor soluţii de reprezentare a preferinţelor Soluţie CtxPrefScor‘06 [Henri06’] OWLPref‘05 [Kim05] Bayes Meta-Net’06 [Kamr06] NNAssoc’05 [Flan05] UPM’05 [Youn05] Context. 4.Reţelele neuronale sunt folosite în [Youn05] pentru a descrie relaţii ponderate între elemente de context (care răspund întrebărilor: cine?. când?.ontologic + Relaţia context-serviciu scor relaţie ontologică probabilistică ponderi reţele asociat.1) am constat că sunt puţine soluţii care iau în calcul reprezentarea şi apoi modificarea valorilor relaţiei contextserviciu.2. dar la care lipseşte posibilitatea modificării dinamice a preferinţelor la rulare. unde?. Mecanismul fiind bazat pe reţele neuronale care sunt astfel antrenate să răspundă cu un anumit serviciu la un context dat.2. ponderi PMS* Actualizare la rulare ++ + * PMS – Perceptron MultiStrat (din limba engleză: MLP-MultiLayer Perceptron) Remarcăm utilizarea modelării ontologice a contextului doar într-un singur caz [Kim05].1. Pentru exprimarea preferinţelor unui serviciu dat fiind contextul există mai multe soluţii. Aceasta permite ca relaţiile ponderate să fie modificate. dar are dezavantajul că nu face aceasta la rulare în funcţie de reacţia utilizatorului. de ce?) şi elementele de context (care răspund întrebării: ce?). În lucrările [Flan05] şi [Youn05] se propune folosirea datelor istorice înregistrate ca perechi context (vectori de elemente de context) – servicii.2 Mecanisme de descoperire a preferinţelor În urma studiului prezentat mai sus (secţiunea 4. Ultima coloană a tabelului permite evaluarea soluţiei din perspectiva obiectivului nostru de a oferi posibilitatea personalizării. Un alt dezavantaj este că reprezentarea contextului este aici neontologică. Astfel că soluţia cu perceptronul multistrat [Youn05] este superioară celei în care se folosesc doar ponderi ce indică asocieri între context şi servicii [Flan05] deoarece permite modificarea ponderilor printr-un mecanism de propagare inversă a erorilor (back propagation). Concluzia studiului este că modelarea ontologică a contextului este bine să fie combinată cu o soluţie pentru reprezentarea ontologică a relaţiei context-serviciu care să permită modificarea valorilor şi înainte (antrenare).

Principial. sau obţinute cumva (nu se ştie încă în ce fel) din istoric) nefiind dată încă o soluţie de iniţializare automată a lor. observăm următoarele: -avantaje: i.4: t1 Ψ U t0 C w S Figura 4.3. pentru soluţia cu meta-reţele Bayes. 47 .2. dat fiind un context C prin reacţie afectivă Ψ la deciziile sistemului Funcţional. la momentul t0 sistemul va răspunde cu un anumit serviciu la contextul dat. Relaţia context-serviciu o reprezentăm prin ponderi. ca în figura 4.2. Contextul va fi modelat ontologic 2.Un element unic al soluţiei [Kamr06] este considerarea unei bucle de reacţie de la utilizator prin care valorile relaţiei context-serviciu sunt modificate la rulare. se pot stabili priorităţi între utilizatori -dezavantaj: probabilităţile condiţionate iniţiale trebuie completate (calculate de proiectant şi editate manual sau utilizând expresii. soluţia pe care o propunem consideră contextul C. Decizia oferirii unui anumit serviciu la momentul t0 va determina o reacţie a utilizatorului la moment imediat următor t1.3 Soluţii propuse 4. un vector de ponderi w. Actualizarea preferinţelor se face prin interpretarea răspunsului afectiv al utilizatorului la fiecare decizie a sistemului. prin care modelăm preferinţele şi pe ale căror valori le stocăm tot în ontologie şi stare afectivă Ψ a utilizatorului U. format din elemente de context legate între ele prin relaţii (model ontologic). Astfel că sistemul va descoperii preferinţa utilizatorului. În concluzie.1 Ontologia casei inteligente şi raţionarea ontologică Pentru reprezentarea cunoaşterii am făcut următoarele alegeri: 1. preferinţele fiecărui utilizator sunt separate şi reutilizabile ii. modelate în ontologie 3. un serviciu S (sau mai multe). din care pe noi ne interesează partea ei afectivă. în funcţie de o matrice de ponderi aleatoare sau preantrenată din date istorice de comportament ale acelui utilizator la contexte similare. Diagrama de principiu a modelării ontologice a preferinţelor w pe care le are un utilizator U pentru un anumit serviciu S.4. 4. va fi interpretată mai întâi ca exprimând un acord sau un dezacord cu decizia sistemului. Astfel sistemul se adaptează la noile preferinţe prin paşi succesivi. Acest acord sau dezacord determină modificarea corespunzătoare a (adecvarea) ponderilor w (fapt simbolizat prin săgeata oblică). Această reacţie.

48 .2.4. Ce legătură este între ontologii şi mesajele schimbate între agenţi? Cum s-a făcut verificarea consistenţei cu Jena? Cum am folosit raţionarea ontologică pentru clasificare în cazul ontologiei Smart House? Cum am folosit raţionarea bazată pe caracteristicile proprietăţilor? Cum am folosit regulile utilizator? 1.am înlocuit clasa User cu clasa Actor cu subclasele Group şi Individ. 4.am adăugat clasele NeuralNetwork şi Sensitivity.5. Am căutat să răspundem la următoarele întrebări: Cum s-a făcut proiectarea ontologiei? a. Pentru proiectarea ontologiei modelului de context am pornit de la ontologia SOCAM [Gu05] pe care am extins-o: .1. a) şi b). 3.1 Proiectarea şi implementarea ontologiei de context şi a raţionării ontologice 1.3. 2. Physiological şi Affective . 5.am adăugat clasa State. Human şi NonHuman . Am păstrat ideea de ontologie de nivel superior (upper) şi de nivel inferior (lower) din [Gu05] aşa cum se poate observa din figura 4. Cum am proiectat ontologia modelului de context? b. cu subclasele Mental.

Acesta este specific Jadex. Beanynizer este o unealtă care se integrează în editorul de ontologii Protege şi permite exportarea conceptelor sub un format compatibil Nuggets XML. În cazul aplicaţiei noastre.5. partea superioară şi b) în dreapta. şi nici caracteristici ale proprietăţilor). Această ontologie este distinctă de cea a casei inteligente din cauza diferenţei între OWL şi RDF. Ontologia de comunicare între agenţi permite atât accesul la un model structurat al domeniului cunoaşterii cât şi facilitarea creării de obiecte JavaBean.6. Ontologia de context pentru casa inteligentă: a) în stânga. La noi Jadex a impus acest format care are o limitare importantă: este doar RDF şi nu OWL. universale. ca urmare este mai puţin expresiv (indică doar relaţii subiect-predicat-obiect. cardinalitate etc.Figura 4. Între ontologii şi mesajele schimbate între agenţi legătura este că mesajele folosesc un cadru comun de discuţie care este reprezentat în ontologie. partea inferioară b. fără restricţii existenţiale. dar cuprinde clasele necesare care să permită comunicarea agenţilor din casă. ontologia pentru comunicarea dintre agenţi este cea din figura 4. La nivel de conţinut se foloseşte limbajul Nuggets XML Content Language. 49 .

Ontologie responsabilă cu comunicarea între agenţi Un exemplu de cod de comunicare interagenţi pentru schimbul unui obiect de tip este următorul: public class InitSensorPlan extends Plan { public void body() { IMessageEvent request = (IMessageEvent)getInitialEvent(). Sensor sensor=(Sensor)request.owl#". jenaModel = new CreateModel(ONT. 50 .6.getContent().getBelief("sensor"). Verificarea consistenţei se face cu Jena la momentul încărcării ontologiei (fişierul OWL) în modelul Jena: String ONT = "http://www.com/Ontology1207603095.getParameter("sender").owl-ontologies. } } 2. getLogger().Figura 4."file:src/ontology/smarthouse_lower.getValue().owl"). AgentIdentifier aId = (AgentIdentifier)request. getBeliefbase().info("Sensor object exchange").setFact(sensor).

Un exemplu este clasa Father (Tată) (vezi figura 4. la acelaşi nivel cu Brother (Frate) şi Son (Fiu). Figura 4. Definirea clasei Man Figura 4. condiţia necesară şi suficientă este ca acel om (Human) să aibă cel puţin un copil (proprietatea hasChild) care.9). este un om şi să aibă valoarea proprietăţii (hasGender) Male (sex masculin). Definirea clasei Father În urma raţionării (a se vedea figura 4.3. desigur.7).8. Raţionarea ontologică pentru clasificare în cazul ontologiei SmartHouse s-a făcut prin definirea claselor pe baza claselor de primitive. se subsumează Father clasei Man (Bărbat).7. Definirea clasei Father s-a făcut plecând de la clasa de bază Human. 51 .

Raţionarea pentru instanţe 52 .Figura 4. Ontologia rezultată în urma raţionării ontologice Figura 4.9.10.

reţelele neuronale permit antrenarea valorilor iniţiale fără ca utilizatorul sau proiectantul să calculeze şi să editeze valori iniţiale de probabilităţi .reţelele neuronale nu solicită completarea tuturor combinaţiilor de situaţii (elemente de context . Care sunt argumentele pentru a stoca parametri reţelei neuronale care face adaptarea comportamentului sistemului (comportamentul este o tuplă (C. (?rfid pre:hasLocation ?room). -> (?c pre:isAuthenticatedBy ?a).servicii) posibile . adică sistemul va putea să răspundă şi la reguli pentru care nu a fost antrenat.2. print(?room)] Ea permite identificarea locaţiei (room) unui utilizator (user) pe baza unei etichete RFID (tag) care îi este asociată (hasRFIDTag). dar nu şi pentru Mary. aceştia le pot transfera şi invitaţilor lor. Care sunt avantajele utilizării reţelelor neuronale faţă de meta-reţelele Bayes? 2. (?c pre:isAuthenticatedBy ?b). (?rfid pre:hasCurrentTag ?ctag). (?user pre:hasRFIDTag ?tag). citită de un cititor (RFIDReader) aflat într-o anumită locaţie (hasLocation) atunci când utilizatorul se autentifică (hasCurrentTag). 5. -> (?user pre:hasLocation pre:RoomNo2).10 se arată un exemplu de raţionare prin care membri familiei Smith sunt „recunoscuţi” ca membri ai familiei printr-o raţionare ce se bazează pe proprietatea „familyName” a cărei valoare este „Smith” pentru John.În figura 4. care este invitata familiei Smith. print(?c)] Astfel dacă sistemul oferă drepturi membrilor casei.3.2 Reprezentarea preferinţelor Reprezentarea ponderilor în ontologie se face în strânsă legătură cu tipul de sistem expert pe care l-am ales: o reţea neuronală de tip perceptron cu straturi ascunse.S) context-serviciu) la preferinţele utilizatorului în ontologie? Răspundem pe rând celor două întrebări: 1.reţelele neuronale permit generalizarea. La soluţia cu meta-reţelele Bayes [Kim05’] avem o creştere foarte mare a numărului de probabilităţi iniţiale odată cu creşterea numărului de valori ale elementelor 53 . (?rfid rdf:type pre:RFIDReader). a selectării datelor pentru antrenare. Reţelele neuronale faţă de meta-reţelele Bayes prezintă următoarele avantaje: . O regulă de tip utilizator este cea de mai jos: [USER_LOCATION: (?user rdf:type pre_upper:Human). Jane şi LittleJohn. Raţionarea bazată pe caracteristicile proprietăţilor este demonstrată prin următorul exemplu de tranzitivitate aplicată pentru acordarea de drepturi pentru utilizatorii casei: [RIGHTS: (?b pre:isAuthenticatedBy ?a). 4. 4. Totuşi la reţelele neuronale dificultatea constă în partea de proiectare a reţelei. Raţiunea acestor decizii este dată de răspunsul la următoarele două întrebări: 1.

2. unde N este numărul de utilizatori. Meta-reţelele Bayes au un ordin de complexitate de O(Npq α + q αNp ) [Kim05’]. înseamnă că pentru n utilizatori este necesar un număr de n+1 nivele Bayes. Deci putem observa o reducere a nivelului de complexitate de 8 ori. adică ajung la 128.de context. Astfel pentru 2 utilizatori s-ar ajunge la 3*128 = 348 de valori de calculat. Reţelele neuronale nu solicită un calcul iniţial pentru valorile ponderilor (acestea se generează aleator) însă solicită un set de perechi intrare (valori ale elementelor de context) – ieşire (acţiuni sau servicii dorite) pe care îl poate lua din date istorice şi cu care se antrenează. rezolvat prin meta-reţele Bayes. În cazul soluţiei cu reţele neuronale. Deci este o creştere exponenţială. q este numărul de valori ale serviciilor sau acţiunilor posibile. unde e este numărul de elemente de context.într-o altă aplicaţie în care se regăsesc aceleaşi elemente de context şi servicii . numărul de neuroni de pe fiecare strat. p este probabilitatea ca un utilizator să fie la o anumită locaţie. Calculând pe exemplul dat O(4*1)=O(4). Pentru exemplul considerat. conflictul dintre mai mulţi utilizatori.într-o altă aplicaţie în care se regăsesc parţial elementele de context iniţiale şi serviciile (ca punct de pornire) ii) permite reconfigurarea dinamică (la rulare) a parametrilor reţelei (numărul de nivele ascunse.preferinţele asupra resurselor care să fie folosite de către sistem (parametri serviciului) 4. Însă dacă mai adăugăm un element de context cu două valori binare posibile (de exemplu zi/noapte sau „în timpul săptămânii”/„sfârşit de săptămână”) numărul valorilor de calculat pentru probabilităţile iniţiale se dublează. cu două nivele de luminoziate (luminos/întuneric) pentru cameră şi exteriorul casei şi două activităţi posibile ale utilizatorului (doarme/treaz) 21*21*21*21 combinaţii posibile pentru situaţia cu jaluzelele închise şi încă atâtea cu jaluzelele deschise. plecând de la elemente de context de ordin inferior (definită de utilizator. bazat pe reguli care se modifică astfel încât comportamentul sistemului să fie mai adaptat. 2. acestea permit o reducere la un ordin de complexitate O(e*q).3. Deşi nu este în scopul cercetării noastre.3 Mecanismul de descoperire a preferinţelor propus Ideea: Se propune înlocuirea parţii bazate pe reguli care nu se modifică cu un nou mecanism. α este o valoare proporţională cu numărul de valori ale elemente de context (echivalent în cazul scenariului nostru).activităţii curente. adică personalizată) . Pentru scenariul nostru am avea de completat. În total 24*22=64. Argumentele pentru a stoca preferinţele utilizatorului ca parametri ai reţelei neuronale în ontologie sunt următoarele: i) permite reutilizarea preferinţelor învăţate de către reţeaua neuronală: . care poate fi autorizat/nu. tipul de funcţie de activare la fiecare nivel) iii) dacă generalizăm această modalitate de reprezentare cu relaţii ponderate actualizate dinamic se poate utiliza pentru a face predicţii asupra: . ordinul de complexitate ar fi O(1*1*28+28*1*1)=O(64). pentru un utilizator. Aceasta este rezonabilă la un număr mic de elemente de context. 54 .

Componenta de Raţionare şi Decizie Knowledge Base Agent Brain Agent Componenta de Interacţiune Console Agent A C L Componenta pentru Informaţii de Context Information Map Agent PLATFORMA de AGENŢI JADE Componenta de Acţiune Mission Agent ACL Action Agent ACL Location Agent Identity Agent Interpreter Agent Affectivity Agent White page Services Yellow Page Services Authentication Services Robot Agent Actuator Agent A C L Componenta pentru Senzori Sensor Manager Agent Componenta fizică Devices Actuators Robots Temperature Agent Lightning Agent Humidity Agent Proximity Agent Sensors Figura 4.1.1 Implementarea 4. 55 .3. Permite înregistrarea de noi senzori şi actuatori.11.1 Arhitectura sistemului multiagent Cerinţele impuse unui sistem senzitiv la context sunt să permită identificarea persoanelor şi obiectelor. Arhitectura sistemului multiagent Componenta de interacţiune Permite utilizatorului monitorizarea şi controlul asupra dispozitivelor din Casa Inteligentă prin intermediul unei interfeţe grafice.2. ca în figura 4.3. monitorizarea valorilor senzorilor şi controlul stării actuatorilor de către utilizatori şi oferă suport pentru stabilirea de sarcini şi misiuni pentru roboţi.11. ierarhică.2.3. să aibă un comportamentul proactiv.4. Aceasta se compune din şapte părţi componente care colaborează între ele. interoperativitatea. auto-organizată. să fie mobil şi securizat.3. Pentru a oferi flexibilitate şi reconfigurabilitate sistemul Smart House este bazat pe o arhitectură de agenţi distribuită.

56 . senzitivitatea. Componenta de raţionare şi decizie Această componentă este formată din agentul bazei de cunoştinţe (Knowledge Base Agent) şi agentul de raţionare şi decizie (Brain Agent). Agentul de raţionare şi decizie transmite componentei de acţiuni şi misiuni care sunt sarcinile pe care este necesar să le îndeplinească. roboţi. s-a decis folosirea platformei multiagent JADE. actuatori. Proiectarea sistemului În proiectarea aplicaţiei Smart House.Componenta pentru informaţii de context Componenta pentru informaţii de context gestionează procesul de achiziţie a informaţiilor de la componenta pentru senzori şi permite celorlalte componente accesul la o aceeaşi bază de cunoştinţe. obiecte. Componenta fizică Această componentă cuprinde senzori. O integrare parţială la acest nivel fizic este asigurată de platforma de senzori şi actuatori Phidgets pe care am utilizat-o. dispozitive. deoarece au platforme de rulare şi formate de date diferite. iar pentru reguli şi accesul la informaţiile din ontologie pachetul Jena. valoarea actuală citită. Agenţii senzor preiau următoarele date: identificatorul senzorului. Componenta pentru senzori Această componentă asigură preluarea informaţiei brute de la senzorii fizici şi transmiterea ei la componenta pentru informaţii de context. cu ajutorul unui sistem expert accesat de către acest agent. Fiecare dintre acestea trebuie conectate la agenţii corespunzători. care are un mecanism de interogare numit SPARQL RDF Query Language. Componenta de acţiuni şi misiuni Componenta de acţiuni şi misiuni operează modificări asupra mediului prin actuatori şi/sau roboţi la modificarea valorilor diferitelor elemente de context. Pentru aceasta există un sistem de publicare a agenţilor disponibili în cadrul platformei şi un mecanism de comunicare şi un limbaj specific (Agent Communication Language). iar agentul Information Map adună informaţiile ce provin de la diferite surse din interiorul sau exteriorul casei pentru a fi disponibile componentei de interacţiune cu utilizatorul. Agentul Brain are două sarcini: cea de rulare a regulilor folosind Jena şi cea de a învăţa preferinţele utilizatorului. Agentul Interpreter agregă datele ce provin de la componenta Senzor. Platforma de agenţi JADE Aceasta asigură comunicarea dintre agenţii distribuiţi pe sisteme diferite de calcul. a descrierii ontologice folosind OWL (Web Ontology Language) a contextului şi preferinţelor. pe ansamblul platformei de agenţi. Primul agent asigură o aceeaşi bază de cunoştinţe actuală. eticheta de timp.

numită JADE LEAP. cu necesităţi de resurse de calcul diferite şi distribuite spaţial (chiar mobile). Evenimentele şi scopurile pot fi legate de metascopuri care vor determina executarea unor meta-planuri. Această bază de date este accesata de către aplicaţia Contextual Designer.1 Arhitectura aplicaţiei realizate Figura 4. Acest modul adaugă platformei WComp funcţii suplimentare ce privesc gestiunea contextului.3 Observarea contextului in cazul platformei WComp Aplicaţia descrisă în această secţiune constă dintr-un modul care se integrează cu platforma WComp [Cheung06]. Raţionarea Jadex meta-nivel Jadex este o variantă de platformă JADE pentru agenţi BDI (Belief Desire Intention). Au fost implementate planuri ce corespund diferitelor strategii ale agenţilor pentru a decide care este acţiunea optimă. În cazul aplicaţiei noastre. dezvoltată de partenerii noştri de la Universite de Nice. Un exemplu. Platforma de bază utilizată este WComp iar serviciile care se pot construi sunt compuse prin asamblarea de dispozitive UPnP. pentru oprirea citirii valorilor de la senzor este următorul: ((Sensor)getBeliefbase(). Jadex permite raţionarea meta-nivel prin folosirea de meta-scopuri şi meta-planuri. dar extinsă).3.Folosirea unui sistem multiagent este justificată de faptul că există părţi componente cu roluri specifice. ceea ce a uşurat integrarea cu alte părţi ale sistemului bazate de asemenea pe Java. există o variantă redusă a platformei JADE ca număr de funcţii disponibile. relativ autonome.getFact()). S-a ales platforma JADE deoarece este scrisă în Java.12 ilustrează componentele principale ale aplicaţiei dezvoltate. Mai mult. În sistemul Smart House s-a decis să se folosească raţionarea meta-nivel pentru a determina strategia agentului la rulare. 4.setDeviceStatus ("OFF"). 57 . se pune problema găsirii planului optim din mai multe planuri existente printr-un proces de raţionare. capabilă să comunice cu agenţii JADE. Sophia-Antipolis. Există o bază de date care menţine informaţii pentru toate aceste dispozitive. pentru partea de comunicare cu dispozitivele mobile. De fiecare dată când are loc un eveniment sau se activează un scop. 4. Pentru a realiza această aplicaţie s-a dezvoltat un nou modul numit ContextualDesigner. starea senzorilor. Acest modul are rolul de a menţine o listă cu elementele de context şi de a selecţiona numai acele elemente de context care sunt relevante pentru o anumită aplicaţie/serviciu. agenţii hărţii de informaţii de context interoghează agenţii care deţin informaţia despre contextul curent: senzorii înregistraţi. Limbajul de interogare Jadex (Jadex Query Language) Jadex permite interogarea cunoştinţelor agenţilor după o sintaxă similară OQL (Object Query Language) (care este la rândul ei similară SQL.getBelief("sensor"). valorile citite.

Aplicaţia poate să scrie informaţii legate de elementele de context direct în baza de date, la efectuarea iniţializărilor (pentru parametri statici), sau prin intermediul unor componente dedicate numite Observatori, care au rolul de a reactualiza informaţia de context pentru dispozitivele observate. Utilizatorul defineşte Observatorii de context, făcând asociaţii între observatori, ce dispozitiv este observat, şi ce element de context este monitorizat. Un set de reguli de filtrare pot fi definite de către utilizator. Aceste reguli permit îngustarea contextului aplicaţiei prin eliminarea dispozitivelor care nu sunt de interes pentru un anumit serviciu. Aplicaţia comunică cu un container WComp şi ii transmite acestuia comenzi de instanţiere a componentelor din acelaşi context, respectiv de eliminare a componentelor ce nu mai aparţin contextului. Aplicaţia citeşte din baza de date şi reactualizează lista dispozitivelor din acelaşi context cu noi de fiecare dată când în reţea apare o modificare de dispozitive (un dispozitiv UPnP apare sau dispare), sau în cazul în care un observator a observat o modificare a contextului unui anumit dispozitiv. În acest caz, containerul WComp va fi înştiinţat dacă să instanţieze sau nu dispozitivul. Observatorii pot fi reprezentaţi de diverse dispozitive UpnP, în principal este vorba despre senzori (temperatură, lumină, prezenţă etc.).

Figura 4.12. Arhitectura aplicaţiei Contextual Designer

4.3.2 Modelarea şi observarea contextului
Informaţia contextuală este compusă din elemente de context, grupate în structura arborescentă, fiecare frunză având o anumită informaţie contextuală ataşată. În figura 4.13 este descrisă interfaţa grafică care permite editarea descrierii contextuale. 58

Utilizatorul poate adaugă sau şterge frunze, sau poate să modifice structura modelului contextual. Aceasta este o reprezentare foarte simplă, dar este totodată şi eficientă, deoarece elementele importante şi legate se pot reprezenta împreună şi se pot grupa uşor în mod ierarhic pentru a reflecta un scenariu real. Modelul contextului, care poate fi construit de utilizator/administrator, se numeşte context_skeleton şi este un fişier xml care are conţinut echivalent cu arborele construit de utilizator. Acest context_skeleton poate fi încarcat de fiecare dată ce aplicaţia este modificată, poate fi construit de la zero, poate fi editat sau importat între utilizatori.

Figura 4.13. Interfaţa grafica a modulului Contextual Designer

Abordarea aleasă este una centralizată: există o bază de date care menţine informaţia despre context. S-a ales varianta utilizării unei baze de date cu stocare în format XML deoarece este puţin costisitoare şi oferă o alternativă simplă la un limbaj structurat mai sofisticat. Aplicaţia foloseşte baza de date ca un registru central pentru o mai bună reprezentare a contextului.

4.3.3 Înregistrarea dispozitivelor
Dispozitivele care vor fi folosite de către aplicaţie vor trebui să treacă printr-un proces de înregistrare. După acest proces de înregistrare, dispozitivul sau serviciul poate fi asociat unui context, iar acest context poate suferi schimbări de-a lungul timpului, schimbări ce vor fi observare de către componentele-observatori. Acest proces de înregistrare de dispozitive presupune adăugarea unei înregistrări în baza de date locală. Înregistrarea va conţine toate informaţiile necesare despre dispozitivul real. Dispozitivul

59

înregistrat poate fi apoi interogat pentru a obţine informaţii despre acesta sau poate fi folosit pentru a executa diverse servicii pe care le oferă. Când dispozitivele sunt adăugate în registrul central, acestea sunt de asemenea adăugate în fişierul xml, care are o structură asemănătoare fişierului context skeleton. Pentru a iniţializa un anumit dispozitiv, acesta trebuie să fie prezent în reţea. Dacă dispozitivul părăseşte reţeaua dar a fost deja înregistrat în baza de date, acesta va rămâne acolo pentru folosiri ulterioare. În cazul în care dispozitivul este prezent, acest lucru este vizibil. Putem construi servicii doar cu dispozitivele prezente şi înregistrate. În cazul în care un dispozitiv reintra în funcţiune, acesta va anunţa în reţea prezenta sa prin mijloace specifice protocolului UpnP. Acest lucru declanşează un eveniment ce va duce la modificarea statusului dispozitivului în baza noastră de date, fiind apoi văzut ca prezent. După aceasta, este posibilă construirea de aplicaţii şi servicii cu acest dispozitiv în interiorul platformei WComp.

4.3.4 Observarea şi filtrarea contextului
Observatorii. Să presupunem că lucrăm cu senzori statici care sunt iniţializaţi şi au toţi parametrii stabili şi nu se modifică în timp. În acest caz nu avem de-a face cu un context dinamic, deoarece nimic nu se schimbă pentru nici un dispozitiv. Dacă am vrea să lucrăm cu dispozitive mobile de exemplu, sau alte tipuri de dispozitive care îşi schimbă contextul foarte uşor, putem ajunge într-o situaţie în care nu putem urmări toate modificările mediului înconjurător (deoarece se schimbă prea repede) şi trebuie să avem un sistem care să actualizeze informaţia despre utilizatorii mobili, în baza de date. O soluţie este să definim serviciile UPnP din reţea care observă alte dispozitive şi, pentru o modificare a contextului acestora, baza de date să fie actualizată. Pentru aceasta, este necesar să menţinem un tabel în care asociem unui element de context un anumit dispozitiv de observare. Filtrarea. Filtrarea este procesul de definire a contextului de interes pe baza unui set de reguli. Acest context nu trebuie să aibă neapărat structura modelului de context, dar trebuie să conţină elemente similare. De exemplu, am putea considera ca fiind contextul de interes mulţimea dispozitivele din clădirea universităţii, sau numai pe cele dintr-o singura sală. Putem de asemenea construi contexte compuse, care privesc 2 sau 3 camere şi numai anumite tipuri de dispozitive. Adaptarea. În această aplicaţie, adaptarea este o instanţiere, în interiorul platformei Wcomp, a dispozitivelor care sunt în contextul de interes. În cazul în care avem deja dispozitive instanţiate, iar contextul lor este diferit după actualizare, se procedează la o eliminare a acestor dispozitive din platforma WComp. Adaptarea este rezultatul aplicării filtrării asupra dispozitivelor din baza de date, care este actualizată de către observatori pentru a reflecta situaţia curentă a contextului fiecărui dispozitiv monitorizat.

4.3.5 Testarea aplicaţiei
Scenariul 1. Să presupunem că avem o mulţime de senzori prezenţi în clădirea universităţii. Aceşti senzori au poziţii fixe şi sunt montate în diverse încăperi şi nu se
60

dispozitivul său va fi deinstanţiat din cadrul platformei WComp. el va obţine în WComp componente ce sunt instanţe ale dispozitivelor din sala 203. În cazul în care un student părăseşte camera. Să presupunem că ne aflăm în clădirea Universităţii. ar putea defini următoarele reguli: se utilizează toate dispozitivele mobile apartinând studenţilor din sala 203 şi cu videoproiectorul din sala 203.mişcă. Aceste dispozitive au parametri statici deja definiţi şi vom vrea să asociem nişte observatori care vor actualiza parametrii dinamici pentru fiecare dispozitiv. asociate lor. Studenţii sunt dotaţi cu carduri de identificare RFID care pot fi citite de un sistem de tipul Badge Reader UPnP. putem filtra contextul definind regulile care specifică această locaţie. Dispozitivele-senzori aderă la standardul UPnP şi sunt conectaţi la reţea. Scenariul 2. să presupunem că aceşti studenţi deţin laptopuri sau dispozitive mobile. Filtrarea va fi realizată în interiorul WComp. După definirea cererii prin reguli simple. 61 . pe laptopul său. având informaţie contextuală asociată caracteristicilor statice. compatibile cu standardul UPnP. Acest scenariu presupune că avem deja o bază de date cu dispozitive şi informaţia lor contextuală. iar pentru o componentă cu contextul schimbat şi care nu mai este de interes să obţinem o instanţiere. adică pentru fiecare dispozitiv care aparţine contextului nostru să avem o instanţiere a unei componente în WComp. Se presupune că am iniţializat dispozitivele pe care le vom folosi în şcoală. În cazul în care un profesor intră în sala 203 şi vrea să creeze o aplicaţie în WComp. Să presupunem că vrem să creăm o aplicaţie cu ajutorul WComp care va folosi doar senzorii din camera 101 de la etajul 1 în interiorul clădirii principale. având adrese IP şi sunt în stare de funcţionare. Cu ajutorul modulului Contextual Designer.

Aşa cum am arătat în introducere. În acelaşi timp. .O aplicaţie de adaptare a unei aplicaţii de comerţ electronic în funcţie de tipul de monedă utilizat. Problema P1 are o rezolvare propusă în teza [Crem05phd]. Spre deosebire de soluţiile tradiţionale „contextaware” unde contextul este stabilit a priori de către dezvoltatorul de servicii. folosind o reprezentare a contextului de tip listă simplă atributvaloare. dar care prezintă limitări în ceea ce priveşte expresivitatea descrierii componentelor/serviciilor. în funcţie de tipul de aplicaţie. servicii de observare) care pot furniza informaţii despre contextul indicat de către profilul P al serviciului S. a rezultat că această problema este foarte puţin abordată în literatura de specialitate. Un rol important îl joacă aici modul în care sunt descrise aceste servicii. concluziile studiului nostru sunt că la ora actuală modelul considerat a fi cel mai expresiv şi bogat este cel ontologic. într-un sistem cu adaptare autonomă. La aceste două probleme se adaugă o a treia problemă. . pentru a atinge acest deziderat este necesară soluţionarea a două probleme fundamentale: P1) Determinarea profilului P al unui serviciu S. unde contextul este descris printr-o listă de cuvinte utilizate de utilizator pentru a-şi exprima cererea în limbaj natural. şi care priveşte modul de reprezentare (modelare) a informaţiei despre serviciu şi context.O aplicaţie de compunere de servicii la cerere (descrisă detaliat în raportul tehnic referitor la scenarii/2008).O aplicaţie de adaptare prin filtrarea contextului relevant pentru un serviciu şi un utilizator. O soluţie de principiu este să considerăm descoperirea contextului ca fiind de fapt descoperirea de servicii ce oferă informaţii despre context. transversală faţă de cele două enunţate mai sus. Au fost dezvoltate următoarele aplicaţii ce pun în evidenţă problema observării contextului: . . dacă nu este neapărat necesară descrierea de relaţii complexe între elementele de context. bazată pe platforma WComp. În ceea ce priveşte a treia problema. P3. unde se utilizează o reprezentare ontologică complexă a contextului. 62 . meta-datele asociate acestor servicii. a modelării serviciilor şi contextului. Totuşi.5 Concluzii şi dezvoltări viitoare În acest raport se tratează problema modelării şi descoperirii contextului din punct de vedere al autonomiei adaptării. este necesar să existe un mecanism de descoperire a contextului. Problema P2 se identifică cu ceea ce în literatura de specialitate se numeşte „context discovery”. se pot utiliza cu succes şi liste simple sau ierarhizate de elemente/atribute de context. P2) Identificarea surselor de informaţie (senzori. bazată pe agenţi. O serie de soluţii existente sunt prezentate în capitolul 3. dacă se cunosc arhitectura internă a serviciului şi profilele componentelor sale interne Ci. Acestă problemă va fi reluată în următoarea fază a proiectului. în urma studiilor efectuate.O aplicaţie de adaptare a comportamentului unei case inteligente în funcţie de nevoile utilizatorului. unde se utilizează o reprezentare a contextului bazată pe o listă ierarhizată.

în funcţie de specificul aplicaţiei. Un astfel de model ar trebui actualizat folosind un protocol de descoperire a serviciilor ce furnizează informaţii despre context. de la o simpla listă de atribute până la un model ontologic.O concluzie care a rezultat în urma evaluării rezultatelor acestor aplicaţii este că modelul cel mai potrivit pentru reprezentarea contextului este un model care poate fi extins uşor. 63 . Rămâne ca dezvoltare viitoare problema agregării şi interpretării automatizate a informaţiilor despre serviciu şi context.

Universite de la Mediterranee. D. Anchor article of a special issue on context-aware computing in the Human-Computer Interaction (HCI) Journal. 16(2-4).. Abowd. 64 .. M. Cambridge.. [Bill93] Bill. directeur. Salber. S. Volume 16 (2-4). W. Norman. A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications.. N. Providing Architectural Support for Building Context-Aware Applications. 2006. US. 2001... Customizing Mobile Application. [Chen04] Chen. Providing Architectural Support for Building Context-Aware Applications. Proceedings of Fourth IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW'06). [Brdi06] Brdiczka. Theimer and Brent. D.. O. Costin MIRON. A. Santa Cruz. PhD Thesis.... PhD thesis. [Bill95] Bill.. Dey. co-tutela cu Universite de Savoie. Mai 1995. Deterministic and Probabilistic Implementation of Context. co-directeur. Intelligent Agents Meet the Semantic Web in Smart Spaces. [Bill94] Bill. A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. 2004. H.. S. N. Chakraborty. Christian Martel.. Joshi. Georgia Institute of Technology. rapporteur. Costin Miron. Dey. D. K.. Marseille..Bibliografie [Anind00] Anind. Context-aware computing applications.Cluj-Napoca. J. F. FRANCE. D. Universite de Nice. A. K. G. J. Mircea Florin Vaida. Noiembrie. D. A Context-Aware System Architecture for Mobile Distributed Computing. December 2000. Perich. Proceedings Workshop on Mobile Computing Systems and Applications. Vaufreydaz. [Crem05pdh] Teza „Adaptation Dynamique de Services”. CA. College of Computing. Universite de Savoie. B. conducator prof.. PhD Thesis. N. Special Issue on Context-Aware Computing Human-Computer Interaction (HCI) Journal. K... A. K. Kagal. Dr. Columbia University. Daniel. Georgia Institute of Technology. Maisonnasse. S. [Dey01] A. Crowley. L. Universite Babes-Bolyai. Michel Riveill. Proceedings of the USENIX Symposium on Mobile and Locationindependent Computing. August 1993. Universite Technique de Cluj-Napoca). RoyWant. L. Universite Technique de Cluj-Napoca. 2001. 2000. rapporteur. [Anind01] Anind. Decembrie 1994. MA. P. Marvin. Gregory. directeur. S. Finin. IEEE Internet Computing 8(6). (Traian Muntean. T.. D. ing. rapporteur. [Dey00] A.. Reignier.. Florian-Mircea Boian.

DC. Gu. B.. W. B. M. Riener... [Fabi04] Fabian.[Ejigu07] Ejigu.. Pung. and Olli Simula. [Glass03] R. Gu. [Fitz02] Fitzpatrick. A middleware for building context-aware mobile services.. dos Santos Rocha... “Devising a Context Selection-Based Reasoning Engine for Context-Aware Ubiquitous Computing 65 . Finland. P.. K. [Flan05] John Flanagan. G. USA. H. A.. International and Interdisciplinary Conference on Adaptive Knowledge Representation and Reasoning. Journal of network and computer applications. 2004.. Schmitzberger. Decembrie 2004... Scuturici. Ville Könönen. Proceedings of AKRR'05. Matti Pöllä. A. K. [Gu04] T. “Context awareness in a mobile device: Ontologies versus unsupervised/supervised learning”. Distributed Systems Institute .Proceedings of the Fifth IEEE international Conference on Pervasive Computing and Communications Workshops. A. [Fers06] Ferscha. First International Workshop on Middleware for Pervasive and Ad Hoc Computing (Middleware 2003). I. Franz. Context for Simplicity: A Basis for Context-aware Systems Based on the 3GPP Generic User Profile. S. Sofia. Glassey. J. Brunie. in Timo Honkela. K. March 19 . 2005. [Gu05] T. Biegel. S.. 2004. Technical Report. Leibniz University Hannover. Wang. Washington. H. Towards a Sentient Object Model. editors. D. Zhang..Knowledge Based Systems. D.. Patrick.. K. IEEE Computer Society. Richmond. Clarke. P. Jan. M. PERCOMW. N. Cho. “An Ontology-Based Approach to Context Modeling and Reasoning in Pervasive Computing”. Context-Aware Profiles. F. M. Eleftherios. ICPS '04: Proceedings of the The IEEE/ACS International Conference on Pervasive Services. Iulie 2006. Context-Aware Computing: A Guide for the Pervasive Computing Community. A Service-oriented middleware for building context-aware services. S. C. Lee. A. Towards a Middleware for Generalised Context Management. A. George. K. Terzis. June 2005.23. USA.. Q. L. M. R. 14-19. 2003. [Guan07] Guan. Seattle. [Ghita04] Ghita. Italia. Workshop on Engineering Context-Aware Object Oriented Systems and Environments (OOPSLA/ECOOSE'02). Hechinger. Lee. Jacques. pages 167-170. DC.-K. G. S. [Enrico04] Enrico. Cahill. Zeidler. R.. 28(1). Ferguson. Proceedings of International Conference on Computational Intelligence.. Stevenson. Nixon. V. 2004. M. Istanbul. 2002.. Proceedings of the international Conference on Autonomic and Autonomous Systems. D. A. Using Semantic Web Technologies for context-aware Information Providing to Mobile Devices. Washington.. P.. Giovanni. Y. Zhang. 2007. Gavrilov. Pung. Proceedings of IEEE Vehicular Technology Conference.. D. Yuan. H. Washington. Turkey. Q. M. Espoo..

. Intanagonwiwat. http://www. Kamrul Hasan. [Held02] Held.. Directed Diffusion forWireless Sensor Networking. No. Softwarepractice & Experience. Proceedings of the 4th International Conference on Mobile Data Management. A.3761. IEEE/ACM Transactions on Networking. Rakotonirainy. WA. R. Young-Koo Lee. A. J. Statele Unite. 2000. Henricksen. D.1.. Heidemann. February 2006. USA. Balakrishnan. A. Heinzelman.. Vol 11. “OWL-Based User Preference and Behavior Routine Ontology for Ubiquitous System”. No 4611. K. Modeling of Context Information for Pervasive Computing Applications. LNAI 4114 0355). International Conference Mobile Computing and Networking MOBICOM. Adaptive protocols for information dissemination in wireless sensor networks. Generating Context Management Infrastructure from High-level Context Models. Seattle.. vol 36. 2003. pages 849-857. Proceedings of the 6th Annual ACM/IEEE International Conference on Mobile Computing and Networking. pag.. ISBN 3-540-29738-3. D. Melbourne. “Using context and preferences to implement self-adapting pervasive computing applications”. LECTURE NOTES IN COMPUTER SCIENCE. Journal of Pervasive and Mobile Computing. 1999. Ed. Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks. Developing context-aware pervasive computing applications: Models and approach. Intanagonwiwat. Experiences in using CC/PP in context-aware systems. H. J. Proceedings of the 6th World Multiconference on Systemics. Robinson.. Rakotonirainy. China. 2(1). [Kamr06] Md. Florida. Kim Anh. Lecture Notes in Computer Science. Indulska. issue 11-12. LNCS 2574.org/2006/. John Wiley & Sons Ltd. Lenin Mehedy. iulie 2002. Cybernetics and Informatics (SCI2002). Proceedings of the 4th International Conference on Mobile Data Management. [Henri03] Henricksen. Kulit. [Inta00] C. [Henri06] Henricksen. vol. Kunming Yunnan Province. Estrin. K. Silva.Middleware”. Indulska. SPRINGER-VERLAG. 1307-1330. ISSN 0302-9743 [Heinz99] W. A. Australia. Estrin. Sungyoung Lee. J. Young-Koo Lee and Sungyoung Lee. 1615-1622. [Indul03] Indulska.. Orlando.. Govindan. K. “Conflict Resolution and Preference Learning in Ubiquitous Environment”. 2006 [Kim05] Kim Anh Pham Ngoc. Melbourne. 2007. 66 . August 16-19... R.. January 2003. R. J. J. Springer. Indulska.. Rakotonirainy. J. Buchholz. [Henri06’] Henricksen. Germany ISBN 978-3-540-73548-9. pag. 2005. [Inta03] C. K. S. Schill. Februarie 2003. 2006.ic-ic. In the 2006 International Conference on Intelligent Computing (ICIC 2006. Januarie.. A.. F. Govindan. R.

California.. University of Kent at Canterbury. Federica Cena. Computing Laboratory. [Luca06] Luca Buriano. 2007. France. Yasumoto. 0.. vol.[Kim05’] Kim Anh Pham Ngoc. [perv04] http://pervasive. Ito. Francesca Carmagnola.cs. 2005. No. Jang.. T. 1. Fall Symposium on Context in Knowledge Representation and Natural Language. no. Context Discovery Using Attenuated Bloom filters in Ad-hoc Networks.W. [Nick] Nick. Faculty of Graduate School of Kyung Hee University. K. Italia. Department of Computer Engineering. 345-351. Chambery. Korea. pp. G. W." Distributed Computing Systems Workshops. Shin. Formalizing Context (Expanded Notes). S. Mobile Data Management. pp. "The Role of Ontologies in Context-Aware Recommender Systems"... Vol.kent. J.. M.0: A Unified Context-aware Application Model for Ubiquitous Computing Environments. 0. Journal of Internet Engineering. Jeju. 2006. C. Cristina Gena. November 2005. no. 1. American Association for Artificial Intelligence. R. Characterizing Situations. S. N. Marco Marchetti. "Framework and rule-based language for facilitating context-aware computing using information appliances. 7th International Conference on Mobile Data Management (MDM'06).uk/projects/mobicomp/fnc/ConteXtML... Buvac. S.semanticweb. [Loke04] Loke... Web Intelligence Conference. [Liu07] F.org/soupa-2004-06. ConteXtML: Exchanging Contextual Information between a Mobile Client and the FieldNote Server.. [McCar97] McCarthy. 25th IEEE International Conference on . Pisa. vol. Ilaria Torre.ac. Heijenk.. 2005. master thesis. IEEE International Conference on. http://www. [Loke06] Loke. Higashino. 6-10 June 2005. J. Liu. Logic Programming for Context-Aware Pervasive Computing: Language Support. 1997. Proceedings of the First Korea/Japan Joint Workshop on Ubiquitous Computing & Networking Systems (ubiCNS2005). [McCar93] McCarthy. Proceedings of the Thirteenth international joint conference on artificial intelligence. 2004.. Menlo Park. Y. 80. and Integration with the Web. K. On Representing Situations for Context-Aware Pervasive Computing: Six Ways to Tell if You are in a Meeting. Korea. Woo.. Shibata. Proceedings of 3rd Workshop on Context Modeling and Reasoning. S..html 67 .W. [Oh05] Oh. ubi-UCAM 2. „User Preference Learning in Context-aware Computing”. Iunie. Working Papers of the {AAAI}. 1993. Notes on formalizing context. Martie 2006.html [Nish05] Nishigaki...

Proceedings of the Third IEEE Workshop on Mobile Computing Systems and Applications (WMCSA'00). M.. Santa Cruz. 2004. [Rob07] Robinson. A. and Hung Keng Pung. Indulska. integration. Deepak Chandraseka. B. R. S. B.Volume 00 (July 11 . PerCom'07 Workshop Proceedings. 2000. Proceedings of the the Fourth IEEE Workshop on Software Technologies For Future Embedded and Ubiquitous Systems. Q. S.13.. M. Bill.[Reto07] Reto Krummenacher. IEEE Computer Society. Lightweight and Energy-Efficient Context Discovery Protocol for Ubiquitous Computing Environments. USA. John.. [Schm01] Schmidt.. [Voel94] Voelker. [Tim00] Tim. and the Second international Workshop on Collaborative Computing.. J. L . Marcos. August 2001.. Bershad. Yau. Venky. „Ontology-Based Context Modeling”. F. An Adaptive. K. Orlando.. Gene.. China. Reasoning and Management. ContextUML: A UML-Based Modeling Language for Model-Driven Development of Context-Aware Web Services Development. California. June 2007. Tao Gu. [Thom04] Thomas. XCML: A runtime representation for the Context Modelling Language.. K. [Xiao04] Xiaohang Wang. Dazhi Huang. G.. V. 2005). S. Proceedings of the IEEE Workshop on Mobile Computing Systems and Applications. S. Jeff. Decembrie 1994.. [Yau06] Yau. D. In Proceedings of Workshop on Context Modeling and Reasoning (CoMoRea '04). J. March 2004. ICMB... G... DC. Nottingham/England. A Context Modeling Survey. 3rd Workshop on Context Awareness for Proactive Systems. Philippe. [Sheng05] Sheng. Laerhoven. Debbie... IEEE Personal Communications 8(4). B. B.P. Places. C... and Assurance (Seus- 68 . Mobisaic: An Information System for a Mobile Wireless Computing Environment. IEEE Computer Society.. K. in conjunction with the 2nd IEEE International Conference on Pervasive Computing and Communications (PerCom '04). 206-212. How to Build Smart Appliances?. S. 10th IEEE International Workshop on Future Trends of Distributed Computing Systems (FTDCS'04). Things: Web Presence for the Real World. People. Proceedings of the international Conference on Mobile Business (Icmb'05) . Workshop on Advanced Context Modelling. Howard.. and Benatallah. Septembrie 2004. Washington. Ontology Based Context Modeling and Reasoning using OWL. [Steph04] Stephen S. Florida USA. Thomas Strang. M.. K. Martie 2007.. Henricksen. Proceedings of 4th International Workshop on Context Modelling and Reasoning (CoMoRea). Liu. Claudia. Z. Gita. N.. John. Daqing Zhang. “Hierarchical Situation Modeling and Reasoning for Pervasive Computing”.

Crete. “Context-based User Profile Management for Personalized Services”. Lavirotte (S. Tigli (J. [Youn05] Youngjung Suh. pages 119–125.Wccia'06). ubiComp. 2006. workshop ubiPCMM.). DC. 5-10. Woontack Woo. IEEE Computer Society.-Y.). Workshop on Rapid Syst. April 27 . 2006. 2005. SEUS-WCCIA. Dongoh Kang.28.). Washington. and Riveill (M. 69 . [Cheung06] Cheung-Foo-Wo (D. Prototyping. 00. Wcomp: a multi-design approach for prototyping applications using heterogeneous resources. In 17th IEEE Intern. vol.).