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.