pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 27
w
Wnioskowanie hybrydowe w relacyjnej bazie danych
wykorzystujące podejście semantyczne
w
da
.b
w
Streszczenie. Niniejszy rozdział przedstawia środowisko semantycznego
przetwarzania danych z wykorzystaniem relacyjnej bazy danych, ontologii
i reguł stanowiących bazę wiedzy oraz zaproponowanego hybrydowego
narzędzia wnioskującego. Potrzeba integracji silników wnioskujących z Relacyjnymi bazami danych wiąże się z możliwością wykorzystania w aplikacjach semantycznych istniejących repozytoriów danych. Hybryda składa się
z silników wnioskujących: wstecz oraz w przód zadających zapytania na bazie ontologii. Oba silniki zostały zaimplementowane w języku skryptowym
Jess Language. Zaproponowana metoda została zaimplementowana w bibliotece narzędziowej SDL (ang. Semantic Data Library). Biblioteka ta odpowiada za automatyczną integrację relacyjnych baz danych, ontologii i reguł silnika Jess, oraz pozwala na zastosowanie wyżej wspomnianej metody wnioskowania hybrydowego. Ze względu na wstępny charakter prac nad biblioteką,
przedstawione zostaną również ograniczenia przyjęte w procesie transformacji i realizacji zapytań, oraz zagadnienia wydajności wnioskowania. Zaprezentowany zostanie przykład zastosowania biblioteki przy wykorzystaniu
ontologii opisującej relacje rodzinne, zawierającej zarówno pojęcia jak i Reguły.
pl
s.
1 Wprowadzenie
Współcześnie istniejące systemy informatyczne wymagają zarządzania danymi we wszystkich warstwach. Relacyjne bazy danych są najczęściej wykorzystywanymi systemami
w aplikacjach wymagających przechowywania i przetwarzania danych. W systemach tych
występuje jednak bariera semantyczna pomiędzy modelem danych, na których działają
aplikacje, a magazynem, jaki stanowi baza danych. Dla metadanych opisujących dane
o ubogiej strukturze (schemat relacyjny) nie wystarczają usługi odpowiedzi na zapytania,
wykonania aktualizacji czy zapewnienia mechanizmów wykonywania transakcji. Pozyskana informacja, żeby mogła być przetwarzana i analizowana, wymaga bogatszych możliwości w warstwie konceptualnej (stworzenia ontologii) i wnioskowania. Konieczna jest budowa środowiska obsługi baz wiedzy o złożonej architekturze, ponieważ jest to niezbędne
Jarosław Bąk, Czesław Jędrzejek
Politechnika Poznańska, Instytut Automatyki i Inżynierii Informatycznej,
Pl. M. Skłodowskiej-Curie 5, 60-965 Poznań, Polska
e-mail: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
J. Bąk, C. Jędrzejek
w
do działania systemów decyzyjnych czy regułowych. Środowisko obsługi, mające zastosowanie praktyczne, wymaga integracji systemów regułowych wraz z wnioskowaniem, systemów przetwarzania metadanych (ontologii) i systemów relacyjnych baz danych.
Przedstawiona w rozdziale metodyka pozwala na integrację relacyjnej bazy danych,
ontologii oraz regułowego silnika wnioskującego. Zaimplementowanie środowiska semantycznego przetwarzania danych, w postaci biblioteki SDL (ang. Semantic Data Library),
umożliwi przeprowadzanie procesów wnioskowana wykorzystujących dane pochodzące
z relacyjnych baz danych oraz metadane zdefiniowane w ontologii.
Wspomniana biblioteka umożliwi integrację:
− modelu konceptualnego wiedzy reprezentowanego w postaci ontologii,
− reguł przetwarzanych przez silnik wnioskujący,
− silnika wnioskującego,
− danych zawartych w relacyjnej bazie danych.
Potrzeba realizacji systemu wyniknęła w pracach przygotowawczych Systemu Analizatora Faktów i Związków [11]. Dotychczas istniejące systemy (SweetRules [20],
OWLJessKB [9]) integrują lub próbują integrować tylko niektóre elementy spośród wyżej
wymienionych. Obecnie istniejące systemy wnioskujące posiadające możliwość interakcji
z bazą danych (systemy wnioskujące wyłącznie w przód), wczytują całą zawartość bazy danych (partiami lub całościowo) do pamięci operacyjnej, co w znacznym stopniu spowalnia
działanie mechanizmu wnioskującego. Stąd wynikła potrzeba zbudowania uniwersalnego
narzędzia, łączącego zintegrowane funkcjonalności ontologii, wnioskowania oraz baz danych. Zastosowanie reguł wraz z ontologiami powinno umożliwić odkrywanie wiedzy, którą bardzo trudno uzyskać w przypadku samych zapytań SQL.
Opracowane przez autorów wnioskowanie hybrydowe, przedstawione w niniejszej pracy, stanowi połączenie dwóch silników wnioskujących: wstecz oraz w przód. Pierwszy
z nich odpowiedzialny jest za pobranie danych z relacyjnej bazy danych, drugi natomiast
pozwala uwzględnić ograniczenia nakładane na zmienne występujące w regułach, które nie
mogły (z przyczyn technicznych) zostać uwzględnione w procesie wnioskowania wstecz.
Zadaniem hybrydy jest zarządzanie dostępem do bazy danych oraz uaktywnianiem odpowiednich silników w procesie wnioskowania.
Celem niniejszej pracy jest przedstawienie budowy biblioteki integrującej wspomniane
narzędzia oraz hybrydowego systemu wnioskującego. Poruszone zostaną problemy występujące w drodze integracji oraz zagadnienia związane z wydajnością procesu wnioskowania. Najlepszym odpowiednikiem przedstawionego środowiska, dla dotychczas istniejących
systemów, jest narzędzie KAON2 [6], którego działanie stanowić będzie porównanie w testach wydajnościowych.
da
.b
w
w
pl
s.
2 Wykorzystywane narzędzia i języki
Do realizacji systemu wykorzystano standardy i narzędzia posiadające ugruntowaną pozycję rynkową i badawczą. Dla każdego, spośród integrowanych elementów, wybrano przedstawiciela w postaci języka bądź narzędzia wnioskującego, które wykorzystuje logiki deskrypcyjne. Z formalnego punktu widzenia stanowią one podzbiory logiki pierwszego rzędu
wraz z efektywnymi algorytmami wnioskowania. Ich przeznaczeniem jest taki sposób Reprezentacji wiedzy, w którym opisuje się ją w formie konceptów (odpowiednik klas bądź
też ram) i ról (porównywalnych z atrybutami klas i relacjami zachodzącymi pomiędzy klasami). Tak reprezentowana wiedza została podzielona na dwie części. Pierwszą z nich jest
terminologia (zbiór aksjomatów - TBox), która stanowi schemat konceptualny i jest wyra336
Wnioskowanie hybrydowe w relacyjnej bazie danych wykorzystujące podejście semantyczne
w
żana za pomocą hierarchicznej struktury pojęć. Terminologia opisuje również związki pomiędzy pojęciami. Drugą jest część asercyjna, tzw. ABox. Jest to instantacja schematu składająca się z tzw. przykładów pojęć tworzących wiedzę zawartą w bazie. Obecnie logiki deskrypcyjne znajdują coraz szersze zastosowanie. Używa się ich, między innymi, w inżynierii oprogramowania, obiektowych bazach danych, czy różnorodnych systemach eksperckich. Pozwalają także na sterowanie procesami produkcyjnymi, planowanie działań w robotyce, ale przede wszystkim wykorzystuje się je do wyrażania ontologii (np. język OWLDL, ang. Web Ontology Language Description Logics).
Reprezentantami poszczególnych elementów integracji są:
− język OWL [8] służący prezentacji konceptualnego modelu wiedzy,
− język SWRL [21] służący do zapisu reguł,
− silnik wnioskujący Jess [2],
− serwer relacyjnych baz danych – produkt firmy Microsoft – SQL Server 2000 [7].
w
2.1 Język OWL
w
da
.b
Język OWL (Web Ontology Language) jest standardem konsorcjum W3C [27]. Jest on
przeznaczony do definiowania semantyki dokumentów internetowych. Stanowi integralną
formę, która łączy zalety języków RDF [14], RDFS [15] oraz DAML+OIL [1]. W związku
z jego pochodzeniem, forma składniowa oparta jest na języku XML [28], przy czym liczba
form zapisu jest dość rozległa (RDF(S), N3, N-Triple i inne). Język OWL umożliwia tworzenie ontologii jako zbioru definicji pojęć, właściwości (relacji, atrybutów) a także obiektów będących przykładami pojęć (instantacje) i relacji. Zgodnie z konwencją wielowarstwowości w językach zapisu ontologii, OWL również posiada strukturę wielopoziomową.
Warstwy języka to tzw. „gatunki sów” (ang. species):
− warstwa OWL Lite – to najniższy poziom, który pozwala tworzyć taksonomię pojęć
ontologicznych opartą o relacje subsumcji. Pozwala również na nakładanie ograniczeń na relacje – jednak wystąpić mogą tylko więzy licznościowe (ang. cardinality
constraints). Warstwa ta nie pozwala na formułowanie rozszerzonych definicji pojęć
(które są jednocześnie tzw. konstruktorami klas),
− warstwa OWL DL (OWL Description Logics) – stanowi semantyczny odpowiednik
logik deskrypcyjnych. Pozwala na tworzenie rozszerzonych definicji klas poprzez
nakładanie kilku rodzajów ograniczeń. Stosowanie ograniczeń w znaczny sposób
wpływa na efektywność i rozstrzygalność systemów realizujących tę warstwę języka,
− warstwa OWL Full – stanowi zbiór konstruktorów, które nie posiadają żadnych ograniczeń, co przedkłada się na niską efektywność i brak rozstrzygalności. Warstwa ta
nie posiada również formalnie zdefiniowanej semantyki.
Ontologie OWL mogą mieć strukturę modularną. Dzięki zastosowaniu tzw. importom,
można tworzyć ontologie na różnych poziomach szczegółowości, a następnie składać je
w jedną całość. Język OWL wykorzystuje wszelkie dostępne obecnie metody i języki, które
mają zastosowanie w semantyce dokumentów, czyli XML, XSD, RDF oraz RDFS. Taka
integracja z językami znaczników, umożliwia rozszerzanie ontologii o inne zastosowania
i języki (np. SWRL).
pl
s.
2.2 Język SWRL
Język SWRL (Semantic Web Rule Language) jest propozycją języka reprezentacji reguł,
zaproponowaną przez konsorcjum W3C. Służy on do zapisu reguł semantycznych. Język
337
w
ten stanowi kombinację języków OWL-DL, OWL-Lite oraz elementów RuleML [18].
SWRL rozszerza aksjomaty języka OWL o reguły w postaci klauzul Horna, które mogą
operować na pojęciach ontologicznych. Budowa reguły jest oparta o standardowy schemat:
ciało reguły, reprezentujące warunki oraz głowa reguły, określająca efekt zajścia warunków. Zarówno głowa, jak i ciało nie muszą zawierać żadnych części atomowych (atom to
najmniejsza możliwa część, zapisana w danym formalizmie). Reguła, która nie zawiera ciała, jest zawsze określana jako prawdziwa, ponieważ nie posiada żadnych warunków, które
muszą zostać spełnione. Natomiast reguła, której głowa jest pusta, jest zawsze interpretowana jako fałszywa. Taki stan może oczywiście powodować brak możliwości spełnienia
warunków w ciele reguły. Zbiór wielu atomów jest traktowany jak koniunkcja warunków,
zakładając, że wszystkie one muszą być spełnione, aby wynik reguły był określony jako
prawdziwy. Wynik reguły oznacza zazwyczaj dodanie nowej danej (faktu) do bazy wiedzy,
co umożliwia zastosowanie nowych reguł (w przypadku sterowania reguł danymi). Zmienne w regułach są zawsze poprzedzone znakiem „?”, w przypadku wartości należy je podawać w cudzysłowie.
Język SWRL można wzbogacić o tzw. funkcje wbudowane w postaci ograniczeń wyrażonych w języku SWRLB (SWRL Built-ins) [22]. Więzy można nakładać na wartości występujących w regułach zmiennych oraz wyrażać zależności pomiędzy zmiennymi (np.?x >
?y).
Język SWRL posiada większą siłę wyrazu niż OWL DL, ale jego reguły, podobnie jak
w przypadku OWL Full, nie zawsze muszą być rozstrzygalne. Propozycja W3C stała się
nieformalnym (nie jest to rekomendacja, ale propozycja – ang. submission) językiem zapisu
reguł, wykorzystywanym przez narzędzia służące do zapisu ontologii (np. TopBraid [25],
Protégé [12]). Przykładem narzędzia, wnioskującego za pomocą reguł SWRL, jest silnik
wnioskujący Pellet [10]. Podobnie, jak RuleML czy OWL/XML, składnia języka SWRL
opiera się na języku XML. Możliwy jest również zapis w postaci składni języka RDF.
da
.b
w
w
2.3 Silnik wnioskujący Jess
pl
s.
Silnik wnioskujący Jess (Java Expert System Shell) [2] jest rozwijany w laboratoriach rządowych Sandia, w Stanach Zjednoczonych od 1995 roku. Jest to biblioteka pozwalająca na
wnioskowanie za pomocą algorytmu Rete [17]. Zmodyfikowanie działanie narzędzia pozwala na przeprowadzanie procesu wnioskowania w przód oraz wstecz. Wnioskowanie
regresywne wymaga jednak dokładnego wyspecyfikowania, które reguły i szablony (będące odpowiednikiem klas) w nim uczestniczą. Jess, jako silnik reguł, pozwala na konstruowanie oprogramowania, które posiada elementy sztucznej inteligencji, zapisane w faktach
i regułach. Całość biblioteki została zaimplementowana w języku Java oraz jest udostępniania nieodpłatnie w celach badawczych i edukacyjnych na okres 2 lat. W pracy wykorzystano wersję 7.0p1 narzędzia; najnowsza jego wersja zawierająca nowe funkcjonalności oraz
poprawę wydajności to 7.1.b1.
Biblioteka Jess znajduje zastosowanie w wielu systemach eksperckich oraz regułowych.
Dzięki możliwości zastosowania wnioskowań wstecz i w przód, istnieje możliwość wykorzystania jej w praktycznie dowolnym systemie, wymagającym mechanizmów wnioskowania.
338
2.4 Serwer relacyjnych baz danych SQL Server 2000
w
Serwer baz danych Microsoft SQL 2000 to komercyjny system zarządzania relacyjnymi bazami danych. Jest to system, który pozwala przechowywać, utrzymywać i zarządzać relacyjnymi bazami danych bardzo dużej skali. Korzysta on z dialektu języka SQL nazwanego
Transact-SQL [26]. Jest to sztandarowy produkt firmy Microsoft (na początku roku 2008
powinna ukazać się najnowsza wersja systemu – SQL Server 2008). Poprzez sterowniki
JDBC (Java Database Connectivity) [3] możliwe jest połączenie z bazą z poziomu języka
Java. SQL pozwala również na połączenie z bazą z użyciem innych języków i technologii
(np. C++, ADO).
w
2.5 Silnik wnioskujący KAON2
da
.b
w
Narzędzie jest następcą wcześniej powstałego narzędzia o nazwie KAON [5], jednak jego
przeznaczenie różni się zasadniczo od wersji poprzedniej. Warto również zaznaczyć, że oba
projekty są zupełnie niekompatybilne ze sobą. Narzędzie KAON służy głównie do tworzenia samej ontologii, natomiast jego następca do przeprowadzania wnioskowania przy użyciu ontologii. KAON2 pozwala również na wnioskowanie przy użyciu relacyjnej bazy danych. Wspominana możliwość wymaga utworzenia pliku XML, który odwzorowuje podstawowe pojęcia na kolumny tabeli relacyjnej (łączące klucz główny z inną kolumną). Plik
ten odpowiada za instantacje pojęć ontologicznych w bazie danych i jest odpowiednikiem
ontologii OWL, jednak zapisanym w formacie języka XML akceptowalnym przez bibliotekę KAON2. Zapytania zadawane są w języku SPARQL [19].
KAON2 działa w oparciu o algorytm wykorzystujący tzw. DL Safe Rules, czyli tzw.
bezpieczne reguły. Metodyka DL Safe Rules ma na celu połączenie zalet systemów regułowych z elementami logik deskrypcyjnych. Reguły te zapewniają rozstrzygalność wnioskowania. Bezpieczne reguły to takie, w których każda zmienna, występująca w regule, jest
zdefiniowana w jej ciele za pomocą predykatu spoza bazy wiedzy. Predykat stanowi gwarancję wartościowania każdej zmiennej występującej w regule do odpowiedniego faktu
w bazie wiedzy (w ABox). Takie podejście gwarantuje użycie wyłącznie zmiennych, dla
których istnieje wartościowanie (stąd określenie: „Safe”). Nie mogą występować zmienne
anonimowe, dla których (np. chwilowo) nie istnieje wartościowanie. Nie może również zostać uruchomiona żadna reguła, dla której nie są znane wszystkie wartościowania zmiennych w niej występujących. Podejście DL Safe Rules zostało szczegółowo opisane
w pracach [13] oraz [16].
pl
s.
3 Architektura oraz proces integracji elementów systemu
3.1 Architektura biblioteki SDL
Prezentowana architektura środowiska semantycznego przetwarzania danych składa się
z następujących modułów:
− Jess – Java Expert System Shell,
− Ontologia OWL – ontologia zawierająca metadane semantyczne opisujące bazę
danych, zapisana w języku OWL,
− Ontologia OWL+SWRL – ontologia wzbogacona nowymi pojęciami oraz regułami
w języku SWRL,
339
− BD – baza danych SQL Server 2000 lub 2005 (biblioteka SDL obsługuje obie wersje
serwera).
Architektura systemu została przedstawiona na rys. 1, na którym kierunek strzałek określa
przepływ informacji pomiędzy modułami.
Jess
w
w
Ontologia OWL
Metadane
Reguły
Zapytania
Odpowiedzi
Dane
Generacja
OWL
w
SDL
Ontologia OWL+SWRL
OWL+SWRL
da
.b
Metadane
Dane
BD
Rys. 1. Architektura narzędzia semantycznego przetwarzania danych – SDL
3.2
Opis procesu integracji relacyjnej bazy danych, ontologii OWL+SWRL oraz
silnika wnioskującego
pl
s.
Celem przedstawionej integracji jest możliwość przekształcania stanowiących powiązaną
całość danych relacyjnych, ontologii OWL oraz reguł SWRL do formatu akceptowalnego
przez silnik wnioskujący Jess. Możliwości biblioteki Jess sprawiły, że jest ona punktem
końcowym całej integracji, w którym dokonywane jest wnioskowanie oraz uruchamiane są
zapytania. W trybie wnioskowania w przód, przestrzeń robocza Jess zawiera dane, pochodzące z relacyjnej bazy danych, odwzorowane na format szablonów języka Jess Language.
Warstwa ontologiczna systemu, którą stanowi dowolna ontologia OWL wraz z regułami
SWRL, jest również odwzorowywana na formę szablonów oraz reguł i zapytań Jess.
Prezentacja wszystkich danych w jednym formacie języka Jess Language pozwala na
wykorzystanie wszystkich możliwości systemu wnioskującego. Proces integracji przedstawiony został na rys. 2.
340
Dodanie pojęć,
właściwości i
reguł
Metadane
Ontologia
OWL
Ontologia
SWRL
w
Baza
danych
Odwzorowanie
wszystkich
elementów w
Jess
Silnik
Jess
w
Zapytania, odpowiedzi
w
Rys. 2. Proces integracji realizowany przez bibliotekę SDL
da
.b
Możliwość wnioskowania na danych, pochodzących z relacyjnej bazy danych, przy użyciu hybrydy wnioskującej, wymaga przeprowadzenia odpowiedniej transformacji. Proces
składa się z trzech etapów oraz wiąże się z koniecznością przyjęcia założeń, których spełnienie jest warunkiem koniecznym dla częściowego zautomatyzowania całego procesu.
Kryteria te muszą obowiązywać od momentu projektowania bazy danych, aż po otrzymanie
wyników wnioskowania. Przyjęte założenia dotyczą głównie form zapisu, których należy
przestrzegać w zapisie metadanych. Należą do nich następujące wymagania:
− nazwa tabeli oraz nazwa kolumny w relacyjnej bazie danych nie mogą zawierać
znaku „-”,
− każda tabela relacyjna musi posiadać jednoelementowy klucz główny,
− właściwości w ontologii są rozumiane w następujący sposób: zapis maOjca(?x, ?y)
oznacza, iż ?y jest ojcem ?x (inaczej: ?x maOjca ?y); pierwsza zmienna jest
odpowiednikiem rdfs:domain, natomiast druga rdfs:range,
− specyfikacja zmiennych, występujących w regułach SWRL, pochodzących z bazy
danych, musi identyfikować kolumnę w tabeli i być rozdzielona znakiem „-”
z identyfikatorem zmiennej (przykładowo: jeśli zmienna ?x ma reprezentować
wartość w kolumnie ID, jej zapis powinien być następujący: ?ID-x),
− ograniczenia, nałożone na zmienne, muszą być zapisywane po wcześniejszej
deklaracji zmiennej (czyli określenia jej przynależności, np. Osoby(?ID-x) ∧
swrlb:equal(?ID-x,4) →...),
− zalety ontologii są wykorzystywane w bardzo wąskim zakresie; ograniczono się
wyłącznie do zastosowania jej w charakterze siatki pojęć i właściwości, jednak bez
określania warunków relacji między nimi; opis relacji oraz ograniczenia zapisać
można za pomocą reguł,
− jeśli chcemy wprowadzić warunki na przynależność jakiejś danej do klasy, należy
zapisać odpowiednią regułę w języku SWRL (przykładowo reguła określająca
przynależność do klasy Kobieta może wyglądać następująco: Osoby-Płeć(?ID-x,
"K") → Kobieta(?ID-x),
− w zapisie ontologii nie specyfikuje się instantacji – użyte mogą być tylko klasy,
właściwości i reguły,
pl
s.
341
w
− w zapisie klas nie precyzuje się warunków, jakie klasa musi spełniać, a także
właściwości dotyczących tej klasy,
− w zapisie właściwości nie rozróżnia się zakresów domain i range,
− właściwości DatatypeProperty pochodzą wyłącznie z bazy danych i są poprzedzone
prefiksem, informującym z jakiej tabeli pochodzą (przykładowo właściwość Płeć,
pochodząca z tabeli Osoby zostanie zaprezentowana następująco: Osoby-Płeć),
− istnieje możliwość dodania własnych właściwości DatatypeProperty w etapie drugim
transformacji, pamiętając o przyjętych założeniach,
− właściwości ObjectProperty są tworzone podczas pracy nad ontologią w edytorze
Protégé,
− dziedziczenie klas lub właściwości nie jest uwzględniane w transformacji ontologii
OWL do formatu języka Jess Language,
− każda klasa, nie pochodząca z bazy danych, ale stworzona w narzędziu Protégé,
posiada atrybut Name, który pozwala identyfikować instantację klasy, pod
warunkiem, że jest unikalny (np. klucz główny pochodzący z tabeli relacyjnej),
− typy danych przechowywane w kolumnach nie mogą być postaci: Image i BLOB,
gdyż późniejsza próba ich odwzorowania w silniku Jess jest niemożliwa,
− typ danych, przechowywanych w danej kolumnie, nie jest odwzorowywany,
ponieważ obecna wersja biblioteki Jess 7.0p1 nie wymaga podania typu danych;
dlatego też wszystkie dane traktuje się jako łańcuchy znaków, dla których można
wykonywać wszystkie funkcje języka SWRLB [22] zawarte w implementacji,
− wynikiem reguł SWRL jest dodanie nowej informacji – brak możliwości innych
manipulacji, takich jak usunięcie czy modyfikacja,
− reguły SWRL są rozszerzone o funkcje wbudowane tzw. built-ins, które zawierają
ograniczenia nakładane na zmienne; obecnie, spośród 122 funkcji wbudowanych
obsługiwane są wyłącznie następujące ograniczenia na zmienne:
− swrlb:equal – określa równość pomiędzy zmiennymi lub wartością i zmienną,
− swrlb:notEqual – brak równości,
− swrlb:greaterThan – większa,
− swrlb:greaterThanOrEqual – większa lub równa,
− swrlb:lessThan – mniejsza,
− swrlb:lessThanOrEqual – mniejsza lub równa,
− ograniczenia SWRLB należy podawać na końcu reguły zgodnie z kolejnością
wystąpienia zmiennej w regule (nie można nadać więzów na zmienną, która nie jest
wcześniej zdefiniowana).
da
.b
w
w
pl
s.
3.2.1
Etap pierwszy transformacji
Etap pierwszy to automatyczna transformacja schematu relacyjnej bazy danych na klasy
i właściwości, wyrażone w języku OWL. Transformacja jest możliwa poprzez podanie nazwy bazy danych. Etap ten jest w pełni zautomatyzowany i realizowany przez bibliotekę
SDL. Wszystkie tabele wraz z kolumnami zostają odwzorowane w następujący sposób:
− nazwa tabeli jest odwzorowywana jako klasa,
− kolumny tabeli są odwzorowywane, jako atrybuty klasy w następujący schemat: klasa-atrybut, przykładowo: Osoby-Płeć,
− pomija się typy kolumn, ze względu na późniejsze odwzorowanie w silniku Jess; jest
to jednak możliwe, lecz wymagałoby synchronizacji pomiędzy bazą danych, ontologią i silnikiem Jess w trzecim etapie transformacji.
342
w
Tak skonstruowane klasy i właściwości są zapisywane w pliku, w formacie języka OWL.
Użytkownik musi jedynie utworzyć nazwę swojej ontologii poprzez podanie adresu URI
oraz nazwę pliku docelowego. Przykładowa struktura przedstawiona została w tabeli 1. Jest
ona odwzorowywana na klasę Osoby oraz właściwości:
− Osoby-ID,
− Osoby-Imię,
− Osoby-Nazwisko,
− Osoby-Płeć,
− Osoby-Wiek,
− Osoby-IdOjca,
− Osoby-IdMatki,
− Osoby-PESEL.
w
Tabela 1. Schemat tabeli Osoby
ID Imię Nazwisko
Płeć Wiek
IdOjca
IdMatki
PESEL
w
da
.b
3.2.2
Etap drugi transformacji
Etap drugi transformacji, nie może być zautomatyzowany. Polega on na tym, że inżynier
wiedzy wczytuje wygenerowany plik OWL do edytora Protégé (lub dowolnego innego
obsługującego formaty OWL i SWRL), a następnie tworzy własne klasy, właściwości oraz
reguły w języku SWRL. Użytkownik może również tworzyć klasy złożone (na wzór klas
pochodzących z bazy danych). W tym celu wystarczy podać nazwę klasy, a podczas definiowania właściwości typu DatatypeProperty poprzedzić jej nazwę, nazwą klasy ze znakiem „-”, przykładowo: klasa Wujek i atrybut Wujek-mieszka.
Podczas tworzenia ontologii występujące w niej pojęcia należy podzielić na dwie grupy:
− pierwsza grupa pojęć łączących klucz główny z wartościami pochodzącymi z każdej
kolumny tabeli relacyjnej, np. maOjca (ID, IdOjca); każde pojęcie w polu domain
zawiera wartość klucza głównego; reguły definujące pojęcia zawierają pojęcia
z pierwszego etapu transformacji,
− drugą grupę pojęć stanowią dowolne koncepty, dla których wystarczy utworzyć reguły je definiujące.
Dla każdego z pojęć musi zostać utworzona jego definicja w postaci reguły. Ze względu
na 3 etap transformacji nie wolno łączyć właściwości wygenerowanych w pierwszym etapie z pojęciami z drugiej grupy. Oznacza to, że w pierwszej kolejności należy tworzyć pojęcia łączące klucze główne tabel z kolumnami, a następnie przy użyciu tak stworzonych
pojęć zapisywać reguły definiujące nowe pojęcia.
Aby móc przejść do etapu trzeciego transformacji, należy przestrzegać wszystkich
wcześniej przyjętych założeń, dotyczących tworzenia pojęć oraz reguł. Konkretne wartości
występujące w definicji reguł, muszą być ujęte w cudzysłów. Przykładowo, chcąc sprawdzić wartość właściwości Osoby-Płeć, zdefiniować można następującą regułę: OsobyPłeć(?ID-x, "K") → Kobieta(?ID-x).
Wynikiem etapu drugiego transformacji jest ontologia OWL wraz z regułami zapisanymi
w języku SWRL. Ontologia zapisana jest w pliku z rozszerzeniem *.owl.
pl
s.
3.2.3
Etap trzeci transformacji
W ostatnim, trzecim etapie transformacji, pojęcia, właściwości oraz reguły są automatycznie zamieniane na format języka Jess Language. Tworzone są dwa odrębne skrypty dla sil343
w
ników: w przód oraz wstecz. Ze względu na duże podobieństwo pomiędzy obydwoma
skryptami w podrozdziale tym zostanie przedstawiona generacja skryptu dla silnika wnioskującego w przód. W podrozdziale 4 natomiast opisane zostały modyfikacje dotyczące generacji skryptu silnika wnioskującego wstecz.
W pierwszej kolejności proces transformacji dotyczy klas oraz właściwości pochodzących z ontologii. Każda klasa jest zamieniana według następującego algorytmu.
1) Zapamiętaj nazwę klasy.
2) Jeśli istnieją jakiekolwiek właściwości, które są powiązane z zapamiętaną nazwą
klasy, to zapamiętaj je jako sloty (ang. slots); jeśli nie istnieją – utwórz jeden slot
name.
3) Utwórz szablon (ang. deftemplate) o nazwie klasy wraz ze wszystkimi odpowiadającymi slotami (jednym name lub wieloma).
W ten sposób jest odzwierciedlona struktura bazy danych, w której szablon oznacza nazwę
tabeli, a nazwa kolumny to odpowiedni slot. Podczas zamiany brane są wyłącznie właściwości typu DatatypeProperty.
W kolejnym kroku zamianie podlegają właściwości niepowiązane z bazą danych. Są to
właściwości typu ObjectProperty, utworzone podczas rozwijania, utworzonej przez człowieka ontologii. Każda właściwość jest traktowana w ten sam sposób. Na początku tworzony jest szablon o nazwie właściwości, a następnie dwa sloty: domain i range, które odpowiadają rdfs:domain i rdfs:range. Ich ontologiczne znaczenie nie jest jednak brane pod
uwagę (wymagałoby to stworzenia nowych reguł, które dokładnie rozróżniają, co jest dziedziną, a co zakresem danej właściwości). Przykładowo właściwość maKuzyna zostałaby zapisana następująco:
da
.b
w
w
(deftemplate maKuzyna
(slot domain)
(slot range))
Ostatnią, a zarazem najtrudniejszą część samej transformacji stanowi zamiana reguł zapisanych w języku SWRL na postać reguł języka Jess Language. Pomimo podobieństwa, związanego z ogólną budową reguł (warunki → konkluzja), ich zapis jest różny. Reguła, określająca relację posiadania córki, w języku SWRL wygląda następująco:
pl
s.
PESEL-IdOjca(?ID-x, ?IdOjca-z),
Kobieta(?ID-x)
→ maCorke(?IdOjca-z, ?ID-x)
natomiast w języku Jess Language prezentuje się ona jak poniżej:
(defrule MAIN::Def-maCorke
(PESEL (IdOjca ?z) (ID ?x))
(Kobieta (name ?x))
=>
(assert (MAIN::maCorke (domain ?z) (range ?x)))
)
Podczas zamiany reguł SWRL na Jess użyto bibliotek, dostarczonych z edytorem Protégé,
z których wykorzystano głównie SWRLJessTab [23] (służy do częściowej zamiany elementów języka OWL na Jess Language) oraz narzędzie Jena2 (służące do operacji dokonywanych na plikach w formacie OWL). Biblioteka SWRLJessTab przekształca reguły
SWRL na swój własny wewnętrzny format. W związku z tym wystąpiła potrzeba zaimplementowania algorytmu, umożliwiającego dostosowanie formatu reguł SWRLJessTab do
formatu Jess. Algorytm zamiany każdej reguły prezentuje się następująco.
1) Wczytaj regułę SWRL, zawartą w ontologii.
2) Transformuj jej postać na format i przy użyciu SWRLJessTab.
344
w
3) Transformuj regułę w formacie SWRLJessTab na format języka Jess Language.
4) Jeśli w zapisie reguły wystąpiły ograniczenia języka SWRLB, to dodaj je do utworzonej reguły Jess.
5) Na podstawie ciała reguły, wygeneruj zapytanie Jess, poprzedzone w nazwie literą
„q” (od ang. query).
6) Dodaj regułę i zapytanie do skryptu silnika Jess.
Przykład działania algorytmu, funkcjonującego na regułach z ograniczeniami, można
przedstawić na podstawie następującej reguły, zapisanej w języku SWRL:
w
Osoby-IdOjca(?ID-x, ?IdOjca-y),
Osoby-IdOjca(?ID-y, ?IdOjca-z),
Osoby-Wiek(?ID-z, ?Wiek-w),
swrlb:greaterThan(?Wiek-w, "65")
→ maDziadka(?ID-x, ?IdOjca-z)
w
Powyższa reguła dodaje do bazy wiedzy wszystkie pary osób typu „wnuk, dziadek”, gdzie
hasło: dziadek określa osobę, która ma więcej niż 65 lat (dziadek będący jednocześnie
emerytem) i posiada wnuka. Po zamianie tej reguły przez SWRLJessTab wygląda ona
następująco:
da
.b
(defrule Def-Dziadek (Osoby-IdOjca ?ID-x ?IdOjca-y)
(Osoby-IdOjca ?ID-y ?IdOjca-z) (Osoby-Wiek ?ID-z ?Wiek-w)
(forceCall ?f:0&:(invokeSWRLBuiltIn Def-Dziadek swrlb:greaterThan
?Wiek-w "65"))
=>
(assert (maDziadka ?ID-x ?IdOjca-z)) (assertOWLProperty "maDziadka"
?ID-x ?IdOjca-z)
)
pl
s.
Elementy powyższej reguły są zamieniane na odpowiedniki w języku Jess Language, np.
element (Osoby-IdOjca ?ID-x ?IdOjca-y) jest zamieniany na (Osoby (IdOjca ?y) (ID ?x)).
Należy to interpretować, jako fakt, iż osoba o identyfikatorze ?x ma ojca o identyfikatorze
?y. Elementy rozpoczynające się od wyrażenia forceCall, oznaczają wystąpienie ograniczenia SWRLB. Element ten jest usuwany i ulega transformacji na ograniczenie, wyrażone
w języku Jess Language, czyli w tym przypadku: (Wiek ?w&:(> ?w "65")). Reszta reguły
jest przepisywana do końca wraz z uwzględnieniem składni języka Jess Language, natomiast rezygnuje się z końcowej części reguły, czyli predykatów: assertOWLProperty lub
assertOWLIndividual. Ostateczna postać reguły w formacie Jess wygląda następująco:
(defrule MAIN::Def-Dziadek
(Osoby (IdOjca ?y) (ID ?x))
(Osoby (IdOjca ?z) (ID ?y))
(Osoby (Wiek ?w&:(> ?w "65")) (ID ?z))
=>
(assert (MAIN::maDziadka (domain ?x) (range ?z)))
)
4
Działanie hybrydy wnioskującej
Opracowana przez autorów metoda wnioskowania hybrydowego składa się z dwóch mechanizmów wnioskowania: wstecz i w przód. Wnioskowanie wstecz ma za zadanie zwiększyć wydajność działania biblioteki SDL. Pozwala pobierać z bazy danych informacje, które są istotne w trakcie wnioskowania, przez co eliminuje potrzebę wczytywania wszystkich
danych znajdujących się w bazie.
345
w
Hybrydę wnioskującą stanowią dwa, współpracujące ze sobą silniki Jess, zawierające skrypty dotyczące wnioskowania w przód oraz wstecz. Ze względu na implementację narzędzia
Jess oraz stosowane w nim algorytmy, niemożliwe jest uwzględnienie dodatkowych ograniczeń nakładanych na zmienne występujące w regułach wnioskowania wstecz. Stąd nastąpiła potrzeba dokonania podziału na silniki wnioskujące w przód oraz wstecz. Pierwszy
z nich tworzony jest we wspomnianej wcześniej integracji. Proces tworzenia drugiego rozpoczyna się na etapie trzecim integracji. Tworzenie skryptu silnika wnioskującego wstecz
przebiega w sposób zbliżony do generacji silnika wnioskującego w przód. Dokonywane są
następujące modyfikacje:
− do definicji każdego z szablonów dodawany jest znacznik wnioskowania wstecz (komenda do-backward-chaining),
− dla pojęć, których definicja wymaga połączenia z bazą danych (pierwsza grupa pojęć), każda zmienna Jess (poza tymi znajdującymi sie w polach domain i range poszukiwanego faktu) zamieniana jest na zmienną języka SQL, np. zmienna ?x na
declare @x varchar(100),
− następnie ciało reguły definujące pojęcie z pierwszej grupy zamieniane jest na zapytanie SQL, które stanowi integralną część reguły; np. dla pojęcia maOjca(?x, ?y),
tworzone jest zapytanie SQL: select ID from PESEL where IdOjca = ?x (zapytanie to
jest tworzone poprzez przekształcenie reguły definiującej relację maOjca: (Osoby
(IdOjca ?y) (ID ?x)) -> maOjca(?x, ?y) ),
− reguły definiujące pojęcia ontologiczne (druga grupa pojęć) zamieniane są poprzez
dodanie do oryginalnej definicji (już po transformacji do Jess) deklaracji need-X,
− reguły SWRL dające w wyniku ten sam efekt (np. różne definicje pojęcia
maDziecko) po zamianie na format języka Jess Language(wraz z zapytaniami SQL)
łączone są w jedną regułę z uwzględnieniem deklaracji need-X oraz pełną formą szukanego pojęcia, np. (need-maDziecko (domain ?x) (range ?y)).
Proces wnioskowania hybrydowego składa się z następujących etapów:
1) Uruchomienie zapytania komendą RunJessQuery – użytkownik otrzyma odpowiedź
(o ile znajduje się ona w bazie wiedzy znajdującej się w pamięci roboczej).
2) W przypadku braku odpowiedzi na zapytanie, zaktywuje ono odpowiednią regułę
(lub listę reguł) znajdującą się w silniku wnioskującym wstecz. Następuje uruchomienie wnioskowania poprzez wydanie komendy run – uruchomienie reguł wnioskujących (pobranie potrzebnych krotek z bazy danych).
3) Ponowne uruchomienie zapytania komendą RunJessQuery – w tym momencie użytkownik otrzyma odpowiedź na zadane zapytanie.
Etap 1 oraz 3 to etapy wnioskowania w przód, natomiast etap drugi to etap wnioskowania wstecz. Zadawane zapytania mają postać trójek RDF: obiekt, predykat, wartość, np.
maOjca(„100831”, ?y). Silnik wnioskujący wstecz dostarcza wyłącznie dane i pojęcia potrzebne do uzyskania odpowiedzi na konkretne zapytanie, natomiast silnik wnioskujący
w przód pozwala na uzyskanie odpowiedzi wraz ze wszystkimi ograniczeniami.
Prezentowane wnioskowanie hybrydowe posiada kilka wad. Aby móc rozpocząć cały
proces należy podać wartość klucza głównego dla dziedziny zapytania. Wartość tę można
uzyskać poprzez wcześniejsze zadanie zapytania SQL, np. SELECT ID FROM Osoby
WHERE imie = ‘Jan’ AND nazwisko = ‘Nowak’. W praktyce oznacza to, że zapytania mogą być zadawane w oparciu o spełnialność istniejących pojęć, przy czym zawsze należy podać wartość pola domain w zapytaniu, np. maKuzyna(„100831”, ?y), gdzie wartość
„100831” to wartość klucza głównego w tabeli. Wynikiem zapytania jest zbiór wartości
zmiennej ?y (w istocie zapytanie zawsze dotyczy pola range). Niemożliwym jest niestety
zadanie zapytania postaci: maKuzyna(?x, ?y) lub maKuzyna(?x, „100831”). Pierwsze zapytanie nie może zostać zadane, gdyż generowane zapytania SQL wymagają podania wartości
da
.b
w
w
pl
s.
346
początkowej (nie występują pytania typu SELECT * FROM tabela). Powodem niemożności
wystąpienia drugiego jest fakt, iż proces generacji zapytań SQL ukierunkowany jest na pole
domain (ewentualne zmiany można dokonywać ręcznie lub stworzyć nowy generator
z ukierunkowaniem na pole range).
5
Wydajność wnioskowania hybrydowego
w
da
.b
w
w
W celu przeprowadzenia testów wydajnościowych wnioskowania hybrydowego, stworzono
ontologię definiującą zależności rodzinne oraz relacyjne bazy danych o schemacie przedstawionym w tabeli 1 o wielkości: 1000, 300 000 i 580 000 wierszy. Testy przeprowadzane
były dla zapytania maKuzyna(„100831”, ?y), przy czym ogólna postać reguł biorących
udział w procesie wnioskowania jest przedstawiona poniżej:
− maRodzenstwo(?z, ?w), maDziecko(?z, ?x), maDziecko(?w, ?y) -> maKuzyna(?x
?y), ?x≠?y,
− maOjca(?x, ?w), maOjca(?y, ?w) -> maRodzenstwo(?x, ?y), ?x≠?y,
− maMatke(?x, ?w), maMatke(?y, ?w) -> maRodzenstwo(?x, ?y), ?x≠?y.
Każdy test był powtarzany pięciokrotnie w celu uśrednienia czasów realizacji zapytania.
Zapytania realizowane były przy użyciu narzędzi: KAON2, Jess (wnioskowanie w przód),
biblioteki SDL oraz odpowiadającego zapytania SQL przedstawionego poniżej:
AS Tab4
AS Tab4
AS Tab4
pl
s.
SELECT Tab4.ID AS y
FROM PESEL AS Tab1, PESEL AS Tab2, PESEL AS Tab3, PESEL
WHERE
Tab3.ID = '100831' AND Tab3.IdMatki = Tab1.ID AND
Tab4.IdMatki = Tab2.ID AND 100831 != Tab4.ID AND
Tab1.ID != Tab2.ID AND Tab1.IdOjca = Tab2.IdOjca
UNION SELECT Tab4.ID AS y
WHERE
Tab3.ID = '100831' AND Tab3.IdOjca = Tab1.ID AND
WHERE
Tab1.ID != Tab2.ID AND Tab1.IdMatki = Tab2.IdMatki
WHERE
WHERE
Tab4.IdOjca = Tab2.ID AND 100831 != Tab4.ID AND
WHERE
AS Tab4
AS Tab4
AS Tab4
347
w
FROM PESEL AS Tab1, PESEL AS Tab2, PESEL AS Tab3, PESEL AS Tab4
WHERE
FROM PESEL AS Tab1, PESEL AS Tab2, PESEL AS Tab3, PESEL AS Tab4
WHERE
w
Wyniki zostały przedstawione w tabeli 2. Testy wykonywane były na komputerze klasy
PC o następującej konfiguracji:
− procesor Pentium IV 3GHz, 1MB Cache,
− pamięć RAM wielkości 1GB, 400 Mhz,
− serwer relacyjnych baz danych SQL Server 2000.
w
Tabela 2. Porównanie wydajności poszczególnych narzędzi
1000
300 000
580 000
da
.b
Wielkość bazy Czas wykonania zapytania w poszczególnych narzędziach [ms]
danych
KAON2
Jess
SDL
SQL
[wiersze]
1200
920
380
33
4300
320 000
1650
650
6250
-
2250
1450
pl
s.
Z wyników przeprowadzonych testów wynika, iż najbliższa wydajności serwera SQL jest
biblioteka SDL realizująca wnioskowanie hybrydowe. Wynika to z przyjętych założeń dotyczących możliwości zadawania zapytań omówionych w Podrozdziale 4. Autorzy zdają
sobie sprawę z faktu, iż prezentowane wyniki nie pozwalają na obiektywną ocenę zaprezentowanej metody wnioskowania. Obecnie trwają prace nad użyciem testów wzorcowych
[24] umożliwiających zaprezentowanie wydajności biblioteki w szerszym zakresie.
Obecnie wykonana biblioteka SDL jest trzecią wersją systemu wnioskującego posiadającego interakcję z relacyjną bazą danych. Wersja pierwsza zawierała wyłącznie możliwość
wnioskowania w przód, co wiązało się z potrzebą wczytania wszystkich danych do pamięci. W wersji drugiej narzędzia wprowadzono wnioskowanie wstecz i stworzono mechanizm
wnioskowania hybrydowego. Obecna implementacja znacznie poprawia wydajność całego
systemu.
Znaczna poprawa wydajności w porównaniu do poprzednich wersji narzędzia wynika:
− ze zmniejszonej liczby reguł, które muszą zostać uruchomione (z 3 do 1) dla uzyskania instantacji jednego pojęcia;
− z operowania wyłącznie na kluczach głównych – brak wczytywania całych krotek.
6 Podsumowanie
Wnioskowanie hybrydowe ma za zadanie zwiększyć wydajność procesu wnioskowania
silnika Jess wykorzystującego relacyjną bazę danych. Zastąpienie potrzeby wczytania
wszystkich danych z bazy, trybem „na żądanie”, pozwala na kilkunastokrotne zmniejszenie
348
w
czasu potrzebnego na uzyskanie odpowiedzi, a tym samym na zbliżenie się do wydajności
serwerów SQL. Zaletą takiego podejścia jest skalowalność. Głównym powodem jest fakt,
iż nie jest wczytywana cała baza danych, a jedynie jej fragmenty istotne w procesie wnioskowania. Takie podejście umożliwia przeprowadzanie wydajnego procesu wnioskowania
na danych o rozmiarze większym, niż pamięć RAM komputera.
Obecna implementacja biblioteki SDL, przedstawiona w niniejszym rozdziale oraz przeprowadzone testy wydajnościowe wskazują, że połączenie relacyjnych baz danych z silnikiem wnioskującym przy użyciu ontologii, tworzy nową jakość i dostarcza narzędzia, które
pozwalają na efektywne zadawanie bardzo złożonych zapytań do bazy danych (trudnych do
poprawnego sformułowania w języku SQL). Wnioskowanie hybrydowe pozwala na usunięcie wad istniejących silników wnioskujących, których szybkość w wielu przypadkach jest
niezadowalająca. Wykorzystywany w pracy Jess jest uznawany za jeden z najszybszych
silników wnioskujących. Ze względu na wykorzystywany algorytm Rete, fakty poddawane
procesowi wnioskowania muszą się znajdować w pamięci RAM. Powoduje to, że silnik ten
może działać na relatywnie małej porcji danych. Zastosowanie wnioskowania hybrydowego usuwa wspominaną niedogodność.
Zaprezentowana hybryda znajdzie zastosowanie w problemach wymagających stosowania reguł. W tej grupie problemów dominują systemy eksperckie, w których duża liczba danych skutecznie ogranicza ich wydajność.
Bieżące badania ukierunkowane są na sprawdzenie wydajności zaproponowanej metodologii przy użyciu testów wzorcowych Manner i Waltz [24]. Wymaga to jednak opracowania
formalnego modelu działania wnioskowania hybrydowego, który zostanie szczegółowo
opisany w następnej pracy.
Obecnie trwają również prace nad praktycznym zastosowaniem opisanej metody
w projekcie systemu eksperckiego wspomagającego analizę dowodów w postępowaniu
przygotowawczym prowadzonym w sprawach gospodarczych. Kolejnym etapem prac nad
wnioskowaniem hybrydowym będzie dalsza poprawa jego efektywności oraz próba poradzenia sobie z przyjętymi obecnie ograniczeniami oraz innymi problemami (np. problem
interpretacji wyników - przyporządkowanie ID do odpowiedniej tabeli w przypadku wnioskowania na dużej liczbie tabel relacyjnych).
Praca ta została sfinansowana ze środków na naukę w latach 2006-2009 jako projekt badawczy rozwojowy "Narzędzie wspomagające procedury śledcze wykorzystujące automatyczne wnioskowanie" oraz przez grant Politechniki Poznańskiej 45-083/07/BS.
da
.b
w
w
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
pl
s.
Literatura
DAML+OIL, http://www.daml.org/2000/12/daml+oil-index
Java Expert System Shell, http://www.jessrules.com/.
JDBC, http://java.sun.com/javase/technologies/database/
Friedman-Hill E., „Jess in Action”, 2003, Manning Publications Co.
KAON, http://kaon.semanticweb.org/
KAON2, http://kaon2.semanticweb.org/
SQL Server 2000, http://www.microsoft.com/poland/sql/sql2000/default.mspx
Web Ontology Language (OWL) Guide Version 1.0, http://www.w3.org/TR/owl-features/
OWLJessKB, http://edge.cs.drexel.edu/assemblies/software/owljesskb/
Pellet, http://pellet.owldl.com/
Polska Platforma Bezpieczeństwa Wewnętrznego, „Narzędzie wspomagające procedury śledcze
wykorzystujące automatyczne wnioskowanie”, http://www.ppbw.pl.
12. Protégé Editor, http://protege.stanford.edu/
13. Motik B., Sattler U., Studer R.,Query Answering for OWL-DL with Rules, 2005.
349
w
14. RDF, http://www.w3.org/RDF/
15. RDFS, http://www.w3.org/TR/rdf-schema/
16. Motik B., Reasoning in Description Logics using Resolution and Deductive Databases,
http://www.fzi.de/ipe/eng/publikationen.php?id=1505, Rozprawa doktorska, 2006.
17. Algorytm Rete w narzędziu Jess, http://herzberg.ca.sandia.gov/jess/docs/70/rete.html
18. RuleML, http://www.ruleml.org/0.91/
19. SPARQL: http://www.w3.org/TR/rdf-sparql-query/
20. SweetRules, http://sweetrules.projects.semwebcentral.org/
21. SWRL: A Semantic Web Rule Language Combining OWL and RuleML,
http://www.w3.org/Submission/SWRL/
22. SWRLB, http://www.w3.org/2003/11/swrlb
23. SWRLJessTab, http://protege.cim3.net/cgi-bin/wiki.pl?SWRLJessTab
24. Testy wzorcowe: Waltza i Mannera, http://www.cs.utexas.edu/ftp/pub/ops5-benchmark-suite/
25. TopBraid Composer, http://www.topbraidcomposer.org/
26. Transact-SQL, http://en.wikipedia.org/wiki/Transact-SQL
27. Konsorcjum W3C, http://www.w3.org/
28. XML, http://www.w3.org/XML/
da
.b
w
w
pl
s.
350

pobierz plik referatu

Transkrypt

Podobne dokumenty

wniosku

Wzór upoważnienia

Pobierz w pdf - CzytajZaFREE.pl

RZECZPOSPOLITA POLSKA Warszawa, 01 lipca 2015 roku

tutaj - JUG Poznań

OŚWIADCZENIE do polisy Ja zam. nr pesel wyrażam

Bazy danych Złączenia zewnętrzne