Metodologia MOKA
Protégé
Pozyskiwanie wiedzy może być prowadzone poprzez strukturalizowany wywiad przez inżyniera wiedzy znającego metodologie MOKA lub samodzielnie przez projektanta z tym, że konieczna jest zaznajomienie się projektanta co najmniej z nieformalnym modelem wiedzy z metodologii MOKA.
Metodologia MOKA
MOKA (Methodology and software tools Oriented to Knowledge based engineering Applications) jest nazwą metodologii powstałej w wyniku projektu badawczego będącego częścią projektu ESPRIT. Założeniem tej metodologii było opracowanie:
- formy reprezentacji wiedzy o wytworze i jego procesie projektowo-konstrukcyjnym oraz metody jej zapisu,
- aplikacji komputerowej do wspomagania zapisu, reprezentacji i pielęgnacji tej wiedzy,
- możliwości w dalszej perspektywie automatycznego generowania kodu aplikacji KBE z tej aplikacji komputerowej.
Nieformalny model obejmuje (rys. 1) pięć rodzajów formularzy ICARE (Illustration, Constraint, Activity, Rule, Entity):
- ilustracje (Illustration),
- ograniczenia (Constraints),
- czynności (Activity),
- reguły (Rule),
- jednostki (Entity).
Rys. 1. Model nieformalny metodologii MOKA
Rys. 2. Formularz ICARE (PCPACK)
Formularz Entity służy do pozyskiwania wiedzy dotyczącej struktury produktu poprzez wyspecjalizowane formularze Structural entity. Możliwe są następujące jednostki struktury produktu: Assembly - podzespół, Part - element, Feature - cecha. Ponadto w zakresie Entities możliwe jest definiowane Functional entity - jednostek funkcyjnych oraz Behavioral entity - jednostek zachowań. Formularze Entity są obok formularzy Activity - czynności najważniejszymi formularzami do pozyskiwania wiedzy. Formularze Entity odzwierciedlają strukturę projektowanego produktu natomiast Activity strukturę procesu projektowego. Obie te struktury powiązane są ze sobą poprzez połączenia, które można definiować i obserwować w tabeli (rys. 2) i na diagramie. Jednocześnie z jednostkami struktury produktu powiązane są Functional entity i Behavioral entity, poprzez które definiowane są funkcje i zachowanie jednostek produktu. Dodatkowo możliwe jest definiowanie powiązanie dodatkowych formularzy Constraint i Rule. Formularze Constraint pozwalają na definiowanie dodatkowych ograniczeń na jednostki struktury produktu a przede wszystkim na cechy (Feature). Formularz Rule natomiast pozwala na określenie reguł dla czynności procesu projektowego (Activity). Poprzez dodatkowy formularz Illustration można dodawać dodatkowe informacje do każdego z poprzednich formularzy. Całość tworzy wielowarstwową sieć poprzez którą można pozyskiwać wiedzę przezde wszystkim od ekspertów ale także z innych źródeł. Jednocześnie złożoność modelu sieciowego nie wpływa negatywnie na prostotę interfejsu przez który wprowadzana jest wiedza - są to powtarzalnej postaci formularze tylko pięciu typów.Całkowicie inne zadanie ma drugi z modeli metodologii MOKA - model formalny (rys. 3,). Model ten jest zapisany w języku MML (MOKA Modeling Language) będący profilem języka UML. Profile są jednym z mechanizmów rozszerzenia funkcjonalności języka UML na specjalizowane dziedziny. Profil języka UML jest najczęściej zbiorem pakietów i jest definiowany poprzez trzy grupy elementów: stereotypy, oznaczone wartości i więzy. Model formalny stanowi strukturę bazy wiedzy której reprezentacja z założenia ma być zrozumiała dla człowieka a jednocześnie przetwarzana przez system komputerowy. Struktura bazy jest w zakresie głównych elementów zdefiniowana na stałe i składa się z modelu produktu (Product Model) i modelu procesu projektowo-konstrukcyjnego (Process Model). Model produktu stanowi osnowę dla dalszych informacji w skład których wchodzi pięć zdefiniowanych widoków na strukturę produktu, które stanowią odrębne przestrzenie nazw oraz pakiety języka MML. Są to widoki: strukturalny, funkcjonalny, zachowań, technologiczny, reprezentacji. Widoki i modele tych widoków pozwalają na klasyfikację wiedzy w bazie wiedzy. Sama baza wiedzy jest budowana z wykorzystaniem modelu formalnego z wiedzy zidentyfikowanej i wstępnie strukturalizowanej poprzez model nieformalny i formularze ICARE.
Dodatkowo w modelach są stosowane zidentyfikowane atrybuty i relacje (rys. 4). Są one stosowane zarówno w modelu formalnym jak i nieformalnym.
Zagwarantowany poprzez zastosowanie języka MML formalizm zapisu modeli zapewnia możliwość dalszego przetwarzania przez systemy komputerowe. W zamyśle język ten ma służyć do budowania aplikacji KBE, która będzie wykorzystywała bazę wiedzy zbudowana w oparciu o model formalny. Metodologia MOKA nie jest nastawiona więc na współpracę z jakimkolwiek systemem CAD/KBE a proponuje uniwersalny sposób reprezentacji wiedzy pozostawiając sprawę budowy systemu KBE całkowicie otwartą.
Rys. 3. Model formalny metodologii MOKA
Rys. 4. Relacje i atrybuty stosowane w modelu formalnym i nieformalnym MOKA
Ponadto oprócz wspomnianych modeli metodologia MOKA opisuje proces identyfikacji, pozyskiwania, gromadzenia i zarządzania wiedzą oraz wskazuje komputerowe narzędzie programowe do realizacji tych zadań. Niezależnie od opracowanego w ramach projektu MOKA narzędzia, do budowy modeli zgodnych z MOKA można wykorzystywać inne narzędzia np. PCPACK lub Protégé.^ do góry
Protégé
Protégé jest bezpłatnym narzędziem rozprowadzanym na zasadzie licencji open source. Jest to aplikacja wspomagająca tworzenie baz wiedzy w tym między innymi do edycji ontologii i pozyskiwania wiedzy od ekspertów. Proces taki nazywany jest czasami modelowaniem wiedzy.
Platforma Protégé umożliwia zastosowanie dwóch form reprezentacji wiedzy poprzez dwie autonomiczne aplikacje Protégé-Frames i Protégé-OWL. Ontologie zbudowane za pomocą aplikacji Protégé mogą być eksportowane do wielu różnych formatów, w tym między innymi RDF(S), OWL i XML Schema.
Aplikacja Protégé jest aplikacją w języku Java i jedną z wielu zalet tej aplikacji jest możliwość rozszerzania funkcjonalności aplikacji poprzez wtyczki i ontologie dostępne dla tej platformy. Istnieje możliwość samodzielnego rozszerzania możliwości aplikacji poprzez samodzielne wykonanie wtyczek do aplikacji a także budowanie własnych ontologii.
^ do góry