Implementacja Modułu akwizycji wiedzy

Moduł ten zgodnie z paradygmatem użytkowania otwartych standardów, będzie implementowany w konwencji otwartego środowiska. Umożliwi to w przyszłości dowolne rozszerzenie dostępnych dla systemu metod niezależnie od platformy. Wskazane podejście jest osiągalne wyłącznie w przypadku zastosowania budowy modułowej dla akwizycji wiedzy. Rozważa się w tym przypadku konstrukcję architektoniczną, podzieloną na dwa zasadnicze komponenty funkcjonalne:

x biblioteki metod - zawierające predefiniowane metody aktywnego gromadzenia i przetwarzania zasobów informacyjnych w środowiskach heterogenicznych,

x środowiska aktywacji metod - pozwalające na uruchomienie danej metody akwizycji wiedzy. Biblioteka metod akwizycji dostarcza potencjalnemu użytkownikowi dostęp do następujących metod: wyszukiwania adekwatnych technik akwizycji dla aktualnie rozpatrywanego problemu decyzyjnego, transferu użytecznych technik do środowiska aktywacji. W tej konwencji to decydent definiuje zakres przedmiotowy interesującego go zagadnienia informacyjnego. Przykładem wskazanych metod będzie, między innymi: analiza delficka implementowana z wykorzystaniem technologii webparts lub metody bazujące na koncepcji webcrawlera, gromadzące dane z sieci internetowej (np. Eurostatu). Metody te nie tylko mogą przebierać formę aktywnego komponentu

gromadzącego dane, lecz również mogą przetwarzać zgromadzone informacje (np. modele trendów, modele prognostyczne, itp.) w użyteczne modele dynamiki SZD.

Wybrane metody zostają transferowane do środowiska wykonawczego, gdzie następuje definicja parametrów startowych poszczególnych metod akwizycji. W przypadku poprawnego zdefiniowania parametrów, następuje uruchomienie wskazanej metody akwizycji. Każda z metod uruchomiona w środowisku aktywacji ma dostęp do modułu wiedzy za pośrednictwem dedykowanych interfejsów, gdzie następuje składowanie pozyskanej lub przetworzonej wiedzy. Przykładową interakcję poszczególnych komponentów przedstawiono na Rys. 7.8.

Wyżej wymienione metody i techniki przedstawiono wyłącznie w formie propozycji, które finalnie mogą służyć budowie adekwatnej architektury SZW na potrzeby roadmappingu oraz metod transferu technologii. W tym kontekście ważna jest identyfikacja istotnych problemów technicznych:

x dostarczenie metod pozyskiwania wiedzy na cele decyzyjne (np. autonomiczne).

x sposoby integracji wymaganej wiedzy w procesie decyzyjnym (synteza lub fuzja wiedzy). x współdzielenie wiedzy w środowisku decyzyjnym i ponowne jej wykorzystanie (osiągnięcie

efektywności skali).

x ewolucja wiedzy (rozwój oraz tworzenie nowej wiedzy).

Odnosząc się do problemu pierwszego, czyli pozyskiwania wiedzy, warto zwrócić uwagę, że podstawą syntezy roadmappingu staje się informacja: formalna i nieformalna. Eksperci do swojej pracy w metodzie RM, wymagają dostępu do danych oraz informacji, np. raportów, analizy, efektów badań foresight. Aby zapewnić to tym grupom wymagany jest dostęp do tzw. Wiedzy na niskim poziomie, tzn. takiej, która może być przedmiotem przetwarzania różnych systemów autonomicznych dokonujących akwizycji i przetworzenia wiedzy. Wiedza może być integrowana na poziomie właściwego kreowania diagramów roadmappingowych, gdzie technicznie postrzega się ją jako całościowy proces integracji ontologii. Oznacza to bezpośrednio łączenie kilku istniejących ontologii w jedną nową spójną całość. Finalny odbiorca uzyskuje dostęp do spójnej ontologii składającej się z wielu hierarchicznych komponentów wiedzy. Te komponenty mogą stać się przedmiotem dalszych operacji na poziomie konsument i producenci wiedzy. Dekompozycję większej struktury ontologicznej na mniejsze fragmenty operacyjne, należy rozpatrywać w kategoriach procesu modularyzacji wiedzy. Termin modularyzacja w prezentowanym kontekście, to podział ontologii na logiczne moduły funkcjonalne, które mogą podlegać procesom wymiany, integracji lub przetwarzania. W przypadku odpowiedniej integracji tych zasobów w jedną spójną całość, będą stanowiły adekwatny opis badanego obrazu świata zagadnienia problemowego. Budowa hierarchicznych struktur sprzyja również dostarczeniu mechanizmów wnioskowania ułatwiających automatyzację niektórych czynności. W kontekście integracji ontologii, warto zwrócić uwagę na pracę Doer i in. [264], Buccella i in. [265] oraz Kutz i in. [266].

Zintegrowana wiedza tworząca spójną oraz przetworzoną formę, powinna się stać przedmiotem obrotu w środowisku decyzyjnym. Problem współdzielenia wiedzy i jej ponownego użycia leży u podstaw konceptu ontologii, upatrując w nim źródło oszczędności zasobów operacyjnych oraz pamięciowych. Problem ten był głównie identyfikowany w zagadnieniach, gdzie istniały już ekstensywne fragmenty wiedzy zgromadzonej w komponentach. Części tych komponentów posiadały wysokie walory uniwersalne, a zatem można je było w łatwy sposób współdzielić. Dla przykładu, Perez i Benjamins [267] we wspomnianym kontekście współdzielenia komponentów dokonał podziału na: ontologie reprezentacji wiedzy, ogólne ontologie (general / common

ontologies), ontologie top-level (top-level ontology), meta-ontologie (meta-ontology), ontologie

dziedzinowe (domain ontology), ontologie lingwistyczne (illustrative linguistic), ontologie zadaniowe (task ontology), ontologie dziedzinowe zadaniowe (domain-task ontology), ontologie metod (method ontologies), ontologie aplikacyjne (application ontologies).

Kategoryzacja ontologii wprowadzona przez Pereza, uświadamia potencjalnemu użytkownikowi szerokie spektrum użytkowania ontologii w złożonych środowiskach aplikacyjnych. Prezentowane podejście techniczne ma swoje ograniczenie związane z efektywnością przeszukiwania rozległych środowisk, celem łączenia i współdzielenia wiedzy. W tym kontekście można się odwołać do prac Urscholda i Gruuninger [268], Grubera [269], Kalfogloua i Schorlemmer [270], Noya [271]. Zjawisko dużej różnorodności oraz inne problemy sygnalizowane w tym względzie w wymienionych

pracach, nie powinny mieć zastosowania dla implementowanego systemu. Wynika to głównie z wypracowania unikatowej architektury wspomagającej proces integracji i współdzielenia wiedzy. Pomocne w tym względzie są wspólne interfejsy wraz z procedurami wymiany i współdzielenia ontologii. Problem ten na poziomie technicznym sprowadza się głównie do właściwego współdzielenia terminologii TBox oraz asercji ABox ([272]).

Problem trzeci - ewolucji wiedzy można postrzegać w kategoriach problemu pochodnego 1-3. Mechanizm ewolucji wiedzy definiuje się jako proces rozszerzenia ontologii w przedmiocie terminologii oraz asercji. Proces ten może być oparty na modyfikacji ontologii w sposób automatyczny lub manualny. Stojanovic i in. [273] definiuje ewolucję ontologii jako „adaptację ontologii w związku ze zmianami uwarunkowań biznesowych”. Spójnie z treściami tej rozprawy można przyjąć definicję ewolucji jako zmiana struktury wiedzy w odpowiedzi na oczekiwane, obecnie i przyszłe, potrzeby użytkowników. Ewolucja ontologii z punktu widzenia technicznego będzie rozpatrywana jako zespół operacji modyfikowania ontologii. Klein [274] zwracał uwagę na potencjalne problemy wynikające z procesu ewolucji, do których należą: zapewnienie dostępu do wiedzy i danych, określenie mechanizmów sprawdzenia spójności wiedzy, synchronizacja, transformacja wiedzy, metody zarządzania rozwojem, definiowanie strategii rozwoju, dostarczenie metod edycji. Wyzwaniem dla wskazanych mechanizmów w dalszym ciągu pozostaje opracowanie metod dynamicznej ewolucji ontologii realizowanej w sposób całkowicie autonomiczny. Powyższe stwierdzenie ma swoje uzasadnienie choćby w pracach Haasea i Stojanovic [275], Novaceka i in. [276], Zablitha [277].

Wszystkie przytoczone powyżej rozwiązania pozwalają na dostęp do treści zgromadzonej w rozproszonym i heterogenicznym środowisku internetowym. Ze względu na rozległy charakter niniejszej pracy konieczne jest ograniczenie tego wątku i dokonanie wyboru kilku technik, celem demonstracji proponowanej konstrukcji architektonicznej modułu akwizycji wiedzy. Diagram aktywności dla tego modułu zawarto na Rys. 4.16. Finalnie dokonano implementacji tego modułu zgodnie z diagramem pakietów zawartym na Rys. 4.17.

Uruchomienie procesu Zakończenie procesu Inicjalizacja zlecenia / na podstawie komunikatu _Zdefiniuj parametry procesu /określ cele i priorytety Inicjalizacja środowiska Buduj strategie pozyskania wiedzy / deleguj i podziel zadania Definiuj / Rekonfiguruj wzorzec Definiuj parametry ilościowe i jakościowe Sprawdź gotowość środowiska wykonawczego / identyfikuj metody pozyskania Zatwierdzenie i delegacja procesowa Informuj o statusie Przypisz zasoby / delegacja zasobów / wykonuj Monitoruj procesy [rak zadań / zlecenie stopu] [wymagana poprawa? Lub nowe zlecenia] [zatwierdzenie parametrów]

[wymagana poprawa?]

Informuj o statusie

Rys. 4.16 Architektura procesowa warstwy akwizycji wiedzy. Źródło: Opracowanie własne, (diagram aktywności UML).

Serwery

Środowisko wykonawcze

Serwer Aplikacyjny Serwer Bazodanowy Serwer Bazy wiedzy

Serwer Microsoft IIS Serwer Microsoft SQL Serwer Ontologii

Środowisko programistyczne

<<use>> Testowe środowisko integracji

Środowisko produkcyjne Środowisko metod akwizycji

Artefakty aplikacyjne Metody akwizycji Workflow SP C# Schema aplikacji C# Interface i metody C# <<use>> Ontologia OWL DL Serwer Hurtowni wiedzy

Serwer Hurtowni Ontologii

Środowisko wykonawcze

Rys. 4.17 Koncepcja implementacji warstwy akwizycji wiedzy. Źródło: Opracowanie własne, (diagram komponentów UML).

4.2.4 Moduł zarządzania wiedzą

1. Definicja modułu

System SWD wyposażono w moduł zarządzania wiedzą. Pełni on funkcję centralną dla elementów przechowywania i zarządzania wiedzą w systemie SWD niezbędnych w procesie decyzyjnym. Dane, informacje i wiedza są pozyskiwane w procesie akwizycji, gdzie następuje identyfikacja potencjalnych źródeł użytecznej wiedzy. Następnie identyfikacji podlegają odpowiednie metody jej pozyskania, po czym następuje właściwy proces akwizycji wiedzy. Zasoby pozyskane za pomocą warstwy akwizycji są transferowane do wyższej warstwy - wiedzy. Moduł ten stanowi realizację fizycznej implementacji owej warstwy, który jest optymalizowany zgodnie z dostarczeniem odpowiednich metod przechowywania oraz zarządzania. Na tym poziomie wiedza może podlegać przetworzeniu lub udostępnieniu innym warstwom (może być również kierowana do innych podmiotów, np. na zasadzie odpłatności). Pojęcie zarządzania wiedzą jest postrzegane jako przyjęcie sformalizowanych procedur gromadzenia, użytkowania oraz jej udostępniania w sensie konsumpcji przez wszystkie zainteresowane podmioty. Zarządzanie stanowi próbę efektywnego wykorzystania posiadanych zasobów, tworzenia nowej wiedzy oraz większego przetworzenia (zrozumienia) pozyskanych zasobów i sposobów ich użytkowania (w tym również współdzielenia wiedzy w przypadku cykliczności procesu). W kolejnych rozdziałach zostaną zaprezentowane podstawy merytoryczne zarządzania wiedzą w kontekście SWD.