STUDIA INFORMATICA 2005 Volume 26 Number 3 (64) Michał ŚWIDERSKI Politechnika Śląska, Instytut Informatyki OGÓLNA ARCHITEKTURA SYSTEMU SEMANTYCZNEJ INTEGRACJI GEOGRAFICZNYCH ŹRÓDEŁ DANYCH *) Streszczenie. W artykule określone zostały wymagania, które stają przed systemem semantycznej integracji geoprzestrzennych źródeł danych w sieci Internet. Następnie przedstawiona została nowa architektura systemu, uwzględniająca relacyjno-obiektową specyfikę danych geoprzestrzennych, wykorzystująca w Schemacie Koncepcyjnym połączenie logiki deskrypcyjnej oraz Datalog, wnioskowanie w komponencie terminologicznym logiki deskrypcyjnej, zmodyfikowany algorytm przepisywania zapytań oraz dodanie opisu semantycznego do dokumentu WSDL usług Web. Słowa kluczowe: semantyczna integracja, GIS, LAV, DL, Datalog GENERAL ARCHITECTURE OF SEMANTIC GEOSPATIAL DATA SOURCES INTEGRATION SYSTEM Summary. In this paper we sketch requirements that the semantic integration system for geospatial data in Internet must face. Then we present novel architecture of such system that takes object-relational nature of GIS data into account, modeling Conceptual Schema with both DL and Datalog, using DL T-Box reasoning, modified query rewriting algorithm and placing semantic data sources annotation in WSDL documents of Web Services. Keywords: semantic integration, GIS, LAV, DL, Datalog 1. Wprowadzenie W dzisiejszych geoprzestrzennych bazach danych zgromadzona jest ogromna ilość danych geograficznych, wykorzystywanych w wielu dziedzinach życia. Dane te służą m.in.
30 M. Świderski do generowania dokładnych map w firmach kartograficznych, planowania przestrzennego władzom państwowym, analizy trendów sprzedaży lub lokalnych efektów akcji marketingowych firmom reklamowym. Z powodu wielości zastosowań danych geograficznych ich zbieranie często nie jest skoordynowane, dane przechowywane są najczęściej w systemach zamkniętych i w przeróżnych formatach. Wszystkie te czynniki skłaniają do wypracowywania sposobów integracji danych geograficznych, biorących pod uwagę specyfikę samych danych oraz najnowsze standardy komunikacji w sieci Internet. Celem systemu integracji jest dostarczenie jednolitego interfejsu dla różnych źródeł danych, tak by użytkownik mógł specyfikować dane, których potrzebuje, natomiast nie musiał szukać odpowiednich źródeł danych, pracować z każdym z tych źródeł osobno, a następnie łączyć danych z nich uzyskanych [1]. W literaturze występuje wiele zaproponowanych architektur systemów integracji, z których najpopularniejszymi były federacyjne i rozproszone bazy danych. Architektury te, mimo swojej przydatności, zajmowały się jedynie integracją danych na poziomach syntaktycznym i strukturalnym oraz nie umożliwiały dynamicznej zmiany zestawu źródeł danych, co jest częstym przypadkiem w sieciach rozległych typu Internet. Proponowana architektura, biorąc pod uwagę specyfikę danych geoprzestrzennych, próbuje rozwiązać problem heterogeniczności danych na poziomach syntaktycznym, strukturalnym i semantycznym [2], umożliwiać przyłączanie i odłączanie źródeł danych w czasie działania systemu oraz wykorzystać aktualne standardy wymiany danych w sieci Internet, wykorzystujące XML, tj.: GML i Web Services. Struktura dalszej części artykułu przedstawia się następująco: w pkt. 2 zajmiemy się problemami oraz wymaganiami, z którymi musi zmierzyć się nowy system semantycznej integracji danych geoprzestrzennych; w pkt. 3 przedstawiona zostanie architektura systemu próbującego odpowiedzieć na postawione wymagania; w pkt. 4 podsumowane zostaną dotychczasowe prace oraz przedstawiony zostanie plan rozwoju zaproponowanej architektury. 2. Wymagania stawiane systemowi integracji Architektura nowo tworzonego systemu semantycznej integracji danych geoprzestrzennych powinna brać pod uwagę: relacyjno-obiektowy charakter danych, realia sieci Internet, w której poszczególne węzły sieci mogą być w danej chwili niedostępne lub mogą pojawić się nowe, wcześniej nie publikowane, potrzebę integracji danych na poziomie semantycznym z wykorzystaniem ontologii zapisanych w logice deskrypcyjnej oraz wykorzystywać *) Praca finansowana z funduszu BW-463/RAu2/2004 Instytutu Informatyki Politechniki
Ogólna architektura systemu semantycznej integracji geograficznych... 31 standardy: opisu geograficznych danych GML oraz zdalnego wywoływania procedur oraz przekazywania danych Web Services. 2.1. Charakterystyka danych geograficznych Dane geoprzestrzenne są o tyle specyficzne, że nie da się ich w pełni opisać ani w modelu relacyjnym, ani w obiektowym. Można sobie łatwo wyobrazić sytuację, gdy przechowujemy w bazie danych obiekty klasy Budynek oraz obiekty klasy Biurowiec, dziedziczące cechy klasy Budynek oraz dodające cechy specyficzne dla siebie. Sytuację taką można zamodelować z użyciem hierarchii klas. W rzeczywistości może zajść konieczność łączenia poszczególnych obiektów klasy Budynek tak, by zamodelować ciąg budynków przyległych do siebie. Ten przypadek wymaga zastosowania modelu relacyjnego. Widać więc, że pożądane jest połączenie modelu obiektowego z relacyjnym, by także obiekty klasy Biurowiec mogły być uwzględnione w danej topologii jako obiekty klasy Budynek. Innym problemem, z którym spotykamy się integrując dane geograficzne, jest możliwie duża ilość rozproszonych źródeł danych oraz ogromna ilość danych w nich przechowywana. Zmusza to system integracji do zapewnienia odpowiedniej wydajności tak, by był on w stanie wykorzystać setki rozproszonych źródeł danych w czasie akceptowalnym dla użytkownika. Dodatkowymi problemami związanymi z danymi geoprzestrzennymi są: integracja danych reprezentowanych w postaci obrazów (często o różnej rozdzielczości) oraz uwzględnianie różnych sposobów projekcji powierzchni Ziemi. Te problemy nie są podejmowane przez niniejszą pracę. 2.2. Integracja danych na trzech poziomach W procesie integracji danych można natknąć się na sytuację, gdy w dwóch 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 w oparciu o opis semantyki, a dopiero w drugiej kolejności konwertować dane do wspólnego formatu (poziom syntaktyczny i strukturalny). W przypadku danych geograficznych problem ten jest szczególnie istotny, ponieważ typy danych mogą być bardzo złożone i znacznie różniące się od siebie, a jednocześnie tak samo się nazywać. Śląskiej w Gliwicach.
32 M. Świderski 2.3. Wykorzystanie istniejących systemów wnioskujących Dołączenie opisu semantyki do danych wymusza wybór formalizmu, w którym ma być ona zapisana, a co za tym idzie możliwości wnioskowań, które można przeprowadzić w danym formalizmie. Najpopularniejszym obecnie sposobem dołączenia opisu semantycznego do danych jest dołączenie ontologii, zazwyczaj w logice deskrypcyjnej [1] (ang. Description Logic). Logika deskrypcyjna jest klasą logik formalnych szczególnie użytecznych do modelowania i wnioskowania na hierarchiach pojęć. DL reprezentuje wiedzę z danej dziedziny za pomocą definiowania konceptów ją opisujących (terminologia dziedziny), a następnie określa właściwości obiektów występujących w dziedzinie za pomocą ról łączących koncepty. Logiki deskrypcyjne reprezentują różną ekspresywność w zależności od dozwolonych w nich zestawów konstruktorów konceptów i ról. Sensowne wydaje się wykorzystanie do wnioskowań dla DL ogólnie dostępnych i silnie zoptymalizowanych silników wnioskujących, np. RACER [3]. 2.4. Konsekwencje podejścia ad hoc Najodpowiedniejszym podejściem do integracji danych w sieci Internet jest podejście ad hoc, w którym staramy się wyszukiwać i rozpoznawać źródła danych geograficznych w czasie działania systemu, a nie jak dotychczas korzystać z przygotowanego wcześniej zestawu dobrze udokumentowanych źródeł. Z taką koncepcją wiąże się kilka konsekwencji przedstawionych poniżej. W sytuacji gdy nie można z góry założyć ilości i zawartości źródeł danych, należy umożliwić dynamiczne przyłączanie i odłączanie źródeł. Dodatkowo każde źródło powinno opisywać parametry wejściowe oraz zwracane dane zarówno na poziomie strukturalnym jak i semantycznym, tak by mogło być poprawnie obsłużone w sposób automatyczny. Ze zmienną ilością źródeł danych związany jest także problem dokładności odpowiedzi na zapytanie. Okazuje się, że nie należy szukać rozwiązania dokładnego, ale maksymalnie zawartego [4], tzn.: najlepszego możliwego dla danego zestawu źródeł danych oraz zastosowanego języka opisu danych. Ponadto, jako udogodnienie dla użytkownika, można dodać możliwość stopniowego rozluźniania ograniczeń nałożonych na zapytanie, tak by dążyć do znalezienia odpowiedzi na zadane zapytanie nawet kosztem dokładności odpowiedzi [1]. Kolejną konsekwencją podejścia ad hoc jest konieczność inteligentnego łączenia danych na poziomie strukturalnym, z wykorzystaniem opisu semantycznego. Sytuacja taka występuje w przypadku łączenia obiektów o różnej strukturze i tej samej semantyce. W podejściu ad hoc niebanalnym problemem jest także wyszukiwanie nowych źródeł danych oraz cykliczne badanie dostępności już wykrytych, jednak nie zajmujemy się tym zagadnieniem w niniejszej pracy.
Ogólna architektura systemu semantycznej integracji geograficznych... 33 2.5. Zgodność z istniejącymi standardami Projektowany system powinien wykorzystywać szeroko przyjęte standardy, tak by jak najlepiej współpracował z istniejącymi już rozwiązaniami. Obecnie język XML staje się standardem reprezentacji danych w sieci Internet, dlatego też powinien być wykorzystany do reprezentacji danych na poziomie syntaktycznym. Konsorcjum OpenGIS opracowało standard GML [5] do reprezentacji danych geograficznych w XML, który został szeroko zaakceptowany. W projektowanym systemie nie są potrzebne wszystkie cechy standardu wersji 3, dlatego można ograniczyć jego użycie do specyfikacji prostych typów Simple Features, mogących jednak wyrazić dowolnie złożone obiekty zawierające prymitywy geometryczne. W proponowanej architekturze podzbiór GML odpowiadałby za warstwę strukturalną integracji danych. Konsorcjum OpenGIS opracowało także standard WFS [6] udostępniania danych geograficznych w Internecie jako Simple Features, jednak nie jest on zgodny ze standardami W3C, dotyczącymi wymiany danych i komunikatów Web Services. Wydaje się sensowne zaimplementowanie geoprzestrzennych źródeł danych jako serwisów Web [7], które zwracają dane typu Simple Feature, a ich dokument WSDL wzbogacony jest o informację o semantyce danego serwisu. Do zapisu Schematu Koncepcyjnego należy użyć standardu zapisu ontologii w XML: OWL [8], tak zmodyfikowanego, by mógł uchwycić także dodatkowe relacje zdefiniowane w schemacie. 3. Architektura systemu integracji By sprostać wszystkim wymaganiom postawionym w pkt. 2 zaproponowana została nowa architektura systemu integracji przedstawiona na rys. 1. W proponowanej architekturze użytkownik formułuje zapytania (krok 1 i 2) w oparciu o Schemat Koncepcyjny, opisujący koncepty dostępne w systemie i wzbogacony o zestaw operatorów przestrzennych (ang. spatial relationship operators). 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) z uwzględnieniem opisów struktur danych dołączonych do każdego źródła danych w postaci dokumentu WSDL. Połączone dane są zwracane do użytkownika w formacie GML. W dalszej części rozdziału przedstawione zostaną rozwiązania przyjęte dla poszczególnych składowych systemu.
34 M. Świderski Rys. 1. Proponowana architektura systemu semantycznej integracji Fig. 1. Proposed semantic integration system architecture 3.1. Schemat koncepcyjny W literaturze występują zasadniczo trzy najważniejsze podejścia do modelowania Schematu Koncepcyjnego [4]: relacyjne, obiektowe i hybrydowe. Dla danych geoprzestrzennych najodpowiedniejszym rozwiązaniem jest zastosowanie schematu hybrydowego, jednak dotychczasowe rozwiązania charakteryzowały się dużą złożonością obliczeniową operacji na takim schemacie oraz koniecznością budowania dedykowanych silników wnioskujących. Proponowane przez nas podejście wykorzysta w Schemacie Koncepcyjnym logikę DLP [9], będącą częścią wspólną logiki deskrypcyjnej SHIQ oraz programów w logice, dzięki czemu może być ona tłumaczona z logiki deskrypcyjnej na program w logice i na odwrót. Daje to bardzo ciekawe możliwości budowania Schematu Koncepcyjnego w logice hybrydowej, w której można wykonywać standardowe wnioskowania dla DL, a następnie przetłumaczyć schemat na program w logice. Transformacja taka ma sens, gdyż schemat staje się zestawem relacji, dla których istnieją bardzo wydajne algorytmy przepisywania zapytań. Schemat Koncepcyjny będzie składał się z dowolnych konstrukcji dozwolonych przez logikę DLP oraz nagłówków klauzul Horna. W DLP wyrażamy hierarchię obiektów i ról, natomiast klauzule Horna wprost wyrażają n-argumentowe relacje (podobnie jak w rozwiązaniach czysto relacyjnych). Spójność modelu zagwarantowana jest przez założenie
Ogólna architektura systemu semantycznej integracji geograficznych... 35 rozłączności zbiorów nazw stosowanych w komponencie terminologicznym i relacyjnym. Dzięki tym założeniom połączenie dwóch Schematów Koncepcyjnych polega na prostym sumowaniu zbiorów relacji schematów, gdzie niezgodności zmiennych usuwane będą w standardowy sposób przez podstawienia, oraz na klasyfikacji komponentów T-Box schematów za pomocą standardowego silnika wnioskującego dla logiki SHIQ, np. RACER. Problemem, który nieodłącznie związany jest z logikami hybrydowymi, jest kompletność rozwiązań przez nie generowanych, co zostało zauważone już przy logice Al-log [10]. Aby uniknąć braku kompletności, ograniczymy zbiór konstruktorów konceptów, których można użyć do budowy zapytań, tak by uniemożliwić zadawanie pytań o informacje negatywne oraz przyjmiemy założenie, że żadne źródło nie zawiera wszystkich danych. Dzięki tym dwóm założeniom nie nastąpi konflikt między podejściem OWA, stosowanym dla logiki deskrypcyjnej oraz CWA, stosowanym dla programowania w logice. 3.2. Zapytanie użytkownika W systemie integracji semantycznej zapytania użytkownika budowane są w oparciu o Schemat Koncepcyjny jako klauzule Horna, gdzie koncepty reprezentowane są 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. Dodatkowo planujemy wprowadzenie trzech typów danych: obiektu geograficznego, napisu oraz liczby zmiennoprzecinkowej, tak by uchwycić podstawowe rozróżnienia danych i umożliwić automatyczne korekty warunków łączenia danych podczas formułowania zapytania. 3.3. Opis źródła 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 [1]. W proponowanej architekturze zostanie użyte podejście LAV (ang. Local-As-View), które do każdej relacji schematu źródła danych dołącza 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ą podejścia LAV jest bezproblemowa modyfikacja zestawu źródeł danych podczas działania systemu, ponieważ źródło określa swoją zawartość względem Schematu Koncepcyjnego, który nie musi zawierać informacji o jego istnieniu (w przeciwieństwie do podejścia GAV).
36 M. Świderski Opis semantyczny w praktyce będzie dołączany do dokumentów WSDL, opisujących serwisy Web na poziomie strukturalnym, łącząc logicznie wejścia, wyjścia i nazwę usługi ze Schematem Koncepcyjnym. Połączenie to, reprezentowane formalnie jako klauzula Horna, zostanie zapisane w dokumencie WSDL w transkrypcji RuleML. 3.4. Przepisywanie zapytania W naszym podejściu wykorzystamy wydajny algorytm przepisywania zapytań Destination Based Algorithm [11] 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, tak by wykryć niejawne relacje subsumpcji konceptów i ról oraz inwersji ról, a następnie traktowaniu konceptu jako sumy tego konceptu i wszystkich jego liści drzewa subsumpcji (analogicznie dla ról). Dzięki przechowywaniu informacji o hierarchii konceptów i ról możliwe będzie dokładniejsze przepisywanie zapytań, a gdy nie uda się znaleźć odpowiedzi na zapytanie, możliwe będzie także stopniowe uogólnianie zapytania użytkownika, by znaleźć jakąkolwiek odpowiedź na zapytanie. 3.5. Łączenie wyników W naszym systemie źródła danych, implementowane jako usługi Web, powinny zwracać kolekcje obiektów GML, tzw. Simple Features Collections. Format ten jest o tyle korzystny, że umożliwia przechowywanie w jednej kolekcji wielu typów obiektów geoprzestrzennych, dzięki czemu możliwe jest bezproblemowe traktowanie typów bazowych i pochodnych w jednakowy sposób. Po uzyskaniu cząstkowych odpowiedzi z poszczególnych źródeł danych następują połączenie i filtracja wyników zgodnie z formą przepisanego zapytania. Poprawnie sformułowane zapytanie powinno łączyć obiekty geograficzne lub nakładać na nie ograniczenia poprzez role konceptów (odpowiadają temu pola klas w modelu obiektowym). W przypadku gdy w zapytaniu pojawi się jednak operacja łączenia lub sformułowany zostanie warunek bezpośrednio na obiektach geograficznych, obiekt będzie identyfikowany domyślnie poprzez obowiązkowy w GML atrybut name. Jeśli uwzględnimy powyższe uwagi, ewaluacja zapytania zasadniczo nie odbiega od ewaluacji zapytania w SQL. Osobnym problemem jest obsługa tzw. operatorów przestrzennych, które odpowiadają za ustalenie zależności przestrzennych między dwoma obiektami geograficznymi. Schemat Koncepcyjny zawiera dziewięć predefiniowanych operatorów, które reprezentowane są jako relacje. Możliwe są dwie interpretacje tych operatorów: jako wbudowanych predykatów interpretowanych lub jako wirtualnych relacji. Traktowanie tych operatorów jako predykatów interpretowanych wymusza skomplikowane przetwarzanie w algorytmie przepisywania
Ogólna architektura systemu semantycznej integracji geograficznych... 37 zapytań, natomiast traktowanie ich jako wirtualnych relacji, z których każda implementowana jest przez jedno wirtualne źródło, pozwala na dołączenie operatora jako kolejnego predykatu zapytania. Jedyną różnicą, w stosunku do zwykłego predykatu, będzie ewaluacja operatora (a właściwe wirtualnego źródła z nim związanego) na samym końcu oraz to, że nie zwraca on wartości, a jedynie odrzuca pary obiektów nie spełniających zadanej zależności przestrzennej. 4. Podsumowanie W artykule określone zostały wymagania, które stają przed systemem semantycznej integracji geoprzestrzennych źródeł danych w sieci Internet, a następnie przedstawiona została nowa architektura systemu próbująca sprostać postawionym wymaganiom. Architektura ta, pomimo swego rozbudowania, nie uwzględnia jeszcze kilku istotnych elementów, którymi można zająć się w przyszłości, m.in.: semantycznego wyszukiwania nowych serwisów Web w ogólnodostępnych katalogach, sprawdzania poprawności zapytania pod kątem semantyki oraz łączenia predefiniowanych Schematów Koncepcyjnych z uwzględnieniem rozwiązywania konfliktów znaczeniowych oraz wykrywania ukrytych zależności między konceptami. LITERATURA 1. Baader F., McGuinness D., Nardi D., Patel-Schneider P. (red): The Description Logic Handbook: theory, implementation, and applications. Cambridge University Press, 2003. 2. UCGIS: Research Priorities. The Geospatial Semantic Web, 2002. http://www.ucgis.org- /priorities/research/2002researchagenda.htm. 3. Haarslev V., Moller R.: Description of the RACER system and its applications. DL2001 Worshop on Description Logics, Stanford CA, USA, 2001. 4. Levy A. Y.: Logic-Based Techniques in Data Integration. Washington, USA, 1999. 5. Open GIS Consortium: OpenGIS Specifications: The Geography Markup Language. http://www.opengis.org/docs/02-023r4.pdf 6. Open GIS Consortium: OpenGIS Web Feature Service Implementation Specification. http://www.opengis.org/techno/specs/02-058.pdf 7. Œwiderski M.: The use of Web Services in Web GIS. IWCIT 03, Gliwice, 2003. 8. W3C: OWL Web Ontology Language. http://www.w3.org/tr/owl-ref/ 9. Volz R.: Web Ontology Reasoning with Logic Databases. Karlsruhe 2004.
38 M. Świderski 10. Levy A., Rousset M.C.: CARIN: A representation language combining horn rules and description logic. European Conference on Artificial Intelligence, 1996. 11. Wang J., Maher M., Topor R.: Rewriting general conjunctive queries using views. Australasian conference on Database technologies, Melbourne, Australia, 2002. Recenzent: Dr inż. Maciej Bargielski Wpłynęło do Redakcji 25 kwietnia 2005 r. Abstract This paper sketches requirements that the semantic integration system for geospatial data in Internet must face, i.e.: taking characteristics of geospatial data into account, integrating data on syntactic, structural and semantic level, implementing an ad hoc approach, using existing inference engines and conforming to W3C standards. Then we present novel architecture of such system (see Fig.1) that takes object-relational nature of GIS data into account by modeling Conceptual Schema with hybrid logic built from DL and Datalog. In such system user formulates query as Horn Clauses where concepts from Conceptual Schema are represented as unary predicates, roles as binary predicates and relations as n-ary predicates. To answer user queries we use a modified Destination Based query rewriting algorithm that is able to use hierarchy of concept and roles to find better rewritings. Finally we present how Web Services, used as data sources, should be semantically annotated and how to join data coming from separate data sources. Adres Michał ŚWIDERSKI: Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-101 Gliwice, Polska, Michal.Swiderski@polsl.pl.