Wykorzystanie metamodelowania do specyfikacji ontologii znaczenia opisów rzeczywistości

We wczesnych etapach projektowania systemów informatycznych zachodzi często potrzeba zrozumienia fragmentu rzeczywistości, którą projektowany system będzie informatyzował, a która jest obca twórcom systemu. Różne metodyki projektowania systemów, m.in. USDP (Unified Software Development Process) [BJR1999b], zalecają utworzyć model biznesowy tej rzeczywistości, który w sposób sformalizowany opisuje zdobytą o niej wiedzę. Często głównym źródłem wiedzy są różne dokumenty tekstowe, które będą dalej nazywane opisami rzeczywistości. Proces pozyskania z nich wiedzy narażony jest na różne trudności związane z obszernością tych dokumentów oraz ich specjalistycznym językiem. W [HŁ2002b] zostało opisane narzędzie wspomagające ten proces przez systematyczną analizę znaczenia tekstu opisu, identyfikację wieloznaczności i niespójności oraz automatyczne generowanie modelu biznesowego w postaci diagramu przypadków użycia i diagramu klas języka UML [BJR1999a]. Niniejszy artykuł opisuje metodę specyfikacji znaczenia opisów rzeczywistości oraz aspekty związane jej z implementacją i wykorzystaniem do wspomagania generacji modelu biznesowego.

Opracowano wiele sposobów wyrażania znaczenia zdań w języku naturalnym. Najbardziej ogólny podział wyróżnia podejścia prawdziwościowe, które wiążą znaczenie zdań z warunkami (wyrażonymi w języku logiki), jakie muszą zajść, aby było ono prawdziwe, oraz podejścia „bazowiedzowe”, w których znaczenie zdania jest zawartą w nim wiedzą, dodawaną do pewnej bazy wiedzy.W praktycznych zastosowaniach modelowania znaczenia, gdzie najczęściej jednym z głównych podzadań jest pozyskanie wiedzy z danego tekstu, naturalnym jest rozumienie znaczenia jako wiedza zawarta w analizowanym tekście. Podejście prawdziwościowe nastręcza problemów zarówno implementacyjnych, jak również nie jest wolne od trudności teoretycznych. Pierwszym postulatem jest więc rozumienie znaczenia jako wiedzy o rzeczywistości opisywanej w tekście.

Odejście od ujęcia znaczenia w terminach logiki z jednej strony daje dużą swobodę konstruowania jego modeli, nieskrępowaną ograniczeniami języka logiki, z drugiej strony często oznacza niski stopień sformalizowania ich struktury oraz brak wyraźnego związku między nimi a rzeczywistością i jej pojmowaniem przez człowieka. Przy poszerzeniu repertuaru uwzględnianych konstrukcji językowych nieuchronnie grozi to problemami z pielęgnacją i rozwijaniem zarówno struktur modeli znaczenia, jak i procedur je tworzących i wykorzystujących. Dlatego postulowane jest, aby struktura modeli znaczenia przejawiała łatwy do wskazania związek ze strukturą rzeczywistości, a dokładnie ze sposobem jej pojmowania przez odbiorców tekstów. Istotna jest też możliwość łatwego rozwijania struktur modeli znaczenia w celu uwzględnienia nowych zjawisk językowych. Łatwość ta dotyczy przede wszystkim opracowania koncepcyjnego zmian w modelach znaczenia, ale także późniejszej implementacji struktur reprezentujących te modele oraz procedur je tworzących i przetwarzających.

Jednym z uznanych, a ostatnio cieszącym się dużą popularnością, sposobem formalizacji wiedzy są ontologie. Termin ontologia pojawia się w kontekście informatycznym już w roku 1967 w pracach S. H. Mealy’ego dotyczących modelowania danych, ale dopiero w dobie morza informacji dostępnych w Internecie i konieczności jej wymiany i przetwarzania zyskał szersze zainteresowanie. Ontologia zajmuje się odkrywaniem i opisywaniem „tego co jest” – w rzeczywistości, w umysłach ludzi i zapisanego w postaci różnych symboli (za S. H. Mealy’m). Ontologia zawsze zajmuje się pewnym fragmentem rzeczywistości – mniej lub bardziej dokładnie określonym. Wyróżniają się tu “wyższe ontologie” (upper ontologies) – opisujące najbardziej podstawowe klasy bytów całej rzeczywistości.Ontologia musi być wyrażona w pewnym języku. Używane są języki nawiązujące do języka logiki, np. KIF (Knowledge Interchange Format) [GF1992], Description Logic[FRAN], do sieci semantycznych, np. RDF (Resource Definition Framework) [LS1999], oraz języki projektowania systemów informatycznych, zwłaszcza UML, np. w pierwszej wersji ontologii prezentowanej w tej pracy [HŁ2002a] oraz w GOL (General Ontological Language) [GHW2002].

Język logiki ma tę wadę w zastosowaniu do wyrażania ontologii, że traktuje właściwości obiektów i relacje między nimi ekstensjonalnie, tzn. pojęcia te nie mają tożsamości a są utożsamiane ze zbiorami odpowiednio obiektów i ich krotek. Uniemożliwia to wyspecyfikowanie cech tych pojęć, np. właściwości relacji takiej, jak wyrażona przez przysłówek uprzejmie w zdaniu

(1) Sprzedawca uprzejmie obsługuje klienta.

Bez tego przysłówka znaczenie zdania można reprezentować jako

(2) obsługuje(sprzedawca, klienta)

Ponieważ relacje nie mają tożsamości, przysłówek modyfikujący czasownik musi być funkcją, która zmienia relację obsługuje w nową relację

(3) uprzejmie(obsługuje)(sprzedawca, klienta)

Przy bogatszym opisie konstrukcje tego typu szybko stają się skomplikowane i trudne do dalszego przetwarzania. Problem ten można obejść stosując reifikację, tzn. nadać właściwościom i relacjom tożsamość (taką, jaką mają obiekty), np. przez zamianę danego predykatu, na uniwersalny predykat (np. holds), którego pierwszym argumentem jest nazwa predykatu, a pozostałymi jego argumenty, a następnie opisać właściwości predykatu, używając jego nazwy jako argumentu predykatu reprezentującego właściwość.

(4) holds( obsługuje, sprzedawca, klienta )
   uprzejmie( obsługuje )

Zapis taki staje się jednak nieczytelny dla większych ontologii, a samo jego tworzenie jest dosyć uciążliwe.Bardzo prosty, ale za to uniwersalny schemat proponuje RDF. Podstawowym pojęciem jest zasób (resource), którym może być wszystko, co ma adres URI (Uniform Resource Identyfier) zgodny z zaleceniami konsorcjum W3C. Zasób może mieć właściwości, które identyfikowane są przez URI i których wartościami są zasoby. Tworzą się trójki: zasób – właściwość – wartość. Używając tego schematu jako bazy, zdefiniowane zostały różne pojęcia służące do definiowania i opisywania coraz bardziej złożonych pojęć. Przykładem takiego systemu pojęć zbudowanym na bazie RDF’a jest DAML+OIL [DAML].

Jako język specyfikacji ontologii używany jest także diagram klas języka UML. W tym przypadku istnieją dwie możliwości: albo klasy reprezentują klasy bytów, a asocjacje – relacje między nimi, albo klasy reprezentują także właściwości i relacje (reifikacja tych pojęć). Przy pierwszym rozwiązaniu występują problemy podobne do tych, jakie napotyka się używając języka logiki do specyfikacji ontologii. Istnieją próby rozszerzenia języka UML, aby zaradzić tym problemom (np. [BAC2001]), ale reifikacja wydaje się wygodniejszym narzędziem w przypadku, gdy potrzeba bardziej szczegółowo opisać same właściwości i relacje. Wadą wykorzystania języka UML do specyfikacji ontologii jest to, że został on zaprojektowany z myślą o zupełnie innych zadaniach i w związku z tym jego semantyka jest inna od semantyki ontologii.

Aby spełnić postulaty opisane w sekcji 2.1. proponuje się wyspecyfikować struktury modeli znaczenia reprezentujących wiedzę zawartą w tekście w postaci ontologii, a samą ontologię wyrazić w języku opisanym przez dedykowany metamodel zdefiniowany w języku MOF (Meta Object Facility [MOF]). Modele znaczenia konkretnych tekstów są wtedy instancjami ontologii traktowanej jako model modeli znaczenia. Tabela 1. przedstawia standardową czterowarstwową hierarchię metamodeli danych wykorzystaną do specyfikacji znaczenia z użyciem ontologii.

Dla porównania tabela 2. przedstawia hierarchię metamodeli dla języka UML.Język MOF jest opracowany przez OMG (Object Management Group) jako uniwersalny język wspierający specyfikacje w paradygmacie obiektowym. W nim jest m.in. wyrażony metamodel języka UML, który z kolei stanowi gramatykę języka UML. Tak samo metamodel ontologii znaczenia specyfikuje gramatykę języka definiowania ontologii. Wyrażenia tego języka mają postać sieci semantycznej. Aktualny stan metamodelu ontologii przedstawia rysunek 1.

Specyfikacja ontologii składa się ze zbioru węzłów (node), które są podstawowymijednostkami wiedzy. Każdy węzeł ma nazwę (Name) identyfikującą węzeł i zbiór atrybutów (attribute), których wartościami są napisy stanowiące treść danej jednostki wiedzy. Różne związki pomiędzy jednostkami wiedzy opisywanymi przez węzły mogą być wyrażane przez relacje nazywane połączeniami (link). Każde połączenie ma nazwę (Name), jest dwustronne, asymetryczne – wychodzi z jednego węzła i wchodzi do drugiego. Dla obu węzłów określona jest krotność ich uczestniczenia w danym połączeniu. Węzły mogą tworzyć hierarchię specjalizacji-generalizacji (Sub–Super). Węzeł będący specjalizacją innego, dziedziczy wszystkie właściwości tamtego, to jest atrybuty i połączenia.

Notacja języka ontologii nawiązuje do diagramu klas języka UML: węzły reprezentowane są jako klasy z atrybutami i ewentualnie relacją generalizacji, połączenia – jako asocjacje nawigowalne w jedną stronę. W następnym podrozdziale znajduje się diagram ontologii znaczenia opisów rzeczywistości.

Rysunek 2. przedstawia aktualny stan ontologii znaczenia opisów rzeczywistości. Ontologia ta powstaje przez analizę występujących w tekstach opisów rzeczywistości pojęć, semantyki występujących w tych tekstach wyrażeń, zjawisk semantycznych uwzględnianych przez teorie semantyczne (prace Kampa [KR1993], Hessa [HESS1989], Piaseckiego [PIAS2002]) oraz z uwzględnieniem istniejących wyższych ontologii (upper ontologies) (Cyc [CYC], WordNet [MILL1993], GOL), języków specyfikacji ontologii (RDF) oraz konstrukcji występujących w metamodelu języka UML. Wyróżnia ją przede wszystkim to, że jest ontologią nie świata, ale znaczenia tekstów opisujących go.

Podstawowym węzłem jest pojęcie (Concept), ale istnieją węzły, które nie są jego specjalizacją (węzeł _uczestnik – _participant) Pojęcie ma trzy specjalizacje: byt(Entity), właściwość (Property) i relacja (Relation). Każde pojęcie ma atrybut termin(Term), którego wartością jest indeks do lingwistycznych baz wiedzy: składniowych i semantycznych. Bazy pierwszego rodzaju przechowują informacje potrzebne do poprawnej analizy składniowej zdań, natomiast bazy drugiego rodzaju – informacje o przynależności danych terminów do grup semantycznych (np. dla rzeczowników: osoba, określenie grupy, inne; dla czasowników: stan, zdarzenie). Informacje te są wykorzystywane podczas tworzenia modelu znaczenia dla danego tekstu. Niektóre bardziej szczegółowe rodzaje pojęć mogą nie wykorzystywać tego atrybutu (np. byty złożone opisane niżej).Zakłada się, że opisy rzeczywistości nie opisują pewnego jej konkretnego stanu, ale wzorce możliwych stanów (mówiąc w terminach modelu biznesowego: odpowiadają im diagramy klas, a nie obiektów). W związku z tym byty rozumiane są jako abstrakcje (klasy) bytów konkretnych. Byty mogą być pojedyncze (SingleEntity) i złożone (ComplexEntity), przy czym te drugie rozumiane są jako skończony zbiór bytów prostych. Byt prosty może mieć określony byt nadrzędny (super), który jest bardziej ogólną klasą bytów konkretnych. Byty mogą mieć właściwości (ConceptProperty) oraz mogą być powiązane relacjami (EntityRelationship), które są specjalizacją pojęcia relacji. Byty uczestniczą w relacji za pośrednictwem pomocniczego węzła uczestnik(_participant) (odpowiednik roli w języku UML), który pozwala określić nazwę roli, jaką dany byt pełni w relacji, oraz krotność, z którą w niej uczestniczy.

Byt pojedynczy może być określony albo przez termin, albo przez termin główny (atrybut Main) i połączenia ma (has) z właściwościami oraz połączenia identyf z relacjami, które są identyfikujące dla danego bytu. Drugi sposób jest wykorzystywany do modelowania wyrażeń rzeczownikowych typu meble kuchenne, urządzenia mające numer seryjny. Termin główny modeluje główny rzeczownik wyrażenia (mebel iurządzenie), natomiast połączenia z właściwościami i relacjami – jego określenia (właściwość kuchenne i relacja ma między urządzeniem i numerem seryjnym). Relacje identyfikujące (oraz właściwości) oprócz tego, że opisują dany byt, pozwalają go odróżnić od bytu bardziej ogólnego (meble kuchenne od klasy wszystkich mebli iurządzenia z numerem seryjnym od wszystkich urządzeń). Istotne jest więc odróżnienie relacji identyfikujących od pozostałych. Poniższe dwa zdania mają podobne znaczenie, ale relacja ma między samochodem (lub limuzyną) a dużym silnikiem jest w pierwszym zdaniu opisowa, a w drugim identyfikująca.

(5) Limuzyny mają klimatyzację i są drogie.

(6) Samochody, które mają klimatyzację, są drogie.

Modelowanie relacji identyfikujących przez dodatkowe połączenie identyf ma tę zaletę, że relacje identyfikujące, które mają w stosunku do relacji opisowych dodatkową właściwość identyfikowania klas, są modelowane przez dodatkowy element ontologii, co pozwala jednolicie traktować wszystkie relacje tam, gdzie jest to wskazane. Z drugiej strony połączenie od bytu do jego relacji identyfikujących pozwala wygodnie porównywać ze sobą dwa byty w przypadku, gdy mają ten sam termin główny. Wynikiem tego porównania może być tożsamość obu bytów, zachodzenie relacji generalizacji między jednym a drugim lub brak związku. Relacja generalizacji będzie wynikiem porównania na przykład bytu samochód z bytem samochód z klimatyzacją, a brak związku – dla bytów samochód z klimatyzacją i samochód terenowy.Kolejnym charakterystycznym elementem proponowanej ontologii jest możliwość połączenia właściwości z relacją. W ten sposób można wygodnie modelować różne wyrażenia dodatkowo opisujące relacje, takie jak przysłówek uprzejmie w zdaniu (1).

Zakłada się, że w opisach rzeczywistości aspekt dynamiczny ograniczony jest do akcji (Action) – zdarzeń inicjowanych przez pewien byt. Są one modelowane są jako relacje między bytami, które w danym zdarzeniu uczestniczą. Między akcjami mogą występować proste zależności czasowe typu „akcja A po akcji B”, modelowane za pomocą relacji między akcjami (ActionRelation).

W celu maksymalnego ułatwienia rozwijania ontologii oraz implementacji struktur reprezentujących jej instancje – modele znaczenia, ontologia rozwijana jest w środowisku CASE do języka UML jako diagram klas, według przyjętej notacji. Implementacja ontologii tworzona jest automatycznie w następujący sposób. Z diagramu klas generowane są klasy języka C++ z wykorzystaniem standardowego mechanizmu generacji kodu programu CASE. Następnie prosty analizator wygenerowanych plików przetwarza je, dodając metody dostępu do atrybutów i połączeń między węzłami. Cały generowany kod wykorzystuje zaimplementowaną ręcznie sieć semantyczną, której struktura odpowiada metamodelowi ontologii. Implementacja sieci zapewnia też mechanizmy niezależne od struktury ontologii: sprawdzanie zawierania się jednej sieci semantycznej w drugiej oraz generowanie nowych faktów (elementów sieci) za pomocą prostych reguł składających się ze wzorca sieci, którego dopasowanie uaktywnia regułę i elementów do wygenerowania. Mechanizmy te opisane zostały w [HŁ2002a] oraz [HŁ2002b]. Pozwalają one wspomagać przetwarzanie tekstów przez wykrywanie niespójności oraz eliminowanie wieloznaczności.Wygenerowana implementacja ontologii jest używana jako struktury reprezentacji znaczenia w rozwijanym przez autora systemie wspomagania modelowania biznesowego [HŁ2002b]. Zmiany w ontologii są automatycznie propagowane na jej implementację, zwykle wymagają niewielkich zmian w procedurach tworzących model znaczenia, a ewentualne niezgodności między nimi a ontologią wykrywane są już na etapie kompilacji systemu.

Tworzony system analizuje kolejne zdania tekstu opisu rzeczywistości i stopniowo tworzy model jego znaczenia dodając kolejne jego elementy. Po przeanalizowaniu całego tekstu, na podstawie utworzonego modelu jego znaczenia, generowany jest diagram klas oraz diagram przypadków użycia opisujące odpowiednio strukturę rzeczywistości oraz występujące w niej procesy, a także jego tekstowa parafraza mogąca służyć walidacji wygenerowanych diagramów przez ekspertów dziedzinowych nie znających języka UML. Podczas analizy system wykrywa w tekście błędy i wieloznaczności o charakterze składniowym, semantycznym i pragmatycznym. Funkcje te zostaną zilustrowane na przykładzie następującego mini-opisu:

(7) Biblioteka składa się z wypożyczalni i czytelni.

(8) Książki są dostępne w wypożyczalni i czytelni.

(9) Czasopisma i gazety dostępne są w czytelni.

(10) Nowe książki dostępne w wypożyczalni przyjmuje pracownik wypożyczalni.

(11) Nowe książki dostępne w czytelni przyjmuje pracownik czytelni.

(12) Przyjmując nową książkę, pracownik zakłada jej kartę katalogową,
    która zawiera jej tytuł, autora i liczbę stron.

(13) Książki dostępne w wypożyczalni wypożycza czytelnikowi
    pracownik wypożyczalni.

(14) Książki dostępne w czytelni może wypożyczyć czytelnikowi 
    każdy pracownik biblioteki.

(15) Rejestrując nowego czytelnika, pracownik zakłada mu kartę 
    zawierającą imię, nazwisko i adres czytelnika oraz numer 
    jego dowodu lub legitymacji.

(16) Nowych czytelników może rejestrować pracownik wypożyczalni.

(17) Pracownik wypożyczalni może wypożyczyć książki czytelnikom,
    którzy nie zalegają ze zwrotem książek lub opłatą kary.

(18) Pracownik czytelni może wypożyczyć książkę każdej osobie,
    która wpisze swoje imię i nazwisko oraz numer dowodu lub legitymacji
    do księgi odwiedzin czytelni.

W dalszej części rozdziału będzie używana następująca skrótowa notacja elementów modeli znaczenia:

• [X] – byt o nazwie X;

• [X] → [Y] – byt Y jest bytem nadrzędnym bytu X (jest ogólniejszy niż X);

• [A](1) –[Rel]– (1..*)[B] – relacja binarna Rel między bytami A i Buczestniczącymi w niej z podanymi krotnościami; brak nawiasów z określeniem liczności oznacza krotność 1, a znak zapytania – krotność nieokreśloną;

• [A] –[Rel_a]– (1..*)[B] –[Rel_b]– [C] – relacja ternarna o nazwie Rel_a Rel_bmiędzy bytami A, B i C;

• ~( F ) – zaprzeczenie faktu F.

W zdaniu (7) wykryta zostanie wieloznaczność składniowa polegająca na wieloznaczności interpretacji liczby gramatycznej rzeczowników wypożyczalni i czytelni, która wiąże się z odpowiedzią na pytanie ile jest czytelni i wypożyczalni i przekłada się na krotność relacji składa się z zachodzącej między bytem biblioteka a bytemwypożyczalnia (i analogicznie dla bytu czytelnia):

(19) [[biblioteka] –[[składa się z]– [[wypożyczalnia]

lub

(20) [[biblioteka] –[[składa się z]– (1..*)[[wypożyczalnia].

Dla zdań (7) – (12) zostanie wygenerowany model znaczenia, który można zobrazować diagramem przedstawionym na rysunku 3. (przedstawione zostały wybrane elementy modelu).W zdaniu (15) rzeczownik pracownik zostanie zinterpretowany jako odnoszący się do frazy pracownik biblioteki występującej w poprzednim zdaniu (zjawisko nazywane anaforą) i zostanie wygenerowany m.in. następujący fakt:

(21) [[pracownik biblioteki] –[[rejestruje]– [[czytelnik].

Natomiast dla zdania (16) zostanie wygenerowane:

(22) [[pracownik wypożyczalni] –[[rejestruje]– [[czytelnik].

Z konstrukcji zdania (16) (szyk oraz użycie czasownika może) wynika, że dla innych bytów, zwłaszcza tych, które mają wspólny z bytem pracownik wypożyczalni byt nadrzędny, powyższa relacja nie zachodzi, czyli

(23) ~( [[pracownik czytelni] –[[rejestruje]– [[czytelnik] ).

Ale jednocześnie

(24) [[pracownik czytelni] → [[pracownik biblioteki]

więc z (21) można wywnioskować, że

(25) [[pracownik czytelni] –[[rejestruje]– [[czytelnik].

i otrzymujemy sprzeczność (23) z (25). Wykrycie tej sprzeczności i zasygnalizowanie jej użytkownikowi systemu pozwoli uściślić tekst i uniknąć błędu niewłaściwego przypisania uprawnień (przy tak małym tekście prawdopodobieństwo tego rodzaju błędów jest oczywiście znikome, ale wraz ze wzrostem rozmiaru opisu rośnie ono znacząco).

Dla zdania (14) zostanie wygenerowany m.in. fakt:

(26) [[pracownik bibl.]? –[[wypożycza]– ?[[książka dost. w czytelni]
    –[[komu]– ?[[czytelnik], 

natomiast dla zdania (18):

(27) [[pracownik czytelni]? –[[wypożycza]– ?[[książka] –[[komu]– ?[[osobie, ...].

Porównanie i utożsamienie tych dwóch faktów, może doprowadzić do zasygnalizowania sytuacji potencjalnie niebezpiecznej pragmatycznie – niezbyt ścisłego użycia terminuczytelnik w zdaniu (14), który, jak pośrednio wynika ze zdań (15) i (16), dotyczy tylko klientów wypożyczalni. Fakt ten jest ukryty w znaczeniu występujących w tych zdaniach terminów, znalazł jednak odzwierciedlenie także w użyciu terminu osoba w zdaniu (18) i dzięki temu może zostać wykryta niekonsekwencja zawarta w zdaniu (14).Dla powyższego opisu zostanie wygenerowany diagram klas, będący diagramem przedstawionym na rysunku 3. uzupełnionym o fakty ze zdania (15) i kilka mniej ważnych powiązań pominiętych dla czytelności, oraz następujący diagram przypadków użycia:

Przedstawiona została metoda specyfikacji znaczenia tekstu opisu rzeczywistości wykorzystująca ontologię oraz technikę metamodelowania. Zdefiniowany został dedykowany metamodel ontologii, który stanowi gramatykę opisu konkretnych ontologii. Znaczeniem danego tekstu są instancje ustalonej ontologii znaczenia. Podejście to daje dużą swobodę sposobu modelowania różnych zjawisk semantycznych, przy zachowaniu ścisłości specyfikacji i przejrzystości przyjętych rozwiązań, a także zapewnia łatwość rozwoju i implementacji struktur modeli znaczenia.Wydaje się, że zaproponowane podejście można zastosować także do specyfikacji innych ontologii w sposób łączący ścisłość specyfikacji z wygodą modelowania różnych aspektów rzeczywistości i jednocześnie zapewniający łatwość implementacji. Natomiast rozwój samej ontologii opisów rzeczywistości może się przyczynić do dokładniejszego opisania struktury modeli biznesowych i efektywniejszej ich komunikacji między różnymi uczestnikami projektów informatycznych.

W najbliższej przyszłości przedstawiona ontologia będzie dalej rozwijana głównie przez analizę przykładowych tekstów opisów rzeczywistości i wykorzystywana w tworzonym systemie wspomagania modelowania biznesowego. Używanie tego systemu powinno zapobiegać powstawaniu części błędów przy generowaniu modelu biznesowego, a także przyspieszać ten proces i ułatwiać komunikację między ekspertami dziedzinowymi a inżynierami tworzącymi system.