MODEL ZARZĄDZANIA ONTOLOGIAMI W ŚRODOWISKU OCENY TECHNOLOGII INFORMATYCZNYCH

Transkrypt

1 Zarządzanie wiedzą i technologiami informatycznymi / C. Orłowski, Z. Kowalczuk, E. Szczerbicki (red.). Gdańsk : Pomorskie Wydawnictwo Naukowo-Techniczne PWNT, (Automatyka i Informatyka). ss : 5 rysunków bibliografia 4 poz. ISBN (wydanie elektroniczne) ROZDZIAŁ 51 MODEL ZARZĄDZANIA ONTOLOGIAMI W ŚRODOWISKU OCENY TECHNOLOGII INFORMATYCZNYCH Adam CZARNECKI Politechnika Gdańska Wydział Zarządzania i Ekonomii Zakład Zarządzania Technologiami Informatycznymi adam.czarnecki@zie.pg.gda.pl. Prawa autorskie: Materiał był opublikowany przez Pomorskie Wydawnictwo Naukowo-Techniczne w książce lub elektronicznym wydaniu książki pod tytułem Zarządzanie wiedzą i technologiami informatycznymi (ISBN ). Możliwe jest zrobienie jednej kopii bądź wydruku tylko i wyłącznie do użytku własnego. Wielokrotne kopiowanie w celach komercyjnych, bądź modyfikowanie treści materiału jest zabronione. Strona WWW wydawnictwa: 1. Wprowadzenie Temat oceny technologii informatycznych, czyli metod i narzędzi używanych w konkretnym kontekście (np. technologii wytwarzania oprogramowania) jest interesujący ze względu na przydatność takich ocen dla osób i organizacji decydujących o wyborze konkretnej technologii lub aplikacji do określonych zadań. Wielość czynników, jakie należy wziąć od uwagę, ich szeroki zakres (czynniki funkcjonalne, ekonomiczne, ergonomiczne, organizacyjne itp.) czy ważność, a także pojawiające się nowe informacje nie pomagają w dokonaniu trafnego wyboru. Stąd propozycja stworzenia systemu, który byłby w stanie pozyskiwać wiedzę o technologiach informatycznych, przechowywać modele ocenowe i udzielać odpowiedzi na pytania związane z doborem rozwiązań IT. Jedną z propozycji jest wykorzystanie architektury wieloagentowej korzystającej z baz wiedzy oraz ontologii (system zwany roboczo MAS_IT). Każdy z tych elementów agenty, bazy wiedzy i ontologie wymaga zdefiniowania i określenia metod zarządzania, by osiągnął swą funkcjonalność po etapie wytworzenia oraz zachował w czasie, gdy system będzie eksploatowany. Niniejszy tekst poświęcony jest jednemu z elementów systemu MAS_IT, jakim są ontologie (definiowane przez Grubera jako wyraźny, formalny opis konceptualizacji wybranej dziedziny [4]) i skupia się na wstępnych pracach związanych z zarządzaniem nimi na etapie tworzenia i rozbudowy. Proponuje też zestaw prostych eksperymentów pozwalających w początkowej fazie powstawania systemu sprawdzić współdziałanie ontologii, baz wiedzy oraz wybranych agentów. 2. Rola ontologii w MAS_IT Prezentowana w tym tekście koncepcja systemu wieloagentowego do oceny technologii informatycznych jest rozwijana od końca 2006 r. W tym czasie sformułowano pewne postulaty dla każdego z komponentów. W przypadku ontologii przekładają się one na następujące funkcjonalności [2]: Wnioskowanie o metodach swoiste abstrakcje wykorzystywane do prezentacji i analizy wiedzy o metodach zarządzania projektami IT. Semantyka dla bazy wiedzy i pytań kompetencyjnych (tj. takich, na jakie ma odpowiadać system MAS_IT). Głębsze wnioskowanie tworząc coraz szerszą i/lub głębszą ontologię, możemy odkryć lub unaocznić nieuświadomione wcześniej relacje, dojść do nowych twierdzeń czy nawet definicji. Byłaby to raczej poboczna funkcja ontologii, niemniej zwiększająca efektywność całego systemu służącego ocenie. 1

2 3. Tworzenie ontologii Inżynier wiedzy zamierzający stworzyć ontologię powinien zastanowić się nad co najmniej trzema zagadnieniami składającymi się na technologię służącą tworzeniu takiego modelu wiedzy. Są to: przyjęte podejście (metodyka), język i narzędzie (najczęściej aplikacja komputerowa). Przy czym zazwyczaj te składniki są ze sobą powiązane Wybór technologii Przegląd technologii do tworzenia ontologii czytelnik znajdzie m.in. w [1] oraz [3]. Przy tworzeniu prototypu ontologii dla celów oceny technologii do zarządzania przedsięwzięciami informatycznymi zdecydowano się na skorzystanie z narzędzia Protégé w wersji 3.3.1, korzystając z jego odmiany wykorzystującej język OWL (ang. Web Ontology Language) w odmianie DL (ang. Description Logics). Konieczne również było podjęcie decyzji dotyczącej wyboru podejścia do budowania pojęć: góra-dół (ang. top-down) lub dół-góra (ang. bottom-up). Wybrano podejście bliższe schematowi dół-góra (tj. od ogółu do szczegółu), albowiem wpierw utworzono pewne ogólne klasy, a następnie ich podklasy oraz instancje Struktura Tworzona na potrzeby badań nad technologiami służącymi zarządzaniu projektami informatycznymi ontologia składa się z hierarchii klas (ang. Classes), ich instancji (ang. Instances) oraz własności (ang. Properties) użytych do łączenia klas lub instancji (rys. 1). Aby ułatwić współpracę nad realizacją badań na poziomie międzynarodowym, przyjęto, że stosowane będą pojęcia w języku angielskim. Rys. 1. Klasy oraz instancje ontologii dla badania technologii zarządzania projektami informatycznymi. Źródło: opracowanie własne w narzędziu Protégé. Aplikacja Protégé domyślnie tworzy klasę owl:thing jako korzeń każdej ontologii. Zatem jako jej podklasy utworzono: PMApplication przechowuje instancje odpowiadające aplikacjom do zarządzania przedsięwzięciami, Functionality grupuje instancje opisujące funkcjonalności mogące występować w badanej technologii, Context zawiera informacje o kontekstach, w jakich może być oceniana technologia. Dodatkowe podklasy oraz instancje przedstawiono na rys. 1. 2

3 O ile znaczenie klas PMApplication i Functionality jest oczywiste, to Context wymaga nieco szerszego omówienia. Zamiennie także stosuje się pojęcia kontekstu lub środowiska, rozumiejąc pod tymi pojęciami specyficzny zestaw uwarunkowań niezależnych od badanej technologii, w jakim ma być ona zastosowana. Na potrzeby tworzonego tu prototypu ontologii stworzono dwa zestawy pojęć kontekstowych: ProjectSize kontekst definiujący rozmiar projektu, który ma być zarządzany przez aplikację z wydzielonymi pojęciami projektu małego (Small), średniego (Medium) oraz dużego (Large), NewOrModify kontekst określający, czy przedsięwzięcie służy wytworzeniu nowego systemu informatycznego (NewSystemDevelopment), czy też zmianie systemu już istniejącego (ModifyExistingSystem). Pełniejsze zdefiniowanie kontekstu będzie wymagało m.in. określenia relacji pomiędzy danym kontekstem a funkcjonalnością (na poziomie klas lub instancji). Na obecnym etapie prototypowania ontologii nie zdefiniowano jeszcze żadnych własności czy warunków dla kontekstów użycia technologii. Kolejną grupą elementów w ontologii są własności. W Protégé pojęcie to oznacza relację binarną pomiędzy dwoma elementami (klasami, instancjami). Na potrzeby prototypu ontologii do oceny technologii zarządzania przedsięwzięciami informatycznymi, stworzono następujące własności: hassomefunctionality łączy klasy PMApplication (jako domenę, ang. Domain) i Functionality (jako zasięg oddziaływania, ang. Range) wskazując, że instancje tej pierwszej klasy mogą być powiązane z instancjami drugiej klasy; należy to powiązanie odczytywać następująco: aplikacje mają jakieś funkcjonalności (linia przerywana na rys. 2 zwrócona od PMApplication do Functionality), isimplementedin własność odwrotna (ang. Inverse) do hassomefunctionality (czyli z klasą Functionality jako domeną i PMApplication jako zasięgiem oddziaływania), informująca o tym, że funkcjonalność jest zaimplementowana w aplikacji jako ogólna cecha pojęcia funkcjonalności, a nie jej konkretnej instancji (linia przerywana na rys. 2 zwrócona od Functionality do PMApplication). Dodatkowo, dla zobrazowania możliwości ontologii, utworzono warunek konieczny mówiący o tym, że istnieje taka funkcjonalność, która jest zaimplementowana w aplikacji (linia ciągła z etykietą na rys. 2 zwrócona od Functionality do PMApplication). isevaluatedinsomecontext łączy klasę PMApplication (domena) z Context (zasięg oddziaływania) informując, że ocena aplikacji może odbywać się w zadanym kontekście (linia przerywana na rys. 2 zwrócona od PMApplication do Context). Istnieją też w ontologii własności predefiniowane wskazujące na relację klasa-podklasa (has subclass) czy klasa-instancja (has instance) (rys. 1). Rys. 2. Własności pomiędzy głównymi klasami z pokazaniem warunku koniecznego isimplementedin PMApplication dla klasy Functionality. Źródło: opracowanie własne w narzędziu Protégé. Dzięki tworzeniu warunków koniecznych i wystarczających dla klas i instancji z użyciem własności, możliwe staje się wnioskowanie z wykorzystaniem osobnego narzędzia-agenta, tzw. resonera. 3

4 4. Rozbudowa ontologii Tworzenie ontologii jest procesem iteracyjnym. Po pierwsze, ze względu na to, że trudno w jednym przebiegu od początku do końca wyczerpać zakres koniecznej do umieszczenia wiedzy. Po drugie, ponieważ z upływem czasu następuje zmiana wymagań wobec ontologii lub pojawia się konieczność zastąpienie istniejącej wiedzy nową. Zatem ontologia posiada określony najczęściej nieznany od początku cykl życia, w czasie którego jest eksploatowana, to jest użytkuje się ją jako element systemu (stanowi przedmiot działania) oraz obsługuje, czyli dokonuje przy niej (domyślnie: inżynier wiedzy) prac mających zapewnić spójną współpracę z pozostałymi komponentami (wówczas ontologia jest podmiotem działania). Przy takim podejściu możemy przyjąć, że konieczne jest zarządzanie eksploatacją ontologii. MAS_IT Zarządzaj ontologią «extends» Dodaj funkcjonalność «extends» «extends» Inżynier wiedzy Dodaj kontekst Dodaj aplikację Rys. 3. Opisywane przypadki użycia przy zarządzaniu ontologią w systemie MAS_IT. Źródło: opracowanie własne. Poniżej rozważone zostaną trzy przypadki związane z obsługą ontologii w systemie oceny IT, jakimi jest rozbudowanie jej o wiedzę na temat nowej funkcjonalności, nowej aplikacji oraz nowego kontekstu użycia aplikacji (rys. 3) Nowa funkcjonalność Dodanie w ontologii wiedzy o nowej funkcjonalności, jakiej możemy oczekiwać w ramach badanej technologii w najprostszym przypadku sprowadza się w narzędziu Protégé do utworzenia nowej instancji w ramach klasy Functionality. Zachodzi wówczas dziedziczenie właściwości isimplementedin, która opisuje relację zachodzącą pomiędzy klasą Functionality (jako domeną) a klasą PMApplication (jako zakresem oddziaływania). Zatem po każdej z funkcjonalności będziemy oczekiwać, że może ona być zaimplementowana w konkretnej aplikacji. Informacja o obecności danej funkcjonalności w wybranej aplikacji, w zamyśle autorów, nie powinna znajdować się w samej ontologii, a w osobnej bazie wiedzy. Istnieje jednak taka możliwość, co zaprezentowano na rys. 4, gdzie pokazano, że funkcjonalność planowania zasobów (ResourcePlanning) jest zaimplementowana w aplikacji MS Project

5 Rys. 4. Instancja ResourcePlanning klasy Functionality połączona własnością isimplementedin z instancją MSProject2003 klasy PMApplication. Źródło: opracowanie własne w narzędziu Protégé. Takie dodawanie funkcjonalności jako instancji jednej klasy jest stosunkowo proste. Warto jednak zadać kilka pytań, przed którymi może stanąć inżynier wiedzy zarządzający zasobami ontologii. Przykładowo, część funkcjonalności może dotyczyć tego samego obszaru (np. możliwość współdzielenia zasobów oraz przydzielania ról osobom zaangażowanym w projekt to funkcje wspólne dla pracy grupowej). Czy wówczas uzasadnione jest wydzielenie takiej grupy funkcjonalności jako osobnej klasy? A może zamiast klasy, dodać tę nadrzędną funkcjonalność jako kolejną instancję i powiązać z funkcjonalnościami zawartymi własnością wskazującą na agregację (haspart ispartof)? Kolejny możliwy scenariusz dotyczy sytuacji, w której obecność jednej funkcjonalności oznacza jednocześnie występowanie innej (np. bilansowanie zasobów jest możliwe tylko wówczas, gdy aplikacja w ogóle pozwala na przydzielanie zasobów w projekcie). Zależnie od dokładniejszego charakteru relacji pomiędzy wybranymi funkcjonalnościami, można rozważyć dwa przypadki: gdy jedna funkcjonalność uszczegóławia inną wtedy możemy zastosować jedno z podejść zaproponowanych wcześniej (wydzielenie dodatkowej klasy dla pojęcia bardziej ogólnego i instancji dla funkcjonalności bardziej szczegółowej), gdy jedna funkcjonalność wymaga istnienia innej wówczas istniałyby jako instancje na tym samym poziomie hierarchii pojęć w ontologii, a odpowiednią semantykę zapewniłyby łączące je właściwości wymaga jest wymagana przez (requires isrequiredby). Można również wyobrazić sobie przypadek, że istnienie jednej funkcjonalności z zasady wyklucza występowania w ramach jednej aplikacji innej funkcjonalności. Wówczas powinno mieć to również swoje odzwierciedlenie w strukturze ontologii. Wybrana na potrzeby tego artykułu technologia zarządzania projektami IT (w postaci aplikacji wspomagających to zadanie) narzuca udostępnianie przez narzędzia informatyczne pewnych funkcjonalności jako minimum, by można te aplikacje uznać za przydatne z punktu widzenia stawianych im celów. Rolą inżyniera wiedzy odpowiedzialnego za utrzymanie ontologii jest pozyskanie informacji od ekspertów na temat takiej właśnie listy wymagań niezbędnych do zakwalifikowania narzędzia jako spełniającego definicję technologii zarządzania projektami IT. Chodzi o to, by uchwycić istotę funkcjonalną wybranej technologii i zdefiniować w sposób bardziej formalny niż na zasadzie: Jaki jest koń, każdy widzi. 5

6 4.2. Nowa aplikacja Drugi przypadek rozbudowywania opisywanej tu ontologii stanowi dodanie nowej aplikacji. Podobnie jak w przypadku wprowadzania kolejnej funkcjonalności, najprostsze działanie będzie polegało na powołaniu nowej instancji reprezentującej aplikację, tym razem w ramach klasy PMApplication. Ta nowo utworzona instancja będzie dziedziczyć po swojej klasie właściwość hassomefunctionality wskazującą na klasę Functionality (a zatem i na jej instancje). Szczegóły, czyli informacje o tym, jakie konkretnie funkcjonalności oferuje dana aplikacja, zawarte powinny być w bazie wiedzy (choć, jak pokazano w punkcie 0, również ontologia tworzona w Protégé ma możliwość przechowywania takich wiadomości). Przyjmując model MAS_IT, w którym fakty o występowaniu funkcjonalności będą umieszczone w bazie wiedzy, a nie w ontologii, musimy pamiętać o zaszyciu w systemie pewnych narzędzi diagnostycznych, które pozwolą wykryć na przykład sytuację, w której w ontologii lub bazie wiedzy istnieje informacja o istnieniu jakiejś aplikacji, natomiast nie istnieje żaden skojarzony z nią fakt przypisujący jej choćby jedną funkcjonalność. To, oczywiście, przy założeniu, że opisaną sytuację potraktujemy jako błąd lub przynajmniej ostrzeżenie. Inną możliwością wynikającą z posiadania ontologii oraz bazy wiedzy na temat aplikacji i ich funkcjonalności, jest detekcja narzędzi komplementarnych (z odpowiednim współczynnikiem zastępowania lub wzajemnego uzupełniania funkcjonalności). Na razie pozostaje to tylko w formie postulatu, gdyż nie podjęto jeszcze w zespole prac nad modelem wykrywania tego typu zależności, czy to na poziomie mniejszego podzbioru funkcjonalności, czy tym bardziej dla całej klasy aplikacji Nowy kontekst Najbardziej złożona z trzech opisywanych tu przypadków dodawania wiedzy do ontologii, wydaje się sytuacja wprowadzania kolejnego kontekstu. Rys. 5. Klasa Context z podklasami i ich instancjami w relacji z klasą PMApplication. Źródło: opracowanie własne w narzędziu Protégé. Znów, najprostszym przypadkiem będzie stworzenie nowej instancji w ramach klasy Context (rys. 5). Jak jednak pokazano wyżej, już w tej wczesnej wersji prototypu należało utworzyć dodatkowe podklasy, by móc zamodelować określone konteksty (tu: rozmiar projektu oraz charakter przedsięwzięcia tworzenie nowego systemu czy modyfikacja istniejącego). Dodatkowo, dla uproszczenia prototypu, nie powiązano klas lub instancji w obrębie domeny Context z innymi elementami ontologii. Warto jednak w tym miejscu zastanowić się, jak takie powiązania mogłyby wyglądać. Na obecnym etapie badań wydaje się, że dany kontekst może być zestawem wymaganych funkcjonalności dla danego zastosowania. Sposobem odwzorowania tej wiedzy w ontologii może być dodanie własności wymaga (requires) pomiędzy instancjami w klasie Context i Functionality, podobnie jak w opisywanej wcześniej sytuacji dwóch funkcjonalności, gdzie jedna wymaga obecności innej. Odpowiednio, można utworzyć relację zwrotną typu jest wymagana przez (isrequiredby) od danej funkcjonalności do konkretnego kontekstu. 6

7 W związku z kontekstami pojawia się też pewien problem. O ile wiedza na temat istnienia aplikacji czy funkcjonalności oraz występowania tych ostatnich w aplikacjach nie wydaje się specjalnie dyskusyjna (chociaż przy popularności architektury wykorzystującej tzw. wtyczki, ang. plug-in, i tu powstaje obszar sporów, co jest rdzenną funkcjonalnością), o tyle zdefiniowanie konkretnego kontekstu wydaje się raczej domeną ekspertów. Przy czym każdy ekspert dany kontekst może widzieć inaczej. A ponieważ ontologia (czy ontologie) w proponowanym rozwiązaniu ma być źródłem do weryfikacji poprawności baz wiedzy, wszelkie stwierdzenia mające charakter względny powinny być umieszczane raczej w bazach wiedzy niż ontologiach. 5. Propozycje eksperymentów Przedstawione w punkcie 4. przypadki rozbudowy ontologii będą oddziaływać na zdolność całego systemu MAS_IT na dokonywanie ocen technologii informatycznych. Ważne jest, by móc przewidzieć, jakiego oddziaływania należy się spodziewać. Sposobem na sprawdzenie skutków rozbudowy ontologii może być zaprojektowanie zestawu eksperymentów opartych na opisanych wcześniej czynnościach eksploatacyjnych, jakimi jest dodanie wiedzy o funkcjonalności, aplikacji i kontekście. Co prawda głównym obszarem stosowania eksperymentów są nauki przyrodnicze, podczas gdy dla dziedzin z zakresu matematyki czy informatyki stosuje się raczej metody dedukcyjne. Jednak dla problemów o większym stopniu złożoności (a za taki przyjęto tu środowisko wieloagentowe do oceny IT), można zaproponować właśnie metody eksperymentalne. Na obecnym, wstępnym etapie budowy prototypu MAS_IT celem eksperymentów będzie sprawdzenie, czy dodawane do ontologii reguły semantyczne pozwalają na weryfikację zawartości bazy wiedzy. Zarówno niewielki stopień zaawansowania prac nad systemem, jak i zasada, wedle której zaprojektowany eksperyment powinien być jak najprostszy w wykonaniu, skłaniają do rozpatrzenia osobno przypadków: Dodania wiedzy o nowej funkcjonalności potraktowania instancji UsingRoles za nową i umieszczenie w bazie wiedzy jednego faktu: RationalMethodComposer7.0.1 hassomefunctionality UsingRoles, a następnie sprawdzenia przez agenta odpowiedzialnego za weryfikację bazy wiedzy w ontologii, czy podany fakt jest semantycznie poprawny. W drugim kroku z bazy usunięto by wymieniony fakt i w jego miejsce wprowadzono odwrotny: UsingRoles isimplementedin RationalMethodComposer Także taki fakt agent miałby skonfrontować z ontologią i, według założeń, wykazać prawdziwość. Jeśli oba testy dałyby pozytywny efekt (tj. agent odnajduje struktury bazy wiedzy w ontologii), należałoby przeprowadzić sprawdzenie, czy fakt postaci RationalMethodComposer7.0.1 isimplementedin UsingRoles (tj. mówiący, że aplikacja jest zaimplementowana w funkcjonalności) zostanie wskazany jako błędny. Dodania wiedzy o aplikacji rozpatrując aplikację reprezentowaną przez instancję MSProject2003, można zaproponować eksperyment z zestawem testów o podobnej strukturze jak przy dodaniu wiedzy o funkcjonalności: sprawdzić, jak agent zareaguje na fakt: MSProject2003 hassomefunctionality Scheduling, następnie na fakt odwrotny: Scheduling isimplementedin MSProject2003, a w końcu na fakt semantycznie niepoprawny: MSProject2003 isimplementedin Scheduling. Dodania wiedzy o kontekście choć, co wspomniano, to do tej pory najbardziej złożona część wiedzy, tu także na początek warto rozważyć testy najprostsze: potraktowanie klasy NewOrModify oraz jej instancji jako nowego elementu ontologii oraz dodanie w bazie wiedzy faktu: RationalMethodComposer7.0.1 isevaluatedinsomecontext NewSystemDevelopment. Dla relacji isevaluatedinsomecontext nie stworzono relacji odwrotnej, więc test z faktem skierowanym od kontekstu do aplikacji nie byłby w tej fazie przeprowadzony. Aktualny natomiast pozostaje test, w którym w fakcie instancja-aplikacja i instancja-kontekst zostaną zamienione miejscami, czyli wyrażenie będzie semantycznie błędne. Powyższe eksperymenty powinny wykazać prawidłowość (lub nieprawidłowość) tworzonych ontologii oraz baz wiedzy, a także działania agenta, którego rolą ma być weryfikacja baz w oparciu o ontologie. W kolejnych krokach, gdy zarówno ontologie, jak i bazy wiedzy będą bardziej rozbudowane, możliwe będzie zaprojektowanie bardziej złożonych eksperymentów, skupiających się mniej na testowaniu samego mechanizmu, a bardziej na wzajemnych zależnościach różnych elementów wiedzy zawartej w systemie. 7

8 6. Podsumowanie W tekście zaprezentowano wczesny prototyp ontologii zbudowanej z myślą o wykorzystaniu w wieloagentowym systemie służącym ocenie technologii informatycznych (MAS_IT). Jako przykład wybrano aplikacje służące zarządzaniu projektami, w szczególności informatycznymi. Główny problem tu podniesiony dotyczy zarządzania procesem tworzenia i rozbudowy ontologii. Jako że nie ma jednej słusznej metody działania, inżynier wiedzy staje przed pytaniami o sposób, w jaki powinna powstawać ontologia, o jej granice czy poziom szczegółowości. W sytuacji powiązania z bazami wiedzy należy postawić linię graniczną między tą wiedzą, która znaleźć się musi w ontologii, a tą do umieszczenia w bazie wiedzy. Pytanie, w którym miejscu przebiega ta granica? Jak pokazano, w języku OWL-DL z użyciem aplikacji Protégé można stworzyć rozbudowaną semantykę poprzez hierarchię klas oraz własności (w prototypie wykorzystano tylko najprostsze ich typy). Istnieje pokusa, by budowana ontologia była jak najdokładniejsza, a zatem by odwzorowywać każdą dostrzeżoną relację oraz określać warunki konieczne lub wystarczające dla klas. Może to prowadzić do niekorzystnych redundancji, czy nawet do nieświadomego zaszycia sprzeczności wewnątrz ontologii, tym trudniejszych do odnalezienia, im gęstsza sieć własności ją oplecie. Dlatego wiedzy w ontologii powinno być tyle, ile jest to konieczne. Mniej rygorystyczne podejście może dotyczyć baz wiedzy. Zanim ontologie oraz bazy wiedzy staną się dość złożone, warto eksperymentalnie przekonać się, jaki jest efekt dodawania nowej wiedzy do systemu. Początkowo mogą to być stosunkowo proste testy, jak te zaproponowane w punkcie 5. W późniejszych fazach będzie można pokusić się o zaprojektowanie eksperymentów mogących pokazać, jak wpływają na siebie różne fakty w świetle przyrastającej zawartości ontologii. Pokazane w tekście dylematy będą musiały zostać rozstrzygnięte na kolejnych etapach tworzenia ontologii. Spodziewanym i pożądanym efektem pobocznym będzie wypracowanie metodyki zarządzania ontologiami. Bibliografia [1] Czarnecki A.: Technologie informatyczne wykorzystywane w projektowaniu i implementacji ontologii. Orłowski C. (red.): Zarządzanie technologiami informatycznymi: stan i perspektywy rozwoju, seria: Automatyka i Informatyka, nr 1, ss Pomorskie Wydawnictwo Naukowo- Techniczne, Gdańsk, [2] Czarnecki A., Orłowski C.: Definicja ontologii w wieloagentowym systemie do oceny technologii informatycznych Knosala R. (red.): Komputerowo Zintegrowane Zarządzanie, vol. 1, ss Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole, [3] Czarnecki A., Orłowski C.: Możliwości zastosowania ontologii do oceny technologii informatycznych Knosala R. (red.): Komputerowo Zintegrowane Zarządzanie, vol. 2, ss Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole, [4] Gruber T.R.: A Translation Approach to Portable Ontology Specifications. W: Knowledge Acquisition. 5(2): ,

9 Information Technology and Knowledge Management A. Czarnecki* *Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, adam.czarnecki@zie.pg.gda.pl Rozdział 51. Wybrane kwestie zarządzania ontologiami w wieloagentowym systemie oceny technologii informatycznych. W tekście zaprezentowano wczesny prototyp ontologii zbudowanej z myślą o wykorzystaniu w wieloagentowym systemie służącym ocenie technologii informatycznych (MAS_IT). Jako przykład wybrano aplikacje służące zarządzaniu projektami, w szczególności informatycznymi. Główny problem tu podniesiony dotyczy zarządzania procesem tworzenia i rozbudowy ontologii. Jako że nie ma jednej słusznej metody działania, inżynier wiedzy staje przed pytaniami o sposób, w jaki powinna powstawać ontologia, o jej granice czy poziom szczegółowości. Information Technology and Knowledge Management A. Czarnecki* *Gdańsk University of Technology, Faculty of Management and Economics, Department of the Information Technology Management, adam.czarnecki@zie.pg.gda.pl Chapter 51. An Issues of the Ontology Management in the Multi-Agent System for the IT Evaluation. This paper presents an early prototype of the ontology built for the purpose of the Multi- Agent system for the information technology evaluation (MAS_IT). The [IT] project management applications were chosen as an example. The main issue stated in the text regards the process of the ontology creation and its further development. As there is no single method (if any) how to manage this process, a knowledge engineer must face certain questions during the ontology life-cycle. 9