5.1 Wprowadzenie
W tym rozdziale zaprezentowano autorski system OCS, służący do budowy, wersjonowania, skła-dowania i integrowania ontologii. Zaprezentowano architekturę systemu i jego główne mechanizmy, takie jak metody konwersji reprezentacji ontologii, ich wersjonowanie, czy możliwość współpracy z edytorem Protégé.
W dalszej części rozdziału przedstawiono możliwości wizualizacji za pośrednictwem narzędzia SOVA oraz sposób działania modułu integracji ontologii, wykorzystującego zaproponowany algo-rytm.
System OCS stanowi podstawowe narzędzie wykorzystywane w trakcie analizy, opisanej w ko-lejnym rozdziale, jakości zaproponowanego rozwiązania.
5.2 OCS - Ontology Creation System
System OCS [18, 20, 21, 22], którego głównym konstruktorem jest autor niniejszej rozprawy, służy do konstruowania ontologii w środowisku rozproszonym umożliwiając uzgadnianie wspólnej war-stwy konceptualnej. Opisywany system służy do zespołowego wytwarzania ontologii, a także ich składowania i udostępniania innym systemom.
Podstawową funkcjonalnością systemu jest możliwość edycji ontologii, czyli tworzenia, modyfi-kacji oraz usuwania klas, atrybutów oraz relacji. Ponadto system umożliwia trwałe przechowywanie za jego pomocą tworzonych i modyfikowanych ontologii, a także podgląd i modyfikację na dowol-nym etapie ich konstrukcji. Operacje te odbywają się dzięki zaimplementowadowol-nym mechanizmom wersjonowania podobnych do znanych z np. Subversion [4, 35], jednak operujących na poziomie semantycznym.
Ważnym aspektem systemu jest możliwość pracy zespołowej – narzędzie umożliwia pracę gru-pową nad ontologiami. Modyfikacje do ontologii wprowadzać może dowolny zarejestrowany użyt-kownik. Każda modyfikacja rejestrowana jest jako sugestie zmian, które z kolei muszą zostać zaak-ceptowane przez użytkowników odpowiedzialnych za stan danej ontologii. Dopiero po tym fakcie sugerowane zmiany stają się integralną częścią opracowywanego rozwiązania wchodząc w skład nowej wersji ontologii. Dzięki temu, pomimo pracy nad ontologią dowolnie dużej grupy ludzi, osta-teczne rozwiązanie zachowuje spójność oraz minimalizowane jest ryzyko wprowadzenia fałszywych informacji. Proces korekty konfliktów pomiędzy propozycjami zmian wykonywany jest ręcznie przez autora ostatniej konfliktowej propozycji.
64 Zastosowanie metod integracji ontologii w systemie OCS
W przypadku pracy nad dużymi ontologiami przewidziano możliwość podziału prac między różnych ekspertów, zajmujących się jedynie fragmentami całego rozwiązania. Każdy z ekspertów rozpatruje jedynie swój fragment ontologii z właściwymi mu propozycjami zmian.
Drugim elementem wspomagającym pracę grupową nad ontologią jest forum dołączone do każ-dej z opracowywanych ontologii. Za jego pomocą użytkownicy systemu będą mogli prowadzić dyskusje nad kształtem poszczególnych elementów ontologii, czy kierunku, w jakim zmierzać po-winno docelowe rozwiązanie.
5.3 Architektura systemu
Rysunek 5.1: Architektura systemu OCS
Ogólna architektura portalu zaprezentowana jest na rys. 5.1. System składa się z czterech głównych komponentów. Są to:
• Warstwa integracyjna wraz z bazą danych – odpowiedzialna za przechowywanie ontologii, oraz zarządzanie wersjami ontologii oraz użytkownikami systemu, steruje dostępem do da-nych przechowywada-nych w systemie. Ontologie przechowywane są w bazie dada-nych w postaci zbioru trójek. Ten moduł dostarcza też całej logiki biznesowej związanej z zarządzaniem on-tologiami oraz ich wersjami, dostępem do danych, zarządzaniem użytkownikami itp. Dostęp do przechowywanych w bazie danych odbywa się dwojako: bezpośrednio poprzez EJB lub WebServices oraz za pośrednictwem biblioteki OntologyManager. Zarejestrowany użytkow-nik ma możliwość pobrania dowolnej wersji każdej z ontologii i wykorzystania jej w dowolnym
5.4 Konwersja reprezentacji ontologii 65
zewnętrznym zastosowaniu. Warstwa integracyjna, poprzez mechanizmy tworzenia ontologii, może być wykorzystywana przez systemy automatycznego generowania ontologii na podsta-wie automatycznie przetwarzanych informacji o zewnętrznym śpodsta-wiecie.
• OntologyManager – będący biblioteką przetwarzającą ontologię z postaci trójkowej (przecho-wywanej w bazie danych) do postaci obiektowej wykorzystywanej w samym edytorze, czyli obiektów OWL API [13, 73]. W dużej mierze odpowiada za komunikację z Warstwą inte-gracji opakowując bezpośrednie wywołania poprzez EJB. Dzięki tej bibliotece możliwe jest korzystanie z zasobów repozytorium ontologii bez konieczności samodzielnego konwertowania reprezentacji ontologii z trójkowej na obiektową i odwrotnie. Umożliwia też bezpieczne zdalne połączenie z repozytorium dzięki zastosowaniu szyfrowania SSL do wszystkich przesyłanych komunikatów. Pozwala również na generowanie propozycji zmian, służących do zgłaszania poprawek do ontologii. Poprzez bibliotekę narzędziową dostępne jest całe API udostępniane przez warstwę integracyjną.
• Portal internetowy – strona WWW systemu oraz graficzny edytor ontologii uruchamiany jako aplikacja Java Web Start [116]. Umożliwia pracę offline jak i online – połączenie z siecią konieczne jest jedynie w momencie pobierania projektu z serwera oraz zgłaszania propozycji zmian do ontologii. Umożliwia wizualizację wytworzonej ontologii dzięki zastosowaniu bi-blioteki Prefuse [120]. Z edytorem zintegrowano również bibliotekę wnioskującą Pellet [127], co umożliwia graficzny podgląd pełnej, wywnioskowanej hierarchii rozszerzonej o elementy wyrażone nie wprost za pomocą właściwości obiektów i ich wzajemnych powiązań.
• Moduły zastosowań – będące elementami zewnętrznymi wykorzystującymi w praktycznych zastosowaniach ontologie wytworzone w systemie. Jako moduły zastosowań traktuje się wszystkie zewnętrzne systemy korzystające z repozytorium ontologii zarówno poprzez bez-pośrednie wywołania EJB czy WebServices czy też za pośrednictwem Ontology Managera.
5.4 Konwersja reprezentacji ontologii
Edytor ontologii systemu OCS, podobnie jak pozostałe moduły, korzysta z biblioteki OWL API.
Podczas pracy nad ontologią wszelkie operacje wykonywane są na jej obiektowej reprezentacji, natomiast przechowywanie ontologii możliwe jest dopiero po jej eksporcie. Jako że formaty XML, wspierane przez OWL API, słabo nadają się do przechowywania w bazach danych, podjęto decyzję o wykorzystaniu formatu trójkowego. W formacie tym ontologia jest listą trójek opisujących relację pomiędzy jej elementami. Podejście to pozwala na użycie relacyjnej bazy danych jako repozyto-rium ontologii – każda trójka może być pojedynczym wierszem w tabeli bazy danych. Rozwiązanie to pozwala też na łatwe generowanie i przechowywanie wspomnianych propozycji zmian, bez ko-nieczności przechowywania całej zmienionej ontologii.
W związku z powyższym pojawiła się konieczność konwersji reprezentacji ontologii. Przy jej zapisie, przekształcana jest z postaci obiektowej, używanej w edytorze, do formatu trójkowego, używanego w bazie danych będącej repozytorium ontologii. Przy wczytywaniu ontologii z bazy danych do edytora konieczna jest konwersja odwrotna.
W trakcie odczytu ontologii z bazy pobierana jest lista trójek opisujących ontologię oraz dodat-kowe elementy takie jak jej URI. Tworzona jest pusta ontologia w postaci obiektu obsługiwanego przez OWL API. Następnie trójki z listy są pojedynczo przekształcane na odpowiednie aksjomaty (ang. axiom), czyli relacje wiążące klasy, byty i właściwości wchodzące w skład ontologii, i doda-wane do wcześniej utworzonego obiektu reprezentującego ontologię. Po przetworzeniu wszystkich trójek, obiekt ten zawiera pełną reprezentację ontologii i jest zwracany jako wynik parsowania.
Konwersja odwrotna przebiega analogicznie. Z obiektowej reprezentacji ontologii kolejno od-czytywane są aksjomaty, a następnie generowana jest ich postać trójkowa. W wyniku tej operacji ontologia zwracana jest w postaci listy trójek odpowiadającym wszystkim aksjomatom, a następnie zapisywana w bazie danych.
66 Zastosowanie metod integracji ontologii w systemie OCS
Dzięki trójkowemu formatowi reprezentacji ontologii możliwa jest efektywna implementacja tworzenia, przechowywania, pobierania i wprowadzania zmian ontologii. Tworzenie propozycji odbywa się poprzez porównanie trójkowej reprezentacji ontologii przed i po wprowadzeniu zmian.
Sprowadza się ono do porównania ich w celu ustalenia, które trójki zostały dodane, a które usunięte.
W wyniku tej operacji powstaje lista trójek wzbogacona o informację o konieczności usunięcia bądź dodania danej trójki z reprezentacji ontologii w celu wprowadzenia zmian. Propozycje reprezen-towane w tym formacie są łatwe do przechowania w repozytorium, przygotowanym do obsługi trójek.
Poprzez zapis trójkowy jest również możliwe pobieranie zgłoszonych propozycji zmian oraz prezentowanie ich na obecnie wczytanej ontologii. Trójki te dzielone są na grupę trójek, które należy dodać do ontologii, oraz takich, które należy usunąć z ontologii. Na ich podstawie generowane są odpowiadające im aksjomaty w postaci obiektów OWL API. W kolejnym kroku są one umieszczane na listach AddAxiom i DeleteAxiom. Na tej podstawie, korzystając z metod OWL API, możliwe jest zmodyfikowanie bieżącej ontologii tak, by odzwierciedlała wybrane, bądź wszystkie, zmiany zasugerowane przez użytkowników systemu.
5.5 Praca grupowa nad ontologią
Aby możliwe było sprawne przetwarzanie wiedzy przez wszystkich potencjalnych odbiorców, ko-nieczne jest, by reprezentowała ona wspólne spojrzenie na dane zagadnienie. Człowiek charak-teryzuje się jednak mocno zindywidualizowanym poglądem na otaczającą go rzeczywistość. Stąd konieczne jest, by praca nad ontologią przebiegała w jak najszerszym gronie, pozwalając tym sa-mym na ujednolicenie wizji opisu wybranego fragmentu świata.
System OCS opiera się na założeniu, że w sytuacji, gdy ontologia ma być stosowana przez szerokie gremium odbiorców, proces jej powstawania również powinien obejmować szeroką grupę pomysłodawców [22]. Zakładając system głosowania przyjęty w Collaborative Protégé [131] au-tor ontologii może łatwo stracić kontrolę nad kierunkiem jej tworzenia a ostateczny efekt może całkowicie odbiegać od przyjętych założeń. Stąd w proponowanym rozwiązaniu uprzywilejowany użytkownik, będący twórcą ontologii, lub ich grupa nominowana przez twórcę ontologii ma prawo akceptować zmiany w ontologii. Każdy inny użytkownik ma prawo zgłaszać propozycje zmian do dowolnej z ontologii, jednak nie zostaną one uwzględnione aż do etapu akceptacji zmian.
Rysunek 5.2: Proces zgłaszania propozycji zmian oraz tworzenia nowych wersji ontologii w systemie OCS
W przypadku ontologii publicznych, których rozwój nie jest nadzorowany, proces zgłaszania propozycji może być również połączony z tworzeniem nowej wersji, realizując algorytm znany z repozytoriów kodu, np. Subversion [10] ale w ujęciu semantycznym. W tym przypadku każdy użytkownik ma prawo tworzenia nowej wersji, a zgłoszone przez niego zmiany są automatycznie zatwierdzane.
5.6 Wersjonowanie ontologii 67
Oba powyższe procesy zostały przedstawione na rys. 5.2. Należy pamiętać, że podobnie jak to ma miejsce w przypadku repozytoriów kodu, to użytkownik tworzący nową wersję odpowiedzialny jest za zachowanie spójności ontologii.
5.6 Wersjonowanie ontologii
Kolejnym istotnym aspektem pracy grupowej nad ontologią jest możliwość śledzenia zachodzących w niej zmian oraz dostęp do dowolnej wcześniejszej wersji ontologii. Obie te operacje są możliwe dzięki zastosowaniu języka OWL, a tym samym oparciu konstrukcji ontologii na trójkach RDF [14, 29].
W systemie ontologie składowane są jako trójki pogrupowane w poszczególne wersje (rys. 5.3).
W tym modelu raz zapisana krotka pozostaje w systemie aż do usunięcia ontologii.
Rysunek 5.3: Sposób składowania ontologii w systemie OCS
Umożliwia to bezpośrednie uzyskanie dostępu do dowolnej z wersji ontologii bez konieczno-ści przetwarzania danych historycznych. Również porównanie dwu wersji ontologii na poziomie semantycznym wymaga jedynie porównania dwóch zbiorów trójek i określeniu różnic pomiędzy nimi. Wynik takiego porównania może zostać następnie przekształcony w aksjomaty języka OWL.
5.7 Zgodność z edytorem Protégé
Autor, chcąc skorzystać z bogatej funkcjonalności oraz popularności edytora Protégé, rozszerzył jego funkcjonalność o możliwość pracy grupowej opartej na przepływie zadań opracowanym dla systemu OCS. Rozszerzenie to obejmuje funkcjonalność pobierania dowolnej wersji ontologii z ser-wera i wysyłania propozycji zmian. Są to czynności niezbędne dla zwykłego użytkownika modyfi-kującego ontologię. Poprzez edytor Protégé właściciel ontologii ma możliwość dodawania nowych ontologii i tworzenia ich kolejnych wersji.
Programiści Protégé umożliwili dodawanie nowych funkcji do edytora poprzez moduł obsługi
„wtyczek” (ang. plugin) [90]. Ponadto, zarówno system OCS jak i edytor Protégé, do operowania na ontologiach wykorzystują bibliotekę OWL API. Biblioteka ta dostarcza manager ontologii, po-zwalający m.in. na wczytywanie i zapis plików ontologii. Pozwala również na edycję składowych wczytanych ontologii. Klasa managera w systemie OCS (PGOWLOntologyManager) jest rozsze-rzeniem klasy z biblioteki OWL (OWLOntologyManger) o funkcje pozwalające na komunikację z serwerem składującym i wersjonującym ontologie. Zezwala również na zarządzanie i uwierzy-telnianie użytkowników, pobieranie ontologii o zadanym URI, porównywanie ontologii, czy też
68 Zastosowanie metod integracji ontologii w systemie OCS
wysyłanie propozycji zmian. Przestawioną architekturę wtyczki zaprezentowano na rys. 5.4.
Rysunek 5.4: Architektura wtyczki integrującej edytor Protégé z systemem OCS
W celu zachowania kompatybilności wtyczki z systemem OCS interfejs użytkownika został przeniesiony z systemu OCS. Zachowano również zgodność plików projektu, dzięki temu możliwe jest edytowanie tego samego projektu zarówno w Protégé, jak i w edytorze OCS.
5.8 Wizualizacja ontologii
Proces wytwarzania ontologii jest procesem złożonym. Ilość elementów wchodzących w skład nawet niewielkiej ontologii może być bardzo duża. Aby wspomóc ten proces, na potrzeby systemu OCS utworzono bibliotekę wizualizacji ontologii o nazwie SOVA (Simple Ontology Visualization API) [21]. Biblioteka ta umożliwia pełną wizualizację złożonych ontologii w postaci grafu, którego wierzchołkami są klasy, byty oraz właściwości, a krawędziami relacje zachodzące pomiędzy tymi składowymi.
Biblioteka SOVA miała na celu umożliwić wizualizację wszystkich elementów wchodzących w skład ontologii, co umożliwia szybsze wychwycenie błędów i niedoróbek wynikających z użycia niepoprawnych konstrukcji języka OWL. Przygotowano więc zestaw symboli graficznych odpowia-dających każdemu możliwemu elementowi w dilekcie DL języka OWL.
Symbole reprezentujące klasy (ang. Class), właściwości (ang. Property) oraz typy danych (ang.
DataType) mają kształt prostokąta z zaokrąglonymi krawędziami, gdyż wszystkie one współdzielą podobne rodzaje relacji. W celu dalszego uproszczenia identyfikacji typu elementu różnią się one kolorem oraz promieniem zaokrąglenia wierzchołka. Byty (ang. Individual), jako elementy wcho-dzące w odmienne relacje, posiadają ostre wierzchołki. Symbole te prezentuje rys. 5.5.
Rysunek 5.5: Symbole reprezentujące klasy (a), właściwości (b), typy danych (c) oraz byty (d) Największym wyzwaniem przy wizualizacji ontologii jest prezentacja klas anonimowych. W przy-padku biblioteki SOVA, wszelkie relacje wprowadzające klasy anonimowe przedstawiane są jako
5.8 Wizualizacja ontologii 69
dodatkowy wierzchołek w postaci żółtego koła z wpisaną literą „A”, gdy jest to niezależna klasa ano-nimowa, lub graficznym symbolem precyzującym typ relacji tworzącej klasę anonimową (rys. 5.6).
W przypadku przecięcia (ang. intersection), komplementarności (ang. complementarity), unii (ang. union) oraz liczności (ang. cardinality) zastosowano ogólnie znane symbole matema-tyczne, czyli odpowiednio: T, ¬, S, N. W przypadku relacji liczności dodatkowe wierzchołki re-prezentują wartość minimalnej, maksymalnej lub dokładnej liczności (ang. min, max oraz equal cardinality).
Analogicznie postąpiono w przypadku relacji zachodzących pomiędzy bytami, z tym że koła mają odmienny kolor. Symbol z wpisanym znakiem = reprezentuje relację tożsamości (ang. sa-meAs), a 6= relację rozłączności, zarówno w wersji jeden do jeden (ang. differentFrom) jak i wiele do wiele (ang. allDifferent).
Rysunek 5.6: Przykładowe symbole prezentujące klasy anonimowe (a), przecięcie (b), minimalną i maksymalną liczność (ang. cardinality) (c), relację tożsamości (d) oraz relację rozłączności (e)
Klasy anonimowe są również wykorzystywane do zobrazowania relacji „owl:-allValuesFrom”
oraz „owl:someValuesFrom” (rys. 5.7). Relacja „owl:allValues-From” zdefiniowana jest następu-jąco: jeżeli dana jest klasa bytów x, dla których para (x, y) jest instancją właściwości P opisanej tą relacją, to y powinno być wystąpieniem klasy będącej przeciwdziedziną właściwości lub ty-pem danych. Z kolei relacja „owl:someValuesFrom” definiuje klasę bytów x, dla których istnieje przynajmniej jeden y, będący instancją klasy lub wartością, dla którego para (x, y) jest instancją właściwości P opisanej tą relacją. Klasa anonimowa łączona jest krawędzią z wykorzystywaną właściwością.
Klasa będąca dziedziną właściwości połączona jest z nią strzałką wychodzącą od klasy i wskazu-jącą na właściwość. W zależności od relacji nazwa właściwości poprzedzana jest kwantyfikatorem ogólnym (dla „owl:allValuesFrom”) lub szczegółowym (dla „owl:someValuesFrom”). Strzałka pro-wadząca od właściwości wskazuje jej przeciwdziedzinę, która może być klasą, zarówno prostą jak i dowolnie złożoną reprezentowaną przez klasę anonimową, lub bytem. Dodatkowo, w celu zacho-wania spójności grafu, właściwości połączone są z ich definicjami linią ciągłą.
Relacje proste są w SOVA reprezentowane za pomocą linii z różnymi grotami. W ogólności kie-runek strzałek wskazuje kiekie-runek czytania danego aksjomatu. Tam, gdzie kiekie-runek nie jest istotny, groty zostały pominięte, by zwiększyć czytelność wizualizacji. Niektóre relacje zaprezentowano na rys. 5.8.
Tam, gdzie to było możliwe, wykorzystano istniejącą notację języka UML. Relacje dziedzicze-nia klas („subClass”) oraz właściwości („subProperty”) reprezentowane są poprzez strzałki z pu-stymi grotami. Tożsamość (ang. equivalent) oraz rozłączność (ang. disjoint) reprezentowane są poprzez linie ze strzałkami zwróconymi w przeciwne strony w celu podkreślenia ich przeciw-stawności. W przypadku definicji właściwości, odwrotność oznaczona jest poprzez czerwony kolor strzałki. Rodzaj strzałki uzależniony jest od symetryczności danej relacji. Tożsamość właściwości
70 Zastosowanie metod integracji ontologii w systemie OCS
Rysunek 5.7: Przykładowa reprezentacja relacji „someValuesFrom” oraz „allValuesFrom”
odróżniona jest od tożsamości klas innym kolorem strzałki.
Dziedzinę (ang. domain) oraz przeciwdziedzinę (ang. range) właściwości dodatkowo zaprezen-towano jako osobne groty (rys. 5.8 e oraz f).
Rysunek 5.8: Przykładowa reprezentacja relacji: rdfs:subclassOf (a), instanceOf (b), owl:equivalentClass (c), owl:disjointWith (d), rdfs:domain (e) oraz rdfs:range (f)
5.9 Łączenie ontologii
System OCS, w jednej z ostatnich faz rozwoju, rozbudowany został o możliwość integracji onto-logii. Interfejs użytkownika został rozszerzony o możliwość prezentacji trzech ontologii: dwóch integrowanych (centralna i prawa część interfejsu) oraz wynikową (lewa część interfejsu). Przykła-dowy zrzut ekranu interfejsu modułu integracji zaprezentowano na rysunku 5.9. Każda z ontologii prezentowana jest w postaci drzewa znanego np. z edytora Protégé.
Pomiędzy dwoma integrowanymi ontologiami znajdują się przyciski, umożliwiające szybkie do-danie lub usunięcie relacji wiążących elementy obu ontologii. Zestaw przycisków zmienia się w za-leżności od typu elementów (klas, bytów i właściwości). Odpowiednie przyciski (dodawania lub usuwania relacji) są włączane i wyłączane w zależności od tego, czy dana relacja została już dodana czy nie. Analogicznie włączane i wyłączane są przyciski umożliwiające usunięcie wskazanej relacji.
Przełączenie w tryb podglądu umożliwia z kolei pokazanie wszystkich relacji, w jakich wybrany element jednej z ontologii znajduje się względem elementów drugiej ontologii (rys. 5.10).
5.9 Łączenie ontologii 71
Rysunek 5.9: Interfejs modułu integracji ontologii systemu OCS – tryb edycji relacji
Rysunek 5.10: Interfejs modułu integracji ontologii systemu OCS – tryb podglądu relacji
72 Zastosowanie metod integracji ontologii w systemie OCS
W przypadku, gdy zachodzi konieczność dodania lub zmodyfikowania któregoś z elementów wynikowej ontologii, lub wprowadzenia innej, bardziej złożonej relacji, użytkownik może to zrobić bezpośrednio korzystając z menu kontekstowego drzewa zawierającego wynikową ontologię.
Finalną ontologię można zapisać w osobnym pliku na dwa sposoby. Jeden z nich to zachowanie oryginalnych URI obu ontologii i korzystanie z mechanizmu importowania dostępnego w języku OWL, tworząc tym samym odwzorowanie elementów jednej ontologii w drugą. Drugi sposób po-lega na eksporcie połączonej ontologii oraz zmianie URI ontologii źródłowych na URI ontologii wynikowej.
System OCS został również rozbudowany o implementację proponowanego w niniejszej rozpra-wie algorytmu. Integrując drozpra-wie ontologie użytkownik może wygenerować powiązania pomiędzy ich elementami wywołując algorytm poprzez menu „Plik” –> „Integracja” –> „Tworzenie Odwzoro-wań” (rys. 5.11).
Rysunek 5.11: Interfejs modułu integracji ontologii systemu OCS – aktywacja algorytmu Po potwierdzeniu algorytm rozpoczyna pracę. W jej wyniku zastąpione zostaną wszystkie dotychczasowe powiązania nowymi wygenerowanymi przez algorytm. System OCS na bieżąco informuje o wykonywanych czynnościach, gdyż w przypadku dużych ontologii wywołanie algorytmu może zająć dużo czasu (rys. 5.12).
Rysunek 5.12: Interfejs modułu integracji ontologii systemu OCS – informacja o działaniu algo-rytmu