Reprezentacja obiektów oraz związków między obiektami w modelach semistrukturalnych

Transkrypt

1 Zeszyty Naukowe 8 Reprezentacja obiektów oraz związków między obiektami w modelach semistrukturalnych Dariusz Put Piotr Soja Janusz Stal Streszczenie Badania nad integracją informacji prowadzone są obecnie w różnych kierunkach. Obejmują problematykę określenia samej integracji, propozycję różnorodnych strategii oraz szereg teoretycznych i praktycznych rozwiązań. Niezależnie od podejścia do zagadnienia integracji istotne znaczenie ma zawsze sposób reprezentacji faktów, czyli obiektów i zdarzeń występujących w rzeczywistości oraz powiązań między nimi. Im bardziej ekspresyjny jest model danych, tym dokładniej można odwzorować projektowaną dziedzinę, jednak utrzymanie złożonego repozytorium oraz formułowanie zapytań staje się wtedy trudniejsze. W artykule dokonano przeglądu rozwiązań dotyczących modelowania konceptów (bytów abstrakcyjnych, klas) oraz związków między nimi w wybranych modelach semistrukturalnych, zaproponowanych do integracji informacji heterogenicznej. Na podstawie tych rozważań podano wskazówki dotyczące wyboru modelu integracyjnego do opisu informacji w organizacji oraz zarządzania tą informacją. Słowa kluczowe: modele semistrukturalne, modelowanie konceptów, integracja informacji, struktury danych Wprowadzenie Zadaniem systemów integracji danych i informacji jest zarządzanie heterogenicznymi informacjami rozproszonymi, przechowywanymi w różnorodnych systemach bazodanowych lub innych repozytoriach. Ze względu na ogromną niejednorodność samych informacji, ich semantyki, wykorzystywanych modeli danych, systemów, aplikacji, a także nieprzewidywalność potrzeb informacyjnych użytkowników oraz poziom posiadanej przez nich wiedzy w zakresie formułowania zapytań, stworzenie jednolitego modelu integracyjnego, a następnie opartego na nim systemu, jest przedsięwzięciem niezwykle złożonym. Projektowanie rozwiązań integracyjnych sprowadza się do stworzenia warunków dla łączenia informacji pochodzących z różnych systemów i zapisanych w różnorodny sposób. Zaproponowano szereg rozwiązań dedykowanych zarówno łączeniu jednego rodzaju informacji, jak i wszystkich możliwych jej typów. Jedno z podejść do integracji dotyczy danych semistrukturalnych i polega na opracowaniu modelu, dzięki któremu wszystkie takie dane mogą być zapisane zgodnie ze zdefiniowanymi w nim założeniami. Spełnienie tej zasady ułatwi wykonywanie operacji na danych, które zostaną dzięki temu zapisane w jednolity sposób. Kluczowe zna-

2 380 Dariusz Put, Piotr Soja, Janusz Stal czenie ma tutaj sposób modelowania faktów oraz powiązań między nimi tak, aby z jednej strony rozwiązanie było wystarczająco ekspresyjne 1, z drugiej, umożliwiało sprawne manipulowanie faktami. Na przykładzie wybranych rozwiązań w artykule omówiono zagadnienia związane z modelowaniem konceptów w systemach integracji danych semistrukturalnych. Formalny zapis informacji o faktach W projekcie koncepcyjnym, tworzonym na najwyższym poziomie abstrakcji, niezależnie od modelu danych, na którym oparty jest system wykorzystywany do implementacji projektu, koncept nazywany jest encją. W klasycznych modelach danych, na podstawie których tworzone są projekty logiczne i fizyczne, występuje pod postacią klas obiektów (w modelu obiektowym), oraz relacji lub encji (w modelu relacyjnym). Oprócz określenia postaci samego konceptu, w modelach definiuje się powiązania, które mogą być w różnorodny sposób implementowane. Modele danych wysoce ekspresyjne, pozwalające na możliwie wierne odtworzenie modelowanej rzeczywistości muszą być bardziej skomplikowane i co za tym idzie trudniejsze w implementacji i utrzymaniu niż modele mniej ekspresyjne i posiadające dzięki temu prostszą strukturę. W systemach opartych na tradycyjnych modelach przechowywania danych (np. relacyjnym i obiektowym) w procesie projektowania tworzony jest schemat danych, a podczas eksploatacji zaimplementowango systemu dane są przechowywane w oparciu o ten schemat, który pozostaje niezmieniony. Tymczasem większość informacji przechowywanych w systemach komputerowych, a szczególnie w sieci Internet, nie jest oparta na uprzednio zdefiniowanym schemacie. Do tego typu informacji należą dane semistrukturalne, które dodatkowo charakteryzują się zmiennością struktury danych w czasie, oraz pliki zwarte, których zawartość nie jest przeszukiwana podczas wykonywania zapytań. Integracja informacji wymaga stworzenia mechanizmu, przy pomocy którego możliwy będzie dostęp do różnorodnej informacji w jednolity sposób. Istnieje szereg podejść do problemu integracji, zdefiniowano wiele strategii oraz stworzono szereg modeli danych dla zapisu danych semistrukturalnych 2. Jedną z istotnych własności takiego modelu jest sposób zapisu konceptów (relacji, klas) oraz powiązań między nimi. 1 Ekspresyjność modelu to zdolność do wiernego odtworzenia modelowanej dziedziny. 2 Por. m.in.: M. Castellanos, F. Saltor, M. Garcia-Solaco, A Canonical Model for Interoperability among Object-Oriented and Relational Databases. Distribiuted Object Management, Papers from the International Workshop on Distribiuted Management (IWDOM), Morgan Kaufmann, 1992, ; R. E. Giachetti, A Framework to Review the Information Integration of the Enterprise, International Journal of Production Research, Taylor & Francis Ltd., 2004; L. A. Kalinichenko, Canonical Model Development Techniques Aimed at Semantic Interoperability in the Heterogeneous World of Information Modeling, Proceedings of the CAiSE INTEROP Workshop on Knowledge and Model Driven Information Systems Engineering for Networked Organizations, Ryga, 2004; O. Volkoff, D. M. Strong, M. B. Elmes, Understanding Enterprise System- Enabled Integration, European Journal of Information Systems, 14, 2005

3 Reprezentacja obiektów oraz związków między obiektami (...) 381 Model XML DOM Model XML DOM (Document Object Model) ma strukturę hierarchiczną (drzewiastą). Elementami drzewa są węzły, z których każdy jest obiektem. Do opisu związków między węzłami-obiektami wykorzystywane są pojęcia rodzic, potomek, rodzeństwo. Rodzic danego obiektu, to węzeł znajdujący się w hierarchii bezpośrednio nad tym obiektem. Węzły znajdujące się na tym samym poziomie i mające tego samego rodzica stanowią zbiór rodzeństwa. Każdy składnik w modelu jest węzłem: cały dokument, wszystkie elementy a także atrybuty. Dostęp do węzłów odbywa się za pośrednictwem drzewa powiązań między nimi. Struktura hierarchiczna oznacza, że istnieje węzeł główny (root), każdy węzeł może mieć wielu potomków oraz ma dokładnie jednego rodzica (za wyjątkiem węzła głównego). W XML DOM zdefiniowano zbiór własności dla węzłów oraz funkcje umożliwiające zarządzanie strukturą pliku, w którym zapisana jest postać drzewa. Własności węzła zestawiono w tabeli 1. Tabela 1. Własności węzła w modelu XML DOM Własność węzła w w.nazwa w.wartość w.typ w.rodzic w.potomek w.atrybut Opis własności nazwa węzła w wartość węzła w (jeśli w jest elementem, wartość jest nieokreślona, jeśli w jest atrybutem, wartość jest wartością atrybutu) typ węzła w (typem może być element, atrybut, tekst, komentarz, dokument) nazwa rodzica węzła w węzeł potomka węzła w atrybut węzła w Źródło: opracowanie własne na podstawie Modele RDF i OWL W modelu RDF koncept nosi nazwę zasobu identyfikowanego przez URI. Strukturą służącą do przechowywania danych są także własności identyfikowane przez nazwę (np. autor, imię), posiadające wartości. Kombinacja zasobu, własności i wartości tworzy zdanie RDF postaci podmiot (występujący także pod nazwami: temat, przedmiot, zasób), predykat (właściwość, cecha), obiekt (przedmiot, wartość) (ang. subject predicate object). W RDF zasoby i związki między nimi można przedstawić w postaci grafu skierowanego, w którym rolę węzłów pełnią zasoby (identyfikowane przez URI) lub literały, krawędzie to własności lub związki między zasobami. Zarówno węzły, jak i krawędzie są opisywane przez etykiety. Taki graf jest więc zbiorem trójek RDF. W zakresie definiowania struktur, RDF oferuje możliwość tworzenia kolekcji lub kontenerów w postaci: nieuporządkowanych zbiorów (np. lista pracowników), uporządkowanych zbiorów (np. kolejne dni tygodnia),

4 382 Dariusz Put, Piotr Soja, Janusz Stal list alternatywnych, z których można wybrać dokładnie jeden spośród dostępnych elementów. Ponieważ RDF to model obiektowy, istnieje możliwość definiowania klas i podklas. RDF jest wykorzystywany m.in. do tworzenia metadanych opisujących informacje przechowywane w różnorodnych źródłach. Przykładem może tu być specyfikacja Dublin Core do opisu dokumentów tekstowych. Model OWL służy do opisu ontologii dla wybranej dziedziny. Ontologia tworzona za pomocą OWL to graf RDF będący zbiorem trójek (zdań) RDF. Zdefiniowano trzy wersje tego modelu: Lite, DL oraz Full. Każda kolejna stanowi rozszerzenie poprzedniej, dzięki czemu istnieje możliwość wyboru pomiędzy rozwiązaniami o różnej ekspresyjności. Najbardziej ekspresyjny OWL Full charakteryzuje się dowolnością składniową, ale bez gwarancji obliczeniowych, co oznacza, że stworzenie oprogramowania będącego w stanie wspierać kompletne rozumowanie logiczne dla wszystkich cech OWL Full jest niezwykle skomplikowane. OWL i RDF mają podobne przeznaczenie, ale OWL posiada większy zasób słownictwa oraz bardziej złożoną składnię, co umożliwia dokładniejsze odwzorowanie rzeczywistości. W OWL koncept jest definiowany w postaci klasy (jak w modelu obiektowym). Klasy mogą być zorganizowane w hierarchię poprzez definiowanie nadklas i podklas. Właściwości służą do tworzenia związków między obiektami, przy czym same właściwości także mogą być uporządkowane w hierarchię. W OWL można wykonywać szereg operacji porównujących klasy, np. ekwiwalentność oznacza, że klasy posiadają takie same elementy (cecha ta także może odnosić się do własności), można sprawdzić, czy dwie jednostki są identyczne, bądź, czy jedna jest różna od pozostałych. W ramach właściwości można definiować ograniczenia ze względu na klasę wskazując, że dana podklasa posiada wszystkie właściwości nadklasy lub tylko niektóre. Istnieje także możliwość określania minimalnej i maksymalnej liczby obiektów, które mogą być powiązane z klasą poprzez daną właściwość. Na przykład w systemie opisującym społeczeństwo monogamiczne obiekt klasy Mężczyzna może być powiązany maksymalnie z jednym obiektem klasy Kobieta poprzez właściwość mażonę. Model OEM W modelu OEM 3 (Object Exchange Model) przedmiotem wymiany są informacje będące obiektami lub pojedynczymi wartościami. Każda informacja posiada etykietę (tag), która opisuje jej znaczenie. Jeśli obiekt jest złożony, wszystkie jego składniki mają etykiety. W modelu OEM etykieta pełni dwie role: identyfikuje obiekt lub jego komponent oraz określa jego znaczenie. Ze względu na tę drugą własność etykiety powinny być czytelne (znaczące) dla użytkowników, gdyż w trakcie eksploatacji sys- 3 Y. Papakonstantinou, H. Garcia-Molina, J. Widom, Object Exchange across Heterogeneous Information Sources, Proceedings of the IEEE International Conference on Data Engineering, Taipei, Taiwan, 1995,

5 Reprezentacja obiektów oraz związków między obiektami (...) 383 temu są przez nich wykorzystywane do wyszukiwania informacji. Każdy obiekt ma strukturę czteroelementową: <e, t, w, oid>, gdzie e etykieta (nazwa obiektu), t typ wartości (typ może być atomowy lub zbiorowy), w wartość obiektu, oid unikalny identyfikator obiektu lub wartość Null. Gdy typ wartości (t) jest atomowy, obiekt taki nazywany jest obiektem atomowym, wtedy także jego wartość (w) jest niepodzielna. Jeśli typ jest złożony, obiekt nazywany jest złożonym, a wartość jest agregatem lub listą identyfikatorów obiektów. W modelu OEM istnieje możliwość definiowania związków typu rodzic-potomek. Model może być zobrazowany w postaci grafu, w którym węzły oznaczają obiekty lub wartości atomowe, a połączenia między węzłami reprezentują nazwy obiektów. Przykładowy graf pokazano na rysunku 1. Obrazuje on organizację składającą się z dwóch działów (ID1 i ID2). Każdy z działów ma nazwę (ID11, ID21), która jest typu tekstowego (ID111, ID211) i jest równa odpowiednio IT oraz księgowość, oraz po jednym zatrudnionym pracowniku (ID12 w dziale ID1 oraz ID22 w dziale ID2). Dział ID1 prowadzi projekt (ID13) o nazwie wnioskowanie. dział dział nazwa ID1 pracownik projekt pracownik ID2 nazwa ID11 ID12 ID13 ID22 ID21 text nazwisko adres nazwa text ID111 ID121 ID122 ID131 ID211 IT text text księgowość ID1211 ID1311 Kowalski wnioskowanie Rys. 1. Przykład grafu w modelu OEM Źródło: opracowanie własne

6 384 Dariusz Put, Piotr Soja, Janusz Stal Model CO Model danych CO (Content-Oriented) 4 składa się z elementów zwanych encjami. Encja stanowi wrapper dla danych znajdujących się w repozytoriach. Dane umieszczone w encji nazywane są zawartością (content). Oprócz zawartości, każda encja posiada typ oraz, opcjonalnie, referencję do innych encji (por rys. 2). Zawartość encji może być dowolna, mogą one przechowywać liczby, dokumenty tekstowe, pliki multimedialne, tablice obiektów, inne encje, lub dowolną inną informację. Encje nie muszą zawierać danych bezpośrednio, mogą przechowywać specjalne obiekty będące referencjami do zewnętrznych danych zmagazynowanych w bazach danych lub w witrynach internetowych. Takie encje stanowiące metadane mogą zawierać informacje wykorzystywane zarówno przez ludzi jak i maszyny. Oprócz opisu składni, zdefiniowano także architekturę modelu, zgodnie z którą posiada on budowę modułową. Wersja podstawowa charakteryzuje się ograniczoną funkcjonalnością, umożliwia wykonywanie jedynie podstawowych operacji na danych. Inne własności są implementowane w zewnętrznych modułach zwanych rozszerzeniami (extensions). Występowanie rozszerzeń umożliwia projektantom systemów wybór odpowiedniej konfiguracji w celu dopasowania własności systemu do aktualnych potrzeb. Ponieważ autorzy modelu położyli nacisk na prostotę, nie zdefiniowano w nim mechanizmów bezpośredniego wspomagania dla obsługi struktur danych. Istnieje jednak możliwość formowania kolekcji, które stanowią jedną z najbardziej powszechnych struktur oraz tzw. list poinformowanych (informed lists). W tego typu listach każdy element może być składnikiem wielu kolekcji oraz w każdym elemencie zapisana jest informacja, do których kolekcji należy. Encja reprezentująca kolekcję zawiera referencję do pierwszego elementu. Każdy kolejny element zawiera referencję do następnego obiektu w kolekcji. Element może być składnikiem wielu kolekcji. W elementach przechowywane są także informacje na temat tego, do których kolekcji należą. 4 T. Novotný, A Content-Oriented Data Model for Semistructured Data, DATESO, Desna, Czechy, 2007, 55 66

7 Reprezentacja obiektów oraz związków między obiektami (...) 385 typ 1 encja zawiera 0..n obiekt referencja encja Rys. 2. Model encji w CO Źródło: T. Novotný, A Content-Oriented Data Model for Semistructured Data, DATESO, Desna, Czechy, 2007, s. 60 Na rysunku 3 zobrazowano listę poinformowaną. Lista jest reprezentowana przez encję lista. Składa się z trzech elementów (element 1, element 2, element 3). Encja pierwszy zawiera referencję do pierwszego elementu listy. Encja null reprezentuje koniec listy. Wiele takich list poinformowanych może tworzyć wielopoziomową strukturę hierarchiczną, w której potomkowie znają swoich przodków. lista pierwszy element 1 element 2 element 3 null Rys. 3. Lista poinformowana w modelu CO Źródło: T. Novotný, A Content-Oriented Data Model for Semistructured Data, DATESO, Desna, Czechy, 2007, s. 61 Podstawowa wersja modelu CO charakteryzuje się dużą prostotą, jednak istnienie szeregu rozwiązań rozszerzających jego własności sprawia, że ich wykorzystanie umożliwia zwiększenie ekspresyjności systemu opartego na modelu CO.

8 386 Dariusz Put, Piotr Soja, Janusz Stal Model XWDM Model danych XWDM (XML-based Web Data Model) 5 oparty na technologii XML jest dedykowany łączeniu danych znajdujących się w witrynach internetowych. Podstawową strukturą danych w XWDM są elementy. Istnieją cztery rodzaje elementów, zależnie od opisywanych przez nie zawartości: doc-elem, base-elem, inside-elem i link-elem. Doc-elem reprezentuje stronę w sieci web. Base-elem, inside-elem i link-elem są sub-elementami elementu doc-elem. Inside-elem wskazuje, że wartość elementu zawiera sub-element oraz że ten element nie posiada odniesienia do innego elementu docelem. Jeśli atrybut elementu zawiera odniesienie do innego elementu doc-elem, ten element jest nazywany link-elem. Inside-elem i link-elem są elementami złożonymi. Base-elem nie zawiera innych elementów, tylko wartość atomową. Doc-elem może być opisany jako grupa składająca się z sześciu atrybutów: doc-elem (eid, name, alias, value, linklist, attributes), gdzie eid unikalny identyfikator elementu na stronie internetowej, name nazwa elementu, alias alternatywna nazwa elementu, co oznacza, że element może używać innej nazwy oprócz name. Alias może zawierać wiele nazw, co wskazuje, że w różnych miejscach mogą istnieć elementy (name), ale mające różne nazwy, value oznacza możliwą wartość elementu oraz typy danych, które mogą być nadane wartościom (typy mogą być tylko atomowe) lub inny sub-element, przy czym sub-elementem może być base-elem, inside-elem lub link-elem; dopuszczalne jest zagnieżdżanie sub-elementów, linklist zawiera wszystkie eid wskazujące na element (włączając jego subelement), attributes wartość atrybutu. Base-elem, inside-elem oraz link-elem są reprezentowane w postaci grup składających się z pięciu atrybutów: (eid, name, alias, value, attribute), gdzie wartość (value) może być w tym przypadku wyłącznie atomowa. W modelu XWDM używa się grafów skierowanych do opisu danych. Definicja grafu XWDM jest następująca: Graf G zawiera agregację węzłów V oraz agregację połączeń E: G(V, E). Jeśli e E, gdzie e jest jedną z krawędzi E, to istnieją dwa węzły i, j V, wtedy e=<i, j> oznacza, że e łączy węzeł i oraz j. Jeśli e to krawędź skierowana, wtedy (i, j) jest uporządkowaną dwójką węzłów oraz i jest węzłem źródłowym e i nosi nazwę source(e) a węzeł j jest docelowym i nosi nazwę target(e). Jeśli w E występuje więcej niż jedno połączenie skierowane, wtedy graf G jest grafem skierowanym. Model danych XWDM został zaproponowany głównie w celu rozwiązania problemów heterogeniczności danych oraz zapętlenia zapytań. Heterogeniczność danych rozumiana jest jako występowanie różnych nazw i opisów tego samego obiektu na 5 Y. Ma, Analysis on the Data Model of Web based on XML, International Journal of Computer and Information Science and Engineering, 1(3), 2007,

9 Reprezentacja obiektów oraz związków między obiektami (...) 387 poszczególnych stronach internetowych. Rozwiązania wymaga tu kwestia identyfikacji, czy informacja opisuje ten sam rzeczywisty obiekt, czy dwa różne. Zapętlenie zapytań (inquiries loop) to problem pojawiający się w przypadku skierowania zapytania do dwóch repozytoriów, gdy informacje pochodzące z jednego z nich są przesyłane do drugiego oraz, jednocześnie, w odwrotnym kierunku. Powoduje to powstanie ogromnej nadmiarowości informacji stanowiących wynik zapytania, szczególnie, jeśli problem dotyczy wielu repozytoriów. Modele integracji informacji personalnej Osobną klasę stanowią modele do zarządzania informacją personalną (PIM Personal Information Management). Modele takie są projektowane w celu stworzenia poszczególnym użytkownikom możliwości jednolitego dostępu do zasobów informacyjnych, przy czym każdy z nich jest traktowany oddzielnie i dysponuje własnym repozytorium informacji. Rozwiązania typu PIM wymagają zdefiniowania semantyki opisującej posiadane zasoby. Przykładem modelu typu PIM jest idm 6. W modelu idm każda informacja jest opisywana za pomocą tzw. logicznych encji. Informacja źródłowa może mieć dowolną formę, m.in.: mogą ją stanowić pliki, elementy strukturalne wewnątrz plików, krotki, strumienie danych, elementy dokumentów XML. Logiczne encje są ze sobą połączone w strukturę grafu i w ten sposób reprezentują całą przestrzeń danych. W modelu danych idm wykorzystywane są następujące założenia: wszystkie informacje są dostępne za pośrednictwem tzw. zbioru widoków zasobów (resource view), które stanowią element pośredniczący między informacjami a aplikacjami korzystającymi z tych informacji. Każdy plik lub folder oraz dane przechowywane wewnątrz plików są reprezentowane w postaci widoków. Widok zasobów to sekwencja komponentów, która umożliwia reprezentację danych strukturalnych, semi-strukturalnych oraz niestrukturalnych. Dzięki widokom różnorodne dane są udostępnione w idm w sposób jednolity, widoki zasobów są połączone w struktury grafowe. Połączenia między jednym widokiem a drugim są wykonywane za pośrednictwem należących do nich komponentów, w odróżnieniu od podejść opartych na XML, w idm nie występuje potrzeba konwersji danych do formatu XML przed wykonaniem zapytania. W modelu występuje wyraźne oddzielenie logicznej i fizycznej reprezentacji danych. Dane mogą być dynamicznie konwertowane podczas przetwarzania zapytania, w modelu występują klasy widoków zasobów (resource view classes), które przechowują informacje o typach oraz sposobie reprezentacji komponentów tworzących widoki zasobów, widoki zasobów mogą być predefiniowane lub tworzone dynamicznie (np. jako wynik wykonania kwerendy). 6 J.-P. Dittrich, M. Salles, idm: A Unified and Versatile Data Model for Personal Dataspace Management, 32 VLDB Conference, Seul, Korea, 2006

10 388 Dariusz Put, Piotr Soja, Janusz Stal Każdy widok zasobu to czteroelementowa krotka <n i, t i, x i, y i >, gdzie: n i nazwa komponentu (w postaci łańcucha znaków), t i krotka komponentu składająca się z dwóch atrybutów: W (schemat) oraz T (pojedyncza krotka zgodna z W). Schemat W =<a j >, gdzie j=1,2,3,..., jest sekwencją atrybutów (a j ) reprezentujących rolę pełnioną przez jakąś dziedzinę D j w schemacie W. Krotka T=<v j >, dla j=1,2,..., jest sekwencją atomowych wartości, gdzie wartość v j jest elementem D j atrybutu a j. x i zawartość komponentu, y i grupa komponentu, jest to dwuelementowa krotka składająca się z S (zbioru widoków zasobów) i Q (uporządkowanej sekwencji widoków zasobów). Nazwa komponentu n i jest wykorzystywana w charakterze referencji do widoku zasobu. Grupa y i jest wykorzystywana do tworzenia grafów skierowanych, które łączą związane ze sobą widoki. Komponenty widoku zasobów są tworzone dynamicznie, nie są predefiniowane, dzięki temu struktura grafowa może ulegać zmianom w trakcie eksploatacji systemu. Istnieją rozwiązania PIM, które nie są oparte na własnym, dedykowanym modelu opisu informacji, lecz wykorzystują istniejące modele. Przykładem może tu być system ontopim 7. OntoPim to rozwiązanie oparte na wykorzystaniu personalnej ontologii zawierającej dziedzinę zainteresowań użytkownika, zawierającej opis interesujących go obiektów, klas i relacji. Ontologia jest personalna w tym sensie, że opisuje daną dziedzinę z punktu widzenia konkretnego użytkownika. Jest używana do reprezentacji semantyki informacji znajdującej się w zasobach użytkownika oraz do formułowania i wykonywania zapytań do systemu w celu uzyskania poszukiwanych informacji. Stworzony mechanizm umożliwia użytkownikom zapisanie dowolnego obiektu na podstawie jego semantyki, zapisania relacji tego obiektu z konceptami znajdującymi się w personalnej ontologii, przy czym obiekt może być dokumentem, em, zdjęciem lub mieć dowolny inny format. Użytkownik ma możliwość skierowania zapytania do personalnej ontologii, system wykonuje zapytanie, wybiera informacje odpowiadające zapytaniu, oraz formatuje je do finalnej postaci. OntoPIM to moduł umożliwiający zarządzanie heterogenicznymi informacjami personalnymi przechowywanymi w zasobach własnego komputera (kontakty, dokumenty, e) oraz dostęp do nich poprzez jednolity, zintegrowany, wirtualny oraz dopasowany do użytkownika widok. Ten widok nosi nazwę Personal Ontology (PO). Do specyfikacji PO wykorzystano język Description Logic o nazwie DL-Lite, gdyż oprócz tego, że umożliwia on wyrażenie najczęściej używanych konstrukcji, pozwala także na tworzenie złożonych zapytań. W opisie obiektów używa się pojęcia konceptów, instancji oraz atrybutów. 7 V. Katifori, A. Poggi, M. Scannapieco, T. Catarci, Y. Ioannidis, OntoPIM: How to Rely on a Personal Ontology for Personal Information Management, Proceedings of the First Workshop on the Semantic Desktop, International Semantic Web Conference, Galway, Irlandia, 2005

11 Reprezentacja obiektów oraz związków między obiektami (...) 389 Zakończenie Wieloaspektowa heterogeniczność i rozproszenie informacji przechowywanych w systemach komputerowych i związane z tym problemy wyszukiwania informacji zrodziły potrzebę opracowania rozwiązań integracyjnych, dzięki którym dane znajdujące się w wielu źródłach mogą być łączone i dostarczane użytkownikom w odpowiedzi na sformułowane przez nich zapytania w jednolitej, zwartej postaci, ukrywając przed nimi wszechobecną różnorodność. Zaproponowano dotychczas szereg modeli integracyjnych. Jednak, jak starano się pokazać na przykładzie wybranych rozwiązań, trudno mówić o istnieniu standardu w tym zakresie. Koncepty postrzegane są w różnorodny sposób, jako encje, zasoby, klasy. Mogą one być powiązane w różnorodne struktury danych, kolekcje, listy, grafy, przy czym sposób tworzenia tych powiązań jest różny w poszczególnych modelach. Można zauważyć, że w większości przypadków podstawową strukturą opisu informacji jest graf skierowany generowany dynamicznie w trakcie eksploatacji systemu. Proponowane rozwiązania są dedykowane zarówno danym semistrukturalnym jak również służą do łączenia informacji zapisanej w klasycznych modelach opartych na predefiniowanym schemacie oraz plików zwartych opisanych przez metadane. Wszystko to powoduje, że powstaje potrzeba tworzenia rozwiązań integracyjnych nad warstwą integracji tak, aby informacje postrzegane były przez użytkowników i agentów informacyjnych w sposób jednolity. Powszechna zgoda co do tego, że technologia XML jest standardem w wymianie informacji ułatwia integrację, jednak istnienie wielu modeli, które mogą być wykorzystywane w charakterze rozwiązań integracyjnych, utrudnia powstanie jednolitych systemów. Podejmując przedsięwzięcie integracyjne należy zdawać sobie sprawę z istnienia wielu rozwiązań w tym zakresie. Wybierając model danych dla projektowanego rozwiązania integracyjnego należy kierować się kilkoma zasadami: zdefiniować przeznaczenie systemu integracyjnego (dla szerokiego grona użytkowników, system integracji informacji personalnej, integracja poprzez witryny internetowe), wybrać model oparty na XML, co w przyszłości ułatwi integrację z innymi rozwiązaniami tego typu, dokonać identyfikacji informacji będącej przedmiotem integracji i wybrać model na tyle ekspresyjny, aby informacje te mogły zostać zapisane, lecz nie zanadto ekspresyjny, gdyż to utrudni implementację, utrzymanie systemu oraz formułowanie zapytań, zdefiniować mechanizm formułowania zapytań dla użytkownika, który powinien być łatwy w obsłudze i wspomagać użytkowników w procesie tworzenia zapytań, uwzględnić wspomaganie dla agentów informacyjnych, które automatyzują proces wyszukiwania informacji, przeanalizować możliwość łatwej modyfikacji rozwiązania opartego na wybranym modelu, gdy pojawi się nowa informacja lub zmianie ulegnie istniejąca. Bibliografia 1. Castellanos M., Saltor F., Garcia-Solaco M., A Canonical Model for Interoperability among Object-Oriented and Relational Databases. Distribiuted Object Man-

12 390 Dariusz Put, Piotr Soja, Janusz Stal agement, Papers from the International Workshop on Distribiuted Management (IWDOM), Morgan Kaufmann, Dittrich J.-P., Salles M., idm: A Unified and Versatile Data Model for Personal Dataspace Management, 32nd VLDB Conference, Seul, Korea, Giachetti R. E., A Framework to Review the Information Integration of the Enterprise, International Journal of Production Research, Taylor & Francis Ltd., Kalinichenko L. A., Canonical Model Development Techniques Aimed at Semantic Interoperability in the Heterogeneous World of Information Modeling, Proceedings of the CAiSE INTEROP Workshop on Knowledge and Model Driven Information Systems Engineering for Networked Organizations, Riga, Katifori V., Poggi A., Scannapieco M., Catarci T., Ioannidis Y., OntoPIM: How to Rely on a Personal Ontology for Personal Information Management, Proceedings of the First Workshop on the Semantic Desktop, International Semantic Web Conference, Galway, Irlandia, Ma Y., Analysis on the Data Model of Web based on XML, International Journal of Computer and Information Science and Engineering, 1(3), Novotný T., A Content-Oriented Data Model for Semistructured Data, DATESO, Desna, Czechy, Papakonstantinou Y., Garcia-Molina H., Widom J., Object Exchange across Heterogeneous Information Sources, [w:] Proceedings of the IEEE International Conference on Data Engineering, Taipei, Taiwan, Volkoff O., Strong D. M., Elmes M. B., Understanding Enterprise System-Enabled Integration, European Journal of Information Systems, 14, 2005 Representation of entities and relations between entities in semistructural models Information integration has been a subject researched by a considerable number of academic papers. Prior research proposes many definitions and various integration strategies. Irrespectively of proposed solutions, the method of facts (objects and events) representation as well as relations between them seem to be an essential issue. In general, the more expressive a data model is, the better a domain is designed. However, if data repository becomes very complex it leads to difficulties in both query formulation and maintaining such a system during operation. This study reviews some solutions concerning modeling of concepts (entities, classes) and relations between them in selected semistructural data models designed for integration of heterogeneous information. On the basis of performed analysis, a number of suggestions related to the choice of data integration model for both description and management of organizational information are put forward.