A2.XVII AD 2009 Usluga wyszukiwania semantycznego

Usługa wyszukiwania semantycznego zastosowana do integracji systemów
na polu walki
mgr Paweł Szklarz *
mgr inŜ. Dariusz Nogalski *
dr inŜ. Anna Wróblewska *
* ABG S.A.
Al. Jerozolimskie 123A
02-017 Warszawa
Podstawowym wyzwaniem wynikającym z nowoczesnych technologii telekomunikacji jest obsługa coraz większej
ilości informacji pochodzących z róŜnych źródeł danych. Techniki semantyczne przede wszystkim skupione są na
problemie ujednolicenia tej wiedzy.
Liczba systemów współdziałających w nowoczesnym polu walki powoduje, Ŝe bezpośrednia integracja prowadzi
do usztywnienia tych systemów i uniemoŜliwia ich rozwój. Usługa wyszukiwania semantycznego (UWS) wchodzi
w interakcji ze wszystkimi systemami jako pośrednik realizujący funkcjonalności wysoko-poziomowe za pomocą
zarejestrowanych usług. Kluczowym elementem integracji z UWS jest fakt, Ŝe nie wymaga
ona Ŝadnych zmian w istniejących systemach, a tylko tworzenia formalnego opisu moŜliwości dostępnych usług.
Opis moŜliwości usług jest odpowiedzią na pytanie ‘co ta usługa potrafi robić i jak ją wykorzystać/uruchomić,
Ŝeby osiągnąć taki wynik?’. Opis ten jest tworzony za pomocą technik semantycznych, co ułatwia komunikację
człowiek-maszyna poprzez formalny zapis wiedzy (zrozumiały dla maszyny) w postaci zbliŜonej do języka
naturalnego (zrozumiały dla człowieka).
Posiadając informację o moŜliwościach usług, UWS na podstawie zapytań dostarczonych przez
klienta/uŜytkownika określa swój problem lub cel i szuka rozwiązania za pomocą wywołania usług. Formalne
opisy semantyczne są wykorzystane wewnątrz UWS i na pograniczu interakcji z klientem i dostawcami usług,
to jest w opisie usług i w tłumaczeniu zapytań na formalny opis semantycznych celów.
Siła integracji poprzez UWS zaleŜy od jakości opisów semantycznych usług i zapytań uŜytkownika. Stąd
konieczny jest rozwój narzędzi pozwalających na tworzenie i sprawdzanie tych formalnych opisów
bez ingerencji w złoŜoną logikę technik semantycznych i wewnętrzną budowę UWS. Na podstawie wniosków
z testów integracji za pomocą UWS powstaną podstawy do planowania i realizacji takich narzędzi.
1 Przeznaczenie usługi wyszukiwania semantycznego
Celem usługi semantycznego wyszukiwania (UWS) usług i informacji jest integracja
dostawców usług oraz ich odbiorców w środowisku federacji heterogenicznych systemów.
Wykorzystuje ona technologie semantyczne w celu integracji usług w architekturze
zorientowanej usługowo (SOA, ang. Service Oriented Architecture). Łączy ona technologie
usług i standardy semantyczne. UWS jest komponentem zintegrowanym z bazą wiedzy i
rejestrem usług. Będzie ona zaimplementowana w demonstratorze SOA, ponadto moŜe być
zastosowana przez inne usługi i aplikacje. Podstawową funkcjonalnością UWS jest
tłumaczenie zapytań uŜytkownika do reprezentacji semantycznej (OWL), bazując na nich
zostają wyszukane semantycznie usługi zarejestrowane w rejestrze usług (RU) dostarczające
niezbędnych informacji odpowiadające na podane zapytania. Następnie zebrane informacje są
agregowane i zwracane do uŜytkownika.
Usługa wyszukiwania semantycznego jest usługą bazową w projekcie Integracja Systemów
Dowodzenia (ISD). UWS wykorzystana w demonstratorze SOA będzie wspierała
wykonywanie szerokiej gamy eksperymentów badawczych na potrzeby poszczególnych
uczestników konsorcjum.
Zakłada się wykorzystanie UWS zaimplementowanej w demonstratorze
w eksperymentach międzynarodowych (środowisko testowe NC3A, MNE-6, itd..).
SOA
2 Integracja semantyczna
Nowoczesne technologie semantyczne stanowią szczególną realizację rachunku predykatów
pierwszego rzędu, często zwanym logiką pierwszego rzędu. Wobec moŜliwości teoretycznych
wynikających z programowaniem za pomocą ścisłego modelu logicznego naukowcy
oczekiwali, Ŝe zastosowanie rachunku predykatów pierwszego rzędu wprowadzi istotnych
zmian w sposobie realizacji algorytmów i systemów informatycznych. JednakŜe bezpośrednie
zastosowanie tego rachunku wymaga dokładnego zrozumienia teorii logicznej będącej u jego
podstaw, a tym samym bardzo duŜego nakładu wyspecjalizowanej pracy. Podjęcie
wyznawania stosowania logiki pierwszego rzędu okazało się więc zbyt wymagającym i z
punktu widzenia twórców systemów nieopłacalne. Korzyści stosowania takiej teorii były
jednak na tyle wyraźne, Ŝe w ostatnim czasie pojawiło się duŜo implementacji „stycznej
inteligencji” wykorzystujących mechanizmów podobnych do wnioskowania logicznego,
uproszczających tą skomplikowaną teorię.
2.1 Problem skali
Okazuję się, Ŝe problem wdroŜenia czystego rachunku predykatów pierwszego rzędu z całą
bogatą logiką nie był w samej teorii, a tylko w wyborze odpowiedniej skali. W erze Internetu,
wszystkie implementacje „ad hoc” omijające podstawy logiczne na rzecz oczywistych
bezpośrednich rozwiązań zbyt mocno upraszczają wiedzę, a dalszy ich rozwój i utrzymanie
stają się praktycznie niemoŜliwe.
śeby zrozumieć problem skali, zwróćmy uwagę, iŜ podczas realizacji systemów
informatycznych, zrozumianych nie tylko jako oprogramowanie, ale i równieŜ otoczka ludzka
i sprzętowa współdziałająca ze sobą, koniecznie jest potwierdzenie zgodności działania
systemu z wymaganiami i ograniczeniami wynikające ze specyfikacji. Kiedy mamy do
czynienia z systemem działające nawet w obrębie sieci lokalnej kilku komputerów,
sprawdzenie działanie systemu i znalezienia błędów są moŜliwe poprzez odpowiednią
organizacją pracy i wytyczenie procedur zarówno implementacji jak i wdroŜenia. Dodatkowo,
waŜnym elementem tego sprawdzenia jest moŜliwość napisania dokumentacji będącą
specyfikacją działania systemu.
Scenariusz przed chwilą przedstawionym przestaje być efektywnym i prowadzi do
nieścisłości z kilku powodów. Po pierwsze, dokumentacja będącą specyfikacją napisana jest
w języku nie formalnym, co prowadzi do sprzecznych interpretacji. Rozwiązaniem
powszechnie stosowanym jest uzgadnianie nieścisłości zgodnie z ich pojawieniem się w celu
prowadzenia do jednoznacznego określenia celów przedsięwzięcia. Niestety wobec braku
ścisłego aparatu logiki i odpowiednich narzędzi weryfikujących wynik takich ustaleń, wynik
końcowy jest specyfikacją niemoŜliwą do implementacji z prostego powodu braku
jakichkolwiek interpretacji.
Drugim powodem powstania nieścisłości jest brak moŜliwości sprawdzenia zgodności
systemu ze specyfikacją. Zwróćmy uwagę, Ŝe nie mamy na myśli realizacji zestawu testów i
uruchomienia systemów pod odpowiednim rygorem monitorowania w celu znalezienia
błędów. Takie testy pozwalają jedynie stwierdzić, Ŝe system działa, nie dają jednak
jednoznacznego stwierdzenia poprawności zgodnie z odpowiednim modelem i logiką.
2.2 Ścisłe rozwiązania.
Techniki semantyczne stosowane w Usłudze wyszukiwania semantycznego (UWS) zostały
przygotowane w celu tworzenia systemów szeroko zrozumianych zgodnie ze ścisłym i
jednoznacznym modelem logicznym.
Pozwala nam to zrealizować wcześniej wspomnianego sprawdzenia zgodności działanie
systemu wykorzystujących UWS ze specyfikacją w kaŜdym kroku jego tworzenia. Zarówno
powiem działanie systemu jak i jego specyfikacja są napisane w formalnym języku logiki
opisowej, co pozwala tworzyć narzędzi ogarniających całość i sprawdzających spójność i
poprawność całego systemu i sposób jednoznaczny. MoŜna stwierdzić, Ŝe w kaŜdym kroku
tworzenia systemu mamy pełen dowód poprawności albo co waŜniejsze, powody nieścisłości
tworzonych implementacji/specyfikacji i brak moŜliwości uruchomienia bez poprawienia
błędów realizacji.
2.2.1 Realizacja integracji.
Integracja systemów poprzez usługi wyszukiwania semantycznego odbywa się poprzez
opisanie w języku formalnym ontologii moŜliwości, zaleŜności, załoŜeń, ograniczeń i
interakcji usług udostępnionych przez kaŜdy system. Na podstawie takich opisów UWS
stwierdza poprawność kaŜdej usługi z osobna i zarówno logiczną spójność całego środowiska
systemów jako jedna całość.
Wspomniany opis zawiera pełną informację potrzebną do wykorzystania usługi zgodnie z jej
przeznaczeniem. Pozwala to równieŜ na znalezienia nowych moŜliwości wynikających ze
złoŜenia kilku niezaleŜnych usług do realizacji nowych funkcjonalności.
2.3 Semantyczny opis usługi:OWL-S
Opis semantyczny usługi wyraŜony jest w języku logiki opisowej zgodnie z formalnymi
wymaganiami zawartymi w ontologii OWL-S (http://www.w3.org/Submission/OWL-S/).
Ontologia OWL-S składa się z trzech głównych klas (rys. [Rysunek 1]):
1) Profil usługi (ang. Service Profile)
Profil opisuje „co usługa robi”. Jest przeznaczony do wykorzystania podczas procesu
automatycznego wykrywania usług.
2) Model usługi (ang. Service Model)
Model mówi “jak usługa działa”. Opisuje teŜ co jest wynikiem uruchomienia usługi i
jaki jest tego skutek. Jest wykorzystywany podczas kompozycji usług podstawowych
do usług złoŜonych.
3) Wiązanie usługi (ang. Service Grounding)
Wiązanie opisuje sposób uruchomienia usługi. Definiuje przejście z wywołania usługi
semantycznej do wywołania konkretnej usługi webowej. Definiuje teŜ mapowanie /
transformację typów danych z usługi semantycznej do usługi webowej i na odwrót.
Rysunek 1 Ontologia usługi w OWL-S [OWL-S 1.1]
Profil usługi (rys. [Rysunek 2]) opisuje organizację dostawcy usługi, funkcjonalność
usługi oraz zbiór własności charakterystycznych (ang. features). Opis dostawcy zawiera
informacje kontaktowe. Opis funkcjonalny jest wyraŜony poprzez tzw. IOPEs 1 opisujące
parametry wejściowe, wyjściowe, zewnętrze warunki wymagane do uruchomienia usługi oraz
oczekiwany efekt.
Na przykład: usługa realizująca płatność moŜe przyjmować numer karty (parametr
wejściowy), drukować potwierdzenie transakcji (parametr wyjściowy), przy czy karta
kredytowa powinna być waŜna (warunek wejściowy), natomiast efektem działania usługi
będzie aktualizacja salda na koncie (efekt).
Własności dodatkowe zawierają takie informacje jak kategoria usługi w systemie
UNSPSC2, parametry jakościowe (QoS), np. estymowany średni czas odpowiedzi.
Rysunek 2 Profil usługi OWL-S [OWL-S 1.1 ].
1
2
Ang. Input Output Preconditions Effect
United Nations Standard Products and Services Code
Model usługi (rys. [Rysunek 3]) opisuje w jaki sposób usługa działa. Podstawową encją w
modelu jest Proces, jest on opisany za pomocą IOPEs, podobnie jak Profil. Proces moŜe być
atomowy (ang. Atomic Process), prosty (ang. Simple Process) lub złoŜony (ang. Composite
Process).
Proces atomowy nie ma Ŝadnych podprocesów i jest wykonywany w pojedynczym kroku.
Jest on powiązany z Wiązaniem, czyli uruchomieniem konkretnej usługi sieciowej.
Proces prosty jest postrzegany jako proces jednokrokowy, nie jest powiązany z Wiązaniem
lecz słuŜy do specyfikacji abstrakcji na potrzeba wnioskowania (np. uogólnianie procesów).
Procesy złoŜone są dekomponowane na inne procesy atomowe, proste lub złoŜone za
pomocą gramatyki z konstruktorami, takimi jak: Sequence, Split, Split+Join, Choice,
Unordered, Condition, If-Then-Else, Iterate, Repeat-While, and Repeat-Until.
Rysunek 3 Model usługi OWL-S [OWL-S 1.1]
Wiązanie usługi (rys. [Rysunek 4]) opisuje, w jaki sposób uruchomić usługę. Definiuje
mapowanie między opisem abstrakcyjnym/semantycznym a konkretnymi usługami
sieciowymi.
Rysunek 4 Wiązanie usługi OWL-S [OWL-S 1.1]
OWL-S nie narzuca konkretnego standardu do jakiego usługi abstrakcyjne mają się
mapować/wiązać. Usługi sieciowe i WSDL został wybrany z pragmatycznego podejścia, są
one powszechne i opracowano kompletny zestaw specyfikacji, języków i narzędzi potrzebny
do ich implementacji (WSDL, SOAP, XSD etc.). MoŜna zatem wykorzystać istniejącą
infrastrukturę i zbudować na niej warstwę semantyki i skorzystać z jej dobrodziejstw
(ekspresyjność języka OWL, wnioskowanie).
3 Logika działania UWS
Pełne wykorzystanie informacji zawartej w opisach semantyczny usług jest moŜliwe poprzez
podział przetwarzania zapytań uŜytkownika na kilka warstw logicznych danych. KaŜda
warstwa komunikuje się tylko i wyłącznie z bezpośrednio sąsiadującą warstwą.
Logika działania UWS zostanie opisana poprzez szczegółowy wykaz interakcji między
warstwami.
3.1 Abstrakcyjne warstwy komunikacji UWS
Przyjęty został podział na 5 warstw zgodnie z rysunkiem [Rysunek 5].
Rysunek 5 Abstrakcyjne warstwy komunikacji UWS.
Zdefiniowanie rozgraniczenia między
mi
tymi warstwami wynika z określenia
ślenia rodzaju danych
wchodzących
cych w skład poszczególnych warstw:
1) AK-GUI (Aplikacja klienta GUI)
Zawiera listę komend dostępnych
dostę
dla uŜytkownika.
UŜytkownik
ytkownik aplikacji klienta ma dostęp do zestawu narzędzi
dzi i operacji umoŜliwiających
umo
mu współpracę z UWS. Cały ten asortyment zostaje wydzielony do warstwy AK-GUI.
AK
Z punktu widzenia
dzenia UWS, warstwa AK-GUI
AK
określa zbiór moŜliwych
liwych komend i danych,
które AK moŜee generować i wysyłać do następnej warstwy AK-Sesja.
Sesja. MoŜliwe komendy
w AK-GUI
GUI to np. pobranie współrzędnych
współrz dnych regionu zainteresowania AOI, wybranie
jednostki na mapie, prośba o wyszczególnienie
wyszczególnienie składu konwoju, sprawdzenie obszaru
raŜenia jednostki artylerii.
2) AK-Sesja (Aplikacja klienta Sesja)
Zawiera kryteria wyszukiwania (warunki logiczne) i stan wiedzy uŜytkownika.
uŜytkownika.
Z danych zawartych w tej warstwie wynika definicja zapytań
zapyta uŜytkownika
ownika jako klienta
usługi UWS, będące
ce podstawą
podstaw do uruchomienia procesu wyszukiwania usług i informacji.
3) Cele
Warstwa ta wydziela zbiór celów. Cel jest formalnym zapisem Ŝądania
Ŝą
informacji i
kryteriów poprawności
ci wyniku opisana w języku
j
formalnym ontologii..
4) Procesy
Warstwa procesów składa się,
si Ŝee zbioru procesów zarejestrowanych w UWS. Proces jest
odzwierciedleniem moŜliwo
Ŝliwości zadeklarowanych
ch w opisie semantycznym usługi i stanowi
podstawą do uruchomienia poszczególnych kroków realizacji rozwiązania
rozwiązania problemu.
problemu
5) Usługi
Poszczególne usługi zarejestrowane w rejestrze usług są widziane jako osobne byty w tej
warstwie. Wykorzystana jest jednak tylko część
cz
opisu semantycznego, mianowicie opis
techniczny (WSDL) i „Grounding” z ontologii OWL-S.
OWL S. Informacja ta określa
okre
jednoznacznie
dnoznacznie sposób wywołania usługi, czyli: jakie informacje i w jakiej postaci wysłać,
wysła
sposób połączenia
czenia i oczekiwaną
oczekiwan postać wyników.
3.2 Wywołanie UWS na poziomie abstrakcyjnych warstw
Komunikacja między warstwami określa całościowo sposób interakcji końcowego
uŜytkownika z usługami zarejestrowanymi w RU i opisanymi semantycznie. Na poziomie
poszczególnych warstw interakcja jest dozwolona tylko z sąsiednimi warstwami.
3.2.1 AK-GUI – AK-Sesja
UŜytkownik wykorzystuje AK-GUI do określenie kryteriów wyszukiwania informacji i usług
na podstawie ontologii referencyjnej i zestawu narzędzi predefiniowanych w AK. Na tle tej
interakcji odbywa się komunikacja z warstwą AK-Sesji, zapisująca te kryteria w stanie sesji
w postaci instancji ontologii. Ta interakcja jest zaznaczona na rysunku [Rysunek 5] literą a.
3.2.2 AK-Sesja – Cele
Na podstawie danych zawartych w stanie wiedzy uŜytkownika i uruchomieniu przez niego
odpowiedniej komendy do AK-Sesji, realizowane jest przeszukiwanie zbioru dostępnych
celów, tak aby znaleźć odpowiednio pasujący cel do zdefiniowanych kryteriów uŜytkownika.
Po pomyślnym znalezieniu celu, zostaje on uruchomiony i wyniki w postaci instancji zostają
zwracane do stanu wiedzy uŜytkownika. Ta interakcja jest zaznaczona na rysunku [Rysunek
5] literą b.
3.2.3 Cele – Procesy
Po uruchomieniu celu, odbywa się poszukiwanie najbardziej adekwatnych procesów, których
moŜliwości spełniają załoŜenia celu.
Na pierwszym etapie prototypowym nie przewiduje się złoŜenie procesów w sposób
automatyczny a tylko uruchomienie jednego procesu.
Po uruchomieniu procesu wybranego na podstawie celu, oddaje on zbiór instancji
wynikowych do wywołującego go celu.
Ta interakcja jest zaznaczona na rysunku [Rysunek 5] literą c.
3.2.4 Wewnętrzne odwołania w warstwie procesów.
Podczas uruchomienia procesu przewiduje się trzy moŜliwe wywołania na tym poziomie
abstrakcji wskazane przez litery d,p,q na rysunku [Rysunek 5]:
d) Wywołanie usługi.
Patrz punkt dalej: komunikacja między procesem i usługą.
p) Wywołanie celu.
W ten sposób proces moŜe oddelegować część swojej pracy, określając dokładnie jaki
jest oczekiwany wynik. Wywołanie celu odbywa się tak samo jak wywołanie od
warstwy AK-Sesji. W tym przypadku, proces nie oczekuje rozwiązanie tego celu przez
szczególny wybrany proces i jest przygotowany na brak kandydatów.
q) Wywołanie procesu.
Proces moŜe zostać napisany w postaci złoŜenia innych procesów. Wskazanie
podprocesów odbywa się przez bezpośrednią referencję.
3.2.5 Procesy – Usługi
Definicje procesów odwołują się do części opisów semantycznych usług określających
sposób wywołania konkretnych metod usługi.
Przygotowanie danych do przesyłania przyjmuje jako dane wejściowe instancje z
wewnętrznego stanu procesu. Wyniki wywołania są równieŜ przetłumaczone na instancje
zgodnie z opisem semantycznym usługi.
4 Wnioski i konkluzje
Ścisły, jednoznaczny i bogaty model logiczny będący podstawą formalnych opisów usług
wykorzystanych w usłudze wyszukiwania semantycznego zapewnia zgodność działania
systemu z wymaganiami uŜytkowników. Wymagania te powinny być opisane równieŜ w
sposób ścisły i jednoznaczny w tym samym języku logicznym. Dzięki takiemu podejściu,
moŜliwości rozszerzania i integracji systemów nie są ograniczone przez skalę lub złoŜoność
przedsięwzięcia.
Podział logiczny problemu integracji na dokładnie określone warstwy z wyraźnie
zdefiniowanym przeznaczeniem prowadzi do elastycznej oraz uporządkowanej realizacji
wyznaczonych przez uŜytkownika celów z maksymalnym wykorzystaniem dostępnych
zasobów widzianych jako usługi formalnie zdefiniowane poprzez opisy semantyczne.
Stosowanie technik semantycznych stanie się w przyszłości koniecznością wobec korzyści i
dogodności wynikających z formalnego opisu problemów i rozwiązań za pomocą ścisłej i
ugruntowanej teorii logiki opisowej.
5 Literatura
[MITRE 2004]
MITRE Technical Report, Netcentric Semantic Linking, październik 2004, Mary K.
Pulvermacher, Suzette Stoutenburg, Salim Semy
[Gomez 2004]
Ontological Engineering, 2004, Asuncion Gomez-Perez, Mariano Fernandez-Lopez,
Oscar Corcho
[OWL04]
Specyfikacja OWL, http://www.w3.org/TR/2004/REC-owl-guide-20040210/
[RDF04]
Specyfikacja RDF, http://www.w3.org/RDF
[OWL-S1.1]
Specyfikacja OWL-S v.1.1 http://www.w3.org/Submission/OWL-S/
Praca naukowa finansowana ze srodków na nauke w latach 2007-2010 jako projekt badawczy
zamawiany.