Budowanie świadomości sytuacyjnej pola walki
Transkrypt
Budowanie świadomości sytuacyjnej pola walki
Budowanie świadomości sytuacyjnej pola walki – generowanie uŜytecznej ontologii na bazie relacyjnego modelu danych MIP JC3IEDM mgr inŜ. Dariusz Nogalski * dr inŜ. Anna Wróblewska * mgr Paweł Szklarz * kpt. mgr inŜ. Mariusz Chmielewski ** * ABG S.A. Al. Jerozolimskie 123A 02-017 Warszawa ** Instytut Systemów Informatycznych, Wydział Cybernetyki, Wojskowa Akademia Techniczna Ul. Kaliskiego 2 00-908 Warszawa RóŜnorodność i liczba systemów wykorzystanych w nowoczesnym polu walki prowadzi do konieczności integracji na poziomie modelu pojęciowego. Inne rozwiązania jak juŜ wiadomo powodują usztywnienie poszczególnych systemów i uniemoŜliwia ewolucję funkcjonalności zgodnie z wymagań wynikających z nowych potrzeb uŜytkownika końcowego. Model pojęciowy stanowi warstwę skojarzenie informacji w jedną całość, tak aby móc operować w kontekście jednej spójnej rzeczywistości. Celem Multilateral Interoperability Program [MIP] jest osiągnięcie interoperacyjności systemów dowodzenia NATO oraz systemów narodowych, wykorzystując MIP jako wspólny model pojęciowy. Specyfikacja MIP zawiera znormalizowany i jednoznacznie określony opis semantyki (znaczenia) wspólnych danych wymienianych między systemami C2 krajów koalicyjnych NATO zarówno na poziomie konceptualnym, logicznym jak i fizycznym. Specyfikuje klasyfikatory informacyjne w takich obszarach jak: struktury organizacyjne, typy uzbrojenia, zdolności (ang. capabilities), typy ‘facilities’, lokalizacje geograficzne, aspekty pogodowe czy aspekty planistyczne. Model zawiera nie tylko klasyfikatory i ich wzajemne relacje, lecz takŜe słowniki instancji konkretnych klasyfikatorów oraz reguły biznesowe (ang. business rules). Są to aksjomaty dziedziny C2, uściślające definicje wiedzy i określające ograniczenia modelu. Reguły biznesowe słuŜą takŜe to sprawdzania poprawności danych przekazywanych między partycypującymi w wymianie danych systemami C2. Wobec braku narzędzi opisu znaczenia, reguły biznesowe są wyraŜone w postaci tekstu i zaimplementowane niezaleŜnie w kaŜdym systemie. Logiczny model JC3IEDM jest aktualnie utrzymywany jako model relacyjny ERD (ang. entity relationship). Do reprezentacji formalnej modelu wykorzystano notację IDEF-1X jako jednej z odpowiednich dla modeli relacyjnych. Notacja ta pozwala na opisywanie takich zaleŜności miedzy encjami jak: klasyfikacja na typy i podtypy (kategorie) oraz relacji. Szczególne problemy przysparzają relacje wiele do wielu, gdzie na poziomie fizycznym naleŜy tworzyć sztuczne tablice do reprezentacji takich zaleŜności. Generowanie ontologii na podstawie MIP’a jest próbą wykorzystania technik semantycznych, tak aby model ten został wzbogacony oraz umoŜliwiał dokładny i logiczny opis swojej struktury. Najlepszym przykładem wzbogacenia modelu jest moŜliwość wprowadzenia reguł biznesowych bezpośrednio do ontologii. W ogólności ontologie słuŜą do formalnego opisu domeny informacyjnej danej dziedziny problemowej, opisu struktury i znaczenia informacji, jak teŜ i sposobów jak ta informacja ma być przetwarzana. Transformacja modelu JC3IEDM do ontologii daje większe moŜliwości wykorzystania semantyki informacji, czyli specyfikacji metod automatycznego dostępu do zasobów oraz znaczenia informacji, które one przetwarzają. Zasoby mające zdefiniowane znaczenie mogą być przeszukiwane w sposób automatyczny przez wyspecjalizowane programy/silniki wnioskujące. Wykorzystanie ontologii umoŜliwia m.in.: sprawdzanie poprawności modelu i danych oraz otrzymanie dodatkowych informacji, które nie są jawnie napisane, poprzez zastosowanie automatycznego wnioskowania; zwiększenie automatyzacji zadań normalnie wykonywanych przez ludzi poprzez lepsze zrozumienie znaczenia informacji; tworzenia inteligentnych agentów zdolnych do komunikacji z człowiekiem i innymi systemami. W referacie przedstawiono logikę transformacji modelu relacyjnego JC3IEDM do uŜytecznej ontologii, będącej m.in. próbą uproszczenia skomplikowanego płaskiego modelu relacyjnego. Przedstawiono równieŜ generator ontologii. Ponadto opisano sposób wykorzystania reguł biznesowych dotyczących modelu poprzez wykorzystanie wnioskowania. Zastosowane transformacje słuŜą przede wszystkim do budowania świadomości sytuacyjnej pola walki, co z kolei ma na celu wsparcie procesu dowodzenia. Planuje się wykorzystanie stworzonej ontologii w brokerze semantycznym słuŜącym do pozyskiwania informacji z wielu heterogenicznych źródeł danych (usługę tę opisano w oddzielnym referacie). 1 Wprowadzenie do ontologii i modelu JC3IEDM Ontologia ogólnie jest dziedziną filozofii zajmującą się teorią bytów, odpowiada na pytanie „co istnieje?”, „czym jest obiekt?”, „co składa się na identyfikację obiektu?” itp. Na potrzeby sieci semantycznej ontologia będzie zbiorem obiektów i ich wzajemnych relacji. Posługując się analogią do modeli obiektowych zbiorem klas, atrybutów klas, relacji między klasami i przynaleŜnych tym klasom wystąpień (obiektów). Relacyjny koncepcyjny model danych, bądź obiektowy model klas jest pewną ontologią opisującą daną dziedzinę problemową. Rysunek 1 Prosta ontologia [MITRE 2004] Przypisanie znaczenia do obiektu odbywa się poprzez a) wyspecyfikowanie jego cech/własności (np. numer tablicy rejestracyjnej, rodzaj nadwozia, ilość siedzeń pasaŜera, ilość drzwi, pojemność silnika, moc, kolor), b) zaklasyfikowanie go do odpowiedniej grupy obiektów (np. samochód) czyli przeprowadzenie typowego zadania klasyfikacji, c) ustawienie obiektu w kontekście hierarchi czyli jego cech nadrzędnych (np. pojazd, samochód jest pojazdem poruszającym się po lądzie) oraz d) wyspecyfikowanie wszystkich pozostałych asocjacji/relacji tego obiektu z innymi obiektami (np. relacja „został wyprodukowany przez”, „został zarejestrowany przez”). Do tej pory wszystko o czym wspomniano bardzo przypomina zasady tworzenia modeli koncepcyjnych w metodykach relacyjnych (model koncepcyjny) i obiektowych (model klas, model obiektów). Ontologie moŜna podzielić pod kątem przyjętej techniki modelowania na : lekkie (ang. lightweight) i cięŜkie (ang. heavyweight) [Gomez 2004]. Ontologie cięŜkie uŜywają języka o duŜo większej ekspresyjności niŜ ontologie lekkie. Ontologie mogą być nieformalne (ang.informal) jeśli są wyraŜane w języku naturalnym lub formalne (ang. formal) jeśli są wyraŜane za pomocą formalnie zdefiniowanego języka rozumianego przez komputery. CięŜkie ontologie są reprezentowane przy uŜyciu logiki predykatów pierwszego rzędu (ang. FOL - First Order Logic) lub logiki deskrypcyjnej (ang. DL – Description Logic). Logika pierwszego rzędu ma następujące właściwości: a) kwantyfikatory i predykaty stosowane są tylko do obiektów a nie do predykatów (funkcji, relacji) b) nie moŜna w niej dowieść fałszywego twierdzenia (ang. soundness) c) wszystkie prawdziwe twierdzenia mają dowód (ang. completeness) Logika deskrypcyjna (DL) jest podzbiorem FOL i ma następujące właściwości: a) brak pojęcia funkcji b) wszystkie relacje są albo unarne albo binarne. Modelując ontologię przy uŜyciu FOL mamy do dyspozycji następujące komponenty: O = (C , R, F , A, I ) , gdzie C – jest zbiorem klas, R – jest zbiorem relacji, F – jest zbiorem funkcji, A – jest zbiorem aksjomatów, I – zbiorem instancji. Rysunek 2 Definicja ontologii Logika deskrypcyjna (czasem zwana opisową) jest podzielona na dwie części TBox i ABox. TBox zawiera informację o konceptach 1(ang.concept) i ich relacjach (poprzez relacje definiuje się atrybuty konceptów), natomiast ABox jest to informacja o konkretnych obiektach czyli instancjach konceptów. Baza wiedzy TBox Terminologia, wiedza o konceptach np.Director ≡ Artist I ∃creates.Movie ABox Asercje, wiedza o obiektach np. StevenSpielberg: Director creates(StevenSpielberg, JurrasicParc) Rysunek 3 Przykład Tbox i Abox w logice descrypcyjnej 1 Koncept jest odpowiednikiem klasy obiektów w FOL Logika deskrypcyjna do reprezentacji ontologii uŜywa konceptów (ang. concepts), ról (ang. roles), konstruktorów (ang. constructors) i obiektów (ang. individuals). Konstruktory prowadzą do róŜnych języków. Im większa ilość konstruktorów w języku tym większa ekspresyjność języka ale teŜ i większa złoŜoność wnioskowania. Z praktycznego punktu widzenia podstawowe konstruktory to : I,U, ¬, ∀, ∃ . Konstruktor Koncept (ang. cocept) Nazwa Roli (ang. role name) Składnia A R Przecięcie (ang. intersection) Suma (ang. union) Ograniczenie wartości (ang. value restriction) CID CUD ∀R.C Ograniczenie występowania (ang. existential restriction) ∃R.C Negacja Koncept uniwersalny (ang. Top) ¬C ┬ Koncept pusty (ang. Bottom) ⊥ Przykład Osoba maDziecko(Jan, Dariusz) Dariusz jest dzieckiem Jana Mezczyzna I Rodzic ≡ Ojciec ∀maDziecko.Kobieta Oznacza osoby których wszystkie dzieci są córkami ∃maDziecko.Kobieta Oznacza osoby które mają przynajmniej jedną córkę Kobieta ≡ ¬Mezczyna Mezczyna ⊆ ┬ ∃maSyna.¬Mezczyzna ≡⊥ Tabela 1 Wybrane konstruktory DL Modelowanie lekkich ontologii moŜna przeprowadzić uŜywając ogólnie rozpowszechnionych technik inŜynierii oprogramowania czyli modelowania obiektowego i relacyjnego. UML (ang. Unified Modelling Language) ma moŜliwość reprezentowania konceptów/klas obiektów, relacji między klasami (zarówno relacji taksonomicznych jak i relacji ad hoc) (patrz diagram klas). Aksjomaty mogę być wyraŜone za pomocą języka OCL (ang. Object Constraint Language). Reprezentacja instancji moŜe zostać zamodelowana przy uŜyciu diagramu obiektów. Jest kilka róŜnic między językami z rodziny DL a UML. Poza róŜnicą w ekspresyjności języka, w DL atrybut jest konceptem (np. Color), jest umiejscowiony poza klasą i związany z nią relacją, moŜe występować w wielu miejscach z róŜnymi ograniczeniami, natomiast w UML atrybut jest przywiązany do klasy i odnosi się jedynie do niej i do jej klas specyfikowanych (ang. subclass-of). 1.1 Języki Formalnego opisu ontologii RDF i OWL RDF jest językiem reprezentowania zasobów w sieci WWW. Szczególnie jest przeznaczony do reprezentowania meta danych o zasobach sieciowych, takich jak autor, data modyfikacji zasobu, informacje o prawach własności i licencjach, źródło na podstawie którego dany zasób został przygotowany, tytuł, typ zasobu, język opisu zasobu itd. RDF ma strukturę grafu, którego wierzchołki reprezentują zasoby (koncepty w ontologii) a krawędzie mówią o relacjach między tymi zasobami. Podstawową strukturą tworzącą graf RDF jest krotka2 3 elementowa w postaci (podmiot, orzeczenie, dopełnienie) (ang. subject, predicate, object). Predykat (ang. predicate) jest funkcję zdaniową (np. predykat ojciec(X,Y) , znaczy X jest ojcem Y) i reprezentuje relację. Mówiąc językiem zasobów w sieci, graf RDF tworzymy poprzez łącznie krotek (zasób, własność, zasób) (ang. (resource, property, resource)), bądź (zasób, własność, wartość własności) (ang. (resorce, property, property value)). Ilustrując to na przykładzie relacji między konkretnymi konceptami (ReŜyser, kieruje realizacją, Film) lub moŜemy mówić o relacjach między instancjami (Steven Spielberg, kieruje realizacją, Park Jurajski). Rysunek 4 Krotka 3 elementowa w reprezentacji grafu skierowanego RDF RDF został utworzony tak, aby mógł być przetwarzany przez automaty (ang. machine readable), aby mógł wspomagać wymianę informacji między automatami przy zachowaniu znaczenia wymienianej informacji. Identyfikacja zasobów w sieci jest moŜliwa dzięki identyfikatorom URI3 i strukturze tych zasobów. Przykładowy graf RDF w postaci graficznej z uŜyciem unikalnych identyfikatorów URI jest przedstawiony poniŜej. Rysunek 5 Przykładowy graf RDF z uŜyciem URI w postaci graficznej [RDF04] 2 3 Uporządkowany skończony zbiór elementów Unified Resource Identifier Język OWL ma więcej mechanizmów po to aby wyraŜać znaczenie niŜ XML, RDF czy RDF-S. Powstał on na podstawie języka DAML4+OIL5 i odzwierciedla zebrane doświadczenia przy jego budowie. OWL natomiast ma jeszcze bardziej bogatą gramatykę i pozwala na reprezentowanie takich relacji między klasami jak na przykład rozłączność (ang. disjointness), wprowadza pojęcie krotności w relacjach ad hoc, pojęcie równowaŜności konceptów czy symetryczność własności (ang. symmetry). W ramach OWL zostały zdefiniowane trzy języki, które róŜnią się między sobą ekspresyjnością OWL Lite, OWL DL i OWL Full. Projektant systemu moŜe dzięki temu uzyskać kompromis między ekspresyjnością języka a moŜliwościami obliczeniowymi maszyny. OWL Lite jest przeznaczony głównie do reprezentowania hierarchii klas i prostych ograniczeń. Krotność relacji moŜe posiadać jedynie wartości 0 i 1. OWL DL (Description Logic) wprowadza znacznie większą ekspresyjność, ale gwarantuje, Ŝe wszystkie prawdziwe hipotezy wyraŜone w tym języku są moŜliwe do obliczenia/udowodnienia (ang. computational completeness) w skończonym czasie (ang. decidability). OWL Full ma największą ekspresyjność ale nie gwarantuje, Ŝe wszystkie prawdziwe hipotezy mają dowód. Jest nieprawdopodobne, Ŝe jakikolwiek program będzie w stanie przeprowadzić pełne obliczenia z wykorzystaniem wszystkich własności i pełnej ekspresyjności OWL Full. 1.2 Wnioskowanie z uŜyciem ontologii Logika opisowa jest podzielona na dwie części: TBox i ABox. TBox zawiera informację o klasach - konceptach (ang.concept) i ich relacjach (poprzez relacje definiuje się atrybuty konceptów). Natomiast ABox jest to informacja o konkretnych obiektach, czyli instancjach konceptów. Gdybyśmy mieli zdefiniować koncept „Szczęśliwy Ojciec” jako „Osoba”, która ma przynajmniej jedną „Córkę” i przynajmniej jednego „Syna” w logice opisowej moŜna by to zapisać w następujący sposób: SzczesliwyOjciec ⊆ Osoba I ≥ 1maDziecko.Kobieta I ≥ 1maDziecko.Mezczyzna Mając zdefiniowany koncept „Szczęśliwy Ojciec”, moŜna teraz za pomocą unarnej funkcji predykatowej zapisać, Ŝe „Jan Kowalski” jest instancją tegoŜ konceptu: SzczesliwyOjciec( JanKowalski ) Wnioskowanie (ang. reasoning) jest odkrywaniem faktów ukrytych na temat konceptów i ich instancji zapisanych w bazie wiedzy (ang. knowledge base) – ontologii nie wprost, posługując się strukturą wiedzy (relacjami między konceptami), wiedzą aksjomatyczną (formalnie zdefiniowanymi prawdami) i aparatem logicznym. Przykładowo załóŜmy, Ŝe w bazie wiedzy mamy zdefiniowane następujące zdania: „A jest ojcem B” oraz „B jest ojcem C”. Maszyna wnioskująca jest w stanie wydedukować zdanie „A jest przodkiem C”. Fakt ten nie był zapisany wprost w postaci trójki uporządkowanej w grafie wiedzy, lecz został wydedukowany. 4 5 DARPA Markup Language Ontology Inference Layer W logice opisowej pewne własności klas mają szczególne znaczenie, wyróŜnia się następujące definicje formalne: • Spełnialność - Klasa jest spełnialna, jeŜeli moŜe istnieć obiekt do niej naleŜący. Częstą przyczyną niespełnialności jest podanie warunków zaprzeczających się, np.: "Krasnoludki to osoby, które mają mniej niŜ 10 lat i więcej niŜ 20 lat". • Zawieranie. Klasa A zawiera klasę B, jeŜeli kaŜdy obiekt naleŜący do A naleŜy równieŜ do B. Kiedy warunki przynaleŜności do klasy B wynikają z opisu czy warunków na przynaleŜność do klasy A, to A zawiera B. Przykład: A: Dorosły to osoba mająca więcej niŜ 18 lat. B: Senior to osoba mająca więcej niŜ 70 lat. Z definicji A i B, wynika Ŝe A zawiera B. • RównowaŜność. Dwie klasy są równowaŜne, jeŜeli zawierają dokładnie ten sam zbiór elementów. Przykład: A: AgentSpecjalny to osoba pracująca w tajnych słuŜbach B: DobrzeUzbrojonyTyp to osoba posiadająca pistolet XX01. Fakt: pistolet XX01 jest przeznaczone tylko dla słuŜb tajnych. Z tej wiedzy wynika, Ŝe kaŜda osoba naleŜąca do DobrzeUzbrojonyTyp naleŜy równieŜ do AgentSpecjalny i na odwrót. Tak więc DobrzeUzbrojonyTyp i AgentSpecjalny są równowaŜne. • Rozłączność. Dwie klasy są rozłączne, jeŜeli nie istnieje element naleŜący do obu klas. Przykład: A: Nastolatek to osoba mająca od 11 do 18 lat. B: Trzydziestolatek to osoba mająca od 30 do 39 lat. Na podstawie tych definicji zostają podstawione zadania do algorytmów wnioskujących, polegających na sprawdzenie, czy dane klasy mają wyŜej wymienione własności. Te zadania silnika wnioskującego są zredukowanych do zadania zawierania (ang. subsumption) i tak na przykład: • Zbiory C i D są równowaŜne ⇔ C ⊆ D i D ⊆ C • Zbiory C i D są rozłączne ⇔ C I D ⊆⊥ , gdzie ⊥ jest zbiorem pustym • Element a naleŜy do zbioru C ⇔ {a} ⊆ C Zadanie zawierania moŜe z kolei być zredukowane do zadania spełnialności (ang. satisfiability): C ⊆ D ⇔ C I ¬D jest zbiorem pustym (warunkiem nie spełnialnym). Typowe zadania silnika wnioskującego to: 1. Automatyczne tworzenie taksonomii klas (ang. taxonomy classification). 2. Test spójności (ang. consistency checking). Wykrywanie klas, które nie mogą mieć instancji. 3. Klasyfikacja instancji. Sprawdzanie, do której klasy naleŜy dana instancja. 4. Wyliczenie instancji naleŜących do danej klasy. 5. Wykrywanie innych podklas danej klasy, niŜ wygenerowane w punkcie 1. 1.3 Ontologie wyŜszego rzędu Ontologie słuŜą do formalnego opisu domeny informacyjnej danej dziedziny problemowej, opisu struktury i znaczenia informacji, jak teŜ i sposobów jak ta informacja ma być przetwarzana. RóŜne domeny są opisywane przy uŜyciu konceptów dla nich specyficznych jak teŜ i konceptów uniwersalnych. Weźmy pod uwagę przykładowe 2 domeny: kontrola ruchu morskiego kontrola ruchu lotniczego Wyobraźmy sobie, Ŝe wdraŜamy system informatyczny w Trójmieście i słuŜba graniczna chciałaby pozyskiwać informacje z tych dwóch róŜnych dziedzin w sposób syntetyczny. KaŜda z dziedzin będzie opisywała koncepty specyficzne dla siebie, kontrola ruchu morskiego będzie operowała rejestrami statków i obiektów pływających, regułami opisującymi krajowe i międzynarodowe przepisy morskie, korytarze ruchu w portach itp. Natomiast kontrola ruchu lotniczego będzie skupiała się głównie na obiektach latających, ich rejestracji, dozwolonych przemieszczeniach itp. Jednak obie te dziedziny będą teŜ potrzebowały opisów uniwersalnych jak na przykład reprezentacji danych meteorologicznych (kierunek, prędkość i siła wiatrów, temperaturę, opady atmosferyczne, ciśnienie atmosferyczne), czy chociaŜby informacji o personelu pracującym w poszczególnych komórkach organizacyjnych czy samej struktury organizacyjnej. Koncepty uniwersalne są to pojęcia które mogą wystąpić w wielu opisach dziedzinowych. Jeśli kaŜda z dziedzin będzie opisywała pojęcia generyczne, czy uniwersalne w swój własny sposób moŜe to doprowadzić to niekompatybilności semantycznej systemów czy chociaŜby duplikacji nakładów na ich rozwój. Rozwijanie odseparowanych (ang. standalone) ontologii dziedzinowych bez wyodrębnienia w nich standardowych, ogólnie rozpoznawalnych wyŜszych warstw abstrakcji przyczyni się do braku zrozumienia między dziedzinami, spowoduje utrudniania o ile nie uniemoŜliwi w ogóle automatyczne wnioskowanie na tak rozproszonych zasobach informacyjnych. W ramach kontr argumentu moŜna by powiedzieć, Ŝe ontologie właśnie są remedium na integrację róŜnych odseparowanych systemów dziedzinowych, wykonanych bardzo często przy uŜyciu starych technologii, z modelami informacyjnymi mało elastycznymi i mało elastycznych jeśli chodzi o integrację z innymi systemami. NaleŜy jednak zaznaczyć, Ŝe wnioskowanie na nie kompatybilnych zasobach czy takich które zawierają pojęcia sprzeczne moŜe być utrudnione czasowo. Jest kilka sposobów na łączenie opisów ontologicznych między dziedzinami, są to: a) mapowanie wybranych konceptów z dwóch ontologii (ang.ontology mapping/linking), b) sumowanie całych ontologii (ang. ontology merge) c) mapowanie z wykorzystaniem ontologii wyŜszego rzędu (ang. ontology layers) KaŜdy z nich ma swoje wady i zalety. Sposób a) powoduje, Ŝe w przypadku kiedy mamy 10 systemów opisanych róŜnymi ontologiami i kaŜdy musi się komunikować z kaŜdym n( n − 1) 2 musimy zrobić 45 (ilość krawędzi w grafie pełnym ) ontologii mapujących. Sposób b) powoduje, Ŝe powstaje jedna wielka ontologia, bardzo cięŜka w zarządzaniu, występują teŜ potencjalne problemy wnioskowania. Korzystnym z punktu widzenia „wspólnej komunikacji” jest sposób c). Sposób ten wymusza niejako podobne opisywanie treści, konceptów, nadawanie im znaczenia w ten sam sposób. Przynosi to szereg korzyści związanych z ułatwieniem komunikacji, zmniejszeniem kosztów wytwarzania systemów, zmniejsza się teŜ ryzyko uzyskania niezadowalających rezultatów wnioskowania przy załoŜeniu duŜych i rozległych zasobów wiedzy. PoniŜszy diagram pokazuje w sposób graficzny pierwszy i trzeci sposób podejścia do mapowania zasobów. Rysunek 6 Mapowanie a stosowanie ontologii wyŜszego rzędu Ontologie mogą być układane w warstwy. Zaczynając od dołu, a idąc ku górze mamy zatem: a) ontologie aplikacyjne (ang. application ontologies) b) ontologie dziedzinowe (ang. domain ontologies) c) ontologie dziedzinowe wyŜszego rzędu (ang. intermediate domain ontologies, higher domain ontologies) Ontologie moŜna dzielić pod kątem dostępu do zasobów, np. prywatne i publiczne. 1.4 Model JC3IEDM Celem Multilateral Interoperability Program [MIP] jest osiągnięcie interoperacyjności systemów dowodzenia NATO, jak i systemów narodowych. MIP nie ma na celu specyfikacji warstwy funkcjonalnej systemów C2, moŜe jednak słuŜyć jako cenne źródło wiedzy w procesie tworzenia narodowych systemów dowodzenia. Najistotniejszym produktem jaki dostarcza MIP jest Information Exchange Data Model (IEDM). Historycznie MIP ma swój początek w pracach nad systemem ATCCIS6 Battlefield Generic Hub Data Model, następnie ewoluował do LC2IEDM7. Wraz ze wzrostem wymagań IER8, model ewoluował do C2IEDM9 znany jako Baseline2. Aktualna wersja znana jako JC3IEDM10 Baseline3 wzbogaciła Baseline2 o model informacyjny NATO Corporate Reference Model. Jak juŜ 6 Army Tactical Command and Control Information System Land C2 Information Exchange Data Model 8 Information Exchange Requirement 9 C2 Information Exchange Data Model 10 Joint Consultation Command and Control Information Exchange Data Model 7 zostało zaznaczone, model MIP nie jest modelem opisu warstwy danych systemu dowodzenia, lecz modelem zapewniającym interoperacyjność systemów C2. Jest jednak stale rozwijany i jego zawartość informacyjna stale rośnie. Celem MIP jest umacnianie swojej pozycji jako wiodącego wspólnego modelu danych systemów C2 w następujących dziedzinach: ‘Combat Service Support and Logistics’, ‘Communications and Electronics’, ‘Fire Support’, ‘Intelligence/Electronic Warface’, ‘Air Defence and Airspace Control’, ‘Engineer Operations’, ‘Administration/Personnel’, ‘Air Support’ i ‘Special Ops’. Specyfikacja MIP zawiera znormalizowany i jednoznacznie określony opis semantyki danych C2 zarówno na poziomie konceptualnym, logicznym jak i fizycznym. Specyfikuje klasyfikatory informacyjne w takich obszarach jak: struktury organizacyjne, typy uzbrojenia, zdolności (ang. capabilities), typy ‘facilities’, lokalizacje geograficzne, aspekty pogodowe czy aspekty planistyczne. Model zawiera nie tylko klasyfikatory i ich wzajemne relacje, lecz takŜe słowniki instancji konkretnych klasyfikatorów. 2 Generowanie ontologii OWL-DL z modelu logicznego JC3IEDM Logiczny model JC3IEDM jest aktualnie utrzymywany jako model relacyjny ERD jednak praktycznie na ukończeniu jest jego transformacja do logicznego modelu UML. Transformacją do modelu UML zajmuje się grupa MDA Working Party programu MIP. Wkrótce nastąpi decyzja co do migracji do UML. Oznaczałoby to, iŜ podstawowym źródłem modelu nie jest model relacyjny lecz obiektowy UML. W związku z tym, iŜ ciągle aktualnym modelem jest model relacyjny rozwaŜania odnośnie transformacji do języka OWL-DL będą dotyczyły modelu ERD. Logiczny model danych PIM JC3IEDM jest przechowywany w dwóch repozytoriach identycznych co do zawartości informacyjnej. Jednym ze źródeł jest repozytorium ERwin 11, a kolejnym meta model MIRD12. W przypadku uŜycia jako źródła danych meta modelu MIRD wystarczy znajomość SQL (MIRD ma strukturę relacyjną opartą o standardowy SQL) lub moŜna teŜ wykorzystać narzędzie JAG-T13 i z jego poziomu dokonać transformacji. JAG-T ma moŜliwość wczytania informacji o modelu (encje, atrybuty, związki etc.) do obiektowego modelu klas JAVA lub modelu XML. Opis metody będzie bazował na modelu MIRD i narzędziu JAG-T. Proces transformacji moŜna podzielić na kilka kroków: • Krok1 Wczytanie informacji o modelu JC3IEDM z modelu MIRD do jego obiektowej reprezentacji w pamięci w postaci klas Java • Krok2 Wykonanie logiki transformacji zgodnie z poniŜej zdefiniowaną metodą • Krok3 Utworzenie reprezentacji modelu OWL w pamięci (do tego celu moŜna zastosować jedno z istniejących OWL API, np. Jena) • Krok4 Serializacja modelu OWL do pliku wynikowego (do tego celu moŜna tak jak powyŜej zastosować jedno z istniejących OWL API, np. Jena) 11 CA ERwin Data Modeller MIP Information Resource Dictionary System 13 JC3IEDM Annex Generation Tool 12 Logikę transformacji moŜna moŜ zebrać w kilku krokach (K1-K4) K4) szczegółowo opisanych w poniŜszych szych punktach. Wynika ona częściowo cz z notacji IDEF-1X, a częściowo częś z wzorców projektowych uŜytych ytych przy modelowaniu JC3IEDM. Krok K1 Translacja Encji do Klas OWL Encje w modelu logicznym IDEF-1X IDEF odpowiadają klasom obiektów przechowywanych w bazie danych. Encja składa się z kluczy i atrybutów określających cych cechy (patrz poniŜszy poni rysunek). Klucze mogą migrować migrowa do innych encji (np. w przypadku relacji wiele do wielu lub lu w przypadku odzwierciedlania kategorii) tylko encje niezaleŜne niezale (ang. independent entities) entities nie zaleŜą w swojej identyfikacji na kluczach innych encji. Rysunek 7 Encje w modelu IDEF-1X Notacja IDEF-1X 1X ma moŜliwość moŜliwo modelowania taksonomii encji, czyli ustawiania encji w hierarchię poprzez uogólniania/specjalizację uogólniania/specjalizacj cech. Notacja pozwala na pokazanie: pokazanie • wszystkich podtypów danej encji (np. ACTION i jej specjalizacje ACTION-TASK, ACTION ACTION-EVENT), czyli wszystkich kategorii (ang. ( complete categories) categories • lub tylko część z nich, jeśli jeś nie zostały zidentyfikowane, a przypuszcza się, si Ŝe istnieją (np. OBJECT-ITEM ITEM i jej specjalizacje FACILTY, FEATURE, MATERIEL, ORGANISATION, PERSON). Rysunek 8 Kategorie w modelu IDEF-1X Rysunek 9 Notacja IDEF-1X kategorie Transformacja encji IDEF-1X do klasy OWL powinna się odbywać w kilku krokach. W poniŜszej tabeli są zebrane reguły. Nie jest konieczne , aby były one wykonane w kolejności sekwencyjnej. Numer reguły transforma cyjnej K1.1 K1.2 K1.3 Odpowiednik IDEF-1X Nazwa encji np. CAPABILITY Definicja encji Odwzorowanie podtypów / podkategorii encji Odpowiednik OWL-DL Definicja nagłówka klasy <owl:Class ID=”Capability/> Dodanie adnotacji do klasy <rdfs:comment> K1.3.1 Dla kaŜdej klasy naleŜy określić jej nadklasę, o ile istnieje, np. <owl:Class rdf:ID="SupportCapability"> <rdfs:subClassOf rdf:resource="#Capability"/> oznacza, Ŝe SupportCapability jest specjalizacją klasy Capability K1.3.2 Opisanie nadklasy jako sumy (ang. union) podklas. Np. <owl:Class rdf:ID="Address"> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#ElectronicAddress" /> <owl:Class rdf:about="#PhysicalAddress" /> <owl:Class rdf:about="#NotOtherwiseSpecifiedAddress" /> </owl:unionOf> </owl:Class> Uwaga: Wartości domenowe (ang. domain values) mogą zawierać wartości Not Known – oznacza wartość nieznaną (np. wiemy Ŝe coś jest czołgiem, ale nie jesteśmy w stanie określić typu) Not Otherwise Specified – oznacza wartość inną, niŜ występującą na liście (np. wiemy, Ŝe coś jest adresem ale nie jest to ani adres elektroniczny, ani fizyczny) K1.3.3 Opisanie podklas nadklasy jako klas rozłącznych Np. <owl:Class rdf:ID="ElectronicAddress"> <rdfs:subClassOf rdf:resource="#Address"/> <owl:disjointWith rdf:resource="#PhysicalAddress"/> <owl:disjointWith rdf:resource="#NotOtherwiseSpecifiedAddress"/> </owl:Class> Przykładem encji z podtypami jest CAPABILITY (patrz poniŜszy rysunek). Rysunek 10 Encja CAPABILITY z modelu JC3IEDM Krok K2 Translacja Atrybutów i Relacji do Własności (ang. Properties) OWL Atrybuty w modelu JC3IEDM dzielą się na: • atrybuty kluczowe (klucze podstawowe, obce, alternatywne, nazwy ról, klucze złoŜone), • atrybuty do określania kategorii z sufiksem „-category-code” , • pozostałe atrybuty określające cechy encji. Atrybuty kluczowe słuŜą do utrzymywania integralności referencyjnej między danymi. Logika translacji kategorii została określona w kroku K1. W kroku K2 zostanie opisana logika translacji atrybutów określających cechy. Dozwolone wartości atrybutu w notacji IDEF-1X są określoną poprzez domenę atrybutu (ang. attribute domain) a zbiór wartości jest określany mianem zbioru wartości domeny (ang. domain values). Repozytorium MIRD poza tym, Ŝe zawiera informacje o modelu logicznym, zawiera takŜe informacje o modelu fizycznym. Podczas transformacji naleŜy wykluczyć wartości fizyczne związane z konkretną reprezentacją bazodanową i atrybutami słuŜącymi do celów replikacyjnych. Atrybuty, które przyjmują dozwolone wartości z list enumerowanych są transformowane na owl:ObjectProperty, natomiast te których zakresem (ang. range) jest typ prosty (np. integer) na owl:DatatypeProperty. Niektóre własności mogą posiadać typ owl:FunctionalProperty, co zostało pokazane na przykładzie na poniŜszym rysunku. <owl:FunctionalProperty rdf:about="#CapabilityUnitOfMeasureCode"> <rdfs:range rdf:resource="CapabilityUnitOfMeasureItem"/> <rdfs:domain rdf:resource="#Capability"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >CapabilityUnitOfMeasureCode</rdfs:label> <rdfs:comment xml:lang="en">The specific value that represents the quantities in terms of which the magnitude of a specific Capability descriptor is stated.</rdfs:comment> </owl:FunctionalProperty> Krok K3 Translacja Wartości Domenowych (ang. Domain Values) do Własności (ang. Properties) OWL KaŜda domena atrybutu (ang. domain) jest określona jako lista enumerowana w notacji IDEF-1X. Domena podlega transformacji do klasy OWL, a następnie kaŜda wartość domeny (ang. domain value) podlega transformacji do instancji klasy. Klasa ma ograniczony zestaw instancji, z których kaŜda jest wzajemnie róŜna (OWL AllDifferent). Ilustracją powyŜszej reguły jest przykład dla atrybutu CapabilityUnitOfMeasureCode. Domeną atrybutu jest CapabilityUnitOfMeasureCodeItem z wybranymi trzema wartościami (ze względu na czytelność dokumentu ograniczono zestaw wartości domenowych). <owl:Class rdf:about="#CapabilityUnitOfMeasureCodeItem"> <owl:oneOf rdf:parseType="Collection"> <CapabilityUnitOfMeasureCodeItem rdf:ID="CapabilityUnitOfMeasureCodeItem01"> <rdfs:label rdf:datatype="xsd:string">CM</rdfs:label> <rdfs:comment xml:lang="en">The standard international unit of volume in the metric system.</rdfs:comment> </CapabilityUnitOfMeasureCodeItem> <CapabilityUnitOfMeasureCodeItem rdf:ID="CapabilityUnitOfMeasureCodeItem02"> <rdfs:label rdf:datatype="xsd:string">EA</rdfs:label> <rdfs:comment xml:lang="en">Singly.</rdfs:comment> </CapabilityUnitOfMeasureCodeItem> <CapabilityUnitOfMeasureCodeItem rdf:ID="CapabilityUnitOfMeasureCodeItem03"> <rdfs:label rdf:datatype="xsd:string">HR</rdfs:label> <rdfs:comment xml:lang="en">A unit of 3,600 seconds duration.</rdfs:comment> </CapabilityUnitOfMeasureCodeItem> </owl:oneOf> </owl:Class> <owl:AllDifferent> <owl:distinctMembers rdf:parseType="Collection"> <CapabilityUnitOfMeasureCodeItem rdf:about="#CapabilityUnitOfMeasureCodeItem01"/> <CapabilityUnitOfMeasureCodeItem rdf:about="#CapabilityUnitOfMeasureCodeItem02"/> <CapabilityUnitOfMeasureCodeItem rdf:about="#CapabilityUnitOfMeasureCodeItem03"/ </owl:distincMembers> </owl:AllDifferent> Krok K4 Translacja Relacji do Własności (ang. Properties) OWL PoniŜszy rysunek przedstawia notację oznaczania krotności relacji IDEF-1X. Model JC3IEDM zawiera następujące informacje o relacjach (owl:ObjectProperty): • identyfikatory encji między którymi występuje relacja (Encja A-relacja-Encja B, Encja A odpowiada domenie (ang. domain) w OWL-DL, natomiast Encja B zakresowi (ang. range), • relacje odwrotną (inverse, co w OWL-DL oznacza się jako owl:inverseOf), • krotność relacji (w OWL odpowiada konstrukcji owl:cardinality uŜywanej przy definiowaniu restrykcji dla klas). Rysunek 11 Notacja krotności relacji w IDEF-1X 3 Wnioski i konkluzje Na polu walki dostawcy informacji mają charakter bardzo dynamiczny. Usługi pojawiają się i znikają, mogą wystąpić zmiany w definicjach informacji niektórych usług. Mechanizm integracji powinien być na tyle elastyczny, aby uwzględniać te uwarunkowania. Integracja semantyczna wspiera integrację róŜnych rozproszonych dostawców informacji i zapewnia luźne wiązanie (ang. loosely coupling) konsumenta z producentem. Luźne wiązanie oznacza, Ŝe w przypadku jakiejkolwiek zmiany po stronie producenta (np. definicji dostarczanej informacji przez usługę), Usługa Wyszukiwania Semantycznego (UWS) w oparciu o bazę wiedzy (ontologię) i mechanizmy wnioskujące będzie w stanie w dalszym ciągu przetworzyć zapytanie uŜytkownika i zwrócić mu satysfakcjonujące rezultaty. Dokładny opis działania UWS zostanie przedstawiony w oddzielnym artykule. Model JC3 zawiera bardzo bogatą taksonomię obiektów. W procesie translacji na ontologię OWL jest to bezpośrednio przekładalne na hierarchię dziedziczenia klas. Daje to duŜe moŜliwości wnioskowania o przynaleŜności do klas na podstawie cech. W mechanizmie wykorzystano teŜ konstrukcję rozłączności klas, pozawala to na wychwytywanie niespójności związanych z zaklasyfikowaniem tego samego obiektu jako naleŜącego do dwóch rozłącznych typów. W modelu JC3 reguły biznesowe (ang. business rules) są opisane głównie w postaci tekstowej lub tabelarycznej. Język ontologii umoŜliwia opisanie ich jako wyraŜeń logicznych i zastosowanie do sprawdzania spójności/poprawności danych pola walki. Automatyczna translacja reguł opisanych tekstowo jest dosyć uciąŜliwa, natomiast moŜna przeprowadzić pół-automatyczną translację reguł opisanych w formie tabelarycznej. Podczas badań zoobserwowano kilka problemów związanych z translacją modelu JC3 do ontologii. Pierwszym z nich jest podwójna taksonomia ObjectType/ObjectItem. W modelu wyjściowym jest to celowa decyzja projektowa, która ma na celu odseparowanie danych statycznych (słowników które zmieniają się dosyć rzadko) od danych dynamicznych (wystąpienia konkretnych obiektów). Ma równieŜ na celu umoŜliwienie elastycznego raportowania o typach obiektów. Jeden raport moŜe raportować obiekt jako czołg, a inny jako własność terenu. Podczas tworzenia ontologii naleŜy wziąć to pod uwagę, gdyŜ wystąpienie instancji o róŜnych typach które są rozłączne doprowadza do powstawania niespójności (ang. inconsistencies). Kolejną kwestią problematyczną jest duŜa liczba znaczeń zapisanych w formie tekstu, np. w opisach encji, atrybutów, relacji. Nie są to opisy zapisane w językach formalnych przetwarzalnych przez maszynę. Tak jest w przypadku opisowej części aneksu G reguł biznesowych. Innym problemem z którym zderzono się przy generowaniu ontologii z modelu relacyjnego JC3 był sam rozmiar modelu ontologicznego. W zaleŜności od przyjętego wariantu generowania model wynikowy miał od 10 do 60 MB tekstu. Jest to zbyt duŜa ontologia, która przekracza moŜliwości dostępnych narzędzi (open source), np. Protege czy Pellet. Rozwiązaniem tego problemu moŜe być podzielenie ontologii na kilka mniejszych dziedzinowych/aplikacyjnych, np. ontologia dotycząca opisu statków – Vessel, czy ontologia dotycząca dziedziny lotnictwa - Aircraft. Model danych JC3 został zaprojektowany pod kątem uŜyteczności zawartego w nim opisu pola walki. Głównym celem zamodelowanej ontologii jest równieŜ przydatność w celu odzwierciedlenia sytuacji pola walki. Wwygenerowanie ontologii ogólnej pokrywającej wszystkie przypadki uŜycia moŜe okazać się bezuŜyteczne. Rozwijanie odseparowanych (ang. standalone) ontologii dziedzinowych bez wyodrębnienia w nich standardowych, ogólnie rozpoznawalnych wyŜszych warstw abstrakcji (ontologii wyŜszego rzędu) często przyczynia się do braku zrozumienia między dziedzinami, powoduje utrudnienia o ile nie uniemoŜliwia w ogóle automatyczne wnioskowanie na tak rozproszonych zasobach informacyjnych. Ontologie wyŜszego rzędu są remedium na integrację róŜnych odseparowanych systemów dziedzinowych, wykonanych bardzo często przy uŜyciu starych technologii, z modelami informacyjnymi mało elastycznymi i mało elastycznych jeśli chodzi o integrację z innymi systemami. Ontologia JC3IEDM jest budowana jako ontologia wymiany danych pomiędzy róŜnymi systemami C2 i moŜe być traktowana jako ontologia wyŜszego rzędu. Pomimo kilku niedociągnięć takich jak: opis wielu znaczeń nie w formie języka formalnego lecz opisu tekstowego, podwójna taksonomia obiektów i typów obiektów, ukierunkowanie na modelowanie relacyjne ER, ontologia ta jest jedynym tak szeroko wykorzystywanym modelem wymiany informacji pomiędzy systemami NATO i narodowymi C2. 4 Literatura [Berners Lee 2001] The Semantic Web, Scientific American Magazine, 17 maja 2001, Tim Berners Lee, James Hendler, Ora Lassila [MITRE 2004] MITRE Technical Report, Netcentric Semantic Linking, październik 2004, Mary K. Pulvermacher, Suzette Stoutenburg, Salim Semy [Gomez 2004] Ontological Engineering, 2004, Asuncion Gomez-Perez, Mariano Fernandez-Lopez, Oscar Corcho [OWL04] Specyfikacja OWL, http://www.w3.org/TR/2004/REC-owl-guide-20040210/ [RDF04] Specyfikacja RDF, http://www.w3.org/RDF [OWL-S1.1] Specyfikacja OWL-S v.1.1 http://www.w3.org/Submission/OWL-S/ Praca naukowa finansowana ze srodków na nauke w latach 2007-2010 jako projekt badawczy zamawiany.