pobierz plik referatu - Politechnika ÅlÄska

Rozdział monografii: 'Bazy Danych: Nowe Technologie', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2007 

www.bdas.pl 

Rozdział 7 

Mechanizmy deklaratywne w systemie P2P 

semantycznej integracji danych 

Streszczenie. Przedstawiono deklaratywną specyfikację systemu P2P, w którym 

agenci dysponują lokalnymi bazami danych zorganizowanymi według 

różnych schematów. Udostępnianie przez agentów schematów oraz danych 

innym agentom odbywa się z użyciem mechanizmów prologowych. W wymianie 

danych i obsłudze zapytań ważną rolę odgrywają odwzorowania pomiędzy 

schematami, które faktycznie wyznaczają semantyczne powiązania 

pomiędzy danymi przechowywanymi w lokalnych bazach poszczególnych 

agentów. Podano semantykę operacyjną operacji prologowych realizowanych 

w środowisku P2P z uwzględnieniem stanów mentalnych agentów. Wybrane 

działania agentów wyspecyfikowano w Prologu. 

1 Wstęp 

W globalnej sieciowej strukturze informacyjnej chcemy, i możemy, sięgać po informacje 

z wielu źródeł. Bogactwo i różnorodność udostępnianych danych, to z jednej strony podstawowy 

walor współczesnych narzędzi informatycznych, a z drugiej – poważne źródło problemów 

z wyszukiwaniem interesujących nas informacji, a zatem także z pozytywną oceną 

proponowanych przez informatyków rozwiązań. Dlatego integracja zasobów informacyjnych 

i efektywne ich udostępnianie to dwa ważne problemy, które muszą być rozwiązane 

w nowoczesnych środowiskach obliczeniowych. 

W systemach informatycznych, nawet te same informacje mogą być wyrażane w różny 

sposób. Reprezentacja danych ma związek z przyjętą metodą modelowania i rozwiązywania 

problemu, zbiorem pojęć wykorzystywanych w opisie problemu, zastosowanym językiem, 

czy sposobem organizowania danych. Wybrana postać danych, przygotowana do określonego 

trybu ich przetwarzania, choć użyteczna dla konkretnego użytkownika w rozwiązywaniu 

danego problemu, może się okazać znacznie mniej wygodna dla innych użytkowników, 

w innych zastosowaniach. Jeśli zatem chcemy efektywnie wykorzystywać dostępne 

w sieci dane, to musimy sięgać do istoty danych, ich znaczenia. Takie założenie leży także 

Jerzy Bartoszek, Grażyna Brzykcy 

Politechnika Poznańska, Instytut Automatyki i Inżynierii Informatycznej, 

pl. Skłodowskiej-Curie 5, 60-965 Poznań, Polska 

email:{jerzy.bartoszek, grazyna.brzykcy}@put.poznan.pl 

(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2007


J. Bartoszek, G. Brzykcy 

u podstaw Sieci Semantycznej WWW (ang. Semantic Web [3]), czyli wizji rozproszonych 

zasobów danych (źródeł wiedzy), które mogą być automatycznie przetwarzane z uwzględnieniem 

ich semantyki, w sposób bardziej efektywny („inteligentny”) niż dotychczas. 

W metodologii tworzenia systemów informatycznych przyjmuje się dzisiaj stanowisko, zorientowane 

na znaczenie danych (ang. content-oriented processing). 

Większość działań zmierzających do ujawnienia znaczenia danych polega na wprowadzaniu 

i wykorzystywaniu różnych aspektów metawiedzy o tych danych. Opracowano odpowiednie 

standardy języków do opisywania tej wiedzy, takie jak np. URI (ang. Uniform 

Resource Identifier), RDF (ang. Resource Description Framework) i RDFS (ang. RDF 

Schema), służące do identyfikowania i opisywania zasobów informacyjnych, czy OWL 

(ang. Web Ontology Language) – do definiowania pojęć i relacji pomiędzy pojęciami, czyli 

ontologii, którymi można posługiwać się przy tworzeniu i przetwarzaniu danych. Coraz powszechniej 

wykorzystuje się do reprezentowania danych język XML (ang. Extensible 

Markup Language), w którym łatwo można wyrażać nie tylko strukturę danych, ale również 

inne rodzaje metawiedzy (np. przez dobór odpowiednich nazw znaczników można 

ułatwiać, ale także utrudniać, rozumienie danych [17]). Warto w tym miejscu zwrócić uwagę 

na wzrost zainteresowania informatyków podstawami formalnymi, odpowiednimi do 

rozważań o semantyce danych, np. teorią sytuacji (ang. situation theory [1]), uważaną za 

jedno z najlepszych narzędzi do definiowania semantyki, i teorią przepływu informacji 

(ang. channel theory [2]), szczególnie przydatną w analizie systemów rozproszonych. 

Duże znaczenie praktyczne w udostępnianiu informacji ma wykorzystywanie istniejących 

zasobów baz danych. W tym obszarze informatyki wypracowano już wiele technik 

przechowywania i sprawnego wyszukiwania informacji. Formułowane przez użytkownika 

zapytanie do zbioru danych jest wyrażane w odpowiednim języku zapytań, przy czym uwzględnia 

się wiedzę o sposobie zorganizowania danych w bazie, czyli schemat danych (np. 

relacyjnych, dokumentów XML). Ten rodzaj metawiedzy, chociaż nie wyraża explicite modelu 

semantycznego danych, może być z powodzeniem użyty do określenia zbioru pojęć 

i zależności pomiędzy tymi pojęciami, definiujących (częściowo) znaczenie danych, a także 

do ujawnienia struktury przechowywanych danych. 

Dzisiaj, ważnym zadaniem jest integracja danych pochodzących z różnych baz. Odbywa 

się ona z wykorzystaniem schematów obowiązujących w poszczególnych repozytoriach. 

Można sobie wyobrazić rozwiązanie, w którym ustala się wcześniej globalny schemat 

i wszystkie zbiory danych tworzone są zgodnie z tym schematem. Podejście takie proponowane 

jest zwykle w obszarze określonej dziedziny i przyjmuje postać rozmaitych standardów 

(np. schematów dokumentów XML wykorzystywanych w hotelarstwie [12]). Nie 

można jednak tej metody przygotowania zbiorów danych do integracji zastosować wobec 

już istniejących repozytoriów, a także trudno sobie wyobrazić istnienie uniwersalnego schematu 

dla różnych dziedzin. Praktycznie bardziej uzasadnione jest budowanie schematów, 

będących specjalizacją pewnej współdzielonej ontologii. Dopasowywanie tak zdefiniowanych 

schematów odbywa się wówczas za pośrednictwem tejże ontologii. Jednak w otwartych 

systemach informatycznych, w których zbiór elementów składowych podlega dynamicznym 

zmianom, w szczególności pojawiają się nowe zbiory danych, nie da się uniknąć 

sytuacji, w których w repozytoriach danych mamy różne, lokalnie i autonomicznie zdefiniowane 

schematy. 

Integrowanie danych z takich zbiorów winno być poprzedzone budowaniem odwzorowań 

pomiędzy ujawnionymi schematami lokalnymi (jeśli schematy można do siebie dopasować) 

i wywodzeniem z nich globalnych, wspólnych ontologii. Trwają intensywne prace 

nad metodami odkrywania semantycznych odwzorowań pomiędzy schematami i ontologiami 

(np. [4], [6], [9], [13], [14], [15]). Włączamy się w ten nurt badań proponując środowisko 

agentowe typu P2P (ang. Peer-to-Peer) do semantycznej integracji danych XML [5]. 

www.bdas.pl 

82 



Mechanizmy deklaratywne w systemie P2P semantycznej integracji danych 

www.bdas.pl 

W dalszej części rozdziału zostanie przedstawiona architektura prezentowanego systemu 

(podrozdział 4), na który składają się agenci – dysponenci zbiorów danych oraz broker 

realizujący funkcje administracyjne. Każdy agent pierwszego rodzaju ma dane, zorganizowane 

według lokalnego schematu, który na żądanie udostępnia innym agentom. Ważne 

miejsce w systemie mają odwzorowania pomiędzy schematami, faktycznie wyznaczające 

semantyczne powiązania pomiędzy danymi. Zakłada się, że odwzorowania mogą 

powstawać w sposób półautomatyczny, przy współudziale użytkowników systemu (ludzi). 

Opis systemu został poprzedzony uzasadnieniem stosowania podejścia deklaratywnego, 

w tym programowania w logice, we współczesnych systemach rozproszonych 

(podrozdział 2). Podano semantykę operacyjną operacji prologowych realizowanych 

w środowisku P2P z uwzględnieniem stanów mentalnych agentów (podrozdział 3). 

Działania różnych rodzajów agentów przedstawiono w Prologu (podrozdział 5), przez co 

wykonywalna specyfikacja prologowa może być również traktowana jako specyfikacja 

formalna prezentowanego systemu. Przewidywane kierunki rozwoju systemu nakreślono 

w podsumowaniu. 

2 Dlaczego podejście deklaratywne (programowanie w Prologu)? 

Użyty w pytaniu termin „podejście deklaratywne” obejmuje wiele różnych modeli obliczeniowych, 

w tym np. programowanie funkcyjne (za pomocą funkcji rekurencyjnych), czy 

programowanie ograniczeń (za pomocą ograniczeń nakładanych na wartości zmiennych). 

Nasza uwaga skupia się na programowaniu w logice, a dokładniej na programowaniu 

w Prologu. 

Zanim przedstawione zostaną przesłanki wyboru tego właśnie sposobu definiowania 

problemów, warto zastanowić się nad tym, na czym ma polegać nowe podejście do obliczeń 

proponowane w inżynierii oprogramowania, czyli przywołane wcześniej przetwarzanie 

zorientowane na znaczenie (semantykę) danych. Najprościej rzecz ujmując, chodzi o to, 

by systemy informatyczne działały w coraz bardziej inteligentny sposób. Sprowadzając ten 

ogólny postulat do konkretu, można sformułować następujące żądanie szczegółowe: system 

ma nie tylko umieć znaleźć dane umieszczone w którymś z zasobów (wyszukać je), ale także 

na podstawie tych danych wywieść nowe dane (takie, które jeszcze w systemie nie występowały). 

Ważną cechą systemów ma być zatem zdolność do prowadzenia wnioskowań. 

To oczekiwanie jawnie wyrażono w strukturze sieci semantycznej WWW, w której 

w warstwach najwyższych, ulokowanych ponad poziomem ontologii, wiedza ma być reprezentowana 

za pomocą reguł, przetwarzanych przez odpowiednie maszyny wnioskujące. 

Z takim właśnie sposobem wyrażania i przetwarzania wiedzy mamy do czynienia w Prologu! 

Programy prologowe to skończone zbiory klauzul (reguł), a obliczenie, podejmowane 

zawsze w odniesieniu do jakiegoś zapytania (zadania), polega na próbie skonstruowania 

dowodu. Jednak nie tyle formalne podobieństwo Prologu do rekomendowanych w sieci semantycznej 

języków programowania, co istnienie sprawdzonych, dojrzałych prologowych 

środowisk wykonawczych może przesądzać o wyborze właśnie tego języka. Na poparcie tej 

tezy warto przywołać doświadczenia twórców systemu Semantic Web Spaces [16], którzy 

praktycznie wykorzystywali standardy i technologie sieci semantycznej. Stwierdzili oni 

nieefektywność i niestabilność wielu rozwiązań (np. obsługi zapytań do zagregowanych danych 

RDF) i uznali Prolog, z jego systemem wykonawczym i rozszerzeniami do działań 

w sieci, za wygodne narzędzie do definiowania nowoczesnych systemów informatycznych 

[8]. 

83 




www.bdas.pl 

Prolog ma także inne cechy, które predestynują go do zastosowań w zadaniach reprezentowania 

i przekształcania wiedzy, formułowania zapytań i wnioskowania. Po pierwsze, 

w Prologu mamy wyższy poziom abstrakcji pojęć niż w językach imperatywnych. Zwarty 

kod prologowy jest przejrzysty i czytelny. Warto tu przypomnieć, że programy prologowe 

mają formalną semantykę. Po drugie, dane i programy są w tym języku reprezentowane 

w analogiczny sposób, co daje szerokie możliwości definiowania metaprogramów. Nie ma, 

więc kłopotów z modyfikowaniem wiedzy, w oparciu o którą prowadzone są obliczenia 

(wnioskowania). Po trzecie, w systemach Prologu mamy dostępne wprost mechanizmy dopasowywania 

do wzorca oraz unifikacji, bardzo przydatne do wyszukiwania danych. Nie 

musimy się także przejmować sposobem przeglądania przestrzeni możliwych rozwiązań 

danego problemu, gdyż system samoczynnie wykonuje nawroty w obliczeniach. 

Znane są także różne użyteczne rozszerzenia Prologu, w tym w szczególności do zastosowań 

w przetwarzaniu rozproszonym i sieci WWW (np. LogicPeer i LogicWeb [10]). Ten 

sam autor proponuje także w [11] specjalny typ programów prologowych do reprezentowania 

sytuacji i uwzględniania ich w działaniach agentów silnie uzależnionych od zmian otoczenia 

(ang. context-aware pervasive computing). 

W systemie semantycznej integracji danych, zwanym systemem SIX-P2P [5], proponujemy 

użycie środowiska prologowego, w którym: 

− mamy zestaw standardowych, predefiniowanych typów, 

− można definiować nowe typy z uwzględnieniem wielodziedziczenia, 

− definicje nowych typów mogą zawierać ograniczenia w formie klauzul prologowych, 

− hierarchia typów jest uwzględniona w mechanizmach unifikacji i wnioskowania, 

− termy reprezentują tzw. struktury cech [7], w których poszczególne argumenty mają 

nazwy oraz typy, 

− argumenty termów można wymieniać w dowolnej kolejności, gdyż ich role są opisane 

przez nazwy, 

− nie trzeba podawać wszystkich argumentów termu. Dla termów danego typu jest określony 

zestaw argumentów obowiązkowych, a pozostałe argumenty mogą, ale nie 

muszą, wystąpić. Za pomocą termów z niepełną listą argumentów można zatem wyrażać 

informacje niepełne. 

3 Reguły opisujące semantykę działań agentów 

Jak wspomniano wcześniej, w prezentowanym systemie występują agenci realizujący pewne 

zadania prologowe. Wiedzę agenta, wyrażaną za pomocą zbioru prologowych procedur 

oraz faktów, można traktować jako jego stan mentalny, w którym obsługuje on zadania pochodzące 

od innych agentów. Z innego (sytuacyjnego) punktu widzenia stan ten można 

traktować również jako sytuację, w której realizowane są zadania. Stan mentalny agenta p 

oznaczamy przez p. Skierowanie od agenta p do agenta q zadania G (traktowanego jak zapytanie 

prologowe) wyrażane jest jako wywołanie q*G procedury G agenta q. Procedura G 

może być realizowana przez agenta q i/lub, po przekształceniu zadania początkowego G na 

podzadania G 1 , ..., G n , przez innych agentów. 

Stwierdzenie „wykonanie zadania G, skierowanego przez agenta p do agenta q, zostało 

zakończone sukcesem (w sensie prologowym), a otrzymane dane, czyli podstawienie θ dotyczące 

zmiennych z zdania G, zostały przekazane przez q do p” zapisujemy jako relację p 

|- θ q*G (por. [10]). 

84 




www.bdas.pl 

Niektóre zadania mogą być realizowane lokalnie (przez jednego agenta). Jeśli więc agent 

p, będący w stanie p, zakończył realizację zadania G z sukcesem i powstało podstawienie θ, 

to fakt ten zapisujemy jako relację p/p |- θ G. 

Dane zadanie prologowe może być realizowane równolegle przez wiele agentów. Zgodnie 

z konwencją przyjętą w [10], jeśli zadanie G ma być wykonywane przez agentów 

q 1 

,q 2 

,...,q n 

, i wszystkie wykonania muszą zakończyć się sukcesem, to zapisujemy to jako 

q 1 ,q 2 ,...,q n 

[] G. Jeżeli sukcesem musi zakończyć się wykonywanie zadania G u co najmniej 

jednego agenta, to piszemy q 1 ,q 2 ,...,q n 

G. Oczywiście, różni agenci mogą przekazać 

zwrotnie różne podstawienia. Jeżeli nie można połączyć ich w jedno podstawienie (ze 

względu na różne wartości przypisywane tym samym zmiennym), to w pierwszym wypadku 

(czyli dla operatora []) przyjmujemy, że wykonanie zadania G zakończyło się porażką. 

W wypadku drugim (czyli dla operatora ), możliwe jest zastosowanie reguł dodatkowych, 

decydujących o sposobie złożenia podstawień otrzymanych od różnych agentów. 

Poniżej przedstawiamy reguły opisujące tzw. semantykę operacyjną działań agentów. 

Ogólną postać reguł zaczerpnięto z [10]. Uzupełniono je jednak o elementy związane ze 

stanami mentalnymi agentów. Każda reguła ma postać 

przesłanki 

konkluzja 

Jeśli prawdziwe są wszystkie formuły z przesłanek, to prawdziwa jest także konkluzja. 

p / p |– true 

∈ 

(1) 

Reguła 2 wyraża fakt, że agent p, będący w stanie p, realizuje zawsze z sukcesem zadanie 

puste (reprezentowane przez stałą logiczną true). 

( ) 

θ = mgu R( v , K, v ), R( t , K, t ) ∧R( v , K, v ) ∈ p 

1 n 1 n 1 n 

p/ p |– R( t , K, t ) 

θ 

1 

n 

(3) 

Reguła 4 opisuje realizację zadania R(t 1 ,...t n ) w stanie p, w którym agent p zna fakt 

R(v 1 ,...v n ), a wartości v 1 , ..., v n mogą być ukonkretnione z termami t 1 ,..., t n . Wynikiem tego 

ukonkretnienia jest podstawienie θ. Nie wpływa ono na zmianę stanu mentalnego agenta p. 

( ) 

γ = mgu A, H ∧H : −B ∈ p ∧ p / p |– Bγ 

p/ p |– 

γδ 

A 

δ 

(5) 

Powyżej opisano realizację zadania A z wykorzystaniem reguły prologowej H :- B, o nagłówku 

H i ciele B. Podstawienie γ jest najogólniejszym unifikatorem zadania A i nagłówka 

H. Jeżeli wykonywanie ciała reguły (po uwzględnieniu podstawienia γ) zakończy się 

sukcesem i występujące w regule 3 zmienne zostaną ukonkretnione zgodnie z podstawieniem 

δ, to realizacja zadania A również zakończy się sukcesem, a złożenie podstawień γ i δ 

będzie podstawieniem wynikowym. 

85 




q/ q |– 

θ 

G 

p / p |– q∗G 

θ 

(6) 

www.bdas.pl 

Reguła 7 dotyczy realizacji zadania G przekazanego przez agenta p do agenta q. Zadanie G 

jest wykonywane przez agenta q w stanie q. 

p / p|– G ∧ p/ p |– Gθ 

θ 

1 γ 2 

p/ p |– G , G 

θγ 

1 2 

(8) 

Wykonywanie zadania złożonego z podzadań G 1 i G 2 odbywa się dwuetapowo. Jeżeli 

w wyniku wykonania zadania G 1 powstanie podstawienie θ, to ma ono wpływ na wykonywanie 

zadania G 2 . 

q/ q |– G∧... ∧q / q |– G 

1 1 θ1 

p/ p |– q , K, q [] G 

θ1... θn 

1 

n n θn 

n 

(9) 

q/ q |– G∨... ∨q / q |– G 

1 1 θ1 

p / p |– q , K, 

q G 

θ1... θn 

1 

n n θn 

n 

(10) 

Reguły 11 i 12 dotyczą zadań realizowanych równocześnie przez wielu agentów. W regule 

13 wykonanie zadania G musi zakończyć się sukcesem u każdego z agentów q 1 ,q 2 ,...,q n . 

Dlatego też przesłanka ma postać koniunkcji. W regule 14 przesłanka ma postać 

alternatywy, gdyż wystarczy, aby tylko jeden agent zakończył pomyślnie wykonywanie 

zadania G. Podstawienia θ 1 , θ 2 , ..., θ n otrzymane od agentów, którzy nie wykonali 

pomyślnie zadania G, są podstawieniami pustymi. Wykonywanie tego samego zadania G 

przez wielu agentów może być użyteczne, gdy pewien agent koordynujący działania innych 

agentów musi zlecić im wykonanie np. zadania o charakterze administracyjnym lub 

porządkowym. 

4 Struktura systemu 

W systemie SIX-P2P [5] poszczególne zasoby danych są reprezentowane przez agentów. 

Każdy agent jest autonomiczny w tym sensie, że ma swoją własną ontologię i decyduje 

o sposobie zorganizowania swoich danych. Każdy zatem zasób w systemie ma lokalny 

schemat danych. Agenci wymieniają dane między sobą, ale nie dążą do wypracowania jednego 

wspólnego schematu (ontologii). System ma być zdecentralizowany, z rozproszeniem 

danych, sterowania i lokalną wymianą informacji. Spełnienie powyższych postulatów ma 

służyć przede wszystkim zapewnieniu większej elastyczności systemu i większej odporności 

na błędy. System jest też otwarty, co oznacza, że mogą do niego przystępować nowi 

agenci, a „starzy” mogą system w pewnym momencie opuścić (np. „wypaść” z systemu na 

skutek awarii). 

Pojedynczy agent „widzi” w systemie pewien podzbiór zbioru wszystkich agentów. Są 

to jego partnerzy (sąsiedzi, przyjaciele, ang. peers), od których może pozyskiwać nową 

86 




www.bdas.pl 

wiedzę (schematy i dane). Zakładamy, że agent, pytany o jakieś dane przez godnego zaufania 

sąsiada, stara się obsłużyć zapytanie w najlepszy możliwy sposób. Ponieważ ma on grono 

swoich sąsiadów, to w efekcie propagowania zapytania w systemie mamy do czynienia 

ze wspólnym obsługiwaniem zapytania przez dużą liczbę agentów. W szczególności, w budowaniu 

odpowiedzi mogą kooperować agenci, którzy nie są bezpośrednio związani 

z agentem pytającym. Naturalnym założeniem jest możliwość unikatowej identyfikacji 

agentów. Przyjmujemy, że każdy agent ma swój identyfikator, a system ma stosowne mechanizmy 

zarządzania identyfikatorami. Wprowadzamy także specjalizowanego agenta, 

zwanego brokerem, który w aktualnej wersji systemu pełni funkcje administracyjne, związane 

z „wchodzeniem” i „wychodzeniem” agentów z systemu. 

W systemie mogą być realizowane różne działania (np. wymiana danych między agentami, 

reformułowanie zapytań). Przyjrzyjmy się bliżej scenariuszowi wspólnej obsługi zapytań 

przez agentów, którzy dysponują wiedzą wyrażaną za pomocą podobnych semantycznie 

pojęć. Pomiędzy schematami danych takich agentów muszą zatem istnieć odwzorowania. 

Niech Map oznacza odwzorowanie ze schematu agenta a do schematu agenta p, a Mpa – 

odwzorowanie w przeciwnym kierunku. Jeśli agent a chce skierować zapytanie do agenta 

p, to najpierw próbuje zdefiniować odwzorowania pomiędzy schematami. W tym celu prosi 

agenta p o przekazanie jego lokalnego schematu. Na podstawie wiedzy o obu schematach, 

być może przy udziale użytkownika, agent a tworzy oba odwzorowania. 

user 

Q D = merge(Da, Mp1a(D1), Mp2a(D2), 

…, Mpna(Dn)) 

a 

Q1 = Map1(Q) 

p1 

D1 

Q2 = Map2(Q) 

p2 

D2 

Dn 

. . . 

Qn= Mapn(Q) 

pn 

Rys. 1. Kooperacyjna obsługa zapytania (Q) i budowanie odpowiedzi (D) przez agenta (a) 

i jego partnerów semantycznych (p1, p2, …, pn) w systemie SIX–P2P 

Obsługa oryginalnego zapytanie Q, kierowanego do agenta a, polega zatem na obsłudze 

lokalnej (w bazie danych agenta a) oraz na obsłudze realizowanej przez podzbiór partnerów, 

dla których agent a utworzył odwzorowania. Zapytanie Q, po zreformułowaniu go za 

pomocą odpowiedniego odwzorowania Mapi, jest kierowane do partnera pi. Uzyskiwane 

od partnerów odpowiedzi, wyrażone w terminach z ich lokalnych schematów, są przez 

agenta a przetwarzane za pomocą odwzorowań odwrotnych do postaci zgodnej 

z jego schematem lokalnym. Po połączeniu (za pomocą funkcji merge), wszystkich odpowiedzi, 

lokalnej Da i częściowych odpowiedzi Dpi od partnerów, agent a przedstawia 

efekt D obsługi oryginalnego zapytania Q. Powyższy scenariusz pokazano na rys. 1. 

87 




5 Wybrane fragmenty prologowej specyfikacji systemu 

www.bdas.pl 

Niżej przedstawiono specyfikacje prologowe podstawowych akcji agentów. W systemie 

SIX–P2P mamy agentów dwóch typów: brokera i dysponentów danych. Broker utrzymuje 

wiedzę o wszystkich agentach (w fakcie o predykacie agents/1) w systemie oraz o związkach 

pomiędzy agentami i ich partnerami (partners/2). Odpowiada on za wprowadzenie 

agenta do systemu (register/2), czyli zarejestrowanie go (dołączenie do listy agentów) 

i wskazanie zbioru jego partnerów. Zadanie wprowadzenia (introduce/3) jest inicjowane 

przez agenta i skutkuje przyjęciem przez niego do wiadomości (zapisaniem w postaci faktu) 

listy (Parts) sąsiadów w systemie wskazanych mu przez brokera. 

introduce(Agent, Broker, Parts) :- 

Broker * register(Agent, Parts), 

assert(partners(Parts)). 

% zarejestrowanie agenta 

% zapamiętanie listy partnerów 

Podobnie przebiega realizacja akcji „opuszczenia” (log_put/1) systemu przez agenta, która 

polega na poinformowaniu o tym zamiarze brokera. Ten ostatni, dysponując wiedzą 

o wszystkich agentach w systemie, przekazuje zainteresowanym agentom, czyli tym, którzy 

korzystali z danych agenta opuszczającego system, informację o jego odejściu 

(logged_out/1). 

log_out(Agent):- 

agents(As), 

a_remove(Agent, As, As1), 

% usunięcie agenta z listy agentów 

retract(agents(_)), assert(agents(As1)), 

set_of(A, (partners(A, Parts), % wyznaczenie zbioru agentów 

member(Agent, Parts)), As2), % zaintersowanych i poinformowal_inform_all(As2, 

Agent), 

% nie ich o odejściu agenta 

retract(partners(Agent, _). 

l_inform_all([ ], _). 

l_inform_all([A | As], Agent):- 

A * logged_out(Agent), 

l_inform_all(As, Agent). 

Również wszelkie zmiany w sposobie organizowania danych przez agenta powinny być 

ujawnione i przekazane brokerowi (modify_schema/1), gdyż mają one zasadniczy wpływ 

na kształt powiązań semantycznych w systemie. Broker odpowiada za poinformowanie 

o zmianach (modified_schema/1) wszystkich zainteresowanych nimi agentów. 

modify_schema(Agent):- 

set_of(A, partners(A, Parts), % wyznaczenie zbioru agentów wymember(Agent, 

Parts)), As), % korzystujacych zmieniony sches_inform(As, 

Agent). 

% mat i poinformowanie o zmianie 

88 

s_inform_all([], _). 

s_inform_all([A | As], Agent):- 

A * modified_schema(Agent), 

s_inform_all(As, Agent). 

Podstawowe działania dysponentów danych polegają na tworzeniu powiązań semantycznych 

z innymi agentami i pozyskiwaniu danych od tych agentów. Powiązania są ustalane 

przez fakt zbudowania odpowiednich odwzorowań między schematami. Agent, po ustaleniu 

zbioru swoich sąsiadów w systemie, próbuje dla każdego z nich stworzyć takie odwzorowanie 

(create_map/3), a właściwie parę odwzorowań. Ponieważ nie zawsze takie odwzorowanie 

istnieje, to wynikiem może być odwzorowanie puste, reprezentowane przez 

wartość null. 

create_map(Part, Mpa, Map) :- 



schema(self, Scha), 

Part * schema(self, Schp), 

map(Part, Scha, Schp, Mpa, Map), 

assert(mappings(Part, Mpa, Map)). 


% odczytanie schematu własnego 

% pobranie schematu od partnera 

% utworzenie odwzorowań 

% zapamiętanie odwzorowań 

Złożony proces obsługi zapytania (ask/3) w systemie P2P z agentami o różnych schematach 

danych obejmuje lokalną obsługę zapytania (query/2) oraz pozyskanie (ask_partners/2) 

i połączenie (merge/3) odpowiedzi wypracowanych przez partnerów semantycznych 

(bezpośrednich i pośrednich). 

ask(Agent, Query, Answer) :- 

query(Query, Ansl), 

% lokalna obsługa zapytania 

choose(QParts), 

% wybranie partnerów semantycznych 

ask_qparts(Query, QParts, Ansr), % wspólna obsługa zapytania 

merge([ ], Ansr, Ans). % połaczenie odpowiedzi od partnerów 

merge([Ansl], Ansr, Answer). % z odpowiedzią lokalną 

Oryginalne zapytanie jest zamieniane (convert/3) na zestaw zapytań do poszczególnych 

partnerów i reformułowane (q_reformulate/3) do postaci zgodnej ze schematem każdego 

z nich. W tych działaniach wykorzystuje się odwzorowania pomiędzy schematami. Podobnie 

jest przy transformowaniu odpowiedzi (a_reformulate/3). Poniżej przywołano specyfikację 

wspólnej obsługi zapytania przez zbiór (listę) partnerów. 

ask_qparts(_, [ ], _). 

% uwzględniono wszystkich partnerów 

ask_qparts(Query, [P|Ps], [A|As]) :- 

convert(Query, P, Qp), % wyznaczenie pojedynczego podzapytania 

mappings(P, Mpa, Map), 

q_reformulate(Qp, Map, Qp1), % reformułowanie zapytania 

P * ask(Qp1, Ap), 

a_reformulate(Ap, Mpa, A), % reformułowanie odpowiedzi 

ask_qparts(Query, Ps, As). % uwzględnienie pozostałych partnerów 

www.bdas.pl 

6 Podsumowanie 

System P2P, w którym ma miejsce semantyczna integracja danych, jest niewątpliwie systemem 

złożonym. Dlatego też w projektowaniu jego prototypu trzeba uwzględniać technologie 

zapewniające odpowiednio wysoki poziom ogólności specyfikowania i weryfikowania 

przyjętych rozwiązań. Za takie uważamy systemy agentowe oraz mechanizmy deklaratywne. 

Technologia agentowa umożliwia wyodrębnianie stosunkowo niewielkich bytów (agentów) 

o ograniczonym zakresie działania. Dodatkowo, działanie takie może być uzależnione 

od stanu mentalnego agenta. W specyfikacjach deklaratywnych łatwo jest połączyć precyzję 

opisu z wykonalnością tych specyfikacji. Można korzystać z unifikacji, subsumpcji 

(przydatnej przy porównywaniu informacji niepełnych) oraz wnioskowania z uwzględnieniem 

hierarchii typów. W obliczeniach mogą występować nawroty, a dane i reguły składające 

się na stany mentalne agentów łatwo się w tych obliczeniach uwzględnia. Dlatego 

w systemie SIX-P2P zaadaptowaliśmy większość z tych mechanizmów. Skorzystaliśmy 

także z propozycji prowadzenia obliczeń prologowych w środowisku rozproszonym [10]. 

W regułach opisujących takie obliczenia wprowadziliśmy, w sposób jawny, stany mentalne 

agentów. 

Analizując w [5] funkcje poszczególnych rodzajów agentów szczególną rolę przypisaliśmy 

brokerowi, który dysponuje pewnymi informacjami wykraczającymi poza wiedzę pojedynczego 

agenta – dysponenta danych przedmiotowych. W obecnym rozwiązaniu, broker 

wyznacza partnerów nowego agenta dołączanego do systemu. Gdy agent kończy swoją 

89 




www.bdas.pl 

działalność w systemie, broker informuje o tym fakcie innych zainteresowanych agentów. 

Rozważając dalsze kierunki rozwoju systemu skłaniamy się ku zwiększeniu roli brokera, 

z zachowaniem jednak natury systemu P2P. W szczególności, mógłby on tworzyć dodatkowe 

odwzorowania schematów poprzez składanie niektórych odwzorowań już istniejących. 

Wówczas zakłócenia w działaniu jakiegoś agenta (spowodowane np. problemami komunikacyjnymi) 

mogłyby być „automatycznie” niwelowanie poprzez przekształcanie zapytań 

według tych dodatkowych odwzorowań. 

Innym ważnym problemem jest zapewnianie niesprzeczności danych wymienianych 

przez agentów. Jak podano w podrozdziale 3, niektóre zadania mogą być realizowane równocześnie 

przez wielu agentów, a uzyskiwane wyniki mogą być ze sobą sprzeczne. Trzeba 

zatem opracować dodatkowe reguły, które mogą ułatwić rozwiązanie tego problemu. 

Literatura 

1. Barwise J., Perry J.: Situations and attitudes. MIT Press, Cambridge, MA 1983. 

2. Barwise J., Seligman J.: Information Flow. The Logic of Distributed Systems. Cambridge 

Universtity Press, 1997. 

3. Berners-Lee T., Hendler J., Lassila O.: The Semantic Web. Scientific American, 284(5), 2001. 

4. Bouquet, P., Serafini, L., Zanobini, S.: Peer-to-peer semantic coordination., Journal of Web 

Semantics, 2(1), 2004, 81–97. 

5. Brzykcy G., Bartoszek J., Pankowski T.: Semantic data integration in P2P environment using 

schema mappings and agent technology, Simposium KES-AMSTA 2007, Wrocław. 

6. Calvanese, D., Giacomo, G. D., Lenzerini, M., Rosati, R.: Logical Foundations of Peer-To-Peer 

Data Integration., Proc. of the 23rd ACM SIGMOD Symposium on Principles of Database 

Systems (PODS 2004), 2004, 241–251. 

7. Carpenter, B.: The logic of typed feature structures: inheritance, (in)equations and 

extensionality. Second European Summer School in Language, Logic and Information. Leuven, 

1990. 

8. Garbers J., Niemann M., Mochol M.: A Personalized Hotel Selection Engine. Demons and 

Posters of the 3rd European Semantic Web Conference (ESWC 2006), Budva, 2006. 

9. Lenzerini, M.: Data Integration: A Theoretical Perspective., PODS, 2002, 233–246. 

10. Loke, S. W.: Declarative programming of integrated peer-to-peer and Web based systems: the 

case of Prolog., Journal of Systems and Software, 79(4), 2006, 523–536. 

11. Loke, S. W.: Representing and Reasoning with Situations for Context-Aware Pervasive 

Computing: a Logic Programming Perspective. School of Computer Science and Software 

Engineering, Monash University, Australia, 2004. 

12. OpenTravel Alliance, www.opentravel.org/OTA/2003/05. 

13. Pankowski, T., Cybulka, J., Meissner, A.: XML Schema Mappings in the Presence of Key 

Constraints and Value Dependencies, ICDT 2007 Workshop on Emerging Research 

Opportunities in Web Data Management, EROW'07, 2007, 1–15. 

14. Rahm, E., Bernstein, P. A.: A survey of approaches to automatic schema matching, The VLDB 

Journal, 10(4), 2001, 334–350. 

15. Schorlemmer M., Kalfoglou Y.: Progressive ontology alignment for meaning coordination: 

An information-theoretic foundation. 4 th Int. Join Conf. on Autonomous Agents and Multiagent 

Systems, 2005. 

16. Tolksdorf R., Nixon L., Liebsch F., Nguyen D. M., Paslaru Bontas E.: Semantic Web Spaces. 

Technical report B-04-11, Freie Universitat Berlin, 2004. 

17. Wrightson A.: Semantics of Well Formed XML as a Human and Machine Readable Language. 

Why is some XML so difficult to read? Extreme Markup Languages, Montreal 2005. 

90

pobierz plik referatu - Politechnika ÅlÄ ska

Create successful ePaper yourself

Delete template?

Save as template?

pobierz plik referatu - Politechnika ÅlÄska