Odnalezienie konkretnego zasobu wiedzy (LO) sprowadza się do znalezienie informacji o tym obiekcie i następnie zaprezentowanie / dostarczenie tej informacji do użytkow-‐ nika. Każdy LO opisany jest zgodnie ze schematem konkretnego systemu (w tym przy-‐ padku jest LRE Application ProWile) który to opis (LOM) wywodzi się ze standardu IEEE LOM. Aby zapewnić skuteczne wyszukiwanie danych opis (LOM) winien być dostępny dla zaproponowanego zorientowanego na agentów systemu wyszukiwania. Bazując na schemacie Federated Search (przedstawionym na str. 23) zaproponowano następujące
możliwości wzbogacenia wyszukiwania w sieci niezależnych repozytoriów.
Rysunek 42. Warstwa agentowa „łącząca” repozytoria w sposób analogiczny jak w przypadku Federated Search
Użytkownik w przedstawionym modelu uzyskuje dostęp i możliwość wyszukiwania czy przeszukiwania innych repozytoriach poprzez swój lokalny system(por. „Szkielet systemu wyszukiwania danych” – str. 21, „Warstwa pośrednia w komunikacji klient-repozytorium” - str. 24, oraz „Federated Search” – str. 24).
W kolejnym kroku rozważań wprowadzono możliwość istnienia dwóch strategii: • z serwerem zarządzającym wyszukiwaniem ;
• bez serwera zarządzającego wyszukiwaniem.
Rysunek 44. Wyszukiwanie bez jednostki centralnej
Dla każdej strategii przyjęto dodatkowe możliwości i tak: wyszukiwanie z serwe-
rem zarządzającym może być realizowane poprzez:
(1) bezpośredni dostęp użytkownika do tego serwera, zlecenie wyszukania i oczekiwa-‐ nie na rezultat, (2) ewentualnie serwer jest „przesłonięty” lokalnymi zasobami, a osoba nie ma do niego bezpośredniego dostępu. Realizacja wyszukania w tej strategii jest analogiczna z istniejącym (i omówionym) podejściem w LORNET, czy ARIADNE.
Z kolei dla wyszukiwania bez serwera zarządzającego rozważono 2 warianty: (3) użytkownik korzysta z aplikacji lokalnie, wysyła agenta przeszukującego zasoby i czeka na jego powrót (por. [94]), bądź (3’) użytkownik zleca realizację wyszukanie interesują-‐
cych go zasobów poprzez lokalny system wyszukiwania zlokalizowany w jego intranecie. Model przedstawiony jako 3’ w istocie jest podobny do modelu z serwerem zarządzają-‐ cym którego część funkcjonalności jest realizowana po stronie jednostki centralnej w danym intranecie(por. “System designed for research centres” i “System designed for Internet users” w pracy autora rozprawy [83]).
Rysunek 45. Serwery obsługujące agentów jako dodatkową usługę po stronie repozytoriów
Rozważono również dwie strategie realizacji zapytań pomiędzy repozytoriami realizowanymi przez agentów mobilnych (zaproponowane przez autora rozprawy [89]). Model pierwszy (określony jako “each-others approach”) polega na wysyłaniu agentów
z każdego repozytorium (3’) bądź serwera centralnego (1,2) do każdego z repozytoriów w poszukiwaniu danych. Model drugi (określony jako “circle approach”) (2,1’) w którym agenci wędrują po sieci, a dane repozytorium może zlecić im wykonanie poszczególnych zadań (por. pojęcie „wolny agent” str. 95 [18]).
Rysunek 46. Strategie realizacji zapytań “each-‐others approach” a “circle approach”
Ostatecznie z uwagi na ograniczone możliwości dostępu do repozytoriów przy-‐ jęto model o możliwie najbardziej szerokiej funkcjonalności w celu łatwości jego adapta-‐ cji i dalszej rozbudowy. Wybrano model z jednostką centralną zajmującą się gromadze-‐ niem metadanych pochodzących z repozytoriów w celu lokalnej ich analizy (por. model 1
oraz Projekt MACE str. 28). Agenci mogą być wysyłani do repozytoriów wspierających
środowisko agentowe gdzie będą odpowiadać za aktualizację kodu, oraz stale monitoro-‐ wać zmiany w danych hoście. Wszelkie aktualizacje będą przesyłane do centralnego repozytorium. Jeśli jednak dane repozytorium nie będzie można wyposażyć w system agentowy to agent do jego obsługi nie będzie migrował lecz komunikacja z nim będzie dokonywać się przez sieć.
System agentowy będzie ponadto zarządzał komunikacją z użytkownikiem końcowym jako osobisty asystent (ang. personal assistant) i w imieniu tej osoby będzie prowadził wyszukiwanie i przetwarzanie informacji. Struktura systemu zapewni również możliwość dodawania funkcjonalności poprzez ewentualne wdrażanie nowych usług. System również będzie można łatwo rozproszyć pomiędzy kilka maszyn w przy-‐ padku wzrostu jego obciążenia – liczby obsługiwanych użytkowników, czy przetwarza-‐ nych metadanych. Wprawdzie wszelkie prace nad ABSS dotyczyły możliwości wzbogace-‐ nia rozproszonych systemów e-‐learningowych o wyszukiwanie spersonalizowane lecz projektowany system miał stanowić równocześnie zestandaryzowaną niezależną całość z dobrze zdeWiniowanymi interfejsami aby w przyszłości móc znaleźć zastosowanie jako wydajne narzędzie wyszukiwania obiektów wiedzy.
3.2. Charakterystyki systemu
Rdzeniem ABSS jest platforma agentowa oparta o rozwiązanie Open Source, Plat-‐ forma JADE [52]. Elementem centralnym systemu jest kontener główny (ang. main container) do którego przyłączane są kontenery zewnętrzne (ang. peripheral containers). Wbudowane mechanizmy platformy agentowej czynią składowe platformy
spójną logiczną warstwą na której działają agenci autonomiczni.
Szkielet systemu z zaznaczeniem elementów Platformy agentowej został przedstawiony na rysunku 47. Kolorem niebieskim zaznaczono elementy stanowiące platformę wieloagentową.
Rysunek 47. Schemat Systemu ABSS [32, 91]
Platforma JADE została wybrana z uwagi na jej otwarty charakter, dobre wsparcie techniczne jak i fakt zgodności ze standardami FIPA. Szczegółowe informacje zostały przedstawione w rozdziale 1 (str. 7-36).
System ABBS ma charakter modułowy. Można wyróżnić w nim dwa moduły zasadnicze:
gromadzący i przetwarzający dane z repozytoriów metadanych oraz moduł zaawan- sowanego wyszukiwania. Powyższe moduły możemy rozdzielić z uwagi na funkcjonal-‐
ność na trzy główne elementy funkcjonalne których celem jest (Rys. 48) [32, 91]:
• Analiza zasobów zgromadzonych w repozytoriach.
Aktualizacja zgromadzonych metadanych i ich przetworzenie do dalszych analiz. • Zarządzanie kontami użytkowników. Obserwacja zachowań użytkowników służąca
klasteryzacji osób w zależności od typu użytkownika, rodzaju obserwowanych cech. Analiza zgodności pro\ili z opisem obiektu edukacyjnego. Komunikacja z użytkowni- kiem i przedstawianie mu wyników wyszukiwania zaawansowanego.
• Przetwarzanie zgromadzonych metadanych w celu optymalizacji działania metod wyszukiwawczych. Realizacja wyszukiwania w oparciu o tak przetworzone meta- dane z rozdzieleniem wyszukiwania na metody i języki.
Rysunek 48. Struktura ABSS z podziałem na moduły funkcjonalne [32, 91]
Każda moduł złożony jest z grupy agentów które komunikują się ze sobą, prze-‐ twarzają dane, monitorują zmiany w repozytoriach, realizują wyszukiwanie w bazach danych czy obsługują polecenia użytkownika. Ponadto w systemie istnieją cztery bazy danych: DB_LOMS (zawiera tabele słownikowe oraz informacje pochodzące z repozyto-‐ riów metadanych), DB_USERS (reprezentuje proWile użytkowników), DB_RANKS (zawiera wszelkie informacje zarówno przetworzone jak i nie przetworzone związane z mechanizmami wyszukiwania spersonalizowanego opartego o CF), oraz DB_METHODS (zawiera przetworzoną informację powiązaną z agentami wyszukującymi.
3.2.1. Zastosowane technologie
Rdzeń Systemu stanowi platforma agentowa JADE, a dokładnej JADE-‐LEAP [16]. Plat-‐ forma została wybrana po analizie obecnie istniejących i stosowanych platform agento-‐ wych („Wybór platformy agentowej” – str. 36) ze szczególnym uwzględnieniem zgodności ze standardami FIPA [12, 80], otwartego charakteru oraz będącej w stałym rozwoju. Liczni autorzy wysoko oceniają zalety platformy JADE [20, 21, 119, 143] co w połączeniu z faktem, iż jak wspomniano, ma ona otwarty charakter czyni ją popularnym i sprawdzo-‐ nym narzędziem wykorzystywanym w różnych projektach naukowo-‐badawczych. Jest zatem narzędziem sprawdzonym i szeroko opisywanym co również stanowiło poważny atut decydujący przy jej wyborze.