pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Nowe Technologie', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2007
Rozdział 7
w
Mechanizmy deklaratywne w systemie P2P
semantycznej integracji danych
w
w
1 Wstęp
da
.b
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.
pl
s.
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
w
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].
da
.b
w
w
pl
s.
82
Mechanizmy deklaratywne w systemie P2P semantycznej integracji danych
w
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.
w
w
2 Dlaczego podejście deklaratywne (programowanie w Prologu)?
da
.b
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].
pl
s.
83
w
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.
da
.b
w
w
pl
s.
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 G1, ..., Gn, 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
w
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
q1,q2,...,qn, i wszystkie wykonania muszą zakończyć się sukcesem, to zapisujemy to jako
q1,q2,...,qn [] G. Jeżeli sukcesem musi zakończyć się wykonywanie zadania G u co najmniej
jednego agenta, to piszemy q1,q2,...,qn <> 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ć
da
.b
w
w
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(v1 ,K , vn ), R(t1 ,K , tn ) ) ∧ R(v1 ,K , vn ) ∈ p
(3)
pl
s.
p / p | –θ R(t1 ,K , tn )
Reguła 4 opisuje realizację zadania R(t1,...tn) w stanie p, w którym agent p zna fakt
R(v1,...vn), a wartości v1, ..., vn mogą być ukonkretnione z termami t1,..., tn. 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
(6)
p / p | –θ q ∗ G
Reguła 7 dotyczy realizacji zadania G przekazanego przez agenta p do agenta q. Zadanie G
jest wykonywane przez agenta q w stanie q.
w
p / p| –θ G1 ∧ p / p | – γ G2θ
p / p | –θγ G1 , G2
(8)
q1/ q1 | –θ 1 G ∧ ... ∧ qn / qn | –θ n G
w
w
Wykonywanie zadania złożonego z podzadań G1 i G2 odbywa się dwuetapowo. Jeżeli
w wyniku wykonania zadania G1 powstanie podstawienie θ, to ma ono wpływ na wykonywanie zadania G2.
p / p | –θ 1...θ n q1 ,K , qn []G
da
.b
q1/ q1 | –θ 1 G ∨ ... ∨ qn / qn | –θ n G
p / p | –θ 1...θ n q1 ,K , qn <> G
(9)
(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 q1,q2,...,qn.
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.
pl
s.
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
w
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.
w
w
user
da
.b
Q D = merge(Da, Mp1a(D1), Mp2a(D2),
…, Mpna(Dn))
a
Q1 = Map1(Q)
p1
D1
D2
Dn
Qn= Mapn(Q)
Q2 = Map2(Q)
pn
p2
pl
s.
. . .
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
w
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.
w
introduce(Agent, Broker, Parts) :Broker * register(Agent, Parts),
assert(partners(Parts)).
% zarejestrowanie agenta
% zapamiętanie listy partnerów
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).
da
.b
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).
pl
s.
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
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) :-
88
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ń
w
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).
w
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ą
w
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.
da
.b
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
6 Podsumowanie
pl
s.
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
w
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.
w
Literatura
3.
4.
6.
7.
8.
9.
10.
12.
13.
14.
15.
16.
17.
pl
s.
11.
da
.b
5.
Barwise J., Perry J.: Situations and attitudes. MIT Press, Cambridge, MA 1983.
Barwise J., Seligman J.: Information Flow. The Logic of Distributed Systems. Cambridge
Universtity Press, 1997.
Berners-Lee T., Hendler J., Lassila O.: The Semantic Web. Scientific American, 284(5), 2001.
Bouquet, P., Serafini, L., Zanobini, S.: Peer-to-peer semantic coordination., Journal of Web
Semantics, 2(1), 2004, 81–97.
Brzykcy G., Bartoszek J., Pankowski T.: Semantic data integration in P2P environment using
schema mappings and agent technology, Simposium KES-AMSTA 2007, Wrocław.
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.
Carpenter, B.: The logic of typed feature structures: inheritance, (in)equations and
extensionality. Second European Summer School in Language, Logic and Information. Leuven,
1990.
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.
Lenzerini, M.: Data Integration: A Theoretical Perspective., PODS, 2002, 233–246.
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.
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.
OpenTravel Alliance, www.opentravel.org/OTA/2003/05.
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.
Rahm, E., Bernstein, P. A.: A survey of approaches to automatic schema matching, The VLDB
Journal, 10(4), 2001, 334–350.
Schorlemmer M., Kalfoglou Y.: Progressive ontology alignment for meaning coordination:
An information-theoretic foundation. 4th Int. Join Conf. on Autonomous Agents and Multiagent
Systems, 2005.
Tolksdorf R., Nixon L., Liebsch F., Nguyen D. M., Paslaru Bontas E.: Semantic Web Spaces.
Technical report B-04-11, Freie Universitat Berlin, 2004.
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.
w
1.
2.
90

pobierz plik referatu

Transkrypt

Podobne dokumenty

ZAŁĄCZNIK DO UMOWY AGENCYJNEJ SPRZEDAŻY

Zadanie 3

Akwizytor

Wykład X/XI

Dlaczego RE/MAX? - giniewicz nieruchomości komercyjne

Opinia2 - AGENT.m6

Mania-Perfum.pl