pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 36
w
Wykorzystanie silnika wnioskującego dla logiki
deskrypcyjnej w systemie semantycznej integracji
w
1 Wstęp
da
.b
w
Streszczenie. Rozdział wskazuje miejsce i określa zadania silnika wnioskującego dla logiki deskrypcyjnej w systemie semantycznej integracji, wykorzystującym metodologię Local-As-View oraz zaproponowaną przez autora logikę hybrydową. Jako podstawowe zadania opisane zostaną: sprawdzanie poprawności schematu koncepcyjnego, sprawdzenie spełnialności zapytania
użytkownika, rozwinięcie zapytania zgodnie z definicjami opisanymi w logice deskrypcyjnej oraz pobranie drzewa subsumpcji i równoważności konceptów i ról. Dodatkowo przedstawione zostaną algorytmy transformacji formuł
Datalog do logiki deskrypcyjnej oraz wyrażeń logiki deskrypcyjnej do
Datalog.
pl
s.
W procesie integracji danych można natknąć się na sytuację, gdy w różnych źródłach danych istnieją typy danych lub tablice tak samo nazwane i o takiej samej strukturze, lecz
o zupełnie innym znaczeniu. Aby rozwiązać ten problem, należy w sposób jawny dołączać
informację o semantyce danych i integrować dane na podstawie opisu semantyki, a dopiero
w drugiej kolejności konwertować dane do wspólnego formatu. Proces integracji biorący
pod uwagę semantykę danych nazywamy semantyczną integracją [1]. W systemie semantycznej integracji zapytania użytkownika oraz semantyka danych zawartych w źródłach danych zazwyczaj określane są na podstawie o schematu koncepcyjnego, który reprezentuje
w ujednolicony sposób, na poziomie koncepcyjnym, schematy autonomicznych źródeł
danych. Logiczne połączenie schematów źródeł danych ze schematem koncepcyjnym
zazwyczaj ustanowione jest w jeden z dwóch sposobów: GAV lub LAV.
W podejściu LAV [2] (ang. Local-As-View) do każdej relacji schematu źródła danych
dołączony jest widok nad relacjami/konceptami schematu koncepcyjnego. Podejście to jest
trudne w implementacji, ponieważ aby odpowiedzieć na zapytanie użytkownika należy najpierw przepisać zapytanie (ang. query rewriting using views) z relacji/konceptów schematu
koncepcyjnego na relacje źródeł danych, mając do dyspozycji tylko widoki na schemacie
koncepcyjnym. Niewątpliwą zaletą tego podejścia jest bezproblemowa modyfikacja zestawu źródeł danych, co jest niezbędne w sieci Internet.
W zaproponowanej przez autora architekturze systemu semantycznej integracji do opisu
schematu koncepcyjnego wykorzystywana jest logika hybrydowa składająca się z kompoMichał Świderski: Politechnika Śląska, Instytut Informatyki,
ul. Akademicka 16, 44-100 Gliwice, Polska
email: [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
M. Świderski
w
nentu relacyjnego, reprezentowanego przez Datalog, oraz z komponentu terminologicznego, reprezentowanego przez specjalnie zaprojektowaną logikę deskrypcyjną. W trakcie
przepisywania zapytania formuły Datalog obsługiwane są przez algorytm DBA (ang.
Destination Based Algorithm), natomiast logika deskrypcyjna obsługiwana jest przez silnik
wnioskujący. Celem niniejszego rozdziału jest wskazanie zadań, za które odpowiedzialny
jest silnik wnioskujący, oraz sposobów ich implementacji z wykorzystaniem popularnego
silnika wnioskującego RACER [3].
Dalsza część tego rozdziału przedstawia się następująco: w podrozdziale 2 przedstawiona zostanie proponowana architektura systemu integracji oraz wskazane zostaną wymagania stawiane silnikowi wnioskującemu; w podrozdziale 3 przedstawione zostaną: sposoby
realizacji tych wymagań z użyciem silnika wnioskującego RACER oraz algorytmy transformacji wyrażeń między Datalog i logiką deskrypcyjną; w podrozdziale 4 podsumowane
zostanie wykorzystanie silnika wnioskującego w systemie semantycznej integracji.
w
2 Architektura systemu semantycznej integracji
w
da
.b
W proponowanej architekturze [4] użytkownik formułuje zapytania (krok 1 i 2) na podstawie schematu koncepcyjnego, opisującego w komponencie terminologicznym koncepty
i role dostępne w systemie i wzbogaconego o zestaw relacji dostępnych w komponencie relacyjnym. Następnie zapytanie użytkownika jest przepisywane (krok 3 i 4), tak by predykaty zapytania zostały zastąpione nazwami źródeł danych, z wykorzystaniem opisu semantycznego dołączonego do każdego źródła danych. Przepisane zapytanie zostaje podzielone
na podzapytania, dotyczące poszczególnych źródeł danych (krok 5) i rozesłane do nich
(krok 6). Odebrane wyniki są łączone (krok 7) i zwracane do użytkownika w formacie
GML. Architektura systemu przedstawiona jest na rys. 1.
pl
s.
Rys. 1. Schemat architektury systemu semantycznej integracji
2.1 Schemat koncepcyjny
Schemat koncepcyjny składa się z konstrukcji dozwolonych przez specjalnie zaprojektowaną logikę DLPSI (ang. Description Logic Programs for Semantic Integration) oraz z nagłówków klauzul Horna. W DLPSI wyrażamy hierarchię konceptów i ról, natomiast nagłówki klauzul Horna wprost wyrażają n-argumentowe relacje (podobnie jak w rozwiązaniach czysto relacyjnych).
362
Wykorzystanie silnika wnioskującego dla logiki deskrypcyjnej w systemie semantycznej integracji
w
2.1.1 Logika deskrypcyjna DLPSI
Na potrzeby systemu została zaprojektowana przez autora logika deskrypcyjna DLPSI, która
umożliwia bezkonfliktowe połączenie logiki deskrypcyjnej oraz nagłówków klauzul Horna
w schemacie koncepcyjnym. Logika ta została opracowana w oparciu o nową logikę DLP
[5], będącą częścią wspólną logiki SHIQ oraz programów w logice. Logika ta jest niesymetryczna, tzn. zbiór konstruktorów mogących pojawić się po lewej stronie aksjomatu zawierania jest różny od zbioru dozwolonego po prawej stronie. Właściwość ta wynika z niesymetryczności programów w logice. Na rys. 2 przedstawiono zestaw dozwolonych konstruktorów wraz z ich umiejscowieniem względem aksjomatu zawierania. Konstruktory
dozwolone dla równoważności mogą znaleźć się po obu stronach aksjomatu zawierania.
Koncept A jest konceptem atomowym, koncept C jest dowolnym konceptem utworzonym
za pomocą konstruktorów z danej strony, rola R jest atomowa.
w
w
Rys. 2. Zestaw dozwolonych konstruktorów dla logiki DLPSI
da
.b
pl
s.
2.1.2 Kompletność algorytmów operujących na Schemacie Koncepcyjnym
Standardowym problemem logik hybrydowych jest brak kompletności algorytmów je wykorzystujących, który może wystąpić w naszej logice na styku Datalog, który korzysta z założenia CWA (ang. Closed World Assumption) oraz logiki deskrypcyjnej, korzystającej
z założenia OWA (ang. Open World Assumption). Konflikt tych założeń nie występuje, ponieważ lewa strona logiki DLPSI, która jednocześnie jest językiem zapytań, jest przetłumaczalna na Datalog [5], a do tego nie zezwala na zadawanie zapytań różnie interpretowanych
w CWA i OWA, takich jak:
Dodatkowo w Schemacie Koncepcyjnym wykorzystujemy założenie UNA (ang. Unique
Name Assumption), które wymusza unikalności nazw stosowanych w komponencie terminologicznym i relacyjnym, oraz zakładamy rozłączność zbiorów nazw wykorzystanych
w tych komponentach.
2.2 Zapytanie użytkownika i opis źródła danych
Zapytania użytkownika są budowane na postawie schematu koncepcyjnego jako klauzule
Horna z równością, gdzie koncepty są reprezentowane jako predykaty unarne, role jako
predykaty binarne, a relacje jako predykaty n-arne. Klauzule mogą zawierać stałe oraz predykaty interpretowane, np. porównania arytmetyczne. Dzięki takim założeniom otrzymujemy język zapytań o ekspresywności porównywalnej z SQL bez grupowania i agregacji.
Ze względu na brak aksjomatu inwersji w logice DLPSI i konieczność kompletności al.gorytmu DBA, zmienne wyróżnione w klauzuli Horna powinny znaleźć się na pierwszej
pozycji predykatów binarnych odpowiadających rolom.
363
M. Świderski
Opis źródła danych jest także realizowany jako klauzula Horna, reprezentująca zapytanie
nad schematem koncepcyjnym. Opis dołączany jest w transkrypcji RuleML do dokumentu
WSDL, opisującego usługę Web na poziomie strukturalnym.
2.3 Przepisywanie zapytania
w
W naszym podejściu wykorzystujemy wydajny algorytm przepisywania zapytań DBA (ang.
Destination Based Algorithm) [6], [7] dla podejścia relacyjnego, który można zmodyfikować tak, by wykorzystywał informacje o hierarchii konceptów i ról, przy jednoczesnym zachowaniu poprawności, kompletności i wydajności. Modyfikacje te polegają na klasyfikacji
schematu koncepcyjnego w silniku wnioskującym RACER, tak by wykryć wszystkie relacje subsumpcji konceptów i ról, a następnie traktowaniu konceptu w zapytaniu jako sumy
tego konceptu i wszystkich jego liści drzewa subsumpcji (analogicznie dla ról).
Aby została zachowana kompletność algorytmu generowania celów w algorytmie DBA
konieczne jest narzucenie kolejnych ograniczeń: komponent terminologiczny musi być
acykliczny; zakazujemy konceptów nie nazwanych, tzn. w TBox, po lewej stronie aksjomatu zawierania, zezwalamy jedynie na nazwy konceptów; wymuszamy rozwinięcie zdefiniowanych konceptów w zapytaniu i opisach źródeł, ponieważ zmodyfikowany DBA działa
podobnie do algorytmu subsumpcji strukturalnej [8]. Złożoność średnia zmodyfikowanego
DBA jest rzędu O(qnq), gdzie n jest ilością uwzględnionych źródeł danych, a q oznacza
ilość predykatów w zapytaniu użytkownika. Ograniczenie terminologii do acyklicznych
zmniejsza ekspresywność logiki, chroni jednak system integracji przed potencjalnie nieskończoną ilością odwołań do danego źródła danych.
Ze względu na wydajność, przed przystąpieniem do przepisywania zapytania, należy
sprawdzić czy cały Schemat Koncepcyjny jest spójny, tzn.: czy nie zawiera sprzeczności
logicznych oraz czy zapytanie jest spełnialne, tzn.: czy ma sens jego przetwarzanie.
da
.b
w
w
3 Wykorzystanie silnika wnioskującego
pl
s.
Z analizy architektury systemu semantycznej integracji wynika miejsce oraz zadania silnika
wnioskującego dla logiki deskrypcyjnej. Jego optymalne wykorzystanie polega na sklasyfikowaniu komponentu terminologicznego, pobraniu drzewa subsumpcji oraz pobraniu definicji wszystkich konceptów przed przystąpieniem do przepisywania zapytań. Podczas generowania przepisań można korzystać z przechowywanych informacji, nie wykonując już
kosztownych odwołań do silnika wnioskującego. Ponowienie całego cyklu współpracy
z silnikiem wnioskującym jest konieczne w przypadku modyfikacji komponentu terminologicznego, jednak w sytuacji rzeczywistej powinna to być operacja bardzo rzadka.
3.1 Współpraca z silnikiem wnioskującym RACER
Do sprawdzenia spójności komponentu terminologicznego (TBox) możemy wykorzystać
komendę:
(check-tbox-coherence)
silnika RACER, której wynikiem jest lista niespełnialnych konceptów. Jeśli TBox jest spójny, tzn.: zwrócona lista jest pusta (NIL), możemy sprawdzić czy komponent terminologicz364
ny jest sklasyfikowany (tzn.: czy znane są wszystkie relacje subsumpcji w TBox). Jeśli nie
jest, wymuszamy klasyfikację TBox. Należy w tym celu przesłać komendę:
(tbox-classified?)
Jeśli otrzymana odpowiedź to NIL należy wymusić ponowną klasyfikację komponentu
terminologicznego, poprzez przesłanie komendy:
(classify-tbox)
w
Gdy TBox jest już sklasyfikowany możemy sprawdzić czy jest cykliczny, tzn. czy definicje konceptów odwołują się bezpośrednio lub pośrednio do samych siebie. Można
sprawdzić to przesyłając do serwera RACER komendę:
(tbox-cyclic?)
w
da
.b
w
Jeśli komenda zwróci T kończymy współpracę z silnikiem wnioskującym RACER. Jeśli natomiast TBox spełnia ograniczenia narzucone przez nasz system, możemy sprawdzić czy
zapytanie użytkownika jest spełnialne.
Zapytanie użytkownika jest przesyłane do systemu integracji jako formuła Horna,
w której niektóre predykaty odnoszą się do TBox, a pozostałe do komponentu relacyjnego
schematu koncepcyjnego. Aby sprawdzić sensowność zapytania względem TBox należy
wyodrębnić predykaty reprezentujące koncepty i role, a następnie przetłumaczyć je na wyrażenie w logice deskrypcyjnej. Algorytm tłumaczenia Datalog na DL przedstawiony
zostanie w punkcie 3.2. Spełnialność przetłumaczonego wyrażenia możemy sprawdzić bez
modyfikacji TBox wysyłając do silnika wnioskującego komendę:
(concept-subsumes? BOTTOM przetlumaczone_wyrazenie)
Jeśli wyrażenie zwróci T, zapytanie jest niespełnialne i nie ma sensu dalej go przetwarzać,
jeśli natomiast jest spełnialne należy pobrać z serwera RACER hierarchię konceptów i ról,
a także wszystkie definicje konceptów, które zostaną wykorzystane do rozwijania (ang.
unfolding) zapytania i opisów źródeł danych.
Aby pobrać hierarchię konceptów TBox przesyłamy komendę:
(taxonomy)
i otrzymujemy informacje w postaci zagnieżdżonej listy ((synonimy) (rodzice) (dzieci)):
pl
s.
((TOP NIL (DROGA ZJAZDY)) (AUTOSTRADA (BEZKOLIZYJNA DWUPASMOWA)
(BOTTOM)) (BEZKOLIZYJNA (DROGA) (AUTOSTRADA)) (DROGA (TOP)
(BEZKOLIZYJNA DWUPASMOWA)) (DWUPASMOWA (DROGA) (AUTOSTRADA)) (ZJAZDY
(TOP) (BOTTOM)) (BOTTOM (AUTOSTRADA ZJAZDY) NIL))
Następnie dla każdego konceptu pobieramy jego definicję. Przykładowa komenda dla konceptu AUTOSTRADA i wyniki wyglądają następująco:
(describe-concept AUTOSTRADA)
Wynik:
(AUTOSTRADA :TOLD-DEFINITION (AND BEZKOLIZYJNA DWUPASMOWA)
:PARENTS ((DWUPASMOWA) (BEZKOLIZYJNA)) :CHILDREN ((*BOTTOM* BOTTOM)))
Jeśli w wyniku, po nazwie konceptu, wystąpi słowo kluczowe :TOLD-DEFINITION, oznacza
to, że koncept został zdefiniowany i należy zapamiętać jego definicję, która następuje po
słowie kluczowym. Definicje te są potrzebne do rozwijania zapytań i opisów źródeł danych, tak by zapewnić kompletność generowania celów w DBA. Algorytm rozwijania zapytań zostanie przedstawiony w punkcie 3.2.
365
M. Świderski
Aby pobrać drzewo subsumpcji ról należy: pobrać nazwy wszystkich ról, pobrać grupy
synonimów, a następnie pobrać opisy dla każdej grupy synonimów. Pobranie nazw ról
może wyglądać następująco:
(all-roles)
Wynik:
((INV MA) MA)
w
Należy odrzucić role poprzedzone INV, ponieważ są one generowane automatycznie. Dla
pozostałych nazw należy pobrać synonimy i ze zwróconych definicji zapamiętać listy
rodziców i dzieci roli:
(role-synonyms MA)
Wynik:
(MA)
w
(describe-role MA)
Wynik:
(MA :PARENTS NIL :CHILDREN NIL :INVERSE (INV MA) :FEATURE NIL
:TRANSITIVE-P NIL)
w
W obecnej implementacji hierarchie konceptów i ról przechowywane są tablicach z mieszaniem, dzięki czemu średni czas sprawdzenia subsumpcji między dwoma konceptami
wynosi O(n/2), gdzie n jest wysokością hierarchii subsumpcji.
da
.b
3.2 Algorytmy konwersji wyrażeń między Datalog i logiką deskrypcyjną
Konwersje pomiędzy Datalog z równością, a logiką deskrypcyjną polegają na przetłumaczeniu wyrażenia z jednej z logik do formuły w logice predykatów pierwszego rzędu
(FOL), a następnie na przetłumaczeniu na drugą logikę [5]. Dzięki temu możemy teoretycznie określić tabelę potrzebnych przejść pomiędzy Datalog z równością i DLPSI. Wyniki
przedstawiono w tabeli 1.
Tabela 1. Przejścia pomiędzy Datalog z równością a DLPSI
pl
s.
Algorytm transformacji zapytania Datalog do logiki deskrypcyjnej można podzielić na
dwie fazy odpowiadające procedurom TransformujDatalogDoDL i GenerujDL. W pierwszej
fazie należy odrzucić predykaty zapytania, które nie mają odzwierciedlenia w TBox, a następnie wyszukać wszystkie wolne zmienne, które będą odpowiadały odrębnym wyrażeniom
DL. W drugiej, rekurencyjnej, fazie w procedurze GenerujDL wyszukujemy wszystkie predykaty odpowiadające wolnej zmiennej i tłumaczymy je do formatu zrozumiałego przez silnik wnioskujący RACER (dla zwięzłości pominięta została generacja nawiasów).
366
Algorytm 1. Konwersja zapytania w Datalog(=) na wyrażenia DL w notacji RACER
Procedura TransformujDatalogDoDL
Wejście: Zapytanie Q, hierarchie konceptów i ról z silnika wnioskującego
Wyjście: Zbiór wyrażeń w DL odpowiadających zapytaniu w Datalog
w
// wyodrębnienie predykatów związanych z TBox
Zbiór predykatów Q’= ø
Dla każdego predykatu treści zapytania Q
Jeśli arności predykatu <=2 i predykat jest (konceptem lub rolą)
Zapamiętaj predykat w Q’
Jeśli Q’== ø zwróć TOP
// wykonanie podstawień zmiennych, by odrzucić ograniczenia z Q
Wykonaj podstawienia zmiennych w Q’ z części ograniczeń zapytania Q
// wyszukanie wolnych zmiennych z DL
w
Zbiór zmiennych VFOUND = ø
Zbiór zmiennych VDEPENDENT = ø
Zbiór zmiennych VFREE = ø
w
Dla każdego predykatu w Q’
Jeśli arność predykatu == 1
Zmienną z pierwszej pozycji zapamiętaj w VFOUND
Zmienną z pierwszej pozycji zapamiętaj w VFOUND
Zmienną z drugiej pozycji zapamiętaj w VFOUND i VDEPENDENT
// wolne zmienne wyznaczają osobne wyrażenia DL
da
.b
VFREE = VFOUND - VDEPENDENT
Zbiór wyrażeń DL RETURNDLS = ø
Dla każdej zmiennej z VFREE
Zapamiętaj w RETURNDLS wynik GenerujDL dla każdej wolnej zmiennej
Zwróć RETURNDLS
Koniec TransformujDatalogDoDL
Procedura GenerujDL
Wejście: Zbiór Q’, wolna zmienna
Wyjście: Wyrażenie DL odpowiadające części zapytania w Datalog powiązanej
z wolną zmienną
pl
s.
Wynik RETURNDL = ø
Zbiór predykatów PREDS = ø
// wyszukanie predykatów odpowiadających danej zmiennej
Dla każdego predykatu w Q’
Jeśli pierwsza zmienna predykatu == wolna zmienna
Zapamiętaj predykat w PREDS
Jeśli PREDS == ø
Zwróć TOP
// generowanie koniunkcji wyrażeń jako konstrukcję (AND A (SOME R C))
Jeśli liczność PREDS > 1 dodaj AND do RETURNDL
Dla każdego predykatu w PREDS
Dodaj nazwę predykatu do RETURNDL
// generowanie kwantyfikacji egzystencjalnej (SOME R C)
Dodaj SOME i nazwę predykatu do RETURNDL
Dodaj wynik GenerujDL dla drugiej zmiennej do RETURNDL
Zwróć RETURNDL
Koniec GenerujDL
Jeśli dany predykat jest rolą, to dla drugiej zmiennej rekurencyjnie wywołujemy procedurę GenerujDL. Pierwszą zmienną możemy traktować jako wolną ponieważ zarówno
w DLPSI jak i w Datalog nie zezwalamy na inwersję ról. Powyższy algorytm przetłumaczy
zapytanie Q(x) :- DROGA(x), MA(x,y), ZJAZDY(z), y=z do prefiksowej notacji RACER
jako (AND DROGA (SOME MA ZJAZDY)).
367
M. Świderski
Algorytm 2. Rozwinięcie zapytania/opisu źródła w Datalog(=) z wykorzystaniem definicji
konceptów w TBox
Procedura RozwinZapytanieZTBox
Wejście: Zapytanie Q, definicje konceptów z silnika wnioskującego
Wyjście: Rozwinięte zapytanie w Datalog
w
Dla każdego predykatu treści zapytania Q
Jeśli predykat jest konceptem i ma definicję
// rozwinięcie predykatu zgodnie z definicjami TBox
Rekurencyjnie rozwiń definicję
Transformuj definicję do Datalog z wykorzystaniem zmiennej
aktualnego predykatu
Podstaw nową definicję w miejsce predykatu
Koniec RozwinZapytanieZTBox
w
w
Algorytm rozwinięcia zapytania w Datalog bierze pod uwagę jedynie koncepty z definicją w TBox. W logice DLPSI jedynym konstruktorem dostępnym w definicji jest koniunkcja konceptów, dlatego rekurencyjne rozwinięcie definicji jest trywialne. Oryginalny predykat zastępujemy, zgodnie z definicją w DL, koniunkcją predykatów unarnych w Datalog,
gdzie zmienną wszystkich predykatów jest zmienna oryginalnego predykatu. Algorytm 2
rozwinie zapytanie Q(x) :- AUTOSTRADA(x), przy definicji (equivalent AUTOSTRADA (AND
BEZKOLIZYJNA DWUPASMOWA)), do postaci Q(x):- BEZKOLIZYJNA(x), DWUPASMOWA(x).
da
.b
4 Podsumowanie
Literatura
1.
2.
3.
4.
5.
6.
7.
8.
pl
s.
W zaproponowanej architekturze systemu semantycznej integracji do reprezentacji schematu koncepcyjnego wykorzystany jest Datalog z równością oraz nowa logika deskrypcyjna
DLPSI. Dzięki jej specyficznym właściwościom oraz ograniczeniom nałożonym na Datalog
wnioskowanie na logice deskrypcyjnej może być wykonywane oddzielnie, w standardowym silniku wnioskującym RACER, a wyniki wnioskowania mogą być użyte w algorytmie przepisywania zapytań nie wpływając na poprawność ani na kompletność algorytmu
generowania celów. Dodatkowo, przy założeniu niezmienności komponentu terminologicznego, dzięki przechowywaniu informacji o drzewie subsumpcji, modyfikacje algorytmu
DBA nie wpływają znacznie na obniżenie jego wydajności, ponieważ średni czas przypasowania dwóch predykatów wzrasta z O(1) do O(n/2), gdzie n jest wysokością hierarchii
subsumpcji konceptów/ról.
Visser U., Stuckenschmidt H., Schlieder Ch.: Interoperability in GIS – Enabling Technologies.
5th Conference on GIS, Palma, 2002.
Levy A. Y.: Logic-Based Techniques in Data Integration. Uniwersytet Washington, May 1999.
Haarslev V., Möller R., Wessel M.: RACER User’s Guide and Reference Manual.
http://www.sts.tu-harburg.de/~r.f.moeller/racer/.
Świderski M.: Ogólna architektura systemu semantycznej integracji geograficznych źródeł
danych. Studia Informatica vol. 26, Gliwice, 2005.
Volz R.: Web ontology reasoning with logic databases. A thesis. Uniwersytet Karlsruhe, 2004.
Wang J., Maher M., Topor R.: Rewriting general conjunctive queries using views.
W materiałach Australasian conference on Database technologies, Melbourne, Australia, 2002.
Świderski M.: Metodologia LAV w systemie semantycznej integracji geoprzestrzennych źródeł
danych. Bazy danych: modele, technologie, narzędzia. WKŁ, Warszawa, 2005.
Baader F., McGuinness D., Nardi D., Patel-Schneider P.: The Description Logic Handbook:
theory, implementation, and applications. Cambridge University Press, 2003.
368

pobierz plik referatu

Transkrypt

Podobne dokumenty

Komunikat dotyczący Zapytania Ofertowego nr 3/2016 W

Formularz ofertowy OFERTA ZŁOŻONA DO ZAPYTANIA

tutaj

Usługa przewozu w obie strony osób transportem własnym

Nowe linie produktów