ﬃ ciencyofgridusage Applicationofsemanticanalysismethodstoincreasethee P olska A kademia N auk I nstytut B ada n ´ S ystemowych

(1)

Polska Akademia Nauk

Streszczenie Pracy Doktorskiej

Application of semantic analysis methods to increase the efficiency of grid usage

Zastosowanie metod analizy semantycznej do zwi ˛ekszenia efektywno´sci wykorzystania gridu

Autor:

mgr in ˙z. Katarzyna Wasielewska-Michniewska

Promotor:

dr hab. Marcin Paprzycki

Warszawa 2018

(2)

Spis tre´sci

Contents i

1 Wprowadzenie 1

1.1 Motywacja . . . . 1 1.2 Zakres i cel pracy . . . . 3

2 Zaproponowane rozwi ˛azanie 4

2.1 Istota zagadnienia . . . . 4 2.2 Reprezentacja eksperckiej wiedzy dziedzinowej . . . . 5 2.3 Wsparcie u ˙zytkownika z wykorzystaniem semantycznego przetwarzania danych . . 6

3 Uwagi ko ´ncowe 11

3.1 Wkład własny . . . . 13

Bibliografia 14

i

(3)

Wprowadzenie

1.1 Motywacja

W ci ˛agu ostatnich lat rozwi ˛azania bazuj ˛ace na gridzie obliczeniowym (oraz, aktualnie, chmurze obliczeniowej) zyskały spore zainteresowanie w obszarach nauki, biznesu i przemysłu jako narz ˛edzia do problemów du ˙zej skali. Rozwi ˛azania tego typu mierz ˛a si ˛e z zagadnieniami zwi ˛azanymi z rozproszeniem danych oraz wykonywaniem du ˙zych ilo´sci cz ˛esto powtarzalnych oblicze ´n. Dodat- kowo, gridy do przechowywania danych (ang. data grids) zapewniaj ˛a infrastruktur ˛e umo ˙zliwiaj ˛ac ˛a dost ˛ep do, modyfikacj ˛e oraz transfer du ˙zej ilo´sci rozproszonych geograficznie, wielo-dziedzinowych zasobów (see, [1]). W gridach obliczeniowych (ang. computational grids) u ˙zytkownicy (lub apli- kacje) mog ˛e uzyska´c dost ˛ep do zasobów (procesorów, miejsca przechowywania, zasobów siecio- wych, aplikacji) w miar ˛e zapotrzebowania, bez potrzeby uwzgl ˛edniania ich fizycznej lokalizacji lub szczegółowych informacji o technologiach wykorzystanych podczas budowy infrastruktury.

W tym kontek´scie, mo ˙zliwe jest utworzenie “wirtualnych superkomputerów” poprzez zagospoda- rowanie niewykorzystywanych zasobów obliczeniowych do realizacji kosztownych obliczeniowo zada ´n.

Gridy s ˛a zazwyczaj zarz ˛adzane poprzez dedykowane oprogramowanie typu middleware, które umo ˙zliwia udost ˛epnianie oraz wykorzystanie zasobów w oparciu o ich konfiguracj ˛e oraz wymagania u ˙zytkownika. Mo ˙zna zaobserwować, ˙ze mimo wi ˛ekszych mo ˙zliwo´sci gridów je ˙zeli chodzi o wykonywane obliczenia, ich implementacja jest bardziej zło ˙zona i efektywne ich wykorzystanie wymaga wi ˛ekszej wiedzy technicznej. W przypadku gridów ogólnego przeznaczenia, u ˙zytkownik dodatkowo powinien zdecydować jaki sposób wykorzystania go interesuje. Pytania na które nale ˙zy udzielić odpowiedzi to m.in.: jaka konfiguracja zasobu jest optymalna dla zadania, które powinno zostać wykonane? które oprogramowanie/metoda/algorytm s ˛a zalecane do rozwi ˛azania danego problemu? czy zasób z zalecan ˛a konfiguracj ˛a jest dost ˛epny w gridzie? czy warunki współpracy s ˛a akceptowalne przez dostawc ˛e zasobu oraz klienta? Aby mo ˙zna było efektywne odpowiedzieć na te pytania, nale ˙załoby zaproponować schemat reprezentacji wiedzy, który umo ˙zliwi zapisanie oraz odpytywanie o odpowiednie informacje. Co wi ˛ecej, schemat reprezentacji wiedzy powinien być od- porny na zmiany kontekstu (np. ró ˙zne standardy opisu), adaptowalny, oraz elastyczny wzgl ˛edem

1

(4)

2

mo ˙zliwo´sci modelowania wiedzy. Bior ˛ac powy ˙zsze pod uwag ˛e, istotna jest publikacja [2], w której autorzy sugeruj ˛a ˙ze semantyka oraz ontologie s ˛a kluczowe w nast ˛epnym pokoleniu technologii we- bowych, poniewa ˙z umo ˙zliwiaj ˛a efektywny i wydajny dost ˛ep to ró ˙znorodnych oraz rozproszonych

´zródeł informacji.

Z perspektywy u ˙zytkowników o ró ˙znym profilu, ró ˙zne kwestie zwi ˛azane z u ˙zytkowaniem gridu s ˛a istotne. Dla administratorów i dostawców zasobów wa ˙zne s ˛a elastyczne oraz ekspresywne metody opisu zasobów. Dla u ˙zytkowników (konsumentów zasobów; klientów gridu) bez wiedzy technicznej (np. naukowcy – nie specjali´sci IT – którzy chc ˛a w gridzie rozwi ˛azać problem ze swojej dziedziny) u ˙zytkowanie infrastruktury gridowej bywa problematyczne ze wzgl ˛edu na ró ˙znice w implementacji interfejsów gridowych (metod poł ˛aczenia, zlecania zada ń, kolejkowania, wyboru zasobu), które musz ˛a opanować. W rezultacie, aby efektywnie u ˙zytkować zasoby gridu nale ˙zy “obej´sć” problem przepracowanego administratora/osoby zapewniaj ˛acej wsparcia techniczne, która jest odpowiedzialna ze wspieranie u ˙zytkowników, informacje na temat zmian w konfiguracji itp. (w szczególno´sci za udzielanie odpowiedzi na pytania z poprzedniego akapitu). W tym kontek´scie, nast ˛epuj ˛ace problemy z u ˙zytkowaniem zasobów gridu/chmury zostały zidentyfikowane: (i) u ˙zytkownicy nie s ˛a skłonni do nauki nowego oprogramowania, (ii) u ˙zytkownicy maj ˛a tendencj ˛e do u ˙zywania jednej, wcze´sniej opanowanej metody/biblioteki/narz ˛edzia do rozwi ˛azania problemu danego typu, (iii) u ˙zytkownicy musz ˛a mieć wiedz ˛e techniczn ˛a aby wskazać optymaln ˛a dla swoich potrzeb konfiguracj ˛e zasobu. Po zidentyfikowaniu problemów powstaje pytanie czy jest sposób aby si ˛e z nimi zmierzyć. W jaki sposób wspomóc u ˙zytkownika przy wyborze zasobu do rozwi ˛azania jego problemu lub przechowania danych? U ˙zytkownik mo ˙ze mieć ró ˙zny poziom wiedzy je ˙zeli chodzi o konfiguracj ˛e odpowiadaj ˛ac ˛a jego potrzebom. W takim przypadku jak mo ˙zna ułatwić wybór zasobu? Który dostawca zasobu oferuje najlepsze warunki dla danego zastosowa- nia? Czy jest dost ˛epna metoda/narz ˛edzie rekomendowane dla danego problemu na podstawie wiedzy przechowywanej w systemie?

Kolejn ˛a kwesti ˛a do rozwa ˙zenie jest mo ˙zliwo´sć wykorzystania zasobów gridu i ich mocy obliczeniowej jako ´zródła dochodu dla ich wła´scicieli (dostawców) [1]. W rezultacie, istotnym aspektem projektowania rozwi ˛aza ń na bazie gridu jest integracja z biznesem. W przeciwie ństwie do przetwarzania dobrowolnego (ang. volunteer computing) np. projekt SETI@home, obliczenia dla biznesu musz ˛a być wykonane w okre´slonej kolejno´sci i czasie, monitorowanie i mieć zapewnion ˛a jako´sć (np. ufno´sć w poprawno´sć wyniku). W konsekwencji, systemy gridowe powinny zapewniać pewn ˛a form ˛e zarz ˛adzania SLA (ang. Service Level Agreement; kontrakt pomi ˛edzy dostawc ˛a a u ˙zytkow- nikiem zasobu), które definiuje poziom jako´sci usług (ang. Quality of Service; QoS) na czas trwania kontaktu. Autorzy [3] zidentyfikowali nast ˛epuj ˛ace ograniczenia w zarz ˛adzaniu SLA: (i) brak stan- dardowej, współdzielonej terminologii i struktury kontraktu, (ii) brak wielo-rundowych negocjacji i renegocjacji SLA [4]. Potrzeba uwzgl ˛ednienia SLA w scenariuszach u ˙zytkowania gridu dostarcza dodatkowe obci ˛a ˙zenie dla u ˙zytkowników, którzy musz ˛a przenalizować i wybrać optymalne warunki współpracy. Dla dostawców zasobów pozostaje zagadnienie jak formalnie wyrazić pro- ponowane warunki współpracy.

Podsumowuj ˛ac, mo ˙zna stwierdzi´c ˙ze rozwi ˛azania gridowe s ˛a najlepszymi kandydatami do dostarczenia platform obliczeniowych dla problemów du ˙zej skali. Mo ˙zna zauwa ˙zy´c, ˙ze mimo i ˙z dost ˛epne s ˛a middleware do zarz ˛adzania zasobami gridu, istotnym stało si ˛e dodanie warstwy infrastruktury,

(5)

która pozwoli na u ˙zycie zasobu w “sposób przyjazny u ˙zytkownikowi”. Zagadnienia badawcze w tym obszarze to: (i) zgodnie z sugestiami [5] zastosowanie ontologii do reprezentacji wiedzy i agentów programowych do dostarczenia inteligentnej infrastruktury dla gridu, (ii) wsparcie podczas interakcji z gridem, aby umo ˙zliwić u ˙zytkownikom z minimaln ˛a wiedz ˛a techniczn ˛a efektywne zlecanie zada ń, (iii) wsparcie u ˙zytkownika przy specyfikacji wymaga ń dotycz ˛acych warunków współpracy oraz w trakcie pó´zniejszej analizy ofert.

1.2 Zakres i cel pracy

Przeprowadzone badania, które stanowi ˛a wkład do rozprawy miały na celu zbadania w jaki spo- sób technologie semantyczne, uzupełnione paradygmatem programowania agentowego, mog ˛a zosta´c zastosowane w gridach obliczeniowych do wsparcia u ˙zytkowników. W szczególno´sci, celem pracy jest ustalenie limitów u ˙zyteczno´sci “czystych technologii semantycznych”, oraz zba- danie sposobów powi ˛azania technologii semantycznych z innymi popularnymi metodami (np.

dost ˛epnymi metodami analizy wielokryterialnej). Prowadzone prace obejmowały zaprojektowanie oraz implementacj ˛e mechanizmów wsparcia u ˙zytkownika, które powinny pomóc w efektywnym wykorzystaniu zasobów gridu zgodnie z zagadnieniami z Sekcji 1.1. Rozwa ˙zania te doprowadziły do sformułowania nast ˛epuj ˛acego zadania badawczego:

Przestudiowa´c w jaki sposób i do jakiego stopnia, szeroko poj˛ete, technologie semantyczne mog ˛a zosta´c wykorzystane do wsparcia u˙zytkowników gridów obliczeniownych.

Sformułowane zadanie badawcze nakłada kluczowe wymagania: zaprojektować uniwersalny, se- mantyczny schemat reprezentacji wiedzy (obejmuj ˛acy wiedz ˛e eksperck ˛a) i zaproponować metody wykorzystania tej wiedzy do wsparcia u ˙zytkownika. Celem rozprawy jest analiza w jakich sytuacjach i do jakiego stopnia technologie semantyczne mog ˛a zostać wykorzystane do wspacia u ˙zytkowników. Kontekst dla pracy jest zapewniony przez projekt Agents in Grid (AiG; [6–8]), któ- rego celem było dostarczenie inteligentnego middleware do efektywnego zarz ˛adzania zasobami w gridzie. W AiG uwzgl ˛edniona ró ˙zne metody (równie ˙z wykorzystuj ˛ace wiedz ˛e eksperck ˛a) do pomocy u ˙zytkownikom przy formułowaniu wymaga ń na konfiguracj ˛e zasobu, oraz przy wyborze optymalnych warunków współpracy. W celu zademonstrowania u ˙zyteczno´sci zaproponowanego schematu reprezentacji wiedzy, opracowano i zaimplementowano metody analizy semantycznej, które go wykorzystuj ˛a. Nast ˛epuj ˛ace szczegółowe cele badawcze zostały okre´slone dla pracy:

1. Zaproponować reprezentacj ˛e wiedzy dla gridu oraz wybranej dziedziny (numeryczna algebra liniowa) opart ˛a o ontologie, bior ˛ac ˛a pod uwag ˛e rozszerzalno´sć oraz adaptacyjno´sć.

Zaproponowana metoda powinna umo ˙zliwi´c wykorzystania wiedzy poprzez zastosowanie szeroko poj ˛etych technologii semantycznych.

2. Wybór i zastosowanie technologii semantycznych do wsparcia u ˙zytkownika podczas specyfikacji wymaga ´n dotycz ˛acych zadania i zasobu. Zaproponowana metoda powinna wykorzystywa´c wiedz ˛e dziedzinow ˛a w stopniu odpowiadaj ˛acym potrzebom u ˙zytkownika.

3. Wybór i zastosowanie technologii semantycznych do wyboru optymalnej oferty z warunkami współpracy (kontrakt pomi ˛edzy klientem a dostawc ˛a zasobów).

(6)

Rozdział 2

Zaproponowane rozwi ˛ azanie

2.1 Istota zagadnienia

Cele badawcze 2 i 3 sformułowane dla rozprawy obejmuj ˛a zaproponowanie mechanizmów wspomagania u ˙zytkownika podczas: (i) specyfikacji wymaga ´n dla poszukiwanego zasobu oraz warun- ków współpracy, (ii) wyboru najodpowiedniejszego zasobu oraz oferty współpracy od dostawcy zasobu. Przyj ˛eto zało ˙zenie, ˙ze ka ˙zdy zasób oraz u ˙zytkownik gridu jest reprezentowany przez agenta programowego (zadania s ˛a wykonywane przez zespoły agentów reprezentuj ˛acych zasoby), a cała wiedza jest zamodelowana w postaci ontologii. Scenariusz w ramach którego u ˙zytkownik chce wykorzysta´c zasobów gridowy jest nast ˛epuj ˛acy:

1. U ˙zytkownik okre´sla wymagania dla zasoby (opcjonalnie z profilem zadania - “job profile”) z wykorzystaniem ontologicznego interfejsu u ˙zytkownika, który automatycznie transfor- muje dane wej´sciowe na ich ontologiczn ˛a reprezentacj ˛e. Je ˙zeli powinna zosta´c u ˙zyta wiedza ekspercka, u ˙zytkownik powinien zdefiniowa´c profil zadania, który specyfikuje (w jak najwi ˛ekszym mo ˙zliwym stopniu) problem – metod ˛e/algorytm – wła´sciwo´sci danych wej´sciowych [9].

2. LAgent (agent programowy reprezentuj ˛acy u ˙zytkownika w cz ˛e´sci back-end systemu wielo- agentowego) odpytuje CIC (Client Information Center) o list ˛e zespołów posiadaj ˛acych zasoby pasuj ˛ace do wymaga ´n. Je ˙zeli wcze´sniej zostało to wskazane, LAgent u ˙zywa jednej z metod analizy semantycznej, ˙zeby wspomóc u ˙zytkownika w specyfikacji wymaga ´n (Decision support - step 1).

3. Lista zespołów posiadaj ˛acych zasoby spełniaj ˛ace wymagania (lub pusta lista) zostaje zwró- cona do u ˙zytkownika, który pó´zniej, eliminuje z listy zespoły uznane za nie wystarczaj ˛aco wiarygodne.

4. U ˙zytkownik specyfikuje wymagania odno´snie kontraktu (opisuj ˛acego warunki współpracy z dostawc ˛a zasobu) np. maksymaln ˛a akceptowaln ˛a cen ˛e, kar ˛e za opó´znienie, warunki na czas wykonania. LAgent komunikuje si ˛e z “zespołami zasobów” i wysyła propozycje kontraktów.

4

(7)

5. LAgent analizuje i ocenia oferty kontraktów i wybiera jedn ˛a, je ˙zeli warunki w niej zawarte s ˛a akceptowalne (Decision support - step 2).

Aby wspomóc u ˙zytkownika podczas selekcji, zostało zaproponowanych kilka metod. W zale ˙zno-

´sci od do´swiadczenia u ˙zytkownika wsparcie mo ˙ze zosta´c ograniczone do prostego odpytywania o zasoby w oparciu o SPARQL, dopasowywania z wykorzystaniem wyra ˙ze ´n klasowych (ang.

class expression matching), dopasowywania grafowego (ang. graph-based matching) oraz najbardziej zaawansowanego mechanizmu opartego o analiz ˛e wielokryterialn ˛a i eksperck ˛a wiedz ˛e dziedzinow ˛a. W ramach zaproponowanych podej´s´c nakre´slone zostaje gdzie u ˙zycie analizy semantycznej mo ˙ze pomóc, a w jakich sytuacjach powinno zosta´c poł ˛aczone z innymi metodami.

Uzyskane wyniki, mog ˛a zosta´c uogólnione poza obszar oblicze ´n gridowych. W pierwszej kolejno-

´sci mo ˙zna zało ˙zyć, ˙ze u ˙zytkownik jest “wszechwiedz ˛acy”. W tym przypadku wymagane wsparcie dla u ˙zytkownika ogranicza si ˛e do wyszukania zasobu, który spełnia jego wymagania, i pozwala na u ˙zycie prostych metod do odpytywania bazuj ˛acych na zapytaniach SPARQL oraz DL (z wykorzystaniem wyra ˙ze ń klasowych) z reasoner’em semantycznym. Po tym jak u ˙zytkownik okre´sli dokładnie to czego chce, otrzymuje list ˛e zasobów które pasuj ˛a do jego wymaga ń. Wynikowa lista jest nieuporz ˛adkowana i nie ma sposobu na wskazanie priorytetów dotycz ˛acych kryteriów wyboru. Je ˙zeli w systemie nie ma zasobu który pasuje do wymaga ń, zapytanie nie zwróci rezultatu.

Kiedy do dopasowania wykorzystywana jest metoda grafowa, istnieje mo ˙zliwo´s´c uchwycenia wiedzy eksperckiej, która wyra ˙zona jest w postaci “wag” nało ˙zonych na relacje pomi ˛edzy poj ˛eciami.

Uzyskana lista zasobów jest uporz ˛adkowana zgodnie z blisko´sci ˛a semantyczn ˛a pomi ˛edzy opisem zasobu a oczekiwaniami u ˙zytkownika. To podej´scie, ró ˙zni si ˛e od poprzedniego tym, ˙ze nie powinna nast ˛apić sytuacja gdy ˙zaden zasób nie zostanie zwrócony, poniewa ˙z mo ˙zna zało ˙zyć ˙ze wszystkie instancje, we wspólnej ontologii, s ˛a powi ˛azane ze sob ˛a poj ˛eciowo. Przy dopasowywaniu w oparciu o metod ˛e grafow ˛a, uwzgl ˛ednione jest zało ˙zenie, ˙ze u ˙zytkownik ma wiedz ˛e pozwalaj ˛a mu na wyra ˙zanie swoich preferencji. Ostatecznie, poł ˛aczenie analizy wielokryterialnej z technologiami semantycznymi pozwala na “udzielanie rekomendacji”. Uwzgl ˛ednienie wielu opinii eksperckich, pozwala na zapewnienie zaawansowanego wsparcia u ˙zytkownika przy formułowaniu wymaga ń.

W tym przypadku, istotne staje si ˛e zagadnienie w jaki sposób uchwycić i aktualizować wiedz ˛e eksperck ˛a. Nale ˙zy zauwa ˙zyć, ˙ze wspomniane podej´scia odpowiadaj ˛a ró ˙znym stopniom wykorzystania technologii semantycznych do wsparcia u ˙zytkownika.

2.2 Reprezentacja eksperckiej wiedzy dziedzinowej

Ze wspomnianego scenariusza mo ˙zna wywnioskować, ˙ze aby efektywnie wspierać u ˙zytkownika w okre´slaniu wymaga ń na zasób (np. zainstalowane oprogramowanie) potrzebny do rozwi ˛azania danego problemu, istotnym jest zaprojektowanie odpowiedniego sposobu do reprezentacji (i przechowywania) eksperckiej wiedzy dziedzinowej. Taka reprezentacja powinna umo ˙zliwić intuicyjne definiowanie profilu zada ń i wydajne wyszukiwanie z po´sród zgromadzonych opinii eksperckich/rekomendacji, dla kombinacji problemu oraz wła´sciwo´sci danych wej´sciowych.

Zgodnie z zało ˙zeniem o semantycznym przetwarzaniu danych, oraz w celu wsparcia u ˙zytkownika, opracowany został zestaw ontologii [10, 11]: (i) AiG Grid Ontology - klasy i wła´sciwo´sci do opisu

(8)

6

struktury gridu i konfiguracji zasobów, (ii) AiG Conditions Ontology - klasy i wła´sciwo´sci do opisu warunków współpracy, (iii) AiG Messaging Ontology - zawarto´s´c wiadomo´sci wymienianych pomi ˛edzy komponentami w systemie, (iv) AiG Expert Ontology - klasy i wła´sciwo´sci do opisu wiedzy eksperckiej i dziedzinowej. Projekt struktury ontologii eksperckiej i dziedzinowej (AiG Expert Ontology) stanowi jeden z celow badawczych rozprawy, podczas gdy pozostałe ontologie s ˛a równie ˙z wykorzystywane w AiG i stanowi ˛a kontekst dla celów badawczych. Do weryfikacji zaproponowanego sposobu reprezentacji wiedzy zamodelowana została dziedzina obliczeniowej algebry liniowej.

Podstawowe poj ˛ecia wspólne dla wielu dziedzin uwzgl ˛ednione zostały w AiG Expert Ontology:

(i) Domain - identyfikuj ˛e dziedzin ˛e, która jest modelowana; (ii) Problem - reprezentuje problemy z danej dziedziny w hierarchicznej strukturze; (iii) Algorithm - reprezentuje algorytmy/metody w hierarchicznej strukturze, które mog ˛a zosta´c wykorzystane do rozwi ˛azania problemów z modelowanej dziedziny; (iv) Data Element - typ danych wej´sciowych dla algorytmów funkcjonuj ˛acych w danej dziedzinie. Dodatkowe poj ˛ecia pozwalaj ˛ace na opisanie wiedzy eksperckiej z danej dziedziny to: (i) Data Property - hierarchia wła´sciwo´sci przy pomocy których mo ˙zna opisa´c dane wej´sciowe;

(ii) Domain Expert - poj ˛ecie reprezentuj ˛ace eksperta (człowiek lub system) który wprowadza rekomendacji w ramach modelowanej dziedziny; (iii) Job Profile - kluczowe poj ˛ecie do realizacji dopasowywania z wykorzystaniem wiedzy dziedzinowej, pozwalaj ˛ace na zamodelowanie profilu zadania do wykonania poprzez powi ˛azanie instancji klas Problem, Algorithm, Data Element, Expert Opinion; (iv) Expert Opinion - poj ˛ecie reprezentuj ˛ace rekomendacj ˛e eksperck ˛a poprzez powi ˛azanie instancji klas JobProfile and Grid Entity, pozwalaj ˛ace na zamodelowane relacji pomi ˛edzy profilem zadania i zalecanej dla niego przez eksperta konfiguracji zasobu.

W eksperckiej ontologii dziedzinowej mo ˙zna wyró ˙znić dwie cz ˛e´sci – model generyczny i model dziedzinowy. Jednym z kluczowych aspektów wiedzy dziedzinowej jest hierarchia problemów funkcjonuj ˛acych w jej ramach. Naturalnie, problemy mog ˛a zostać uporz ˛adkowane w postaci hierarchii, w której ni ˙zsze poziomy s ˛a podproblemami lub uszczegółowieniami problemów na wy ˙zszych poziomach. Po zidentyfikowani głównych problemów, nale ˙zy zidentyfikować metody które mog ˛a zostać u ˙zyte do ich rozwi ˛azania. Analogicznie, mog ˛a one zostać uporz ˛adkowane w postaci hierarchii. Aby być w stanie wskazać która metoda/algorytm jest rekomendowany do rozwi ˛azania którego problemu nale ˙zy zamodelować równie ˙z wła´sciwo´sci danych wej´sciowych. Specyfikacja wła´sciwo´sci danych wej´sciowych poprzez u ˙zytkowników zlecaj ˛acych zadania oraz ekspertów pozwala na lepsze dopasowanie profili zada ń do rekomendacji eksperckich zapisanych w postaci ontologii.

2.3 Wsparcie u˙zytkownika z wykorzystaniem semantycznego prze- twarzania danych

Tak jak zostało wspomniane w Sekcji 2.1 wsparcie u ˙zytkownika mo ˙ze zostać podzielone na dwa etapy - pierwszy, gdy u ˙zytkownik okre´sla wymagania wzgl ˛edem zasobu, oraz drugi, gdy nale ˙zy wybrać najlepsz ˛a ofert ˛e współpracy z dostawc ˛a zasobu. Te dwa etapy s ˛a niezale ˙zne i mog ˛a wykorzystywać t ˛a sam ˛a lub ró ˙zne metody analizy semantycznej. W rozprawie uwzgl ˛edniono

(9)

cztery metody, u ˙zycie których jest determinowane potrzebami oraz poziomem wiedzy u ˙zytkownika gridu.

Wybór zasobu z wykorzystaniem zapyta ń SPARQL. Pierwsza metoda analizy semantycznej, która mo ˙ze zostać u ˙zyta do wsparcia bardziej zaawansowanego u ˙zytkownika jest oparta o zapytania SPARQL. SPARQL stanowi zestaw specyfikacji definiuj ˛acych j ˛ezyki i protokoły do manipulowania grafami RDF. W tym przypadku, zapytanie SPARQL zostanie u ˙zyte do dopasowania wymaga ń u ˙zytkownika do specyfikacji dost ˛epnych zasobów. Zapytania SPARQL s ˛a elastyczne przy specyfikacji warunków i filtrów, jednak ˙ze u ˙zytkownik powinien znać wewn ˛etrzn ˛a struktur ˛e odpytywanej ontologii.

Wybór zasobu z wykorzystaniem wyra˙ze ń klasowych. Kolejne podej´scie do zapewnienia wspar- cia u ˙zytkownikowi wykorzystuje zapytania DL poprzez wyra ˙zenia klasowe. Ten mechanizm mo ˙ze zostać wykorzystany przy wyborze zasobu. W OWL 2, wyra ˙zenia klasowe s ˛a konstruowane za pomoc ˛a klas i wyra ˙ze ń z restrykcjami na wła´sciwo´sci, które pozwalaj ˛a na okre´slanie zbiorów instancji. Klasa OWL mo ˙ze zostać zdefiniowana przy pomocy wyra ˙zenia klasowego wraz z asercj ˛a,

˙ze wskazana klasa nazwana jest równowa ˙zna jakie´s nazwanej b ˛ad´z nienazwanej klasie opisanej wyra ˙zeniem. Dopasowywanie w oparciu o wyra ˙zenia klasowe jest naturalne w przypadku AiG, poniewa ˙z interfejs u ˙zytkownika automatycznie generuje fragment ontologii OWL z wyra ˙zeniem klasowym opisuj ˛acym wymagania u ˙zytkownika. Takie wyra ˙zenie jest nast ˛epnie u ˙zyte do wnioskowania o instancjach które do niego pasuj ˛a.

Wybór zasobu i kontraktu z wykorzystaniem podej´scia grafowego. Podej´scie z wykorzystaniem algorytmów grafowych mo ˙zna wykorzysta´c w krokach Decision support - step 1 oraz Decision support - step 2. Bazuje ono algorytmie opisanym w [12] (po odpowiednich adaptacjach), który wykorzystuje fakt, ˙ze w przestrzeni wiedzy (ang. knowledge space) wszystkie zasoby informacyjne s ˛a powi ˛azane po´srednio lub bezpo´srednio. Co wi ˛ecej, ró ˙zne relacje pomi ˛edzy obiektami mog ˛a mie´c ró ˙zn ˛a moc.

Istnienie i siła relacji powinna by´c brana pod uwag ˛e podczas oceniania w jaki sposób dwie klasy- /instancje s ˛a ze sob ˛a powi ˛azane. W tym celu wprowadzono poj ˛ecie semantycznej blisko´sci (ang.

semantic closeness) oraz semantycznego pokrewie ństwa (ang. semantic relevance). Semantyczne pokrewie ństwo bazuje na ró ˙znorodnych bezpo´srednich relacjach, które mo ˙zna zidentyfikować w przestrzeni wiedzy, oraz po´srednich relacjach które s ˛a dostarczane przez kontekst. Aby móc wyko- rzystywać zgromadzon ˛a wiedz ˛e w sposób efektywny, struktura dla przestrzeni wiedzy powinna najpierw zostać zaproponowana na poziomie koncepcyjnym, a nast ˛epnie poszczególne obiekty informacyjne zostan ˛a w ramach niej zamodelowane. Naturalnie, ontologie zapewniaj ˛a dogodn ˛a formaln ˛a struktur ˛e do reprezentowania wiedzy. W szczególno´sci, ka ˙zda ontologia mo ˙ze być zapre- zentowana jako graf skierowany, w którym klasy/instancje s ˛a w ˛ezłami a kraw ˛edzie reprezentuj ˛a wła´sciwo´sci (które stanowi ˛a odpowiednik kryteriów decyzyjnych w procesie wyboru). Grafy mog ˛a zostać wygenerowane na poziomie koncepcyjnym (T-Box) i poziomie instancji (A-Box). Na poziomie koncepcyjnym, w ˛ezły to klasy (poj ˛ecia) a kraw ˛edzie odpowiadaj ˛a aksjomatom dotycz ˛acym wła´sciwo´sci (bez uwzgl ˛edniania instancji). Na poziomie instancji w ˛ezły odpowiadaj ˛a instancjom klas a kraw ˛edzie asercjom dotycz ˛acym wła´sciwo´sci dla uwzgl ˛ednionych instancji. Nale ˙zy podkre´slić, ˙ze to podej´scie do zapewnienia wsparcia u ˙zytkownikowi pozwala uchwycić: preferencje u ˙zytkownika i wiedz ˛e eksperck ˛a. Wiedza ekspercka mo ˙ze (ale nie musi) być uwzgl ˛edniona na

(10)

8

poziomie koncepcyjnym gdzie ka ˙zda kraw ˛ed´z mo ˙ze mieć przypisan ˛a “odległo´sć”, która jest od- wrotnie proporcjonalna do podobie ństwa pomi ˛edzy dwoma s ˛asiednimi w ˛ezłami. Preferencje u ˙zytkownika (wynikaj ˛ace z jego do´swiadczenia) mog ˛a zostać wł ˛aczone do analizy poprzez przypisanie wag do kraw ˛edzi (skalowanie kraw ˛edzi) na poziomie instancji.

Wybór zasobu i kontraktu z wykorzystaniem MCA. Ostatnie uwzgl ˛ednione w rozprawie podej-

´scie wykorzystuje analiz ˛e wielokryterialn ˛a (MCA), która jest stosowana do rozwi ˛azywania wielu praktycznych problemów i ma za sob ˛a dług ˛a histori ˛e bada ń. Jednak ˙ze, wraz z rosn ˛acym zainte- resowaniem technologiami semantycznymi, nale ˙zy udzielić odpowiedzi na nowe pytanie: czy jest mo ˙zliwe zastosowanie metody analizy wielokryterialnej w scenariuszu, w którym wiedza u ˙zyta w procesie decyzyjnym jest formalnie zapisana w postaci ontologii? W takim przypadku, wybrana metoda powinna “wykorzystywać w pełni” sposób reprezentacji wiedzy. Co nast ˛epuje, ka ˙zda metoda MCA, zastosowanie której zmusza do “spłaszczenia” hierarchicznej struktury ontologii (zakłada ˙ze wszystkie kryteria odpowiadaj ˛ace wła´sciwo´sciom s ˛a traktowane jednakowo), nie jest brana pod uwag ˛e (see, also [13]).

Nast ˛epuj ˛ace kroki opisuj ˛a sposób formułowania problemu i wsparcie u ˙zytkownika:

1. Eksperci przygotowuj ˛a swoje rekomendacje, które stanowi ˛a powi ˛azanie pomi ˛edzy proble- mem, własno´sciami danych wej´sciowych, sugerowan ˛a metod ˛a rozwi ˛azania problemu oraz zalecan ˛a konfiguracj ˛e zasobu. Dost ˛epne opinie eksperckie (jako odr ˛ebne “byty”) składaj ˛a si ˛e na repozytorium eksperckiej wiedzy dziedzinowej (ontologia ekspercka). Wiarygodno´sć opinii jest wyra ˙zana przy pomocy wag, które mog ˛a być przypisane ekspertom. Dodatkowo, eksperci powinni mieć mo ˙zliwo´sć przypisania wag do wła´sciwo´sci, które s ˛a wykorzystane w definicji opinii eksperckiej np. dla danego problemu, w zalecanym zasobie, ilo´sć rdzeni jest znacznie istotniejsza ni ˙z pr ˛edko´sć zegara.

2. U ˙zytkownik gridu, który chce wykonać okre´slone zadanie obliczeniowe i wykorzystać rekomendacje eksperckie, w pierwszym kroku definiuje profil zadania (problem, i na ile to mo ˙z- liwe własno´sci danych wej´sciowych, oraz metod ˛e, któr ˛a chce wykorzystać do rozwi ˛azania zadania). Je ˙zeli u ˙zytkownik posiada odpowiedni ˛a wiedz ˛e to równie ˙z konfiguracj ˛e wymaga- nego zasobu.

3. Bazuj ˛ac na profilu zadania, który zdefiniował u ˙zytkownik, jego agent wybiera z repozytorium (zawieraj ˛acego wiedz ˛e eksperck ˛a) opinie pasuj ˛ace do profilu. Je ˙zeli nie ma opinii pasuj ˛acych do profilu, u ˙zytkownik nie otrzyma ˙zadnych rekomendacji, a wymagania inicjalnie okre´slone przez u ˙zytkownika powinni zosta´c wykorzystane w kolejnych krokach.

4. Je ˙zeli dost ˛epne s ˛a opinie eksperckie pasuj ˛ace do profilu zadania, wykonywana jest analiza wielokryterialna. System analizuje opinie aby wybra´c “reprezentatywn ˛a” dla danego problemu. Ocena jest wykonywana bez potrzeby interakcji z ekspertami (automatycznie), jednak ˙ze opinie eksperckie s ˛a analizowane “z perspektywy eksperta”. Wybrana opinia jest konfrontowana z oryginalnym profilem zadania.

5. W efekcie, trzy sytuacje s ˛a mo ˙zliwe: (i) wymagania u ˙zytkownika pasuj ˛a do rekomendacji eksperckich; (ii) u ˙zytkownik nie doprecyzował wymaga ´n, a system mo ˙ze pomóc mu w ich doprecyzowaniu np. u ˙zytkownik okre´slił problem i wła´sciwo´sci danych wej´sciowych, ale nie

(11)

wie której metody najlepiej u ˙zy´c do rozwi ˛azania problemu; (iii) wymagania u ˙zytkownika nie s ˛a poprawne (z perspektywy dost ˛epnych opinii eksperckich); w takiej sytuacji alternatywne opinie mog ˛a zosta´c wybrane z repozytorium np. rekomendacja wskazuj ˛aca na inny algorytm lub konfiguracj ˛e zasobu.

Naturalnie, ta sama metoda MCA mo ˙ze zostać u ˙zyta w krokach Decision support - step 1 oraz De- cision support - step 2. Preferowana metoda MCA powinna mieć nast ˛epuj ˛ace cechy: (i) pozwalać na u ˙zycie wiedzy pochodz ˛acej od wielu ekspertów, którzy mog ˛a mieć przypisane ró ˙zne wagi np.

opinia studenta nie jest równowa ˙zna opinii profesora; (ii) pozwala´c na u ˙zycie wielu hierarchicznie uło ˙zonych kryteriów, które maj ˛a przypisane wagi np. preferencje u ˙zytkownika wskazuj ˛a, ˙ze cena jest istotniejsza od terminu wykonania zadania; (iii) wspiera´c fakt, ˙ze hierarchiczna struktura alternatyw jest ró ˙znorodna – ró ˙zne drzewa odpowiadaj ˛ace ró ˙znym zestawom wła´sciwo´sci wybranych ze wspólnej ontologii.

Jednym z kluczowych wyzwa ń przy projektowaniu mechanizmów wspomagania u ˙zytkownika, które poł ˛acz ˛a technologie semantyczne z analiz ˛a wielokryterialn ˛a, jest wybór odpowiedniej tech- niki MCA. Podczas wst ˛epnych rozwa ˙za ń przedstawionych w [13] metody, które wydawały si ˛e odpowiednie do wykorzystania w scenariuszu zlecania zadania do wykonania zostały przeana- lizowane zgodnie z metodologi ˛a z [14]. Zawierały one: TOPSIS ([15]), PROMETHEE ([16]), GRIP ([17]), oraz Analytical Hierarchy Process (AHP; [18]). Dodatkowo, weighted sum method (WSM), weighted product method (WPM), MAUT (multi-attribute utility theory; np. SMART, SMARTS, SMARTER) zostały uwzgl ˛ednione. Ewaluacja potwierdziła ˙ze TOPSIS, PROMETHEE, GRIP i AHP stanowi ˛a dobrych kandydatów do wyboru ostatecznej metody. Przede wszystkim, ich cechy odpowiadaj ˛a wst ˛epnym wymaganiom nało ˙zonym na metod ˛e (mog ˛a zostać u ˙zyte/dostosowane do u ˙zycia z ontologiami, oraz wspieraj ˛a wiele kryteriów oraz decydentów), s ˛a dobrze ugrunto- wane i powszechnie u ˙zywane, a ka ˙zda z metod reprezentuje inne podej´scie do przeprowadzania analizy wielokryterialnej. Jednak ˙ze, naturalne wsparcie dla cech ontologii (np. zastosowanie po- równa ń parami zgodnie ze struktur ˛a hierarchiczn ˛a pasuje do wiedzy sformalizowanej w postaci ontologii) i semantycznego przetwarzania danych, oraz czytelna interakcja z decydentem (np.

podczas specyfikacji wymaga ń), doprowadziły do wyboru AHP jako metody zaadaptowanej i za- implementowanej do weryfikacji podej´scia zaproponowanego w rozprawie. Nale ˙zy podkre´slić, ˙ze ka ˙zda inna metoda spełniaj ˛aca powy ˙zsze wymagania mo ˙ze zostać zaadaptowana do u ˙zycia razem z ontologiczn ˛a reprezentacj ˛a wiedzy i semantycznym przetwarzaniem. W szczególno´sci, metoda do oceny alternatyw mo ˙ze być wymieniona, podczas gdy reprezentacja wiedzy, wymaga ń i problemu pozostanie taka sama, natomiast w razie potrzeby struktura problemu decyzyjnego b ˛edzie musiała być dostosowana.

Metoda AHP okre´sla kolejne kroki, które prowadz ˛a do wyboru optymalnego wariantu (alternatywy) bior ˛ac pod uwag ˛e oceny pochodz ˛ace od wielu ekspertów. Procedura AHP mo ˙ze zosta´c podzielona na trzy fazy. Pierwsze dwie s ˛a uwzgl ˛ednione w trakcie projektowania, podczas gdy zbierane s ˛a informacje o decyzji i czynnikach, które na ni ˛a wpływaj ˛a, oraz ekspertach, którzy b ˛ed ˛a w stanie oceni´c alternatywy.

Wybór kryteriów oceny. W rozwa ˙zanym scenariuszu, zestaw kryteriów jest determinowany przez wła´sciwo´sci dost ˛epne w ontologiach (AiG Expert Ontology oraz AiG Grid Ontology przy wyborze zasobu, AiG Conditions Ontology przy wyborze warunków współpracy). Podczas wyboru

(12)

10

reprezentatywnej rekomendacji eksperckiej czyli instancji klasy exp:ExpertOpinion (w kroku Deci- sion support - step 1), kryteria odpowiadaj ˛a wła´sciwo´sciom OWL z dziedzin ˛a exp:ExpertOpinion, a podkryteria wła´sciwo´sci ˛a klas które s ˛a w zasi ˛egu wcze´sniej wybranych wła´sciwo´sci.

Wybór ekspertów. W przypadku wykorzystania wiedzy eksperckiej, zbiór zarejestrowanych eksper- tów, którzy mog ˛a zosta´c wykorzystani podczas ewaluacji jest okre´slany w momencie wyszukiwa- nia instancji klasy exp:JobProfile, które pasuj ˛a do profilu zadania okre´slonego przez u ˙zytkownika.

Nale ˙zy uwzgl ˛edni´c sytuacj ˛e, w której rekomendacje ró ˙znych ekspertów maj ˛a ró ˙zn ˛a wag ˛e. Waga ka ˙zdego eksperta jest wyliczana z macierzy preferencji, analogicznie do wyliczania wag dla kryte- riów decyzyjnych (opisane poni ˙zej).

Ewaluacja ilo´sciowa. Ewaluacja ilo´sciowa w AHP mo ˙ze zostać rozło ˙zona na kilka kroków. Celem tej fazy jest numeryczna ocena alternatyw oraz ustanowienie rankingu zgodnie ze stopniem w jakim odpowiadaj ˛a one preferencjom u ˙zytkownika. Nale ˙zy zauwa ˙zyć, ˙ze preferencje i czynniki wpływaj ˛ace na decyzj ˛e mog ˛a zostać zamodelowane w postaci hierarchii, takiej ˙ze korze ń odpo- wiada celowi (opinia ekspercka w Decision support - step 1, oferta kontraktu w Decision support - step 2). Poziom pod korzeniem zawiera główne czynniki/kryteria wpływaj ˛ace na decyzj ˛e, poni ˙zsze poziomy zawieraj ˛a podczynniki/podkryteria od których s ˛a one zale˙zne, a˙z do najni˙zszego poziomu z najbardziej detalicznymi kryteriami. Konstrukcja drzew decyzyjnych jest wykonywana na podstawie klasy OWL lub wyra ˙zenia klasowego z wykorzystaniem faktu, ˙ze ontologi ˛e mo ˙zna przedstawić jako graf skierowany. Korze ń takiego drzewa odpowada celowi decyzji i reprezentuje instancj ˛e exp:ExpertOpinion lub cond:JobExecutionCondition (w zale ˙zno´sci od kontekstu). Czynniki (kryteria) na najwy ˙zszym poziomie odpowiadaj ˛a wła´sciwo´sci ˛a OWL z dziedzin ˛a b ˛ed ˛ac ˛a jedn ˛a z tych dwóch klas. W kolejnym kroku nale ˙zy skonstrukować macierze porównawcze dla kryte- riów na poszczególnych poziomach z których wyznaczane s ˛a wagi dla kryteriów. Je ˙zeli istnieje wielu ekspertów zaanga ˙zowanych w konstrukcj ˛e bazy eksperckiej wiedzy dziedzinowej to nale ˙zy skonstrukować macierze porównawcze dla ekspertów i na ich podstawie wyznaczyć wagi analogicznie jak w przypadku kryteriów. Ostatecznie, ostatni krok to numeryczna ewaluacja alternatyw (instancji klas exp:ExpertOpinion lub exp:JobExecutionCondition) z perspektywy decydentów.

W przypadku Decision support - step 1, po dokonaniu wyboru, opinia ekspercka jest porównywana z pocz ˛atkowymi wymaganiami wprowadzonymi przez u ˙zytkownika. Trzy sytuacje s ˛a mo ˙zliwe:

(i) rozszerzenie - sugestia dotycz ˛aca np. algorytmu/metody, która mo˙ze zostać wykorzystana do rozwi ˛azania problemu przy danych wej´sciowych o wskazanych wła´sciwo´sciach; wskazanie do- datkowych wymaga ń na konfiguracj ˛e zasobu; (ii) modyfikacja - je ˙zeli znaleziono rekomendacj ˛e eksperck ˛a dla kombinacji problemu – algorytmu – danych wej´sciowych, jednak ˙ze wymagania okre´slone przez u ˙zytkownika s ˛a inne od tych w reprezentatywnej rekomendacji to powinna zo- stać zasugerowana modyfikacja wymaga ń wprowadzonych przez u ˙zytkownika; (iii) wskazanie alternatyw - je ˙zeli nie znaleziona rekomendacji dla kombinacji problemu – algorytmu – danych wej´sciowych, to alternatywne (cz ˛e´sciowo pasuj ˛ace) rekomendacje powinny zostać zwrócone.

Pomimo ˙ze, omówienie podej´scie zakłada wykorzystanie AHP jako metody analizy wielokryterialnej, ka ˙zda inna metoda która spełnia wymagane warunki mo ˙ze zostać wykorzystana. W takim przypadku, procedura do wyznaczania wag i porównywania alternatyw ulegnie zmianie. Stopie ń w którym metoda spełnia postawione wymagania, wpływa na “jako´sć” integracji.

(13)

Uwagi ko ´ncowe

Podsumowuj ˛ac, poni ˙zej omówione zostały główne wyniki uzyskane w pracy. Po pierwsze, zapro- ponowany został oryginalny, generyczny i oparty na ontologii schemat do reprezentacji wszystkich aspektów wiedzy potrzebnej do u ˙zytkowania gridów obliczeniowych. Ontologiczny model kon- cepcyjny (T-Box) definiuje poj ˛ecia ogólne potrzebne do zamodelowania: (i) wiedzy eksperckiej np.

rekomendacji, (ii) samej dziedziny wiedzy. Zaproponowana metoda reprezentacji wiedzy dziedzinowej wspiera rozszerzalno´s´c oraz adaptacyjno´s´c.

W ramach przeprowadzonej analizy, zidentyfikowane zostały sytuacje w których u ˙zytkownik gridu mo ˙ze skorzystać ze wsparcia od systemu. Poni ˙zej, podsumowane zostały cztery podej´scia uwzgl ˛ednione w pracy, które odnosz ˛a si ˛e do ró ˙znych przypadków u ˙zycia gridu. Pierwsze podej´scie bazuje na wykorzystaniu zapyta ń SPARQL do dopasowania wymaga ń u ˙zytkownika do konfiguracji zasobów dost ˛epnych w gridzie. W tym podej´sciu u ˙zytkownik jest traktowany jako dobrze znaj ˛acy problem i specyfikacj ˛e zasobu, który jest mu potrzebny do jego rozwi ˛azania. U ˙zytkownik szuka zasobów, które spełniaj ˛a jego wymagania, ale nie ma potrzeby tworzenie rankingu zgodnie ze stopniem ich dopasowania (sam dokonuje ostatecznego wyboru w oparciu o własne do´swiad- czenie). Ka ˙zdy zasób spełniaj ˛acy kryteria jest dla u ˙zytkownika akceptowalny. W tym podej´sciu, zapytania mog ˛a być kierowane bezpo´srednio do ontologii w której została opisana struktura gridu, lub ewentualnie równie ˙z do eksperckiej ontologii dziedzinowej (wykorzystywanej w podej´sciu bazuj ˛acym na MCA). Zapytanie o zasób mo ˙ze być równie ˙z wykonywane za po´srednictwem systemu AiG. W tym przypadku, od u ˙zytkownika wymagana jest znajomo´sć struktury ontologii, aby był w stanie formułować “dobre pytania”. Co wi ˛ecej, w tym podej´sciu nie ma wsparcia w formie rekomendacji. Korzy´sci ˛a tego podej´scia jest wykorzystanie ontologicznej reprezentacji wiedzy i najbardziej standardowego sposobu pracy z ontologiami czyli wykonywania zapyta ń SPARQL.

Drugie podej´scie bazuje na wyra ˙zeniach klasowych OWL które s ˛a wykorzystywane w zapytaniach DL. Podej´scie to jest dedykowane u ˙zytkownikom o takim samym profilu jak podej´scie pierwsze.

Ta metoda równie ˙z mo ˙ze zostać u ˙zyta do dopasowania wymaga ń u ˙zytkownika oraz konfiguracji dost ˛epnych zasobów. W tym przypadku, równie ˙z, uzyskana lista zasobów nie jest uporz ˛adkowana zgodnie ze stopniem dopasowania. Dzi ˛eki wykorzystaniu ontologicznego interfejsu u ˙zytkownika (poza zakresem rozprawy) mo ˙zna automatycznie wygenerować wyra ˙zenia klasowe reprezentuj ˛ace wymagania, i sprawić, ˙ze interakcja z ontologi ˛a jest “bardziej przyjazna u ˙zytkownikowi”. Co

11

(14)

12

wi ˛ecej, wyra ˙zenia klasowe OWL pozwalaj ˛a w łatwy sposób wyrazić warunki graniczne (maksi- mum, minimum). Implementacja tego podej´scia wymaga wykorzystania reasoner’ów (silników wnioskuj ˛acych), które domy´slnie zakładaj ˛a wykonanie klasyfikacji ontologii i inferencji nowych aksjomatów/asercji, dzi ˛eki czemu w pełni wykorzystuj ˛a mo˙zliwo´sci jakie daje semantyczne prze- twarzanie danych. W ko ńcu, tak jak w przypadku podej´scia ze SPARQL, u ˙zytkownik nie uzyskuje rekomendacji. W konsekwencji, u ˙zytkownik powinien wiedzieć jakich zasobów je ˙zeli chodzi o konfiguracj ˛e potrzebuje do wykonania zadania, i która metoda jest najlepsza do rozwi ˛azania problemu.

Trzecie zaproponowane podej´scie wykorzystuje algorytmy grafowe do dopasowania w oparciu o wyliczenie semantycznej blisko´sci pomi ˛edzy instancjami zdefiniowanymi w ontologii. To podej´scie jest dedykowane u ˙zytkownikom, którzy znaj ˛a problem i wymagania, ale maj ˛a preferencje je ˙zeli chodzi o kryteria u ˙zyte przy wyborze. Co wi ˛ecej, u ˙zytkownicy mog ˛a chcieć skorzystać z wag przypisanych do kryteriów, które zostały wskazane przez ekspertów. To podej´scie mo ˙ze zo- stać wykorzystane do zaimplementowania wyboru zarówno zasobu jak i kontraktu, okre´slaj ˛acego warunki współpracy. Blisko´sć semantyczna jest mierzona pomi ˛edzy instancjami w ontologii, co powoduje, ˙ze wymagania od u ˙zytkownika powinny zostać zamodelowane jako instancja. W konsekwencji, specyfikacja wymaga ń jest bardziej “sztywna”, natomiast mo ˙zna wykorzystać wiedz ˛e eksperck ˛a w sposób bardziej wyszukany. Waga dla relacji na poziomie koncepcyjnym mo ˙ze być dodana do ontologii, natomiast waga dla relacji pomi ˛edzy instancjami mo ˙ze być uwzgl ˛edniona w przypadku konkretnych zdefiniowanych wymaga ń. Istotno´sć relacji wyra ˙zona na poziomie koncepcyjnym powinna zostać okre´slona przez ekspertów, którzy s ˛a w stanie ocenić które cechy opisu zasobu lub kontraktu s ˛a istotniejsze ni ˙z inne. Te warto´sci s ˛a re-u ˙zywane pomi ˛edzy wszyst- kimi wykonaniami algorytmów. Przypisane do relacji wagi umo ˙zliwiaj ˛a skalowanie odległo´sci (reprezentuj ˛acych wa ˙zno´sć z modelu koncepcyjnego) zgodnie z preferencjami u ˙zytkownika w ka ˙zdym wykonaniu algorytmu. W podej´sciu grafowym, w przeciwie ństwie do poprzednich, uzyskana lista zasobów jest uporz ˛adkowana zgodnie ze stopniem dopasowania, i istnieje mo ˙zliwo´sć wyra ˙zenia preferencji wzgl ˛edem kryteriów na poziomie globalnym, oraz na poziomie instancji per wykonanie. Mechanizm wsparcia u ˙zytkownika, nie daje konkretnych rekomendacji, ale pozwala wpływać na proces selekcji i uwzgl ˛edniać wiedz ˛e eksperck ˛a podczas dopasowywania. U ˙zytkownik gridu w dalszym ci ˛agu powinien wiedzieć jaki zasób lub kontrakt jest przez niego wymagany, oraz jak ˛a metod ˛e preferuje do rozwi ˛azania problemu, natomiast ma mo ˙zliwo´sć wskazania, ˙ze np.

czas wykonania jest dla niego najistotniejszy przy wyborze warunków współpracy.

Ostatnie i najbardziej wyszukane podej´scie bazuje na wykorzystaniu analizy wielokryterialnej.

Jest ono dedykowane u ˙zytkownikom, którzy nie s ˛a pewni jakiej metody/narz ˛edzia chc ˛a u˙zyć do rozwi ˛azania problemu, i nie wiedz ˛a w jaki sposób najlepiej wyspecyfikować wymagania na za- sób. Co wi ˛ecej, mog ˛a oni mieć swoje preferencje odno´snie istotno´sci poszczególnych kryteriów wyboru. Podej´scie to mo ˙ze zostać wykorzystane zarówno przy wyborze zasobu jak i przy wyborze kontraktu. Jako walidacja zaproponowanego podej´scia wykorzystana została metoda AHP.

W przypadku wyboru zasobu, do weryfikacji wymaga ń u ˙zytkownika wykorzystywana jest ekspercka ontologia dziedzinowa przechowuj ˛aca rekomendacje eksperckie. U ˙zytkownik mo ˙ze mieć ograniczon ˛a wiedz ˛e o wymaganym zasobie i metodzie wykorzystywanej do rozwi ˛azywania jego problemu, natomiast powinien sprecyzować problem i wła´sciwo´sci danych wej´sciowych. Onto- logie (oraz wykorzystanie wnioskowania) pozwalaj ˛a u ˙zytkownikowi na okre´slanie wymaga ń do

(15)

poziomu do którego u ˙zytkownik czuje si ˛e kompetentny (nie trzeba operować na zbyt du ˙zym poziomie szczegółowo´sci). Jednym z wymaga ń dotycz ˛acych wyboru metody MCA była mo ˙zliwo´sć wyra ˙zania preferencji u ˙zytkownika wzgl ˛edem kryteriów decyzyjnych oraz wykorzystanie wiedzy od wielu ekspertów. AHP dostarcza ´srodków na spełnienie obydwu. Wiedza płyn ˛aca od wielu ekspertów jest wyra ˙zona w postaci rekomendacji eksperckich, oraz u ˙zywana do wyboru jednej reprezentatywnej rekomendacji, która jest zwracana u ˙zytkownikowi. Na etapie wyboru kontraktu, wiedza ekspercka nie jest wykorzystywana, jednak ˙ze inne charakterystyki MCA np. wyznaczenia wag kryteriów, s ˛a ci ˛agle wykorzystywane.

Podsumowuj ˛ac, “czyste” technologie semantyczne same w sobie dostarczaj ˛a dobrej metody do modelowania i odpytywania danych o zło ˙zonej strukturze. Wspieraj ˛a one dopasowanie w oparciu o elastyczne wielokryterialne zapytania. Jednak ˙ze, nie dostarczaj ˛a prostego sposobu na udzielenie odpowiedzi na pytanie “co jest najlepsze?”. Technologie semantyczne pozwalaj ˛a na wydobycie wariantów (alternatyw) spełniaj ˛acych kryteria z których u ˙zytkownik dokona ostatecznego wyboru.

Poł ˛aczenie technologii semantycznych z analiz ˛a wielokryterialn ˛a rozszerza mo ˙zliwo´sci wsparcia u ˙zytkownika o odpowied´z równie ˙z na pytanie “który wybór jest najlepszy?”.

3.1 Wkład własny

W kontek´scie przeprowadzonych bada ´n, poni ˙zsze punkty stanowi ˛a wkład własny, który został omówiony w rozprawie (i powi ˛azanych publikacjach):

1. Zaprojektowanie na poziomie koncepcyjnym oraz implementacja semantycznej reprezentacji wiedzy eksperckiej i dziedzinowej, jak równie ˙z metod persystencji wiedzy w postaci ontologii.

2. Zaprojektowanie oryginalnej ontologii dziedzinowej dla dziedziny obliczeniowej algebry liniowej. Ta ontologia została wykorzystana do walidacji zaproponowanego schematu reprezentacji wiedzy oraz metod wspomagania u ˙zytkownika przy wykorzystaniu zasobów gridu.

3. Obszerne przestudiowanie metod bazuj ˛acych na technologiach semantycznych, które mog ˛a zostać wykorzystane do wsparcia u ˙zytkownika w efektywnym wykorzystaniu gridu. Wy- brane metody zostały skonfrontowane ze zidentyfikowanymi przypadkami u ˙zycia, aby usta- lić przydatno´sć oraz ograniczenia zwi ˛azane z ka ˙zd ˛a z nich.

4. Analiza mo ˙zliwych powi ˛aza ´n pomi ˛edzy popularnymi metodami MCA i wiedz ˛a eksperck ˛a w postaci ontologii w kontek´scie wsparcia u ˙zytkownika. Ustalenie zalet i wad dla oryginalnego mechanizmu wsparcia u ˙zytkownika zrealizowanego w oparciu o wspomniane metody i ontologiczn ˛a reprezentacj ˛e wiedzy. Eksperymentalna walidacja projektu oraz implementacji z wykorzystaniem metody Analytical Hierarchy Process.

5. Ustalenie wytycznych je ˙zeli chodzi o u ˙zyteczno´sć technologii semantycznych w obszarze wspomagania u ˙zytkownika (na które pytania mo ˙zna udzielić odpowiedzi oraz w jakich przypadkach i w jaki sposób nale ˙zy metody semantyczne poł ˛aczyć z innymi metodami).

(16)

Bibliografia

[1] Ian Foster and Carl Kesselman, editors. The Grid 2, Second Edition: Blueprint for a New Computing Infrastructure. The Elsevier Series in Grid Computing. Elsevier, 2004.

[2] Salvatore F. Pileggi and Carlos Fernandez-Llatas. Semantic Interoperability Issues, Solutions, Challenges. River Publishers, Wharton, TX, USA, 2012. ISBN 8792329799, 9788792329790.

[3] Michael Parkin, Rosa M. Badia, and Josep Martrat. A Comparison of SLA Use in Six of the European Commissions FP6 Projects. Technical report, Institute on Resource Management and Scheduling, CoreGRID - Network of Excellence. URL http://www.coregrid.net/mambo/

images/stories/TechnicalReports/tr-0129.pdf.

[4] Wasielewska Katarzyna. Negotiations in a Resource Allocation Process in a Grid (in Polish), volume 12 of Analiza Systemowa w Finansach i Zarz ˛adzaniu, Wybrane problemy, pages 175–185.

Instytut Bada ´n Systemowych PAN, 2010.

[5] Ian Foster, Nicholas R. Jennings, and Carl Kesselman. Brain Meets Brawn: Why Grid and Agents Need Each Other. In Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems, 2004. AAMAS 2004, pages 8–15, Jul 2004.

[6] Mateusz Dominiak, Wojciech Kuranowski, Maciej Gawinecki, Maria Ganzha, and Marcin Paprzycki. Utilizing agent teams in Grid resource management—preliminary considerations.

In Proc. of the IEEE John Vincent Atanasoff Conference, pages 46–51, Los Alamitos, CA, 2006. IEEE CS Press.

[7] Wojciech Kuranowski, Maria Ganzha, Maciej Gawinecki, Marcin Paprzycki, Ivan Lirkov, and Svetozar Margenov. Forming and managing agent teams acting as resource brokers in the grid—preliminary considerations. International Journal of Computational Intelligence Research, 4 (1):9–16, 2008.

[8] Katarzyna Wasielewska, Michał Drozdowicz, Maria Ganzha, Marcin Paprzycki, Naoual At- taui, Dana Petcu, Costin Badica, Richard Olejnik, and Ivan Lirkov. Trends in Parallel, Distri- buted, Grid and Cloud Computing for engineering. chapter Negotiations in an Agent-based Grid Resource Brokering Systems. Saxe-Coburg Publications, Stirlingshire, UK, 2011.

[9] Katarzyna Wasielewska, Maria Ganzha, Marcin Paprzycki, and Ivan Lirkov. Developing onto- logical model of computational linear algebra – preliminary considerations. In AIP Conference Proceedings, volume 1561, pages 133–144. American Institute of Physics.

14

(17)

[10] Michał Drozdowicz, Katarzyna Wasielewska, Maria Ganzha, Marcin Paprzycki, Naoual At- taui, Ivan Lirkov, Richard Olejnik, Dana Petcu, and Costin Badica. Ontology for Contract Negotiations in Agent-based Grid Resource Management System. Saxe-Coburg Publications, Stir- lingshire, UK, 2011.

[11] Paweł Szmeja, Katarzyna Wasielewska, Maria Ganzha, Michał Drozdowicz, Marcin Paprzycki, Stefka Fridanova, and Ivan Lirkov. Reengineering and extending the Agents in Grid Ontology.

In Large Scale Scientific Computing, LNCS. Springer Germany, 2013.

[12] Mariusz M. Mesjasz, Marcin Paprzycki, and Maria Ganzha. Establishing semantic closeness in an agent-based travel support system. Scalable Computing: Practice and Experience, 14(2), 2013.

URL http://www.scpe.org/index.php/scpe/article/view/844.

[13] K. Wasielewska, M. Ganzha, M. Paprzycki, C. Badica, M. Ivanovic, and I. Lirkov. Multicriterial analysis of ontologically represented information. In AIP Conference Proceedings, volume 1629, pages 281–295. American Institute of Physics, 2014.

[14] B.Roy and R.Slowinski. Questions guiding the choice of a multicriteria decision aiding method.

EURO Journal on Decision Processes, 1(1-2):69–97, 2013. ISSN 2193-9438. doi: 10.1007/s40070- 013-0004-7.

[15] Hsu-Shih Shih, Huan-Jyh Shyur, and E. Stanley Lee. An extension of {TOPSIS} for group decision making. Mathematical and Computer Modelling, 45(7–8):801 – 813, 2007. ISSN 0895- 7177. doi: http://dx.doi.org/10.1016/j.mcm.2006.03.023.

[16] B.Mareschal, J.P.Brans, and C.Macharis. The GDSS PROMETHEE procedure: a PROMETHEE- GAIA based procedure for group decision support. ULB Institutional Repository 2013/9373, ULB – Universite Libre de Bruxelles, 1998.

[17] J.R.Figueira, S.Greco, and R.Slowinski. Building a set of additive value functions representing a reference preorder and intensities of preference: GRIP method. European Journal of Operational Research, pages 460–486, 2009.

[18] T.L. Saaty. The Analytic Hierarchy Process. RWS Publications, Pittsburg, 1990.