pdf(paper) - MEAG-WWW - Politechnika Warszawska

pdf(paper) - MEAG-WWW - Politechnika Warszawska

Rys. 3 pokazuje wybrane możliwości narzędzia ODA Web Wizard. Wybrano kilka stron Webowych narzędzia, pokazujących
najbardziej typowe zastosowania.
***
W artykule przedstawiono cele i założenia projektu SIMS, ze
szczególnym uwzględnieniem zadań, w których uczestniczy Instytut Telekomunikacji PW. Zostały omówione „namacalne” wyniki projektu SIMS osiągnięte w ramach prac. Są to m. in. metody reprezentacji usług za pomocą ontologii, ontologia usług telekomunikacyjnych, narzędzie dla fazy tworzenia usługi (Artefact Wizard) oraz
narzędzia dla fazy działania usługi (ODA Web Wizard).
Dodatkowo zespół zdobył cenne doświadczenie, badaniach
nad technikami ontologicznymi (szczególnie nad kontekstem
usług telekomunikacyjnych), jak również w pracy w stosunkowo
dużych, międzynarodowych projektach badawczych.
Osiągnięte wyniki badawcze będą rozwijane w kolejnych projektach10). Narzędzia i powstała ontologia będą wykorzystywane w celach naukowych (m. in. prawdopodobnie zastosowanie narzędzi
w pracach eksperymentalnych doktorantów ITPW), jak i dydaktycznych (powstanie kilku prac inżynierskich i magisterskich dotyczących tematyki i zagadnień rozwijanych w projekcie SIMS).
W najbliższym czasie (jest to ostatnia faza projektu SIMS) jest
planowane stworzenie aplikacji zbudowanych na podstawie metodologii, techniki i narzędzi SIMS i testowe uruchomienie ich,
w które będzie zaangażowan ITPW. Oczekuje się, że wyniki eks-
10)
Jednym z nich jest projekt europejski POBICOS (http: //ict-pobicos.
eu/), gdzie planuje się wykorzystanie technik ontologicznych pokrewnych wykorzystanym w projekcie SIMS do reprezentacji różnych zasobów w sieciach heterogenicznych. Dodatkowo planuje się przeprowadzenie adaptacji narzędzia Artefact Wizard do edycji artefaktów
w systemie POBICOS oraz wstępnej walidacji/wyszukiwania artefaktów
ontologicznych.
perymentalne posłużą walidacji podejścia i umożliwią zebranie
bogatych doświadczeń dotyczących potencjału i możliwości wyników projektu. Posłużą też do ilustracji i weryfikacji tez naukowych, które planuje się wkrótce opublikować.
LITERATURA
[1] Domaszewicz J., et al.: ROVERS: Pervasive Computing Platform for
Heterogeneous Sensor-Actuator Networks. In 4th International Workshop on Mobile Distributed Computing (MDC'06). 2006. Niagara-Falls/Buffalo, NY, USA
[2] Domaszewicz J., Rój M., and Pruszkowski A.: Opportunistic Pervasive Computing with Domain-Oriented Virtual Machines. Proceedings
of the 9th EUROMICRO Conference on Digital System Design. 2006:
IEEE Computer Society
[3] Domaszewicz J. and Rój M.: Lightweight Ontology-driven Representations in Pervasive Computing. iIn IFIP International Symposium on
Network Centric Ubiquitous Systems (NCUS 2005). 2005. Nagasaki, Japan: Springer-Verlag
[4] Rój, M., et al.: Ontology-based Use Cases for Design-time and Runtime Composition of Mobile Services. In International Workshop on
the Role of Services, Ontologies, and Context in Mobile Environments (RoSOC-M '08). 2008. Bejing, China
[5] Sanders R.: Collaborations, Semantic Interfaces and Service Goals:
a way forward for Service Engineering. In Faculty of Information Technology, Mathematics and Electrical Engineering, Department of Telematics. 2007, Norwegian University of Science and Technology
(NTNU): Trondheim
[6] Sanders R. T. et al.: Service Discovery and Component Reuse with
Semantic Interfaces. In Proc. of the 12th Int. SDL Forum. 2005. Grimstad, Norway: Springer
[7] Dawidziuk R.: Semantic Service Explorer: Klient semantycznych usług
sieciowych. In Instytut Telekomunikacji. 2008, Politechnika Warszawska (Warsaw University of Technology): Warszawa
[8] Horridge M. et al.: The Manchester OWL Syntax. In OWL Experiences and Directions Workshop (OWLED'06) at the ISWC'06. 2006.
Athens, Georgia, USA
Artykuł recenzowany
Michał KOZIUK*, Jarosław DOMASZEWICZ*,
Radosław Olgierd SCHOENEICH*, Krzysztof KACPERSKI*
Wykorzystanie ontologii na potrzeby
kontekstowych aplikacji mobilnych
1)
Ten artykuł prezentuje architekturę systemu umożliwiającego
wykorzystanie ontologii na urządzeniach mobilnych opracowaną
w ramach projektu 6FP STREP MIDAS (ang. Middleware Platform
for Developing Advanced Mobile Services). Architektura umożliwia wykorzystanie ontologii jako modelu domeny oraz reprezentację informacji przechowywanych w systemie zgodnie z zawartą w tej ontologii semantyką. Zaproponowana reprezentacja
umożliwia przeprowadzenie wnioskowania w oparciu o posiadane dane. W projekcie MIDAS założono, że całość przetwarzania
ontologii zachodzi na urządzeniu mobilnym, bez konieczność korzystania z usług dedykowanego serwera, co umożliwia zastosowanie proponowanego rozwiązania w sieciach bezprzewodowych o ograniczonym dostępie do infrastruktury.
* Instytut Telekomunikacji, Politechnika Warszawska,
e-mail: [email protected], [email protected]
1)
Praca współfinansowana w ramach projektu 6FP STREP - IST MIDAS,
numer kontraktu: 027055
PRZEGLĄD TELEKOMUNIKACYJNY z ROCZNIK LXXXI z nr 8–9/2008
Współczesne aplikacje mobilne mają na celu uzyskanie maksymalnej prostoty użytkowania. Jedną z możliwości uzyskania
niezwykle prostego interfejsu użytkownika jest stworzenie systemu świadomego kontekstu (context aware) użytkownika. Znając
ten kontekst, aplikację można dostosować do niego w celu uzyskania jak najlepszej wydajności lub aby uprościć wyświetlany interfejs. Dla przykładu aplikacja, mająca informacje o planie zajęć,
lokalizacji i preferencjach użytkownika oraz o porze dnia, może
udostępnić na pierwszym miejscu funkcje, których wykorzystanie
jest najbardziej prawdopodobne – dla kogoś, kto codziennie wieczorem ogląda w domu telewizję taką funkcją jest plan jego ulubionych kanałów telewizyjnych.
Jednym z zagadnień leżących u podstaw aplikacji kontekstowych, jest definicja kontekstu. W literaturze pojawiło się dotychczas wiele takich definicji, które zasadniczo nie różniły się zbyt,
nio od siebie. Przyjeto definicję według A. Dey a i G. Abowda [1]:
Kontekst to dowolna informacja, która może zostać wykorzystana, aby opisać sytuację jednostki. Jednostką może być osoba,
miejsce lub obiekt uważany za istotny dla interakcji pomiędzy użytkownikiem a aplikacją (w tym również sam użytkownik oraz sama
aplikacja).
957
Aby umożliwić aplikacjom korzystanie z informacji kontekstowych, jest konieczna warstwa pośrednia (middleware) odpowiedzialna za wykonywanie następujących funkcji:
z modelowanie i reprezentacja kontekstu,
z wnioskowanie,
z synteza kontekstu,
z pozyskiwanie informacji kontekstowych.
Elementem składowym architektury warstwy pośredniej MIDAS
[2] jest system zarządzający kontekstem spełniający przedstawione powyżej wymagania. W ramach niniejszej publikacji omówiono stworzony przez nas komponent wchodzący w skład projektu MIDAS, udostępniający na potrzeby pozostałych komponentów systemu funkcje a i b. Komponent ten to tzw. kontekstowa
baza wiedzy (Context Knowledge Base).
Funkcja c została zaimplementowana przez współpracującą z nami szwedzką firmę Appear Networks, natomiast funkcja d została
zdefiniowana jako zbiór aplikacji współpracujących z warstwą pośrednią MIDAS w celu dostarczania informacji kontekstowych.
WYKORZYSTANIE ONTOLOGII
W SYSTEMIE MIDAS
Modelowanie kontekstu
W rozwiązaniu przyjętym przez projekt MIDAS modelem kontekstu jest ontologia. Zawarte w ontologii pojęcia (głównie klasy
i relacje) tworzą semantyczną strukturę, opisującą pewien wybrany fragment świata (dziedzinę). Zawartość ontologii zależy od
dziedziny zastosowania platformy MIDAS2) . Dla przykładu w sytuacji, gdy dziedziną zastosowania są sytuacje kryzysowe, ontologia powinna między innymi odzwierciedlać proces zarządzania
sytuacjami kryzysowymi. Fragment ontologii, przedstawiony na
rys. 1, jest skupiony wokół klasy Incident. Każdej instancji tej kla-
„ Rys. 1. Fragment modelu kontekstu w formie ontologii (relacje)
sy, czyli każdemu wydarzeniu kryzysowemu, można przypisać takie dane, jak: czas, typ i status zdarzenia lub dodatkowe informacje. W tym celu należy wykorzystać relacje przypisujące dane
konkretnych typów do klas (tzw. datatype property), jak np. incidentType. Dodatkowo w przedstawionej ontologii występują relacje pomiędzy instancjami dwóch klas (tzw. object property),
dzięki którym można np. wyrazić powiązania między sytuacją kryzysową a liniami metra, których ona dotyczy (relacja relates_To_Line), lub określić procedurę wykorzystywaną przy obsłudze konkretnego zdarzenia (relacja hasProcedure).
2)
Zgodnie z założeniami projektu platforma MIDAS jest przeznaczona
do zastosowania przy obsłudze wydarzeń o krótkim okresie trwania i
dużej liczbie użytkowników takich jak sytuacje kryzysowe lub
wydarzenia sportowe
958
„ Rys. 2. Fragment modelu kontekstu w formie ontologii (hierarchia
klas)
Wszystkie klasy występujące w ontologii są ułożone w hierarchię klas (rys. 2). Przykładowo wszystkie instancje należące do
klasy Manager są również instancjami klasy Metro_Staff, ponieważ klasa Manager jest podklasą klasy Metro_Staff (co stanowi
najprostszy przykład wnioskowania na podstawie ontologii). Analogicznie w modelu kontekstu może występować również hierarchia relacji.
Logika deskryptywna DL-Lite
Standardowe ontologie wyrażone w języku OWL-DL[3] (lub
OWL-Lite) wymagają zaawansowanych narzędzi, wnioskujących
ze względu na liczbę dostępnych konstrukcji. Dostępne narzędzia
(takie jak np. Pellet [4]), są tworzone dla komputerów stacjonarnych i ze względu na ich duże wymagania (pamięć operacyjna
i moc obliczeniowa) nie można ich zastosować w urządzeniach
mobilnych. Czas potrzebny do wykonania przez oprogramowanie Pellet wnioskowania na komputerze stacjonarnym to wartości rzędu 1s, co praktycznie oznacza brak możliwości wykorzystania go w urządzeniach mobilnych.
W celu umożliwienia wnioskowania w urządzeniach mobilnych
jest konieczne wykorzystanie logiki prostszej niż OWL-DL, która
oferuje dobre proporcje pomiędzy złożonością ontologii a prędkością wnioskowania. W projekcie MIDAS postanowiono wykorzystać logikę DL-Lite [5][6], która stanowi podzbiór logiki OWLDL dobrany tak, aby było możliwe mapowanie ontologii na
struktury relacyjnej bazy danych. Dzięki temu wnioskowanie może wykorzystać gotowe bazodanowe algorytmy przeszukiwania
danych, co w rezultacie daje prosty i efektywny system.
Logika DL-Lite umożliwia korzystanie z klas, relacji oraz instancji. Klasy mogą być łączone w hierarchię; można również zdefiniować rozłączność klas. W analogiczny sposób można też definiować relacje, które dodatkowo można również oznaczyć jako
funkcjonalne3) lub odwrotnie funkcjonalne. W celu wyrażenia zależności między klasami a relacjami można wykorzystać następujące elementy logiki DL:
z definiowanie dziedziny i przeciwdziedziny relacji; w ten sposób
można określić, jakie klasy mogą zawierać się w dziedzinie/przeciwdziedzinie danej relacji,
z definiowanie restrykcji dla klas; w ten sposób można zdefiniować ograniczenie na instancje danej klasy, które określi, jakie relacje muszą być zdefiniowane dla tych instancji.
3)
Relacje będące funkcjami
PRZEGLĄD TELEKOMUNIKACYJNY z ROCZNIK LXXXI
z
nr 8–9/2008
Za pomocą opisanych powyżej elementów logiki DL-Lite można zbudować ontologię służącą jako model kontekstu dla projektu MIDAS. Za pomocą hierarchii klas można zdefiniować oraz
uporządkować typy obiektów występujących w modelowanej
dziedzinie, jak np. role użytkowników systemu lub typy miejsc,
w których użytkownicy ci mogą się znaleźć. Kolejnym etapem
modelowania dziedziny będzie wyrażenie zależności pomiędzy
obiektami poszczególnych klas obiektów w formie relacji Object
properties. Dodatkowo każdemu obiektowi można przypisać zestaw charakteryzujących go atrybutów, definiując klasę tych
obiektów jako domenę relacji Datatype property (atrybuty wymagane definiuje się przez dodatkowe dodanie restrykcji dla wybranej klasy).
Reprezentacja kontekstu
Reprezentacja kontekstu w projekcie MIDAS składa się
z dwóch części: modelu kontekstu i danych o kontekście. Dane o kontekście są reprezentowane za pomocą instancji logiki
DL-Lite. Każdy obiekt ze świata rzeczywistego może zostać
przedstawiony jako instancja, która należy do dowolnej liczby
nierozłącznych klas i ma przypisaną dowolną liczbę wartości dla
dowolnej liczby relacji. Zależności pomiędzy dowolnymi dwoma obiektami są reprezentowane przez relacje między dwoma
instancjami, które mogą być dodawane/usuwane w trakcie działania systemu (podobnie jak instancje). W ten sposób system
MIDAS zyskuje dostęp do dynamicznie zmieniającej się bazy
wiedzy, której stałym elementem jest model danych (tak zwany
TBox), a zbiór instancji klas oraz relacji (ABox) zmienia się wraz
ze zmianą kontekstu węzła.
Zgodnie z założeniami logiki DL-Lite dane o kontekście są przechowywane w relacyjnej bazie danych. W DL-Lite schemat tablic
bazy danych jest generowany z części TBox ontologii, czyli z modelu kontekstu, w następujący sposób:
z dla każdej klasy jest tworzona tabela o nazwie identycznej z nazwą tej klasy, mająca jedną kolumnę zawierającą identyfikatory
instancji należących do danej klasy,
z dla każdej relacji jest tworzona tabela o nazwie identycznej
z nazwą relacji klasy, mająca dwie kolumny; pierwsza z kolumn
zawiera identyfikator instancji znajdującej się w dziedzinie relacji;
druga zawiera identyfikator instancji, będącej wartością tej relacji (dla Object properties) lub po prostu wartość (Integer, Float,
String lub Boolean) tej relacji (dla Datatype properties).
Opisana powyżej struktura bazy danych została zaprojektowana tak, aby umożliwić wyszukiwanie w niej zbiorów instancji
o określonych parametrach (co jest celem algorytmu wnioskującego logiki DL-Lite). Wykorzystanie wielu niewielkich tabelek wynika z przyjętego przez twórców DL-Lite założenia dotyczącego
zapewnienia wsparcia dla bardzo dużej liczby instancji. Ponieważ
w projekcie MIDAS wymagania dla funkcjonalności kontekstowej
bazy wiedzy są nieco większe niż zapewniane przez standardowe mechanizmy DL-Lite (np. niezbędna jest funkcjonalność wyszukiwania wszystkich klas, do których należy wybrana instancja)
oraz liczba instancji nie powinna być zbyt duża, w projekcie
MIDAS ta struktura bazy danych została zmieniona w następujący sposób4) :
z istnieje jedna tabela służąca do przechowywania listy wszystkich istniejących instancji, która posiada jedną kolumnę zawierającą identyfikatory instancji,
z istnieje jedna tabela służąca do przypisywania klas do instan-
4)
Przedstawiona struktura bazy danych jest niepełna. W rzeczywistej
implementacji w ramach projektu, ze względu na dodatkowe
wymagania innych komponentów warstwy pośredniej, są jeszcze
wykorzystywane dodatkowe tabele bazy danych. Ze względu na brak
powiązań z zagadnieniami przedstawianymi w tym artykule, nie zostały
one omówione
PRZEGLĄD TELEKOMUNIKACYJNY z ROCZNIK LXXXI z nr 8–9/2008
cji, która ma jedną kolumnę zawierającą identyfikatory instancji,
i drugą z nazwą klasy,
z istnieje jedna tabela służąca do przypisywania wartości relacji
do instancji, która ma jedną kolumnę zawierającą identyfikatory
instancji, drugą z nazwą relacji, a trzecią z wartością tej relacji.
Wnioskowanie
Logika DL-Lite udostępnia mechanizm wnioskujący, który
umożliwia wyszukiwanie instancji spełniających określone kryteria. Kryterium wyszukiwania ma formę wyrażenia logicznego tak
zwanego conjunctive query, które jest iloczynem logicznym prostych elementów składowych (atomów), takich jak na przykład
stwierdzenia, że instancje muszą należeć do wybranej klasy.
Szczegółowy opis mechanizmu conjunctive query można znaleźć
w [4]. Zgodnie z założeniami logiki DL-Lite proces wnioskowania
przebiega następująco.
z Dla każdego kolejnego atomu zawartego w wyrażeniu conjunctive query, na podstawie części TBox, ontologii, będącej modelem dziedziny, są znajdywane wszystkie alternatywne atomy, którymi można zastąpić dany atom. W ten sposób powstają
dodatkowe (równoważne) wyrażenia conjunctive query. Proces
powtarzany jest aż do uzyskania wszelkich możliwych wyrażeń.
Przykładowo, jeżeli ontologia zawiera a klasę Człowiek, która
ma dwie podklasy: Kobieta i Mężczyzna, wyrażenie conjunctive
query w postaci: Człowiek (x) powinno zwrócić wszystkie instancje reprezentujące ludzi. Przez wnioskowanie zostaną wygenerowane dodatkowe dwa wyrażenia: Kobieta (x) oraz Mężczyzna (x).
z Dla każdego z wyrażeń conjunctive query wytworzonych w ramach procesu wnioskowania jest wykonywane odpowiednie zapytanie na relacyjnej bazie danych (zawierającej dane o kontekście,
czyli informacje o wszystkich istniejących instancjach), które zwraca listę wszystkich instancji odpowiadających danemu zapytaniu.
Przykładowo, dla każdego z trzech wygenerowanych wyrażeń
conjunctive query są wykonywane następujące zapytania do bazy danych:
Conjunctive
query
Człowiek (x)
Kobieta (x)
Mężczyzna (x)
Zapytanie SQL
SELECT instanceID FROM Człowiek
SELECT instanceID FROM Kobieta
SELECT instanceID FROM Mężczyzna
Przykładowy
wynik
x1, x2, x3
y1,
z1, z2
z Wynikiem wnioskowania jest suma zbiorów instancji uzyskanych poprzez wykonywanie zapytań do bazy danych dla każdego wygenerowanego przez wnioskowanie wyrażenia conjunctive
query.
Dla wybranego przykładu wynikiem wnioskowania wykonanego dla wyrażenia Człowiek (x) będzie zbiór sześciu instancji: x1,
x2, x3, y1, z1, z2.
Implementacja tego algorytmu w ramach projektu MIDAS została zastosowana w celu sprawdzenia, czy jedna wybrana instancja pasuje do wyrażenia conjunctive query. W związku z tym opisany powyżej algorytm został zmodyfikowany w celu poprawy
wydajności przetwarzania wyrażeń conjunctive query:
z zapytania do bazy danych zostały zmodyfikowane przez dodanie warunku:
WHERE instanceID = wybranaInstancja
z zapytania do bazy danych są wykonywane jedynie do momentu, gdy dla dowolnego conjunctive query zostanie uzyskany wynik pozytywny (ponieważ oznacza to, że wybrana instancja odpowiada sprawdzanemu wyrażeniu).
959
ARCHITEKTURA SYSTEMU
Plik zawierający ontologię jest dołączany do platformy MIDAS,
gdzie zostaje odczytany przez komponent CKB (kontekstową bazę wiedzy) podczas uruchamiania warstwy pośredniej. Dzięki temu oprogramowanie warstwy pośredniej jest niezależne od dziedziny i ten sam kod może zostać użyty dla wielu różnych dziedzin.
Wystarczy jedynie wymienić ontologię, aby móc uruchomić aplikacje kontekstowe przeznaczone dla innej dziedziny.
Ontologia jest zapisywana w formacie Manchester OWL Syntax [7], który jest wczytywany za pomocą parsera wygenerowanego przez narzędzie JavaCC [8]. Informacje odczytane z pliku
ontologii są następnie umieszczane w bibliotece LOnt, wykorzystywanej przez komponent CKB do przechowywania struktury
ontologii. Zarówno biblioteka Lont, jak i zastosowanie składni
Manchester OWL Syntax, zostało wykonane w ramach pracy magisterskiej [9] na potrzeby projektu MIDAS.
Komponent CKB (podobnie jak większość warstwy pośredniej
MIDAS) napisano w języku Java, wykorzystując biblioteki zgodne z Java 1.4.2. Do celów testowych wykorzystano bazę danych HSQL [10].
WYNIKI TESTÓW
Implementacja komponentu CKB została przetestowana na
urządzeniu Nokia N800 [11] (procesor 330 MHz, pamięć RAM 128
MB). Testowano trzy istotne parametry wydajności wykonanego
oprogramowania: opóźnienia przy dostępie do modelu kontekstu (czyli do części TBox ontologii), opóźnienia przy dostępie (zapis, odczyt, usunięcie) do danych o kontekście (czyli do części
ABox ontologii) oraz opóźnienia przy wnioskowaniu.
W ramach testów każda badana metoda była wywoływana
N=100 razy i był mierzony czas dla N wykonań. Uzyskana wartość czasu wykonywania metody jest średnią wyliczoną ze zmierzonej wartości, dzięki czemu unika się wpływu czynników losowych (działania pozostałych procesów systemu operacyjnego) na
wartości pomiarów.
Dostęp do informacji o modelu kontekstu (bez wykorzystania
wnioskowania) to czasy rzędu 0–2 ms, w zależności od złożoności modelu (np. zapytanie o podklasy trwa tym dłużej, im więcej
jest tych podklas). Zapis oraz usuwanie danych o kontekście (czyli takie operacje, jak: stworzenie nowej instancji, dodanie wartości relacji lub ustawienie wartości relacji) zajmuje czas rzędu
10–20 ms, natomiast odczyt danych (pojedynczej wartości) zajmuje około 4–6 ms. Oznacza to, że nawet na urządzeniu mobilnym jest możliwe wprowadzanie stosunkowo dużej liczby informacji do systemu, a ich odczytywanie wprowadza minimalne
opóźnienia.
Widoczna jest znaczna różnica pomiędzy metodami, które wymagają dostępu do bazy danych (modyfikacja informacji kontekstowych) a tymi szybszymi, które korzystają jedynie z modelu
przechowywanego w bibliotece Lont (dostęp do modelu kontekstu). Badania nad wydajnością komponentu CKB pokazały, że
głównym czynnikiem wpływającym na wydajność metod związanych z modyfikacją kontekstu jest wydajność bazy danych –
w przypadku wykorzystania bazy danych H2 (zamiast HSQL) wydajność komponentu była znacząco niższa.
Wydajność wnioskowania zależy bezpośrednio od wydajności zarówno dostępu do informacji o strukturze ontologii, jak i od wydajności dostępu do informacji kontekstowych. Dodatkowo czas wnioskowania zależy od stopnia złożoności wyrażenia conjunctive query.
Zmierzony czas wykonania najprostszego conjunctive query (które
złożone jest z jednego atomu składowego i nie generuje dodatkowych wyrażeń w trakcie wnioskowania) wyniósł ok. 25 ms, natomiast
dla sześciu atomów wzrósł do 150 ms. W przypadku gdy liczba dodatkowych zapytań wygenerowanych w ramach wnioskowania rośnie, czas wnioskowania wzrasta od ok. 35 ms (gdy nie ma możliwości wygenerowania dodatkowych wyrażeń) do 800 ms, gdy
w wyniku wnioskowania powstaną 23 nowe wyrażenia.
960
Widać wyraźnie, że prędkość wnioskowania zależy zarówno od
złożoności modelu, jak i od złożoności wyrażenia conjunctive query. Czasy uzyskane w urządzeniu mobilnym są zadowalające dla
prostego modelu dziedziny i prostego wyrażenia conjunctive query. W pozostałych sytuacjach czas wnioskowania wydłuża się
znacząco (jednak pozostaje na poziomie akceptowalnym dla klasy usług o dużej tolerancji na opóźnienia, jak na przykład wymiana wiadomości typu SMS). Kolejnym krokiem będzie implementacja mechanizmów cache'owania wyników wnioskowania, co
powinno poprawić uzyskane czasy (zwłaszcza w sytuacjach, gdy
kontekst węzła nie ulega zmianie, a wyrażenia conjunctive query
powtarzają się). Przechowywane wyniki wnioskowania dla tych
wyrażeń pozostaną prawdziwe, dopóki kontekst węzła nie ulegnie
zmianie, co w rzeczywistych sytuacjach może być prawdą dla wielu węzłów sieci.
***
W ramach prac wykonanych przez Instytut Telekomunikacji PW
w projekcie 6FP STREP MIDAS (Middleware Platform for Developing and Deploying Advanced Mobile Services, numer kontraktu: 027055) powstało oprogramowanie umożliwiające praktyczne wykorzystanie ontologii w urządzeniach mobilnych. Dzięki
ograniczeniu ekspresywności ontologii, uzyskano wydajność porównywalną z oferowaną przez narzędzia dostępne dla komputerów stacjonarnych. Otwiera to nowe możliwości w dziedzinie
mobilnych aplikacji kontekstowych, które dotychczas w większości przypadków musiały korzystać z dedykowanego serwera odpowiedzialnego za obsługę ontologii i wnioskowanie. Brak konieczności dostępu do serwera oznacza możliwość korzystania
z ontologii w urządzeniach mobilnych o ograniczonych możliwościach komunikacyjnych, jak na przykład w mobilnych sieciach
peer-to-peer.
Dodatkowe informacje o wykorzystaniu opisanej tu kontekstowej bazy wiedzy w ramach projektu MIDAS są dostępne w publikacji [12].
LITERATURA
[1] Abowd G. D., Dey A. K. Brown, P. J., Davie N., Smith M. and Steggles:
Towards a Better Understanding of Context and Context-Awareness. In
Proceedings of the 1st international Symposium on Handheld and Ubiquitous Computing (Karlsruhe, Germany, 27 – 29 września 1999). H. Gellersen Ed. Lecture Notes In Computer Science, vol. 1707. Springer-Verlag, London
[2] Gorman J.: The MIDAS Project: Interworking and Data Sharing, The 8th
International Symposium on Interworking. Santiago (Chile), 15-19 stycznia 2007
[3] OWL Web Ontology Languag, W3C Recommendation: http: //www. w3.
org/TR/owl-guide/, 10 lutego 2004
[4] Siri E., Parsia, B., Grau, B. C., Kalyanpu, A., and Katz, Y.: Pellet: A practical OWL-DL reasoner. Web Semant. 5, 2 (Jun. 2007), 51-53. DOI= http:
//dx. doi. org/10.1016/j. websem. 2007.03.004
[5] Calvanese D., De Giacomo G., Lembo D., Lenzerin M., Rosati R.: DL-lite:
Tractable Description Logics for Ontologies In Proceedings of the Twentieth National Conference on Artificial Intelligence (AAAI 2005) 2005
[6] Grau B. C.: The University of Manchester: OWL 1.1 Web Ontology Language, Tractable Fragments (19 December 2006) http: //www. w3.
org/Submission/owl11-tractable/
[7] Horridge M., Drummond N., Goodwin J., Rector A., Stevens R., Wang
H.: The Manchester OWL Syntax OWL: Experiences and Directions 2006
Athens, Georgia, USA, 10–11 listopada 2006
[8] Java Compiler Compiler [tm] – The Java Parser Generator – https: //javacc. dev. java. net/
[9] Jabłonowski M. and Boetzel P.: Middleware Layer For Semantic Object
Tagging, Master Thesis at Warsaw University of Technology, The Department of Electronics and Information Technology, The Institute of Telecommunications, promotor: J. Domaszewicz. Warszawa, 2007
[10] HSQL: A java database engine v. 1.7.3 (2005-02-07) http: //hsqldb. org/
[11] NOKIA N800: Product homepage (2008) http: //www. nseries. com/products/n800/
[12] Koziuk M. and Domaszewicz J. and Schoeneich R. O. and Jabłonowski
M. and Boetzel P.: Context-Addressable Messaging with a DL-Lite Domain Model, zgłoszony na: 3rd IEEE European Conference on Smart Sensing and Context, October 29-31, 2008 Zurich, Switzerland
PRZEGLĄD TELEKOMUNIKACYJNY z ROCZNIK LXXXI
z
nr 8–9/2008