asparagus – system do semantycznej agregacji wyników zapytań

Transkrypt

Politechnika Poznańska
Wydział Informatyki
Instytut Informatyki
Praca dyplomowa inżynierska
ASPARAGUS – SYSTEM DO SEMANTYCZNEJ AGREGACJI
WYNIKÓW ZAPYTAŃ SPARQL
Michał Madziar, 84844
Aleksandra Nowak, 84856
Krzysztof T. Pawlak, 84864
Jędrzej Potoniec, 84868
Promotor
dr inż. Agnieszka Ławrynowicz
Poznań, 2011
Tutaj przychodzi karta pracy dyplomowej;
oryginał wstawiamy do wersji dla archiwum PP, w pozostałych kopiach wstawiamy ksero.
Spis treści
1 Wstęp
7
1.1
Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2
Motywacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.3
Cel i zakres pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.4
Przewidywana funkcjonalność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.5
Podział zadań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.6
Sposób organizacji pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2 Wykorzystane języki
11
2.1
Resource Description Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Logiki deskrypcyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
RDF Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.4
Web Ontology Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.5
SPARQL Protocol And RDF Query Language . . . . . . . . . . . . . . . . . . . . .
22
3 Wykorzystane oprogramowanie
11
27
3.1
Pellet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Semantic Similarity Measures Library . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3
Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.4
Serwlety HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4 Specyfikacja
27
39
4.1
Przypadki użycia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2
Wymagania pozafunkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5 Implementacja
43
5.1
Architektura systemu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2
Opcja CLUSTER BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.3
Opcja CATEGORIZE BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.4
Manager zapytań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.5
Interfejs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6 Podręcznik użytkownika
51
6.1
Interfejs webowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.2
Końcówka SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7 Testy
55
7.1
Testy jednostkowe dla algorytmów . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
7.2
Testy akceptacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6
Spis treści
8 Podsumowanie
61
Literatura
63
Rozdział 1
Wstęp
1.1
Wprowadzenie
Semantyczny Internet to idea Tima Bernersa-Lee, twórcy World Wide Web (WWW ). Ma on
rozszerzać Internet o elementy semantyczne, dobrze definiujące znaczenie informacji. Dzięki temu
Sieć stanie się nie tylko źródłem informacji dobrze zrozumiałych dla ludzi, ale możliwe będzie ich
automatyczne przetwarzanie przez programy komputerowe, a więc dużo łatwiejsza kooperacja ludzi
i maszyn [TJO01].
Istnieją dwie główne drogi rozwijania Semantycznego Internetu. Pierwsza - poprzez tworzenie
adnotacji semantycznych do istniejących w Internecie zasobów. Druga - poprzez udostępnianie
i łączenie w Sieci danych pochodzących z ustrukturalizowanych źródeł np. baz danych. Dzięki
takiemu podejściu otrzymuje się wielką „sieć danych”, o jawnej strukturze i znaczeniu. Niestety,
pomimo podobieństwa struktury danych, wyszukiwanie informacji w Semantycznym Internecie
istotnie różni się od wyszukiwania w relacyjnych bazach danych.
Pracując z Semantycznym Internetem, ma się do czynienia z otwartym źródłem danych o zwykle nieznanej a priori użytkownikowi strukturze i treści. Stąd, podczas wyszukiwania informacji,
użytkownik może być zainteresowany wynikami, które nie tylko ściśle spełniają kryteria wyszukiwania, ale także pozostałymi, które jeszcze pełniej prezentują poszukiwane zasoby informacyjne.
Zatem wyszukiwanie informacji w Semantycznym Internecie przypomina wyszukiwanie w nieustrukturalizowanych dokumentach tekstowych sieci WWW , gdzie użytkownicy często dodatkowo
eksplorują uzyskane wyniki, by jak najdokładniej zbadać źródło wiedzy. W standardowym języku
zapytań do zasobów Semantycznego Internetu, języku SPARQL (ang. SPARQL Protocol And RDF
Query Language), warunki zapytań są jednocześnie ścisłymi kryteriami zgodnymi z algebrą Boole’a. Może to doprowadzić w niektórych sytuacjach do pogorszenia jakości otrzymanych wyników.
Przykładowo, w przypadku agregacji wyników, użycie zbyt ścisłych kryteriów może doprowadzić
do uzyskania tak znacznej liczby grup, że utrudni dalszą analizę wyników i rozkładu danych. Z tym
problemem użytkownik spotka się, używając klauzuli GROUP BY, która utworzy dla każdej wartości
atrybutu grupowania osobny wiersz wynikowy.
W niniejszej pracy prezentowane jest inne podejście, opierające się m.in. na agregacji wyników
za pomocą jednej z metod eksploracji danych - analizy skupień. Prezentowany system umożliwia
wykonywanie zapytań w rozszerzonej notacji języka SPARQL do danych opisanych semantycznie
za pomocą języka OWL (ang. Web Ontology Language).
8
Wstęp
1.2
Motywacja
Poniżej zostaną przedstawione przykłady wyjaśniające potrzebę stworzenia systemu automatycznego grupowania wyników zapytań do semantycznych baz wiedzy.
Przykład 1: wybór oferty turystycznej.
Użytkownik poszukuje ofert turystycznych w róż-
nych źródłach danych, choć opisanych jedną ontologią. Przykładowo, chce spędzić urlop w Polsce.
W tym celu poszukuje atrakcyjnych ofert turystycznych. Chce, żeby wyniki zostały pogrupowane
według kryterium celu podróży, takim jak miasto, wieś, kurort itp. Po analizie wyników wydaje kolejne zapytanie, w którym atrakcje turystyczne mają być pogrupowane według dwóch atrybutów:
ich położenia oraz oferowanych tam rozrywek. Dla ułatwienia analizy wyników, uzyskane grupy
powinny mieć, jeżeli to możliwe, opis obrazujący wspólne cechy elementów należących do tej grupy.
Gdyby użytkownik korzystał z relacyjnej bazy danych, użyłby polecenia GROUP BY miejsce.
Niestety, semantyka polecenia GROUP BY może doprowadzić do powstania zbyt wielu grup. Przykładowo, jeżeli wartościami atrybutu miejsce będą nazwy miast, dla każdej nazwy powstanie osobny
wiersz wynikowy, co może znacznie utrudnić interpretację wyników. Zatem grupowanie według
tego atrybutu nie będzie w żaden sposób pożyteczne dla użytkownika. Prezentowane rozwiązanie
będzie działało w inny sposób. Wyniki zostaną pogrupowane dzięki zastosowaniu indukcyjnych
metod eksploracji danych, zamiast przez zastosowanie ścisłych kryteriów. Zamiast GROUP BY użyjemy: CLUSTER BY miejsce, co by zachować spójność ze składnią języka SPARQL przyjmie postać
zapytania ze zmienną: CLUSTER BY ?miejsce
Przykład 2: przygotowywanie oferty marketingowej. Duży bank planuje odświeżenie swojej oferty kont osobistych. Jednakże kadra zarządzająca chciełaby uniknąć sytuacji, w której jeden
rodzaj konta osobistego jest wykorzystywany przez 90% klientów banku, a pozostałe 9 rodzajów
przez 10%. Pojawia się problem: jakie grupy klientów mogą zostać wyróżnione?
W rozwiązaniu tego problemu można wykorzystać następujący scenariusz:
1. Przygotowanie opisu semantycznego danych posiadanych przez bank w bazie danych klientów.
2. Wykonanie grupowania tych danych.
W efekcie kadra zarządzająca banku otrzymuje cechy jakie charakeryzują podobnych klientów,
np. przedział wiekowy czy średnie zarobki. Dzięki temu może dostosować ofertę banku do potrzeb
swoich klientów.
Powyższe przykłady ilustrują problemy, z jakimi mierzy się osoba wyszukujący dane: duża,
trudna do przetworzenia ilość podobnych do siebie informacji, które jednak nie są w żaden sposób
pogrupowane. Rozwiązaniem tego problemu jest grupowanie wyników zapytań tak, by możliwie
ułatwić ich przeglądanie i skrócić czas potrzebny na znalezienie poszukiwanej informacji.
By zrealizować zaproponowane podejście, konieczne jest zdefiniowanie, w jaki sposób krotki wynikowe będą porównywane. Warto zauważyć, że ten problem jest mało eksploatowany w literaturze
i w związku z tym nie istnieją gotowe do wykorzystania implementacje. Biblioteki algorytmów takie jak Weka lub Rapid-I RapidMiner są nieprzystosowane do przetwarzania danych oznaczonych
semantycznie. Wymienione powody spowodowały, że niejako jednocześnie z rozwojem ASPARAGUS -a rozwijany jest na Politechnice projekt biblioteki miar podobieństwa dla danych oznaczonych
semantycznie SeSiL (ang. Semantic Similarity Measures Library).
1.3. Cel i zakres pracy
1.3
9
Cel i zakres pracy
Celem niniejszej pracy jest zaprojektowanie, stworzenie i przetestowanie w pełni sprawnego systemu umożliwiającego grupowanie wyników zapytań zadawanych w języku SPARQL. Wymagane
jest, by system:
• miał możliwość odczytywania danych dostarczonych przez użytkownika w formie plików w języku OWL bądź RDF ;
• miał możliwość pobierania danych z końcówek SPARQL;
• umożliwiał grupowanie wyników zgodnie z hierarchią pojęć z ontologii (opcja CATEGORIZE BY);
• umożliwiał grupowanie wyników z wykorzystaniem algorytmów eksploracji danych (opcja
CLUSTER BY);
• posiadał interfejs WWW do obsługi przez człowieka;
• posiadał interfejs końcówki SPARQL do wykorzystania przez inne systemy.
1.4
Przewidywana funkcjonalność
Gotowy system ma umożliwiać grupowanie wyników zapytań w języku SPARQL z wykorzystaniem jednego z trzech algorytmów:
• algorytmu CATEGORIZE BY,
• algorytmu k-Medoids,
• algorytmu aglomeracyjnego grupowania hierarchicznego.
System będzie wykorzystywał bibliotekę SeSiL do obliczania podobieństwa pomiędzy obiektami
w danych.
Obsługiwane będą dane zapisane w języku OWL (dialekt OWL DL) oraz RDF/XML. Będzie
istniała również możliwość ściągnięcia danych z końcowki SPARQL z wykorzystaniem protokołu
SPROT .
Interfejs użytkownika zostanie przygotowany z wykorzystaniem biblioteki GWT i będzie umożliwiał zadawanie zapytań zgodnych z rozwiniętą w tej pracy składnią SPARQL, przeglądanie wyników tych zapytań, a także wskazywanie źródeł danych, przez podanie adresu bądź przesłanie
pliku na serwer.
1.5
Podział zadań
Michał Madziar
• implementacja końcówki SPARQL (rozdz. 5.5.1)
• implementacja interfejsu WWW (rozdz. 5.5.2)
Aleksandra Nowak
• implementacja algorytmu aglomeracyjnego grupowania hierarchicznego (rozdz. 5.2.1)
Krzysztof T. Pawlak
• implementacja algorytmu k-Medoids (rozdz. 5.2.2)
Jędrzej Potoniec
• implementacja managera zadań (rozdz. 5.4)
• implementacja algorytmu CATEGORIZE BY (rozdz. 5.3)
10
Wstęp
1.6
Sposób organizacji pracy
Praca zorganizowana jest zgodnie z następującym porządkiem.
W rozdziale drugim przedstawiono wykorzystywane sposoby zapisu danych oraz języki. Resource Description Framework jest podstawowym sposobem zapisu informacji w Semantycznym
Internecie. Logiki deskrypcyjne stanowią podstawę teoretyczną, na której opiera się wnioskowanie.
RDF Schema i Web Ontology Language są językami dodającymi semantykę do danych zapisanych w postaci RDF. Język zapytań SPARQL służy do zadawania koniunkcyjnych zapytań do baz
wiedzy.
W rozdziale trzecim przedstawiono wykorzystywane biblioteki i oprogramowanie. Pellet jest
systemem wnioskującym, wykorzystywanym do przetwarzania danych. SeSiL jest biblioteką miar
podobieństwa pomiędzy danymi opisanymi sematycznie. Google Web Toolkit i serwlety HTTP
zostały wykorzystane do stworzenia interfejsu użytkownika.
W rozdziale czwartym znajduje się szczegółowa specyfikacja wymagań w postaci przypadków
użycia oraz wymagań pozafunkcjonalnych.
Rozdział piąty poświęcony jest szczegółowej architekturze i implementacji systemu zgodnie z
przedstawionymi wcześniej wymaganiami. Znajduje się tam projekt modułowej architektury systemu, opis zaimplementowanych algorytmów, interfejsu użytkownika, a także managera zapytań,
służącego koordynowaniu prac poszczególnych komponentów.
W rozdziale szóstym znajduje się podręcznik użytkownika.
W rozdziale siódmym przedstawione są testy jednostkowe, którymi testowane były zaimplementowane algorytmy. Opisane są również scenariusze testowe, które były wykorzystywane do
testowania interfejsu użytkownika i jego powiązania z resztą systemu.
W rozdziale ósmym znajduje się podsumowanie.
Rozdział 2
Wykorzystane języki
2.1
Resource Description Framework
2.1.1
Wprowadzenie
RDF (ang. Resource Description Framework ) jest modelem zapisu informacji w Sieci Semantycznej [DOS03], [HFB09]. Dzięki niemu jest możliwa wymiana i łączenie danych w Sieci przez maszyny, nawet jeśli struktura tych informacji się różni. Język posiada formalną semantykę i składnię
opartą na języku XML (ang. Extensible Markup Language, zdefiniowano specjalny język znaczników RDF/XML, [KC04]). W RDF model danych oparty jest na grafie. Do opisu danych, w sposób
analogiczny do hiperłączy w Internecie, używa adresów URI (ang. Uniform Resource Identifier ).
W Sieci Semantycznej wiedza jest reprezentowana jako zbiór zdań zwanych często trójkami,
gdyż są one złożone z trzech części: podmiotu, orzeczenia (predykatu) i dopełnienia (obiektu),
o znaczeniu analogicznym do znaczenia tych części zdania w normalnej gramatyce każdego języka.
Podmiot zdania jest pojęciem, którego dane zdanie dotyczy. Dopełnienie to część zdania oznaczająca pasywny przedmiot czynności wyrażonej orzeczeniem. Natomiast orzeczenie opisuje relację
pomiędzy podmiotem a obiektem.
Wierzchołkami w grafie RDF są podmiot i dopełnienie zdania, które graf reprezentuje. Wyróżnia się dwa rodzaje wierzchołków:
Zasoby reprezentują obiekty świata rzeczywistego, mają postać URI.
Literały reprezentują dane o konkretnej wartości np. liczby lub łańcuchy znaków. Nie mogą stanowić podmiotu zdania, jedynie dopełnienie.
Łuki reprezentują predykaty, zwane także własnościami, które łączą dwa zasoby lub zasoby
i literały. Własności są także rodzajem zasobu. Tak jak podmioty posiadają własne URI.
Niech dane będą przykładowe zdania (pochodzące z [HFB09], dla zachowania spójności ze
źródłem przykład pozostawiono w języku angielskim):
Andrew knows Matt. (Andrew zna Matta.)
Andrew’s surname is Perez-Lopez. (Andrew nazywa się Perez-Lopez.)
Matt knows John. (Matt zna Johna.)
Ryan works with John. (Ryan pracuje z Johnem.)
Rysunek 2.1 przedstawia graf RDF reprezentujący ten zbiór informacji. Zdania naturalnie odpowiadają skierowanemu grafowi, gdzie podmiot i dopełnienie są reprezentowane przez wierzchołki,
a orzeczenia jako łuki.
Na rysunku 2.2 przedstawiony jest w pełni opisany graf, w którym każdy zasób ma przypisany
adres URI.
12
Rysunek 2.1: Przykład grafu. Zasoby są reprezentowane przez wierzchołki owalne,
literały przez wierzchołki prostokątne, łuki oznaczają własności. (Źródło: [HFB09])
Rysunek 2.2: Przykład grafu z URI dla każdego zasobu. (Źródło: [HFB09])
Przestrzenie nazw to dokumenty XML zawierające gotowe zasoby - zbiory słownictwa, które
ułatwiają prace przy tworzeniu własnych dokumentów RDF. Dzięki przestrzeniom nazw staje
się możliwe wielokrotne użycie gotowych pojęć oraz dostosowywanie i rozszerzanie tego zestawu
do własnych potrzeb. W celu zachowania przejrzystości zapisu do URI reprezentującego daną
przestrzeń nazw przypisuje się prefiks, który dalej jest używany. Poniżej wymieniono podstawowe
przestrzenie nazw:
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http://www.w3.org/2000/01/rdf-schema#
owl http://www.w3.org/2002/07/owl#
xsd http://www.w3.org/2001/XMLSchema#
2.1.2
Serializacja
Przedstawienie danych RDF w formie grafu jest formą łatwo czytelną dla człowieka. Jednak,
by była możliwa wymiana informacji, ten abstrakcyjny model musi zostać skonwertowany do odpowiedniego formatu, np. pliku lub strumienia bajtów. Jest to proces zwany serializacją. Istnieje
13
2.1. Resource Description Framework
kilka porównywalnych formatów serializacji, z których najpopularniejsze to RDF/XML, Terse RDF
Triple Language (Turtle) i N-Triples.
RDF/XML reprezentuje trójki RDF używając składni XML. RDF/XML jest standardem do
wymiany danych zapisanych w RDF.
Całość dokumentu RDF , jest ujęta w znaczniki rdf:RDF. Natomiast zdania opisujące zasoby są zawarte w znacznikach rdf:Description. Wewnątrz nich znajdują się poszczególne
elementy zdania. Istnieją trzy następujące sposoby opisu wykorzystujące:
• Znacznik rdf:about, który oznacza odniesienie do istniejącego zasobu. Poniższy przykład w pseudo-RDF/XML prezentuje użycie tego znacznika:
<rdf:RDF>
<rdf:Description rdf:about="podmiot">
<predicate rdf:resource="obiekt" />
<predicate>literał</predicate>
</rdf:Description>
</rdf:RDF>
• Atrybut rdf:ID, który oznacza nowy zasób (choć można go również stosować zamiennie
z rdf:about):
<rdf:RDF>
<rdf:Description rdf:ID="podmiot">
<predicate rdf:resource="obiekt" />
<predicate>literał</predicate>
</rdf:Description>
</rdf:RDF>
• Poprzez utworzenie zasóbu anonimowego bez nazwy.
Terse RDF Triple Language (Turtle) jest kolejną składnią zaprojektowaną dla modelu danych RDF. Turtle nie bazuje na XML lecz został zaprojektowany specjalnie na potrzeby
RDF. Graf nie jest tutaj reprezentowany jako drzewo, dzięki temu reprezentacja jest bardziej ścisła i łatwiejsza do odczytania. Jest najbardziej przyjaznym człowiekowi sposobem
zapisu [BBL08].
Turtle ma prosty format zapisu trójek. Podmiot, predykat i obiekt zapisywane są w jednej
linii, oddzielone spacjami, a zdanie kończy się kropką.
<http://semwebprogramming.net/people#Ryan>
C
<http://semwebprogramming.net/2008/06/ont/foafextension#worksWith>
C
<http://semwebprogramming.net/people#John> .
Zasoby mogą być zapisywane w dwojaki sposób: za pomocą URI ujętego w nawiasy ostrokątne (<, >) lub przy użyciu prefiksu. Stąd ten sam przykład przy użyciu przestrzeni nazw
wygląda następująco:
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix people: <http://semwebprogramming.net/people/> .
@prefix ext: <http://semwebprogramming.net/2008/06/ont/foafextension#> .
people:Ryan ext:worksWith people:John .
Turtle umożliwia skrócony zapis kilku zdań, które mają ten sam podmiot. Podmiot wystąpi tylko raz, a kolejne zdania będą oddzielone średnikami:
people:Andrew
foaf:knows people:Matt ;
foaf:surname "Perez-Lopez" .
14
Istnieje również możliwość zapisu zdań o takim samym podmiocie i predykacie. Używa się
wtedy przecinka:
people:Andrew foaf:knows people:Matt, people:Ryan, people:John .
N-Triples jest uproszczoną wersją Turtle. Zdania zapisuje się analogicznie. Nie ma jednak możliwości użycia prefiksów. Nie można także zapisać jednego zdania w więcej niż jednej linii,
stąd nie ma tutaj skróconych form zdań.
C
<http://xmlns.com/foaf/0.1/worksWith> C
<http://semwebprogramming.net/people#Ryan>
<http://semwebprogramming.net/people#John> .
2.2
Logiki deskrypcyjne
2.2.1
Logika pierwszego rzędu
W poniższym podrozdziale zdefiniowana zostanie logika pierwszego rzędu, będąca podstawowym formalizmem dla logik deskrypcyjnych [Lig06], [BA05].
Składnia
Definicja 2.1 (alfabet). Alfabet logiki pierwszego rzędu składa się z następujących symboli:
stałych typowo oznaczanych przez a, b, c, . . . ∈ C;
zmiennych typowo oznaczanych przez x, y, z, . . . ∈ V ;
symboli funkcyjnych typowo oznaczanych przez f, g, h, . . . ∈ F , z każdym symbolem funkcyjnym powiązana jest liczba naturalna n oznaczająca liczbę argumentów (arność) tego symbolu;
predykatów typowo oznaczanych przez p, q, r, . . . ∈ P , z każdym predykatem powiązana jest
liczba naturalna n oznaczająca jego liczbę argumentów (arność);
relacji {¬, ∧, ∨, →, ↔}
kwantyfikatorów {∃, ∀}
Definicja 2.2 (term). Zbiór termów T jest to zbiór elementów a spełniających jeden z następujących warunków:
• a jest stałą;
• a jest zmienną;
• a jest postaci f (t1 , t2 , . . . , tn ) gdzie f jest symbolem funkcyjnym, t1 , t2 , . . . , tn prawidłowymi
termami, a n arnością symbolu f .
Definicja 2.3 (atom). Zbiór atomów A definiuje się następująco:
A = {p(t1 , t2 , . . . , tn )|p ∈ P ; t1 , t2 , . . . , tn ∈ T }
(2.1)
przy czym n oznacza arność predykatu p.
Definicja 2.4 (formuła). Zbiór formuł F jest to zbiór elementów spełniających jedną z poniższych
własności:
• Jeżeli φ ∈ F to φ ∈ A.
• Jeżeli φ ∈ F to ¬φ ∈ F.
• Jeżeli φ, ψ ∈ F, to:
– φ∧ψ ∈F
– φ∨ψ ∈F
– φ→ψ∈F
2.2. Logiki deskrypcyjne
15
– φ↔ψ∈F
• Jeżeli φ ∈ F, x ∈ V to
– ∀φ(x) ∈ F
– ∃φ(x) ∈ F
Definicja 2.5 (zmienna związana). Niech dana będzie formuła φ oraz zmienna x. Zmienna x jest
związana jeżeli występuje w wyrażeniu ∀x : φ bądź ∃x : φ.
Definicja 2.6 (zmienna wolna). Zmienna, która nie jest związana.
Definicja 2.7 (podstawienie). Zbiór przypisań termów do zmiennych.
Definicja 2.8 (zdanie). Formuła, która nie zawiera zmiennych wolnych.
Semantyka
Definicja 2.9 (interpretacja). Interpretacją I nazywa się (∆I , ·I ), w której ∆I jest niepustym
zbiorem nazywanym dziedziną, a ·I funkcją przypisującą elementom alfabetu elementy zbioru ∆I
zgodnie z poniższymi regułami:
• Jeżeli a ∈ C, to ·I (a) = aI ∈ ∆I .
• Jeżeli f ∈ F , to ·I (f ) = f I , gdzie f I : (∆I )n → ∆I , a n oznacza arność f .
• Jeżeli p ∈ P , to ·I (p) = pI , gdzie pI : (∆I )n → {prawda, fałsz}, a n oznacza arność p.
Definicja 2.10 (wiązanie zmiennych). Jest to dowolna funkcja ξ I : V → ∆I .
Definicja 2.11 (wartościowanie termów). Wartościowanie νξI (t) termu t w interpretacji I, przy
założeniu wiązania zmiennych określonego funkcją ξ I , wyraża się następująco:
• Jeżeli a ∈ C, to νξI (a) = aI .
• Jeżeli a ∈ V , to νξI (x) = ξ I (x).
• Jeżeli f ∈ F oraz t1 , t2 , . . . , tn ∈ T , to
νξI (f (t1 , t2 , . . . , tn )) = f I (νξI (t1 ), νξI (t2 ), . . . , νξI (tn ))
(2.2)
Definicja 2.12 (wartościowanie formuł). Niech dana będzie formuła φ, jej wartościowanie νξI (φ)
wyznacza się następująco:
• Jeżeli φ ∈ A, to νξI (φ) = pI (νξI (t1 ), νξI (t2 ), . . . , νξI (tn )), gdzie p jest predykatem występującym w formule φ, t1 , t2 , . . . , tn jego argumentami, a n jego arnością.
• νξI (¬φ) = prawda wtedy, i tylko wtedy, gdy νξI (φ) = fałsz.
• νξI (φ) = prawda wtedy, i tylko wtedy, gdy νξI (¬φ) = fałsz.
• Niech φ = φ1 ∨ φ2 . νξI (φ) = prawda wtedy, i tylko wtedy, gdy zachodzi co najmniej jedno
z: νξI (φ1 ) = prawda lub νξI (φ2 ) = prawda.
• Niech φ = φ1 ∧ φ2 . νξI (φ) = prawda wtedy, i tylko wtedy, gdy zachodzi νξI (φ1 ) = prawda
oraz νξI (φ2 ) = prawda.
• Niech φ = φ1 → φ2 . Wtedy νξI (φ) = νξI (¬φ1 ∨ φ2 )
• Niech φ = φ1 ↔ φ2 . Wtedy νξI (φ) = νξI ((φ1 ∧ φ2 ) ∨ (¬φ1 ∧ ¬φ2 ))
Definicja 2.13 (spełnialność). Interpretacja I spełnia formułę φ jeżeli νξI (φ) = prawda i oznacza
się to przez I φ. Formuła φ jest spełnialna, jeżeli istnieje interpretacja I, dla której zachodzi
I φ.
Definicja 2.14 (niespełnialność). Formuła φ jest niespełnialna, jeżeli nie istnieje interpretacja
I, dla której I φ.
16
Definicja 2.15 (konsekwencja logiczna). Formuła φ jest konsekwencją logiczną formuły ψ, co
zapisuje się ψ φ jeżeli dla każdej interpretacji I, dla której I ψ, zachodzi I φ.
Definicja 2.16 (tautologia). Tautologią nazywa się formułę φ, dla której zachodzi I φ dla
dowolnej interpretacji I. Oznacza się to przez φ.
Definicja 2.17 (logiczna równoważność). Formuły φ i ψ są logicznie równoważne (co oznacza się
przez φ ≡ ψ lub φ ⇐⇒ ψ), jeżeli φ ↔ ψ.
2.2.2
Logiki deskrypcyjne
Logiki deskrypcyjne są grupą języków, będących podzbiorem logiki pierwszego rzędu, przystosowanych do opisu pojęć i informacji z rozważanej dziedziny w sposób sformalizowany i efektywny
do przetwarzania, przy jednoczesnym zapewnieniu wystarczającej ekspresji [Baa03]. Ich początków
należy szukać we wcześniejszych formalizmach z dziedziny przetwarzania informacji, jakimi były
sieci semantyczne oraz ramy. Wadą wymienionych rozwiązań był brak precyzyjnie zdefiniowanej
semantyki, a co za tym idzie, duża dowolność w przetwarzaniu informacji. Dopiero spostrzeżenie,
że z systemem ram można powiązać semantykę pochodzącą z logiki pierwszego rzędu doprowadziło
do rozwoju logik deskrypcyjnych.
Zauważono mianowicie, że jeżeli wykorzystać tylko pewne fragmenty logiki pierwszego rzędu,
można budować systemy, które z jednej strony zapewniają wystarczającą siłę przekazu, a przy tym
wnioskowanie w nich jest rozstrzygalne. Również dzięki ograniczeniu zbioru używanych konstrukcji
możliwe było stworzenie bardziej wyspecjalizowanych algorytmów zamiast ogólnych, przeznaczonych dla logik pierwszego rzędu.
Składnia
Podstawowymi elementami logiki deskrypcyjnej są pojęcia atomowe oraz role atomowe. Z tych
elementów, będących najprostszymi pojęciami, buduje się pojęcia złożone, przy wykorzystaniu odpowiednich operatorów. W poniższym opisie przyjęto następującą konwencję symboli:
A pojęcie atomowe,
R rola atomowa,
C, D pojęcie złożone,
n dowolna liczba naturalna.
Na potrzeby przykładów opisywanych pojęć przyjmuje się dwa pojęcia atomowe Człowiek i Kobieta
oraz rola atomowa maDziecko, z intuicyjnym pojmowaniem tych pojęć.
Dla przykładu zostanie tu przedstawiony prosty język AL, zdefiniowany po raz pierwszy w [SSS91].
Dopuszczalne są w nim następujące konstrukcje:
pojęcie uniwersalne >, które reprezentuje pojęcie bardziej ogólne od każdego innego;
pojęcie dolne ⊥, które reprezentuje pojęcie bardziej szczegółowe od każdego innego;
koniunkcja dowolnych pojęć C u D
atomowa negacja ¬A
ograniczenie na przeciwdziedzinę ∀R.C, oznaczające, że obiekt, który pozostaje w relacji
R z pojęciem opisanym w ten sposób, musi być opisany pojęciem C;
ograniczone wymuszenie istnienia ∃R.>, oznaczające, że obiekt opisany w ten sposób musi
pozostawać z dowolnym innym w relacji R.
Należy zauważyć, że zachodzą prawa ⊥ u C ≡ ⊥ oraz > u C ≡ C, wynikające wprost z definicji
pojęcia uniwersalnego i dolnego.
Intuicyjnymi przykładami dla powyższych konstrukcji niech będą następujące pojęcia:
17
2.2. Logiki deskrypcyjne
• M ęż czyzna ≡ Czł owiek u ¬Kobieta
• M atka ≡ Kobieta u ∃maDziecko.>
Oczywiście, istnieją liczne rozszerzenia języka AL. Część z nich została przedstawiona w tablicy 2.1. Korzystanie z nich nie zawsze jest pożądane, ponieważ wraz ze wzrostem złożoności
języka, rośnie też złożoność obliczeniowa. Litery, podane w kolumnie oznaczenie języka, dołączane
są po AL, to znaczy język z dopuszczalną negacją dowolnego pojęcia oznaczany jest przez ALC.
Istotnym jest, by zauważyć, że ten sam język można skonstruować na kilka różnych sposobów. Korzystając, na przykład, z zaczerpniętych z logiki pierwszego rzędu praw De Morgana łatwo zauważyć, że negacja dowolnego pojęcia implikuje alternatywę dowolnych pojęć (¬(C u D) ≡ ¬C t ¬D).
Również zgodnie z prawem negowania kwantyfikatorów ¬∀R.C ≡ ∃R.¬C. W związku z tym z samej
negacji otrzymuje się alternatywę i wymuszenie istnienia, a więc języki ALC i ALUE są równoważne. Przyjęło się wybierać tę pierwszą nazwę, ze względu na krótszy zapis.
Tablica 2.1: Rozszerzenia języka AL
opis
negacja dowolnego pojęcia
alternatywa dowolnych pojęć
wymuszenie istnienia
ograniczenie ilościowe
składnia
¬C
C tD
∃R.C
nR, ¬ nR
oznaczenie języka
C
U
E
N
Semantyka
Jak już wspomniano wcześniej, logiki deskrypcyjne są podzbiorem logiki pierwszego rzędu, więc
również tutaj pojawia się pojęcie interpretacji I = (∆I , ·I ), gdzie ∆I jest dziedziną, a ·I funkcją
interpretacji. Semantyka poszczególnych konstrukcji, opisanych w poprzednim paragrafie, została
zebrana w tablicy 2.2. Zebrane tam informacje należy traktować jako wymagania, które musi
spełniać funkcja ·I , przyporządkowująca pewnym pojęciom składniowym elementy zbioru ∆I .
Tablica 2.2: Semantyka popularnych konstrukcji logik deskrypcyjnych
składnia
A
R
>
⊥
C uD
C tD
¬C
∀R.C
∃R.C
nR
¬ nR
semantyka
A I ⊆ ∆I
R I ⊆ ∆I × ∆I
∆I
∅
C I ∩ DI
C I ∪ DI
I
I
∆
\C I
I
I
→ b ∈ CI
a ∈ ∆I |∀b ∈ ∆I : (a, b) ∈ R
I
∈ C :I (a, b) ∈ R I a ∈ ∆I |∃b
a ∈ ∆I | b ∈ ∆I |(a, b) ∈ RI n
a ∈ ∆ | b ∈ ∆ |(a, b) ∈ R ¬ n
Wykorzystanie logik deskrypcyjnych
Semantyczny opis świata, dokonywany przy pomocy logiki deskrypcyjnej, przechowywany jest
w bazie wiedzy (ang. KB - knowledge base). Typowo podzielony jest on na dwie części: część
terminologiczną (TBox) oraz część asercyjną (ABox).
W części terminologicznej umieszczone są opisy z wykorzystaniem składni danego języka i reprezentujące ogólną wiedzę o danej dziedzinie. Poza przedstawionymi powyżej konstrukcjami dopuszczalne są tutaj definicje zawierania i równoważności, opisane w tablicy 2.3.
18
Tablica 2.3: Dodatkowe konstrukcje dopuszczalne w części terminologicznej
opis
zawieranie pojęć
zawieranie relacji
równoważność pojęć
równoważność relacji
składnia
CvD
RvS
C≡D
R≡S
semantyka
C I ⊆ DI
RI ⊆ S I
C I ≡ DI
RI ≡ S I
Część asercyjna zawiera konstrukcję interpretacji, to znaczy opisuje poszczególne obiekty (indywidua), ich przynależność do zdefiniowanych wcześniej pojęć i relacji. Dopuszczalne typy asercji
zostały zebrane w tablicy 2.4.
Tablica 2.4: Dopuszczalne typy asercji w ABox (a, b oznaczają rozważane indywiduua)
opis
przynależności do pojęcia
przynależności do relacji
identyczność obiektów świata rzeczywistego
różność obiektów świata rzeczywistego
składnia
C(a)
R(a, b)
a=b
a 6= b
semantyka
[C(a)]I = (aI ∈ ∆I )
[R(a, b)]I = ((aI , bI ) ∈ RI )
(a = b)I = (aI = bI )
(a 6= b)I = (aI 6= bI )
Definicja 2.18 (spełnialność części terminologicznej). Interpretacja I spełnia (ang. satisfy) część
terminologiczną jeżeli dla każdej definicji zawierania oraz równoważności zachowana jest jej semantyka.
Definicja 2.19 (spełnialność części asercyjnej). Interpretacja I spełnia część asercyjną jeżeli dla
każdej definicji przynależności, identyczności oraz różności obiektów zachowana jest jej semantyka.
Definicja 2.20 (spełnialność bazy wiedzy). Interpretacja I spełnia bazę wiedzy jeżeli spełnia
jednocześnie TBox i ABox.
Typowymi zadaniami dla narzędzi wnioskujących w bazach wiedzy (ang. reasoner, przykładem
jest Pellet, roz. 3.1) są zadania weryfikacji:
• czy TBox bądź ABox są spełnialne;
• czy dla danych pojęć C, D zachodzi C v D;
• czy dla danego indywiduum a i pojęcia C zachodzi C(a).
2.3
RDF Schema
RDFS (ang. RDF Schema) jest językiem reprezentacji wiedzy opartym na RDF. Celem RDFS
jest ustrukturalizowanie zasobów RDF poprzez stworzenie klasyfikacji i opisów obiektów. Uzyskuje
się to przy wykorzystaniu trójek RDF do zdefiniowania klas i ich hierarchii. Tak zapisane struktury
nazywa się słownikami RDF (ang. RDF vocabularies). Są one podstawowymi elementami opisu
ontologii - wiele komponentów RDFS jest włączonych do języka opisu ontologii OWL. Język RDF
Schema stanowi rekomendację W3C [BG].
Podstawowym pojęciem języka RDFS jest klasa, rozumiana jako zbiór elementów o wspólnych
cechach. Jest to równoznaczne z pojęciem typu lub kategorii. Wierzchołek grafu RDF może zostać
przydzielony do dowolnej liczby klas. Klasy są definiowane za pomocą własności.
Do komponentów RDF Schema należą [DOS03],[BG]:
rdfs:Class Element, który definiuje grupę powiązanych obiektów, które mają wspólne własności.
Użycie razem z rdf:Property, rdfs:range i rdfs:domain pozwala na przypisanie klasie
2.4. Web Ontology Language
19
własności. Wymaga URI jako identyfikatora w atrybucie rdf:about. rdfs:Class jest instancją rdfs:Class.
rdfs:label Własność, która określa łatwą do odczytania przez człowieka etykietę klasy. Ma to
zastosowanie np. w aplikacjach, które wyświetlają nazwę klasy, chociaż formalnym identyfikatorem klasy jest URI określony przez atrybut rdf:about.
rdfs:subClassOf Własność, która określa, że klasa jest specjalizacją innej istniejącej klasy. Ideą
specjalizacji jest dodawanie przez podklasę unikalnych cech do ogólnego pojęcia.
rdf:Property Klasa definiująca własność klasy i zakres wartości, jakie ta własność może przyjmować. Jest używany razem z własnościami rdfs:domain i rdfs:range.
rdfs:domain Własność taka, że trójka postaci P rdfs:domain C oznacza, że P jest instancją
klasy rdf:Property, C jest instancją klasy rdfs:Class, a zasoby opisane podmiotami trójek,
w których predykatem jest P, są instancjami klasy C.
rdfs:range Własność taka, że trójka postaci P rdfs:range C oznacza, że P jest instancją klasy
rdf:Property, C jest instancją klasy rdfs:Class, a zasoby opisane dopełnieniami trójek,
w których predykatem jest P, są instancjami klasy C.
rdf:type Własność określająca, że podmiot RDF jest typu zdefiniowanego w RDF Schema.
rdfs:subPropertyOf Własność określająca, że własność będąca podmiotem wyrażenia jest podwłasnością innej istniejącej własności.
rdfs:seeAlso Własność pozwalająca odwołać się do zasobu mogącego dostarczyć dodatkowych
informacji RDF o bieżącym zasobie.
rdfs:isDefinedBy Własność definiująca przestrzeń nazw podmiotu. Jest podwłasnością
rdfs:seeAlso.
rdfs:comment Własność pozwalająca na opatrzenie klas i własności dodatkowym opisem w celu
wytłumaczenia ich innym użytkownikom schematu.
rdfs:Literal Własność wyrażająca stałą wartość reprezentowaną jako łańcuch znaków. Do składni
RDF dodano też literały typowane, więc mogą one być dowolnego typu ze specyfikacji XML
Schema (np. integer czy float).
rdfs:XMLLiteral Własność reprezentująca stałą wartość będącą dobrze uformowanym dokumentem XML. Pozwala to na łatwe osadzanie XML w RDF.
Oprócz powyższych klas i własności, RDFS definiuje klasy i własności rdfs:Container,
rdf:Bag, rdf:Seq, rdf:Alt, rdfs:member i rdfs:ContainerMembershipProperty dla pojęć kontenerów oraz rdf:Statement, rdf:subject, rdf:predicate i rdf:object dla pojęć związanych
z reifikacją.
2.4
Web Ontology Language
OWL (ang. Web Ontology Language) to kolejny język stworzony na potrzeby semantycznego
przetwarzania danych. Ma jednak więcej możliwości niż przedstawiony wcześniej RDF, gdyż klasy,
instancje i relacje między nimi można opisywać i charakteryzować za pomocą dodatkowego słownictwa, o które wzbogacono OWL [MvH04].
Języki semantyczne czynią założenie otwartego świata (ang. open world assumption), które
mówi, że z braku wiedzy na temat prawdziwości zdania, nie można wyciągnąć wniosku, że jest
ono fałszywe. Założenie otwartego świata ma istotny wpływ na sposób interpretacji i modelowania
informacji. Kolejnym założeniem jest założenie o nieunikalności nazw (ang. no unique name assumption). Mówi ono, że nie można czynić założenia, że dwa zasoby o różnym URI są różne, jeżeli
nie jest to jednoznacznie powiedziane.
20
Rysunek 2.3: Hierarchia klas w OWL. (Źródło: [MKS04])
2.4.1
Elementy ontologii
Ontologie są zapisywane w dokumentach, które składają się z następujących części:
Nagłówek jest opisem zasobu, który reprezentuje ontologię. Nagłówek jest elementem opcjonalnym. Może zawierać przypisy dotyczące przykładowo wersji, kompatybilności oraz etykiety
i komentarze. W nagłówku mogą być także zdefiniowane klauzule importu innych ontologii.
Adnotacje są to niesemantyczne własności. Adnotacje są zdaniami opisującymi zasoby. Mogą
być użyte do opisu każdego zasobu czy aksjomatu ontologii, a także samej ontologii. Klasy
i własności są opisywane poprzez zdania, w których adnotacje stanowią predykat zdania.
Definicje klas i własności klasy są zbiorami obiektów o pewnych wspólnych własnościach.
Wiedza o instancjach czyli wystąpieniach klas.
Defnicje typów danych które wyrażają zakres wartości danych. Można także (w OWL 2) definiować własne typy danych.
2.4.2
Podstawowe elementy OWL
Podając za [HFB09] podstawowe elementy OWL to:
klasy i instancje Klasy w ontologii będą tworzyć strukturę hierarchiczną. Najbardziej bazowe
pojęcia powinny odwoływać się do klas, które są korzeniami w taksonomii. Każda instancja
w OWL należy do klasy owl:Thing (odpowiednik >). Stąd każda klasa zdefiniowana przez
użytkownika jest podklasą owl:Thing. Można także zdefiniować pustą klasę owl:Nothing
(odpowiednik ⊥). Jest ona podklasą wszystkich klas w OWL. Schematycznie taka struktura
jest przedstawiona na rysunku 2.3.
Klasy definiuje się za pomocą nazwy i listy ograniczeń dla instancji klasy.
<owl:Class rdf:ID="nazwa" />
lista ograniczeń
</owl:Class>
Rodzaje ograniczeń:
• owl:equivalentClass oznacza, że dwie klasy są równoważne i wszystkie wystąpienia
jednej klasy są instancjami drugiej.
Przykład: <owl:equivalentClass rdf:resource="klasa"/>
• owl:disjointWith znaczące, że dwie klasy są rozłączne, tj. nie posiadają wspólnych
instancji.
Przykład: <owl:disjointWith rdf:resource="klasy"/>
2.4. Web Ontology Language
21
Dla zachowania hierarchicznej taksonomii, konieczne jest tworzenie podklas. W OWL służy
do tego rdfs:subClassOf. Ta operacja łączy bardziej szczegółowe klasy, z bardziej ogólnymi. Jeżeli X jest podklasą Y, wtedy każda instancja X jest także instancją Y. Relacja
rdfs:subClassOf jest przechodnia, jeżeli X jest podklasą Y, a Y jest podklasą Z, to X jest
podklasą Z.
<owl:Class rdf:ID="ClassName">
<rdfs:subClassOf rdf:ID="subClassName" />
...
</owl:Class>
Instancje uzyskuje się przez:
<klasa rdf:ID="nazwaInstancji">
opis, ograniczenia
</klasa>
Poniższe własności można wykorzystać przy tworzeniu opisu i ograniczeń:
• <owl:sameAs rdf:resource="nazwaInstancji" />, która oznacza, że dwie instancje
są identyczne. Taka sytuacja jest możliwa, z powodu braku założenia o unikalności nazw.
Gdy instancje są identyczne, wnioskowanie na temat jednej z nich jest prawdziwe dla
obu.
• <owl:differentFrom rdf:resource="nazwaInstancji" />, która oznacza różność dwóch
instancji. Jest to stwierdzenie, że mechanizmowi wnioskującemu nie wolno udowodnić
równoważności danych instancji.
własności Własność jest relacją binarną. Wyróżnia się dwa typy własności:
• pomiędzy instancjami klas i literałami - owl:DatatypeProperty pozwala utworzyć relację
<owl:DatatypeProperty rdf:ID="nazwaWłasności">
ograniczenia
</owl:DatatypeProperty>
• pomiędzy instancjami klas - owl:ObjectProperty
<owl:ObjectProperty rdf:ID="nazwaWłasności">
ograniczenia
</owl:ObjectProperty>
Własności można ograniczać na wiele sposobów, np. poprzez ustalenie dziedziny (rdfs:domain)
i przeciwdziedziny (rdfs:range). Własność może być także zdefiniowana jako specjalizacja
(podwłasność) istniejącej własności (rdfs:subPropertyOf)
Relacje między własnościami [BvHH+ 04]:
równoważność owl:equivalentProperty Formuły mają te same wartości, ale mogą oznaczać inne pojęcia.
odwrotność owl:inverseOf Formuły są odwrotne, gdy dla każdej pary postaci (x,y) we
właśności P1, istnieje para (y,x) we własności P2.
funkcyjność owl:FunctionalProperty Zachodzi jeśli dla każdej instancji x, własność ma
tylko jedną i unikalną instancję y.
odwrotna funkcyjność owl:InverseFunctionalProperty Mówi, że nie może istnieć więcej niż jedna instancja x, dla której własność przyporządkowuje instancję y.
przechodniość owl:TransitiveProperty Własność jest przechodnia, wtedy gdy, jeżeli
para (x,y) oraz (y,z) są instancjami własności P, to można wnioskować, że para (y,z)
także jest instancją P.
22
2.4.3
Rodzaje OWL
Można wyróżnić trzy podjęzyki języka OWL 1: OWL Lite, OWL DL i OWL Full. Każdy z nich
jest odpowiednio rozszerzeniem swojego poprzednika, pod względem tego co można za jego pomocą
wyrazić i jego możliwości wnioskowania.
OWL Lite jest najmniej złożonym rodzajem OWL. Służy przede wszystkim do tworzenia hierarchii i prostych ograniczeń.
OWL DL (ang. OWL Description Logic) umożliwia uzyskanie maksymalnej ekspresywności przy
zachowaniu zupełności (tzn. możliwości uzyskania obliczeniowo wszystkich wniosków) i rozstrzygalności (wszystkie obliczenia muszą się zakończyć w skończonym czasie). OWL DL
zawiera wszystkie konstrukcje języka OWL, które jednak mogą być użyte pod określonymi
warunkami.
OWL Full posiada cały język konstruktorów OWL, który można stosować bez żadnych ograniczeń. Niestety przekłada się to na małą efektywność i wydajność. Jest mało prawdopodobne
by jakikolwiek system wnioskujący wspierał całkowicie wnioskowanie dla każdego elementu
OWL Full [MKS04].
Kolejne rodzaje języka można wyróżnić w drugiej wersji OWL (OWL 2). W OWL 2, by upodobnić
składnię do grafu RDF, dodano nowe typy danych oraz, by uprościć zapis, składnię OWL 2 Manchester Syntax i inne konstrukcje językowe. OWL 2 jest w pełni kompatybilny z pierwszą wersją
OWL. Jego trzy rodzaje to:
OWL EL umożliwia wykonanie wnioskowania w czasie wielomianowym. Stąd jest użyteczny
w aplikacjach z bardzo dużą liczbą własności lub klas.
OWL QL jest używany w przypadku małych ontologii z dużą ilością danych oraz kiedy wykonywane są zapytania relacyjne (np. SQL) do danych.
OWL RL stosowany, gdy wymagane jest skalowalne rozstrzyganie, bez poświęcania ekspresywności. Zapewnia użycie algorytmów bazujących na technologiach baz danych rozszerzonych
o reguły w czasie wielomianowym i manipulujące bezpośrednio na trójkach RDF. Systemy
wnioskujące OWL 2 RL mogą być zaimplementowane przy użyciu silników wnioskujących
opartych na regułach.
2.5
SPARQL Protocol And RDF Query Language
SPARQL (ang. SPARQL Protocol And RDF Query Language) jest językiem zapytań i protokołem dla plików RDF, uznanym za standard W3C. Pozwala przeszukiwać dane uwzględniając ich
semantykę poprzez formułowanie zapytań do końcówek (ang. endpoint, processor ), a także umożliwia wybieranie z plików RDF danych określonych kryteriami zawartymi w predykatach RDF.
Język SPARQL jest dostosowany do struktury grafów RDF i opiera się na trójkach, które
je tworzą. W tym różni się od klasycznego SQL stworzonego dla relacyjnych baz danych, ale
wyraźnie inspiruje się nim w składni i funkcjonalnościach. Ewaluacja zapytań SPARQL opiera się
na mechanizmie dopasowania wzorców grafowych.
Dla SPARQL powstał również protokół SPROT (ang. SPARQL Protocol for RDF ), który
opisuje, jak klient SPARQL (np. dostępny przez przeglądarkę) komunikuje się z końcówką SPARQL. Końcówka jest usługą, która przyjmuje i przetwarza zapytania SPARQL, i zwraca wyniki
w różnych formatach w zależności od typu zapytania. Przykładową końcówkę można znaleźć pod
adresem http://dbpedia.org/sparql.
W SPARQL występują cztery typy zapytań:
SELECT zwraca wartości zmiennych związanych w dopasowaniu wzorca zapytania,
CONSTRUCT pozwala na transformację grafów RDF i ontologii OWL,
2.5. SPARQL Protocol And RDF Query Language
23
Tablica 2.5: Struktura zapytania SPARQL. Wyrażenia w nawiasach są opcjonalne,
a złożone pismem pochyłym wymagają wypełnienia przez użytkownika. Źródło:
[Bec05].
opis
prolog (opcjonalnie)
typ zapytania (wymagany dokładnie jeden)
źródła danych (opcjonalnie)
wzorzec grafowy (opcjonalnie,
wymagany dla ASK)
sortowanie wyników (opcjonalnie, tylko z SELECT)
selekcja wyników (opcjonalnie)
schemat zapytania
BASE <iri >
PREFIX prefix : <iri > (może wystąpić wielokrotnie)
SELECT (DISTINCT) ?zmienna1 ?zmienna2 ... ?zmiennaN
SELECT (DISTINCT) *
DESCRIBE ?zmienna1 ?zmienna2 ... ?zmiennaN
DESCRIBE <iri >
DESCRIBE *
CONSTRUCT { wzorzec grafowy }
ASK
FROM (NAMED) <iri > (może wystąpić wielokrotnie)
WHERE { wzorzec grafowy (FILTER wyrażenie) }
ORDER BY lista zmiennych
LIMIT n, OFFSET m
Tablica 2.6: Powszechnie używane przestrzenie nazw RDF. Źródło: [Bec05].
przestrzeń nazw
RDF
Dublin Core
FOAF
Typy danych XML Schema
RDFS
OWL
prefiks
rdf:
dc:
foaf:
xsd:
rdfs:
owl:
URI przestrzeni nazw
http://www.w3.org/1999/02/22-rdf-syntax-ns#
http://purl.org/dc/elements/1.1/
http://xmlns.com/foaf/0.1/
http://www.w3.org/2001/XMLSchema#
http://www.w3.org/2000/01/rdf-schema#
http://www.w3.org/2002/07/owl#
ASK zwraca wartość logiczną określającą, czy wynik zapytania będzie niepusty,
DESCRIBE zwraca graf RDF opisujący znalezione zasoby.
Ogólna struktura zapytania SPARQL znajduje się w tablicy 2.5.
URI przestrzeni nazw zapisywany jest w nawiasach ostrokątnych (<, >). W celu zwiększenia czytelności zapytania poprzez uniknięcie tak długiego łańcucha znakowego, można zastąpić
go identyfikatorem (prefiksem) zadeklarowanym po słowie kluczowym PREFIX, np.: PREFIX rdf:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#> Powszechnie używane przestrzenie nazw znajdują się w tablicy 2.6.
Po słowie kluczowym SELECT następuje ciąg zmiennych, których wartości mają się znaleźć w wyniku zapytania. Zmienne reprezentują zasoby lub typy danych. Ich nazwy poprzedzone są znakami
zapytania (lub rzadziej znakami dolara). Aby wybrać wszystkie zmienne używane w zapytaniu,
zamiast ciągu zmiennych należy wpisać gwiazdkę (*). Użycie modyfikatora DISTINCT zapewnia
unikalność wyników.
GRAPH Operacja dopasowywania grafu działa na jednym grafie RDF. Domyślny graf może być
zmieniony za pomocą słowa kluczowego GRAPH.
Składnia jest następująca:
• GRAPH <uri > { . . . wzorzec grafowy . . . }
• GRAPH ?zmienna { . . . wzorzec grafowy . . . }
Jeśli podany jest identyfikator URI, wzorzec grafowy będzie dopasowywany do zbioru danych o tej nazwie. Jeśli podana jest zmienna, wypróbowywane są wszystkie nazwane grafy
24
(roz. FROM NAMED). Zmienna ta może być użyta także w innym miejscu, więc może się zdarzyć,
że jej wartość będzie już znana i zostanie wypróbowany tylko jeden graf nazwany.
FROM (NAMED) W zapytaniu SPARQL można określić zbiór danych RDF, który będzie użyty
do dopasowania, poprzez użycie klauzuli FROM lub FROM NAMED.
Składnia jest następująca:
• FROM <url > pozwala wskazać dane, które powinny się znaleźć w grafie domyślnym.
• FROM NAMED <url > pozwala zidentyfikować graf nazwany.
Jeśli zapytanie zawiera taki opis zbioru danych, to zbiór ten jest użyty zamiast tego,
którego użyłaby końcówka w przypadku braku takiego opisu w zapytaniu. Zbiór danych
po uwzględnieniu klauzul FROM i FROM NAMED składa się z domyślnego grafu stanowiącego
połączenie grafów z klauzuli FROM oraz ze zbioru par (IRI, graf) - po jednej z każdej klauzuli
FROM NAMED. Jeśli w zapytaniu nie występuje klauzula FROM, natomiast występuje co najmniej
jedna klauzula FROM NAMED, domyślny graf jest pusty.
Zbiór danych RDF może też zostać określony w żądaniu protokołu SPARQL. W tym
przypadku opis w protokole nadpisuje każdy opis w zapytaniu. Końcówka może odrzucić
zapytanie, jeśli opis zbioru danych nie jest akceptowalny.
WHERE Klauzula WHERE definiuje wzorzec grafowy, który będzie dopasowany do danych w repozytorium RDF. Każda linia klauzuli WHERE, podobnie jak trójka RDF, składa się z trzech elementów: podmiotu, predykatu/orzeczenia (własność) i dopełnienia/obiektu (wartość) i musi
być (z wyjątkiem ostatniej) zakończona kropką. Zapis przyjmuje wtedy następującą postać:
a :b c .
e :f g
Jeżeli w obu zapytaniach występuje ten sam podmiot (tzn. a oraz e są tożsame) można
zapisać:
a :b c .
:f g
Jeżeli zaś tożsame są podmiot i relacja (tzn. pary a i b oraz e i f są tożsame) zapis
przyjmuje formę:
a :b c, g .
Puste węzły (inaczej zmienne anonimowe, ang. blank nodes) pozwalają połączyć trójki
bez poświęcania uwagi łączącemu je zasobowi. Mogą być nazwane (nazwę poprzedza znak
podkreślenia i dwukropek : np. :blank) lub nienazwane (oznaczone przez nawiasy kwadratowe). Nienazwane mogą być użyte tylko raz. Nie są uwzględniane w wyniku zapytania
SELECT *.
FILTER W dowolnym miejscu klauzuli WHERE można po słowie kluczowym FILTER umieścić wyrażenie filtrujące - zwrócone będą tylko te wyniki zapytania, dla których będzie ono spełnione.
Przykład: FILTER (xsd:integer(?zmienna)>250)
OPTIONAL Modyfikator OPTIONAL pozwala dodać opcjonalne wiązania. Jeśli zostaną znalezione, zostaną dodane do zbioru wynikowego. W przeciwnym razie jednak żadne wyniki
zapytania nie zostaną usunięte. Klauzule OPTIONAL można umieszczać wewnątrz klauzuli
WHERE.
UNION Wyrażenie UNION pozwala połączyć zbiory wynikowe dla dwóch wzorców grafowych.
Przykład: WHERE { { . . . wzorzec grafowy . . . } UNION { . . . wzorzec grafowy . . . } }
ORDER BY Modyfikator ORDER BY umożliwia sortowanie wyników zapytania (ma to sens tylko
w przypadku typu zapytania SELECT, gdyż tylko wynik takiego zapytania da się posortować). Domyślnie jest to sortowanie rosnące (czyli w przypadku łańcuchów znakowych - alfabetyczne), użycie modyfikatora DESC(?zmienna) pozwala na sortowanie malejące.
Przykład: ORDER BY ?zmienna1 DESC(?zmienna2)
2.5. SPARQL Protocol And RDF Query Language
25
OFFSET, LIMIT W przypadku bardzo dużego zbioru wynikowego, przydatne jest jego podzielenie na mniejsze części. Umożliwiają to modyfikatory OFFSET i LIMIT, dzięki którym można
wyświetlić określony wycinek zbioru wynikowego. Użycie tych modyfikatorów wymaga posortowania wyników zapytania za pomocą ORDER BY w celu zapewnienia powtarzalności wyników. OFFSET to liczba pominiętych początkowych wyników, a LIMIT to liczba wyników,
które mają być zwrócone.
Przykład: LIMIT 10, OFFSET 110
Słowa kluczowe są często pisane dużymi literami, choć wielkość liter nie ma znaczenia. Linie
rozpoczęte znakiem # są traktowane jako komentarze.
Przykład zapytania SPARQL znajduje się poniżej:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX ont: <http://dbpedia.org/ontology/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT DISTINCT *
WHERE {
{
_:blank1 foaf:name ?nazwa ;
ont:abstract ?opis
}
UNION
{
_:blank1 foaf:name ?nazwa ;
rdfs:comment ?opis
}
}
Wzorzec grafowy w klauzuli WHERE jest zdefiniowany za pomocą wyrażenia UNION. Pierwsza
część wyrażenia UNION oznacza: pusty węzeł :blank1 ma nazwę (name) ?nazwa w sensie ontologii
FoaF oraz opis (abstract) ?opis w sensie ontologii http://dbpedia.org/ontology/ . Do zbioru
wynikowego odpowiadającego temu wzorcowi grafowemu zostanie dołączony drugi, pochodzący
z drugiej części wyrażenia UNION. Tutaj jako opis jest traktowana właśność comment w ontologii
RDFS. Modyfikator DISTINCT zapewnia unikalność wyników. W zbiorze wynikowym, pomimo
użycia SELECT *, nie ma informacji o pustych węzłach.
Warto zauważyć, że SPARQL w obecnej wersji nie posiada mechanizmów agregacji wyników
zapytań, takich jak GROUP BY w SQL.
Rozdział 3
Wykorzystane oprogramowanie
3.1
Pellet
Pellet jest narzędziem do wnioskowania w OWL DL dla języka Java [Pel]. Umożliwia manipulowanie danymi w języku RDF oraz ontologiami w języku OWL DL. W połączeniu z biblioteką
Jena (roz. 3.1.3) lub OWL API, pozwala na obsługę zapytań w języku SPARQL. Ponadto, Pellet
umożliwia sprawdzanie spójności ontologii, obliczanie hierarchii klasyfikacji i uzasadnianie wyników wnioskowania. Pellet został zaimplementowany w języku Java i jest udostępniony na licencji
typu open-source. Jest opracowany i komercyjnie wspierany przez Clark & Parsia LLC.
3.1.1
Metoda tabel semantycznych
Mechanizm działania systemu Pellet opiera się na metodzie tabel semantycznych.
W rachunku zdań służy ona do badania spełnialności (a przez dualność także prawdziwości) formuł [BA05]. Polega na systematycznym poszukiwaniu modelu (interpretacji spełniającej formułę).
Problem spełnialności formuły zostaje zredukowany do problemu spełnialności zbiorów literałów.
Zbiór literałów jest spełnialny wtedy i tylko wtedy, gdy nie zawiera pary literałów komplementarnych. Do zapamiętywania wartości przypisywanych poszczególnym podformułom w metodzie
tabel semantycznych wykorzystywane są drzewa. Pierwotna formuła zostaje umieszczona w korzeniu, a zbiory formuł powstałe w trakcie analizy - w wewnętrznych wierzchołkach drzewa. Liście
zawierają zbiory literałów, które powinny być spełnione. Liście, które nie zawierają zbioru literałów komplementarnych są oznaczane przez , a liście zawierające taki zbiór - przez ×. Formuły
stanowiące koniunkcje podformuł nazywane są formułami typu α, zaś formuły stanowiące alternatywy podformuł - formułami typu β . Do formuł typu α stosuje się reguły typu α, a do formuł
typu β - reguły typu β (tablica 3.1).
Tablica 3.1: Reguły typu α i β w metodzie tabel semantycznych [BA05].
α
¬¬A1
A1 ∧ A2
¬(A1 ∨ A2 )
¬(A1 → A2 )
¬(A1 ↑ A2 )
A1 ↓ A2
A1 ↔ A2
¬(A1 ⊕ A2 )
α1
A1
A1
¬A1
A1
A1
¬A1
A1 → A2
A1 → A2
α2
β
β1
β2
A2
¬A2
¬A2
A2
¬A2
A2 → A1
A2 → A1
¬(B1 ∧ B2 )
B1 ∨ B2
B1 → B2
B1 ↑ B2
¬(B1 ↓ B2 )
¬(B1 ↔ B2 )
B1 ⊕ B2
¬B1
B1
¬B1
¬B1
B1
¬(B1 → B2 )
¬(B1 → B2 )
¬B2
B2
B2
¬B2
B2
¬(B2 → B1 )
¬(B2 → B1 )
28
Definicja 3.1 (Algorytm tworzenia tabel semantycznych).
Wejście: Formuła rachunku zdań A.
Wyjście: Tabela semantyczna T dla A, której wszystkie liście są oznakowane.
Tabela semantyczna T dla formuły A jest drzewem, którego każdy wierzchołek zawiera zbiór
formuł. Początkowo T składa się z pojedynczego wierzchołka (korzenia) zawierającego zbiór jednoelementowy A. Tworzenie tabeli semantycznej przebiega iteracyjnie przez wybór nieoznakowanego
liścia l zawierającego zbiór formuł U(l) i zastosowanie jednej z następujących reguł. Proces tworzenia kończymy, gdy wszystkie liście zostaną oznakowane przez × lub .
• Jeśli U(l) jest zbiorem literałów, to sprawdź, czy zawiera on parę literałów komplementarnych.
Jeśli tak, to oznakuj ten liść jako domknięty × ; a jeśli nie zawiera, to oznakuj go jako
otwarty .
• Jeśli U(l) nie jest zbiorem literałów, to wybierz dowolną formułę z tego zbioru nie będącą
literałem.
– Jeśli formuła jest typu α, to utwórz nowy wierzchołek l’ jako potomka wierzchołka
l i umieść w nim zbiór formuł:
U (l0 ) = (U (l) − {α}) ∪ {α1 , α2 }.
(3.1)
Jeśli formuła α jest postaci ¬¬A1 , to nie ma formuły α2 .
– Jeśli formuła jest typu β, to utwórz dwa nowe wierzchołki l’ oraz l” jako potomki
wierzchołka l. W wierzchołku l’ umieść zbiór formuł:
U (l0 ) = (U (l) − {β}) ∪ {β1 }
(3.2)
a w wierzchołku l”:
U (l0 ) = (U (l) − {β}) ∪ {β2 }
(3.3)
Algorytm ten jest niedeterministyczny, ponieważ w każdym jego kroku dokonuje się wyboru liścia
oraz wyboru formuły do przetworzenia ze zbioru formuł znajdujących się w tym liściu [BA05].
W logikach deskrypcyjnych metoda tabel semantycznych wykorzystywana jest do badania spełnialności pojęć.
Aby sprawdzić spełnialność pojęcia D, podstawowy algorytm inicjalizuje drzewo zawierające
pojedynczy wierzchołek x (zwany korzeniem) z L(x) = {D}. Następnie rozwija drzewo, stosując
reguły, które rozwijają etykiety węzłów bądź dodają nowe węzły - liście. Zbiór reguł rozwijania dla
logiki deskrypcyjnej ALC pokazano w tablicy 3.2, gdzie C i D są pojęciami, a R jest rolą. Należy
zauważyć, że:
• Zakłada się, że pojęcia są w negacyjnej postaci normalnej (negacje tylko przy nazwach pojęć).
Arbitralne pojęcia ALC mogą być przekształcone do negacyjnej postaci normalnej, przez
przesunięcie negacji do środka, przy użyciu połączenia praw De Morgana i równoważności
¬(∃R.C) ⇐⇒ (∀R.¬C) oraz ¬(∀R.C) ⇐⇒ (∃R.¬C). Ta procedura może być rozszerzona
do bardziej ekspresywnych logik przez zastosowanie dodatkowych równoważności takich jak
¬(¬ nR) ⇐⇒ ( (n + 1)R).
• Rozłączne pojęcia (C t D) ∈ L(x) powodują niedeterministyczne rozwijanie. W praktyce jest
to zazwyczaj rozwiązywane przez wypróbowywanie każdego możliwego rozwinięcia z kolei,
aż do znalezienia w pełni rozwiniętego drzewa bez konfliktów lub wykazania, że wszystkie
możliwości prowadzą do sprzeczności. W bardziej ekspresywnych logikach inne wyrażenia,
takie jak ograniczenie maksymalnej liczby (¬ n R), także prowadzą do niedeterministycznego
rozwijania.
29
3.1. Pellet
reguła u
reguła t
jeśli 1.
2.
to
jeśli 1.
2.
to
reguła ∃
jeśli 1.
2.
to
reguła ∀
jeśli 1.
2.
to
(C u D) ∈ L(x)
{C, D} * L(x)
L(x) −→ L(x) ∪ {C, D}
(C t D) ∈ L(x)
{C, D} ∩ L(x) = ∅
albo L(x) −→ L(x) ∪ {C}
albo L(x) −→ L(x) ∪ {D}
∃R.C ∈ L(x)
@y : L(< x, y >) = R ∧ C ∈ L(y)
stwórz nowy węzeł y i krawędź < x, y >
z L(y) = {C} i L(< x, y >) = R
∀R.C ∈ L(x)
∃y : L(< x, y >) = R ∧ C ∈
/ L(y)
L(y) −→ L(y) ∪ {C}
Tablica 3.2: Reguły rozwijania tabel dla ALC. Źródło: [Baa03].
• Pojęcia egzystencjalnych ograniczeń roli ∃R.C ∈ L(x) powodują stworzenie nowych węzłów,
następników R, a pojęcia uniwersalnych ograniczeń roli ∀R.C ∈ L(x) rozwijają etykiety
następników R.
Drzewo jest w pełni rozwinięte, kiedy żadna z reguł rozwijania nie może być zastosowana.
Jeśli można znaleźć w pełni rozwinięte drzewo bez konfliktów, badane pojęcie jest spełnialne,
w przeciwnym razie - niespełnialne [Baa03].
3.1.2
Funkcje i możliwości
Poniższy opis funkcji i możliwości systemu Pellet powstał na podstawie [SPG+ 07].
Koniunkcyjne zapytania ABox Pellet zawiera mechanizm zapytań, który może efektywnie odpowiadać na koniunkcyjne zapytania ABox wyrażone w języku SPARQL lub RDQL . W przypadku wystąpienia zmiennych egzystencjalnych w zapytaniu, użyta jest technika rolowania,
aby odpowiedzieć na zapytania w kształcie drzewa. W przeciwnym razie, na każdy atom
zapytania końcówka może odpowiedzieć oddzielnie i mogą być obsłużone zapytania o dowolnym kształcie. Dla takich zapytań, dwoma czynnikami wpływającymi na obsługę zapytania są liczba atomów w zapytaniu i kolejność, w jakiej są one ewaluowane. Pellet stosuje
dwie techniki optymalizacji dla tych przypadków: upraszczanie zapytania, czyli znajdowanie nadmiarowych atomów w zapytaniu używając aksjomatów dotyczących dziedziny bądź
przeciwdziedziny oraz reorganizację zapytania, czyli sortowanie atomów zapytania, używając
zrandomizowanej techniki próbkowania, jak przyjęto w relacyjnych bazach danych.
Wnioskowanie z typami danych Pellet stosuje podejście systemu typów do wspierania wnioskowania z typami danych. W szczególności, Pellet posiada wyrocznię typów danych, która
może wnioskować z typami danych bazującymi na XML Schema. Wyrocznia typów danych
może sprawdzać spójność powiązań (wbudowanych lub pochodnych) typów danych XML
Schema. Pellet wspiera typy zdefiniowane przez użytkownika w oparciu o typy numeryczne
lub reprezentujące czas, więc, na przykład, przedziały numeryczne lub czasowe mogą być
zdefiniowane i używane jako nowe typy danych.
Wskazywanie aksjomatów i wyszukiwanie błędów Wskazywanie aksjomatów jest rozszerzeniem wnioskowania logik deskrypcyjnych, która dostarcza uzasadnienie dla dowolnej implikacji uzyskanej przez system wnioskujący z bazy wiedzy OWL DL. Dla danej ontologii
i wszystkich jej logicznych konsekwencji, opcja wskazywania aksjomatów określa przesłanki
w bazie wiedzy, które są wystarczające, aby zaszła dana konkluzja. Takie uzasadnienie jest
30
przydatne do zrozumienia wyniku wnioskowania, które jest kluczowe dla wielu zadań, np.
w wyszukiwaniu błędów, projektowaniu i ewolucji ontologii.
Wskazywanie aksjomatów jest osiągane poprzez śledzenie, jak oryginalne źródłowe aksjomaty z ontologii są modyfikowane i używane podczas stosowania metody tabel semantycznych. W rezultacie, kiedy wykryta jest niespójność w ontologii, można określić, który
konkretny zbiór aksjomatów powoduje problem.
Integracja z formalizmem reguł Pellet razem z systemem wnioskującym w języku Datalog
implementują framework AL-Log do łączenia logik deskrypcyjnych z regułami. AL-Log łączy
Datalog i logiki deskrypcyjne, pozwalając na użycie klas logik deskrypcyjnych w ciele reguły.
Pellet ma także eksperymentalną implementację bezpośredniej metody tabel semantycznych
dla integrowania DL-bezpiecznych reguł z SHOIQ(D).
Wnioskowanie z wieloma ontologiami przy użyciu E-Connections Oprócz
mechanizmu
owl:imports, Pellet wykorzystuje nową technikę łączenia ontologii opartą na E-Connections
do wnioskowania z wieloma ontologiami. E-Connections jest ogólnym frameworkiem do łączenia poszczególnych rodzin logik rozstrzygalnych.
Wnioskowanie niemonotoniczne W ramach rozwijania logik niemonotonicznych udawało się
z powodzeniem uchwycić różne formy wnioskowania zdroworozsądkowego i bazodanowego.
Znaczna rodzina formalizmów niemonotonicznych bazuje na różnych formach założenia o zamkniętości świata. Logika deskrypcyjna ALCK dodaje niemonotoniczny operator K do logiki
deskrypcyjnej ALC, aby umożliwić „włączenie” założenia o zamkniętości świata, kiedy jest
to potrzebne. Wnioskowanie dla języka ALCK zostało w Pellecie zaimplementowane, aby
odpowiadać przy założeniu o zamkniętości świata na zapytania używające operatora K.
3.1.3
Jena
Jena jest frameworkiem dla języka Java, który oferuje API (ang. Application Programming
Interface) umożliwiające tworzenie i przetwarzanie grafów RDF, dostęp do ontologii i przetwarzanie
słowników, a ponadto dostarcza narzędzi takich jak parser RDF/XML, język zapytań RDQL,
moduły wejścia wyjścia dla N3, N-triple i RDF/XML [CDD+ 03]. Jena umożliwia wnioskowanie na
danych, zapewniając dostęp do interfejsu programowania, który pozwala konfigurować mechanizmy
wnioskujące dla języków OWL i RDFS oraz wspomaganie reguł. Pozwala również na dołączenie
zewnętrznego mechanizmu wnioskowania (np. Pellet).
Pellet zawiera zoptymalizowany mechanizm zapytań, mogący odpowiadać na zapytania ABox.
Jest on dostępny bezpośrednio przez API zdefiniowane w pakiecie org.mindswap.pellet.query.
Został także zintegrowany z wiązaniami Jena Pellet dzięki czemu obiekty zapytań Jena mogą być
z nim używane. Jeśli zapytanie nie jest zapytaniem ABox, mechanizm zapytań systemu Pellet nie
znajduje zastosowania i zostaje użyty domyślny mechanizm zapytań Jena [Pel].
3.2
Semantic Similarity Measures Library
SeSiL (ang. Semantic Similarity Measures Library) jest biblioteką powstającą od 2010 roku
na Politechnice Poznańskiej w ramach 7. Projektu Ramowego Unii Europejskiej e-LICO (An eLaboratory for Interdisciplinary Collaborative Research in Data Mining and Data-Intensive Science).
Jej celem jest stworzenie zbioru funkcji mających za zadanie określać stopień podobieństwa między
indywiduami opisanymi za pomocą ontologii.
31
3.2. Semantic Similarity Measures Library
3.2.1
Podstawy teoretyczne
Funkcje podobieństwa implementowane dotychczas przez SeSiL są funkcjami jądrowymi, zdefiniowanymi poniżej [STC04].
Definicja 3.2 (wektor). Dane jest ciało skalarów (R, +, ·). Wektorem n-elementowym nazywa się
element zbioru Rn . Oznaczając v, w ∈ Rn , v = (v1 , v2 , . . . , vn ), w = (w1 , w2 , . . . , wn ), α ∈ R
Wtedy:
v + w = (v1 + w1 , v2 + w2 , . . . , vn + wn )
(3.4)
α · v = αv = (αv1 , αv2 , . . . , αvn )
(3.5)
Zauważmy, że (Rn , +, ·) stanowi przestrzeń liniową nad ciałem liczb rzeczywistych.
Definicja 3.3 (iloczyn skalarny). Niech dane będą dwa n elementowe wektory x = (x1 , x2 , . . . , xn )
oraz y = (y1 , y2 , . . . , yn ), przy czym x, y ∈ Rn . Przez iloczyn skalarny hx, yi rozumie się liczbę
hx, yi =
n
X
xi yi
(3.6)
i=1
Niech dane będą pary (x1 , y1 ), (x2 , y2 ), . . . , (xl , yl ), przy czym xi ∈ Rn (dla i = 1, 2, . . . , n).
Dany jest następujący problem: skonstruować funkcję liniową g(x) = hw, xi, która w sposób możliwe dokładny przybliża wartości y1 , y2 , . . . , yl odpowiednio dla wektorów x1 , x2 , . . . , xl , to znaczy
∀i = 1, 2, . . . , l : |yi − g(xi )| ≈ 0
(3.7)
Oczywiście relacja ≈ nie jest precyzyjnie zdefiniowana, więc powyższe zadanie przedstawia się
w postaci problemu optymalizacyjnego, używając sumy kwadratów różnic jako prostego w obliczeniu i różniczkowalnego odpowiednika wartości bezwzględnej.
min
l
X
(yi − g(xi ))2
(3.8)
i=1
Powyższe sformułowanie ma jednak tę wadę, że otrzymany wektor wag w może mieć wysokie
(a więc potencjalnie niekorzystne) numerycznie wartości.
Definicja 3.4 (regresja grzbietowa). Regresją grzbietową (ang. ridge regression) nazywa się zadanie optymalizacji następującego wyrażenia:
2
min λ |w| +
w
l
X
(yi − hw, xi i)2
(3.9)
i=1
przy czym λ oznacza relację ważności pomiędzy wartościami występującymi w wektorze wag,
a jakością przybliżenia.
Powyższe zagadnienie łatwo jest rozwiązać obliczając pochodne po elementach wektora w i szukając ich miejsc zerowych. Oznaczając przez X macierz l×n, w której kolejnym wierszom odpowiadają kolejne wektory xi , przez G macierz l × l, w której Gi,j = hxi , xj i, a przez y = (y1 , y2 , . . . , yl )
można wykazać, że:
w = X T (G + λI l )−1 y
(3.10)
gdzie I l oznacza macierz jednostkową typu l × l. Wracając do pierwotnego problemu otrzymuje
się:
g(x) = hw, xi = y T (G + λI l )−1 k
(3.11)
32
dla k będącego wektorem l-elementowym, w którym ki =< xi , x >.
Niezwykle istotny jest fakt, że otrzymane przedstawienie funkcji g(x) w złożoności obliczeń
zależy głównie od l. Jedynym miejscem, gdzie występuje n jest obliczanie wektora k. Jeżeli jednak
znajdzie się efektywny sposób liczenia zarówno macierzy G, jak i wektora k otrzyma się narzędzie,
które umożliwi rozwiązywanie problemu aproksymacji dla dowolnie wysokich wymiarów.
Można wykorzystać tę informację do wyszukiwania nieliniowych zależności między pewnymi danymi przez przeniesienie ich do pewnej przestrzeni (być może bardzo wysokiego wymiaru), w której
te zależności okażą się liniowe. Przykład takiego odwzorowania znajduje się na rysunku 3.1. Należy
zauważyć również, że do rozwiązania problemu wyszukania liniowej zależności (obliczenia funkcji
g(x)) wcale nie jest konieczna znajomość tej przestrzeni, ani bezpośrednich odwzorowań danych.
Jedyne, co trzeba umieć obliczyć to wartość iloczynu skalarnego między dwoma obiektami w tej
przestrzeni, które są niezbędne do obliczenia G i k.
Rysunek 3.1: Odwzorowanie pomiędzy przestrzenią oryginalną, a przestrzenią cech.
Źródło: [STC04]
Definicja 3.5 (funkcja jądrowa). Jądro jest to funkcja κ taka, że
∀x, z ∈ Rn : κ(x, z) = hφ(x), φ(z)i
(3.12)
Przez φ(x) oznacza się funkcję odwzorowującą wektory z pierwotnej przestrzeni Rn do pewnej
innej przestrzeni Rm .
W pracy rozważa się problem grupowania wyników (analizy skupień), dla którego kluczowa jest
możliwość obliczenia odległości pomiędzy dwoma obiektami. Łatwo pokazać, że do jej obliczenia
również wystarczy znajomość wartości iloczynu skalarnego:
2
|x − z| =
n
X
i=1
(xi −zi )2 =
n
X
i=1
(x2i +zi2 −2xi zi ) =
n
X
i=1
x2i +
n
X
i=1
zi2 −
n
X
2xi zi = hx, xi+hz, zi−2 hx, zi
i=1
(3.13)
33
3.2. Semantic Similarity Measures Library
3.2.2
Opis biblioteki
Przyjmijmy, że a, b ∈ ABox (to znaczy, że a i b są indywiduami) oraz O = (TBox, ABox) jest
bazą wiedzy. Biblioteka SeSiL w aktualnej wersji posiada zaimplementowane następujące funkcje
jądrowe:
Normalisation Jest to funkcja jądrowa przekształcająca daną funkcję k(x, y) w funkcję o przeciwdziedzinie [0, 1] zgodnie ze wzorem [BS07]:
k 0 (a, b) = p
k(a, b)
(3.14)
k(a, a)k(b, b)
Gaussian Również jest to funkcja przekształacająca inną, poprawną funkcję jądrową k(x, y) zgodnie ze wzorem [BS07]:
k(a, a) − 2k(a, b) + k(b, b)
0
k (a, b) = exp −
2σ 2
σ ∈ R+
(3.15)
gdzie:
σ jest pewnym parametrem.
Identity [BS07]
k(a, b) =

1
O |= a = b
0
w przeciwnym przypadku
(3.16)
CommonClasses [BS07] Niech:
C(a, b) = {C ∈ TBox : O |= C(a) ∧ O |= C(b)}
(3.17)
wtedy:
k(a, b) = |C(a, b)|
(3.18)
Zaimplementowana jest również postać ważona, wykorzystująca funkcję µ : TBox → R
k(a, b) =
X
µ(C)
(3.19)
C∈C(a,b)
DataProperty Niech PD oznacza zbiór wszystkich relacji, które jako przeciwdziedzinę mają literały (np. wartości numeryczne, łańcuchy znaków), a nie indywidua [BS07]. Wtedy:
k(a, b) =
X
X
X
kp (d, e)
(3.20)
p∈PD {d : O|=p(a,d)} {e : O|=p(b,e)}
przy czym obowiązkiem użytkownika biblioteki jest dostarczyć poprawną funkcję jądrową kp
porównującą literały. Informacje o takich funkcjach można znaleźć np. w [STC04].
ObjectProperty Niech PO oznacza zbiór wszystkich relacji, które jako przeciwdziedzinę mają
indywidua [BS07]. Wtedy:
k(a, b) =
X
X
X
kp (d, e)
(3.21)
p∈PO {d : O|=p(a,d)} {e : O|=p(b,e)}
przy czym funkcja kp musi być inną, poprawną funkcją jądrową porównującą indywidua.
BariEpistemic Jest to funkcja parametryzowana liczbą p ∈ R+ oraz opcjonalnie zbiór pojęć
F = {F1 , F2 , . . . , Fm } (w przypadku jego braku wykorzystywany jest cały dostępny TBox)
34
[dFE08].
! p1
m
1 X
p
k(a, b) =
|σi (a, b)|
m i=1



1 (O |= Fi (a) ∧ O |= Fi (b)) ∨ (O |= ¬Fi (a) ∧ O |= ¬Fi (b))


σi (a, b) = 0 (O |= Fi (a) ∧ O |= ¬Fi (b)) ∨ (O |= ¬Fi (a) ∧ O |= Fi (b))



 1 w pozostałych przypadkach
2
(3.22)
(3.23)
BariALC Ta funkcja jądrowa przystosowana jest wyłącznie do języków nie bardziej skomplikowanych niż ALC [Fd06].
Definicja 3.6 (koniunkcyjna postać pół-normalna). Pojęcie C jest w koniunkcyjnej postaci
pół-normalnej, jeżeli zachodzi jedno z poniższych:
1. C ≡ >
2. C ≡ ⊥
3. C = C1 u C2 u . . . u Cn i każde z pojęć Ci jest w jednej z następujących postaci:
a) Ci jest pojęciem atomowym lub negacją pojęcia atomowego;
b) Ci jest w postaci ∀R.D dla pewnej relacji R i pojęcia D, a przy tym nie istnieje Cj
(j 6= i) w postaci ∀R.D0 , gdzie D0 jest pojęciem niekoniecznie różnym od D;
c) Ci jest w postaci ∃R.D dla pewnej relacji R i pojęcia D.
Zauważmy, że zachodzą następujące prawa:
• ∀R.C u ∀R.D ≡ ∀R.(C u D)
• ¬∀R.C ≡ ∃R.(¬C)
• ¬∃R.C ≡ ∀R.(¬C)
Wykorzystując powyższe prawa można przekształcić dowolne wyrażenie postaci C = C1 u
C2 u . . . u Cn do koniunkcyjnej postaci pół-normalnej. Niech C będzie wyrażeniem w tej
postaci. Oznaczmy:
•
prim(C) = {Ci |i = 1, 2, . . . , n ∧ (3a)}
(3.24)
• valR (C) = D, przy czym zachodzi Ci = ∀R.D dla pewnego i oraz Ci spełnia 3b.
•
exR (C) = {D|∃i = 1, 2, . . . , n : Ci ≡ (∃R.D)}
(3.25)
NR (C) = {R|∃i = 1, 2, . . . , n : ∃D : [Ci ≡ (∃R.D) ∨ Ci ≡ (∀R.D)]}
(3.26)
•
Definicja 3.7 (postać normalna). Pojęcie C jest w postaci normalnej, jeżeli zachodzi jedno
z poniższych:
• C=>
• C=⊥
•
C = D1 t D2 t . . . t Dn
(3.27)

Di =
l
P ∈prim(Di )
P u
l
R∈NR (Di )
∀R.valR (Di ) u

l
∃R.E 
i = 1, 2, . . . , n
E∈exR (Di )
(3.28)
i przy tym wszystkie wyrażenia występujące pod kwantyfikatorami są w postaci normalnej.
35
3.3. Google Web Toolkit
Definicja 3.8 (funkcja jądrowa ALC dla pojęć). Niech dane będą dwa pojęcia w postaci
Fm
Fn
normalnej C1 = i=1 Di1 , C2 = i=1 Di2 i interpretacja I. Przez funkcję jądrową ALC dla
I
pojęć rozumie się funkcję kt
(C1 , C2 ) zdefiniowaną poniżej. λ ∈ [0, 1] jest parametrem [Fd06].
I
kt
(C1 , C2 )
=λ
m X
n
X
I
ku
(Di1 , Dj2 )
(3.29)
i=1 j=1
Y
I
ku
(D1 , D2 ) =
I
kA
(Pi1 , Pj2 )·
Pi1 ∈prim(D 1 )
Pj2 ∈prim(D 2 )
Y
I
kt
(valR (D1 ), valR (D2 ))·
(3.30)
R∈NR (D 1 )∩NR (D 2 )
Y
X
I
kt
(Ei1 , Ej2 )
R∈NR (D 1 )∩NR (D 2 ) Ei1 ∈exR (D 1 )
Ej2 ∈exR (D 2 )
I
kA
(P1 , P2 ) = P1I ∩ P2I (3.31)
Definicja 3.9 (najbardziej specyficzne pojęcie). Niech dany będzie ABox i należące do niego
indywiduum a. Najbardziej specyficznym pojęciem (ang. msc - most specific concept) nazywa
się pojęcie C takie, że:
ABox |= C(a) ∧ ∀D : (ABox |= D(a) → C v D)
(3.32)
Dla niektórych języków, w tym dla języka ALC najbardziej specyficzne pojęcie nie zawsze może być wyznaczone w sposób dokładny, dlatego wykorzystuje się przybliżenie msc∗
wyznaczane zgodnie z poniższą definicją, podaną w [d’A07] oraz [Ian06].
Dla danego ABox oznaczmy:
CA(a) = {C |ABox |= C(a)}
(3.33)
IR(a) = {R |∃b : ABox |= R(a, b)}
(3.34)
RFR (a) = {b |ABox |= R(a, b)}
(3.35)
Definicja 3.10 (algorytm wyznaczania msc∗ ). Niech dany będzie pewien ABox i należące
do niego indywiduum a. Wtedy msc∗ (a) wyznacza się zgodnie z poniższymi zależnościami:
msc∗ (a) = msc∗ (a, ∅)
l
msc∗ (a, S) =
C u
C∈CA(a)
msc0 (a, S) =
l
(3.36)
l
∃R.msc0 (a, S)u
R∈IR(a)
b∈RFR (a)\S
l
∃R.>
R∈IR(a)
b∈RFR (a)∩S
msc∗ (b, S ∪ {a, b})
(3.37)
(3.38)
b∈RFR (a)
Warto zauważyć, że msc∗ generuje pojęcia w postaci normalnej.
Definicja 3.11 (funkcja jądrowa ALC dla indywiduów). Niech dane będą dwa indywidua
a, b należące do pewnego ABox, będącego elementem interpretacji I. Wtedy:
I
k(a, b) = kt
(msc∗ (a), msc∗ (b))
3.3
3.3.1
(3.39)
Google Web Toolkit
Informacje ogólne
Google Web Toolkit (GWT ) jest to framework służący do tworzenia aplikacji uruchamianych
w przeglądarce internetowej. Aplikacje z wykorzystaniem GWT tworzy się w języku Java z zastosowaniem paradygmatu MVC (ang. Model View Controller ), przedstawionego na rysunku 3.2.
36
W procesie kompilacji z wspólnego kodu w języku Java powstają dwie odrębne kategorie modułów:
Klienckie składające się z kodu HTML oraz procedur JavaScript. Są one uruchamiane w przeglądarce użytkownika i tworzą warstwę prezentacji (ang. View ) oraz kliencką część warstwy
sterownika (ang. Controller ).
Serwerowe uruchamiane na serwerze aplikacji jako serwlety Java lub przy wykorzystaniu Google
Apps Engine na serwerach firmy Google. Zajmują się one przetwarzaniem danych tworząc
systemową część warstwy sterownika oraz warstwę modelu (Model ).
Client Side Controller Server Side
View
Model
Rysunek 3.2: Podział Model-View-Controler w GWT
3.3.2
Widgety
Graficzna część aplikacji w GWT tworzona jest z gotowych komponentów (widgetów ). W efekcie pisanie aplikacji internetowej nie różni się znacząco od tworzenia aplikacji z wykorzystaniem
standardowego pakietu Swing.
Widgety dostępne w GWT :
• Button, PushButton – przyciski,
• RadioButton – przyciski opcji,
• CheckBox – przyciski wyboru,
• DatePicker – narzędzie wyboru daty,
• ToggleButton – przełączniki,
• TextBox – jednolinijkowe pole tekstowe,
• PasswordTextBox – pole tekstowe maskujące tekst,
• TextArea – obszar edycyjny,
• RichTextArea – obszar edycyjny z zaawansowanym formatowaniem,
• Hyperlink – odnośnik,
• ListBox – lista wyboru,
• MenuBar – pasek menu,
• Tree – widok drzewa,
• Table – tabela,
• TabBar – przełączane zakładki,
• DialogBox – okno dialogowe.
37
3.3. Google Web Toolkit
3.3.3
Struktura GUI
Struktura GUI opiera się o spotykane również w innych bibliotekach panele. Programista nie
opisuje położenia każdego komponentu lecz umieszcza je w drzewiastej strukturze kontenerów o korzeniu com.google.gwt.user.client.ui.RootPanel. Zależnie od użytych paneli i ich ustawień
silnik aplikacji dostosowuje wyświetlanie widgetów tak, aby optymalnie rozmieścić je na ekranie.
Dostępne w GWT panele:
• PopupPanel,
• StackPanel,
• StackLayoutPanel,
• HorizontalPanel,
• VerticalPanel,
• FlowPanel,
• VerticalSplitPanel,
• HorizontalSplitPanel,
• SplitLayoutPanel,
• DockPanel,
• DockLayoutPanel,
• TabPanel,
• TabLayoutPanel,
• DisclosurePanel,
Ich wzajemne powiązania przedstawione są na rysunku 3.3.
RootPanel
Lorem ipsum
Curabitur sollicitudin,
ipsum quis suscipit
consequat, leo
neque ornare lorem,
nec congue eros
libero sed lorem.
Ut ut urna nec erat
pulvinar ultricies.
In auctor
pellentesque massa,
sit amet tincidunt elit
varius eget.
HorizontalPanel
Btn1
Btn2
VerticalPanel
TextBox
HorizontalPanel
TextArea
Button
Button
Rysunek 3.3: Układ paneli i widgetów oraz odpowiadające im drzewo.
3.3.4
Komunikacja klient-serwer
Komunikacja pomiędzy częścią serwerową i częścią kliencką aplikacji odbywa się w formie zdalnego wywołania procedury (ang. RPC - remote procedure call ) oraz asynchronicznych wywołań
zwrotnych (ang. asynchronous callback ).
Typowo, komunikacja inicjalizowana jest przez GUI na skutek akcji użytkownika. Wywoływana
jest zdalnie procedura serwera, po czym zależnie od potrzeb, GUI czeka na odpowiedź lub pracuje
dalej. Po zakończeniu przetwarzania serwer przekazuje jego wynik klientowi.
Niskopoziomowo implementacja realizowana jest przez żądania HTTP. Wywołania klient-serwer
są proste: klient wysyła klasyczne żądanie HTTP. Wywołania serwer-klient zrealizowane są przez
długo aktywne połączenia: na początku pracy klient nawiazuje połączenie z serwerem, wysyła żądanie HTTP i czeka asynchronicznie na odpowiedź. W momencie gdy serwer chce przesłać dane,
wysyła je w odpowiedzi na to żądanie, a klient natychmiast wysyła kolejne.
38
3.4
Serwlety HTTP
Serwlety Java to technologia dostarczania danych na potrzeby aplikacji internetowych. W paradygmacie MVC można z ich wykorzystaniem zbudować model oraz kontroler.
Servlet HTTP jest to klasa pochodna po javax.servlet.http.HttpServlet implementująca
zależnie od potrzeb metody doGet i doPost, odpowiadające na żądania GET i POST protokołu
HTTP. Serwlety uruchamiane są przez serwer aplikacji, czyli serwer HTTP zajmujący się obsługą
połączeń sieciowych, połączeń z bazą danych, parsowaniem żądań HTTP i przekazywaniem ich do
odpowiednich serwletów.
Rozdział 4
Specyfikacja
4.1
Przypadki użycia
UC1. Przetworzenie zapytania użytkownika
Scenariusz główny
1. Użytkownik specyfikuje zapytanie i powiązane z nim dane.
2. Dane przechowywane przez użytkownika lokalnie zostają przesłane na serwer.
3. Zapytanie jest przetwarzane zgodnie z UC3.
4. Wyniki są prezentowane użytkownikowi.
Rozszerzenia
1a. Użytkownik wybiera jedno z predefiniowanych zapytań.
UC2. Przetworzenie zapytania automatycznego
Scenariusz główny
1. Zdalny klient łączy się z końcówką SPARQL.
2. Zapytanie i dane są dostarczane zgodnie z protokołem SPROT.
3. Zapytanie jest przetwarzane zgodnie z UC3.
4. Wynik jest serializowany zgodnie z protokołem SPROT.
5. Wynik jest odsyłany do użytkownika.
6. Połączenie jest zamykane.
UC3. Przetworzenie zapytania
Scenariusz główny
1. Dane dostępne on-line zostają ściągnięte z Internetu.
2. Jest wykonywane zapytanie.
3. Obliczane jest podobieństwo między wynikami zapytania.
4. Wyniki zapytania są grupowane zgodnie z wybranym algorytmem.
Rozszerzenia
1a. Nie udało się ściągnąć danych.
a) Użytkownik jest informowany o błędzie.
b) Koniec przypadku użycia.
2a. Nie udało się wykonać zapytania.
a) Użytkownik jest informowany o błędzie.
b) Koniec przypadku użycia.
40
4.2
4.2.1
Specyfikacja
Wymagania pozafunkcjonalne
Funkcjonalność
Odpowiedniość
• System jest odpowiedni do grupowania wyników zapytań do danych oznaczonych semantycznie.
Dokładność
• Wyniki kategoryzacji (CATEGORIZE BY) są powtarzalne i deterministyczne.
Interoperacyjność
• Możliwość działania jako końcówka SPARQL.
• System można uruchomić na dowolnej platformie sprzętowej (programowej), na której
można uruchomić system Pellet.
Bezpieczeństwo
• System nie może umożliwiać uzyskania dostępu do wykonywania poleceń w systemie
operacyjnym.
• System umożliwia dostęp do plików tylko za pośrednictwem silnika wnioskującego.
Zgodność funkcjonalności
• System obsługuje zapytania w języku SPARQL.
• Możliwość działania jako końcówka SPARQL.
4.2.2
Niezawodność
Dojrzałość
• Podczas normalnej pracy użytkownika z produktem nie występują defekty.
Odporność na błędy
• Błędne dane w pojedynczym zapytaniu nie mogą wpływać na wykonanie innych zapytań.
• W przypadku awarii aplikacji powinna ona zostać zrestartowana przez serwer aplikacji.
Odtwarzalność
• Aplikacja po awarii i ponownym uruchomieniu pracuje tak samo jak przed awarią.
4.2.3
Użyteczność
Łatwość zrozumienia
• Produkt powinien być zrozumiały dla inżyniera-informatyka.
• Użycie przykładów i zbadanie ich wyników powinno być zrozumiałe dla osoby umiejącej
posługiwać się komputerem.
Łatwość nauczenia się
• Wykształcony informatyk po zapoznaniu się z niniejszą pracą powinien być w stanie
używać produktu po jednodniowym zapoznaniu.
Łatwość operowania
• Do obsługi produktu powinna wystarczyć możliwość posługiwania się przeglądarką internetową.
Atrakcyjność
• Produkt posiada logo.
• Interfejs WWW jest estetyczny.
• Interfejs WWW jest stworzony zgodnie z zasadami dobrego tworzenia interfejsów.
4.2. Wymagania pozafunkcjonalne
4.2.4
41
Wydajność
Wykorzystanie czasu
• Odpowiedź na zadane zapytanie powinna pojawić się w przeciągu 30 sekund (pomijając
opóźnienia łącza) dla wyników poniżej 100 indywiduów.
Wykorzystanie zasobów
• Produkt powinien uruchamiać się na serwerze semantic.cs.put.poznan.pl.
4.2.5
Łatwość utrzymania
Łatwość wprowadzenia zmian
• Naprawa błędów w implementacji algorytmów nie powinna zająć doświadczonemu programiście więcej niż pięć dni roboczych.
Stabilność
• Ryzyko wystąpienia nieprzewidzianych zachowań systemu po modyfikacji powinno być
zminimalizowane przez właściwe testowanie z wykorzystaniem testów jednostkowych
oraz testów akceptacyjnych.
Łatwość testowania
• Algorytmy grupowania powinny posiadać testy jednostkowe.
• Dla interfejsu użytkownika powinny być stworzone scenariusze testowe.
4.2.6
Przenośność
Łatwość adaptacji
• System powinien być uruchamialny na dowolnym systemie, na którym można uruchomić
silnik Pellet.
Łatwość instalacji
• Nowe wersje aplikacji powinny być dostępne w formie plików WAR.
• Produkt powinien być instalowalny przez administratora mającego doświadczenie z serwerami aplikacji.
Zgodność
• Oprogramowanie jest napisane w języku przenośnym na różne platformy programowe.
Łatwość zastąpienia
• Aplikacja, jako produkt wielozadaniowy, powinna być zastępowalna specjalizowanym
systemem, dostosowanym np. do potrzeb jednej ontologii.
Rozdział 5
Implementacja
5.1
Architektura systemu
Rysunek 5.1 przedstawia ogólny schemat architektury stworzonego systemu. Centralną rolę
odgrywa manager zapytań, opisany dokładniej w rozdziale 5.4. Jego zadaniem jest szeregowanie
zleconych zadań i odpowiednie wywoływanie kolejnych operacji. Pellet i Jena są kluczowymi bibliotekami, opisanymi w rozdziale 3.1, realizującymi dostęp do bazy wiedzy, a także odpowiadającymi
na zapytania w języku SPARQL (roz. 2.5).
Zaimplementowane algorytmy grupujące powiązane są wspólnym interfejsem programistycznym, opisanym w rozdziale 5.2. Interfejs ten pośredniczy również w dostępie do biblioteki SeSiL,
służącej do obliczania stopnia podobieństwa między porównywanymi obiektami. Biblioteka ta została opisana w rozdziale 3.2.
Algorytmy k-Medoids (roz. 5.2.2) i grupowania hierarchicznego (roz. 5.2.1) grupują obiekty
zgodnie z ich odległością względem określonej miary. Algorytm CATEGORIZE BY grupuje obiekty
wyłącznie na podstawie ich przynależności do pojęć opisanych w bazie wiedzy. Szczegółowe informacje na jego temat można znaleść w rozdziale 5.3.
Interakcja z użytkownikiem możliwa jest w tworzonym systemie w dwojaki sposób. Po pierwsze
użytkownik może wykorzytać stronę WWW, opisaną w rozdziale 5.5.2. Interakcja automatyczna lub
półautomatyczna możliwa jest również przy wykorzystaniu standardowego interfejsu SPROT do
automatycznego zadawania zapytań SPARQL, opisanego w rozdziale 5.5.1. Informacje praktyczne
na temat interfejsu użytkownika znajdują się w rozdziale 6.
interfejs WWW
SPROT
manager zapytań
Pellet
API
Jena
algorytm hierarchiczny
categorize by
SeSiL
k-Medoids
Rysunek 5.1: Architektura systemu
44
Implementacja
5.2
Opcja CLUSTER BY
Wyrażenie CLUSTER BY jest wyrażeniem rozszerzającym standardową składnię języka SPARQL
o możliwość grupowania wyników wykorzystującą algorytmy analizy skupień. Służą one do grupowania kolekcji obiektów (inaczej: elementów, indywiduów) w podzbiory zwane grupami (skupieniami) tak, aby obiekty w obrębie grupy były ze sobą silniej związane, niż są związane z obiektami
spoza niej. Istotnym problemem jest określanie poziomu podobieństwa między grupowanymi indywiduami. W pracy do obliczania tych miar wykorzystuje się bibliotekę SeSiL (roz. 3.2).
Zaimplementowane zostały dwa algorytmy grupowania:
• algorytm aglomeracyjnego grupowania hierarchicznego, generujący hierarchię grup, opisany
w rozdziale 5.2.1;
• algorytm k-Medoids, generujący płaską strukturę grup, opisany w rozdziale 5.2.2.
Definicja 5.1 (składnia wyrażenia CLUSTER BY). Składnia (wyrażona w EBNF [ISO96]):
query ::= select query, cluster by
cluster by ::= "CLUSTER BY", variables, [using]
variables ::= variable, {" ", variable}
using ::= "USING <", uri, ">"
uri ::= "http://semantic.cs.put.poznan.pl/asparagus/cluster-by/hierarchical" |
"http://semantic.cs.put.poznan.pl/asparagus/cluster-by/kmedoids"
Przy czym select query reprezentuje poprawne wyrażenie typu SELECT, a variable dowolną
zmienną występującą jako wybierana w wyrażeniu SELECT (być może przez zastosowanie symbolu ∗).
5.2.1
Algorytm aglomeracyjnego grupowania hierarchicznego
W trakcie działania algorytmu aglomeracyjnego grupowania hierarchicznego następuje seria
przydziałów obiektów do grup. Elementy, a w późniejszych etapach elementy z grupami lub dwie
grupy, są przydzielane do jednej grupy na podstawie podobieństwa.
Algortytm wytwarza serię podziałów danych: Pn , Pn−1 ,. . . , P1 . Pierwszy, Pn , zawiera n jednoelementowych grup, a ostatni, P1 , zawiera jedną grupę wszystkich obiektów. Na każdym etapie
algorytm łączy ze sobą dwie najbliższe grupy (tj. takie, dla których semantyczna odległość jest minimalna). Oczywiście w początkowych etapach łączone są dwa najbliższe sobie obiekty. W następnych krokach połączenie następuje na podstawie odległości między grupami. Można ją wyznaczać
na wiele sposobów. W naszej implementacji wybrano metodę single linkage clustering (najbliższego
sąsiada, najmniejszej odległości). Definiuje ona odległość między grupami jako odległość między
najbliższą sobie parą obiektów, złożonych z jednego obiektu z każdej grupy, czyli jest obliczana
zgodnie ze wzorem:
D(X, Y ) =
min
x∈X,y∈Y
d(x, y)
(5.1)
gdzie d(x, y) jest odległością pomiędzy obiektami x i y. W wyniku działania algorytmu uzyskuje
się hierachię grup, odzwierciedlającą poszczególne etapy grupowania obiektów.
Podczas pracy algorytmu dla każdej grupy generowany jest opis, charakteryzujący jej zawartość.
Dzięki opisom grup zwiększy się przejrzystość wyników i ich analiza będzie łatwiejsza dla użytkownika. Za opis grupy przyjmowana jest lista klas elementów, które do niego należą. Następnie,
dla grup wieloelementowych, opis ten jest skracany:
• jeżeli na liście klas znajdują się duplikaty, są usuwane,
5.3. Opcja CATEGORIZE BY
45
• klasy będące podklasami innych, także występujących w opisie, są usuwane,
• każde dwie klasy, mające wspólną bezpośrednią nadklasę są nią zastępowane.
Procedura skracania opisu jest kontynuowana tak długo, aż żadnen z powyższych warunków nie
jest spełniony.
5.2.2
Algorytm k-Medoids
Algorytm k-Medoids służy do podziału danych na grupy jednostek danych. Jednostka danych
najbardziej „typowa” dla swojej grupy (na podstawie określonych miar podobieństwa) nosi nazwę
medoidu.
Jako dane wejściowe są pobierane: zbiór jednostek danych, maksymalna liczba grup i maksymalna liczba wewnętrznych iteracji. Dane wyjściowe stanowi tablica zbiorów grup.
Na początku wszystkie jednostki danych są w jednej grupie (jest ona wpisywana do tablicy
wynikowej). Aż do osiągnięcia maksymalnej liczby grup, wybrane grupy są dzielone na dwie części. Jako grupa do podziału wybierana jest ta, w której różnice między jednostkami danych są
największe.
Podział odbywa się następująco: najbardziej różniące się jednostki danych z dzielonej grupy
stają się medoidami nowych grup. Następnie pozostałe jednostki danych z dzielonej grupy są
przypisywane do nowopowstałych grup. W tych grupach medoidami zostają jednostki danych najbardziej podobne do pozostałych w swojej grupie. Pozostałe jednostki danych są na nowo przypisywane do nowych grup. Wybieranie nowych medoidów jest powtarzane, dopóki podział jednostek
danych między grupami nie przestanie ulegać zmianom lub nie zostanie osiągnięta maksymalna
liczba iteracji.
Po dokonaniu podziału, do wynikowej tablicy zbiorów grup zostaje dodany zbiór, w którym
podzielona grupa jest zastąpiona przez dwie nowe.
Jako bazę wykorzystano kod przygotowany przez pana Łukasza Koniecznego i dostępny na
licencji Affero General Public License.
5.3
Opcja CATEGORIZE BY
Wyrażenie CATEGORIZE BY jest wyrażeniem rozszerzającym standardową składnię języka SPARQL o możliwość grupowania wyników zgodnie z naturalną hierarchią klas, do których należą
poszczególne wartości w danej krotce. Zostało ono zaproponowane w [dFL10]. Należy nadmienić,
że ze względu na konieczność wykorzystania hierarchii pojęć CATEGORIZE BY może być stosowane
wyłącznie do zmiennych mających abstrakcyjną dziedzinę.
Definicja 5.2 (składnia wyrażenia CATEGORIZE BY). Składnia (wyrażona w EBNF [ISO96]):
query ::= select query, categorize by
categorize by ::= "CATEGORIZE BY", variables
variables ::= variable, {" ", variable}
Przy czym select query reprezentuje poprawne wyrażenie typu SELECT, a variable dowolną
zmienną występującą jako wybierana w wyrażeniu SELECT (być może przez zastosowanie symbolu ∗).
Definicja 5.3 (drzewo klasyfikacji pojedynczej zmiennej). Dla danej zmiennej c niech Xc oznacza
zbiór zawierający wiązania tej zmiennej dla wszystkich krotek, będących wynikiem zapytania.
Drzewem klasyfikacji Tc dla tej zmiennej nazywa się podzbiór hierarchii klas wynikającej z danej
46
Implementacja
Atrakcja
Atrakcja kulturalna
Filharmonia
Kościół
Katedra
Muzeum
Klasztor
W Polsce
W kujawsko–pomorskim
W małopolsce
Atrakcja, W Polsce
Atrakcja kulturalna, W kuj.–pom.
Kościół, W kuj.–pom.
Atrakcja kulturalna, W małopolsce
Kościół, W małopolsce
Rysunek 5.2: Przykładowe drzewa klasyfikacji dla jednej zmiennej oraz powstałe
z nich drzewo klasyfikacji dla dwóch zmiennych.
ontologii O ukorzeniony w klasie C takiej, że ∀x ∈ Xc : O |= C(x) i przy tym dla każdej innej klasy
D, dla której spełniony byłby ten warunek, zachodzi C v D.
Definicja 5.4 (drzewo klasyfikacji dwóch zmiennych). Dla danych zmiennych c, d powiązanych
z drzewami Tc , Td ukorzenionymi w wierzchołkach Cc , Cd posiadającymi dzieci, będące korzeniami
poddrzew, odpowiednio Tc1 , Tc2 , . . . , Tcm oraz Td1 , Td2 , . . . , Tdn drzewo wynikowe Tc,d jest ukorzenione w wierzchołku (Cc , Cd ) (para uporządkowana), który jest rodzicem dla drzew:
Tc1 ,d1 , . . . , Tc1 ,dn , Tc2 ,d1 , . . . , Tc2 ,dn , . . . , Tcm ,dn
(5.2)
powstałych przez rekurencyjne zastosowanie tej definicji. Oczywiście jeżeli n = 0 lub m = 0 drzewo
Tc,d jest pojedyńczym wierzchołkiem (rysunek 5.2).
Definicja 5.5 (drzewo klasyfikacji wielu zmiennych). Niech dane będzie drzewo klasyfikacji dowolnej liczby zmiennych Tc1 ,c2 ,...,cn oraz drzewo klasyfikacji jednej zmiennej Td . Drzewem klasyfikacji
Tc1 ,c2 ,...,cn ,d nazywa się drzewo, które powstaje przez potraktowanie zbioru {c1 , c2 , . . . , cn } jak jednej zmiennej i zastosowanie definicji dla drzewa klasyfikacji dwóch zmiennych, a następnie zamiany
krotki, w której jest ukorzenione ((c1 , c2 , . . . , cn ), d) na krotkę postaci (c1 , c2 , . . . , cn , d).
Definicja 5.6 (klasyfikacja wyniku). Niech dana będzie krotka k wiążąca zmienne (c1 , c2 , . . . , cn ).
Mówimy, że krotka k należy do grupy (C1 , C2 , . . . , CN ) względem danej ontologii O, jeżeli
∀i = 1, 2, . . . , n : O |= Ci (ci )
(5.3)
5.4. Manager zapytań
47
Definicja 5.7 (najbardziej specyficzna grupa). Grupa C = (C1 , C2 , . . . , Cn ) jest najbardziej specyficzną grupą dla danej krotki k jeżeli należy ona do grupy C i nie należy do jakiejkolwiek innej
grupy występującej w poddrzewie drzewa klasyfikacji dla danych zmiennych ukorzenionym w grupie C.
Definicja 5.8 (algorytm działania opcji CATEGORIZE BY). Dla danych zmiennych c1 , c2 , . . . , cn
podlegających działaniu CATEGORIZE BY oraz wyniku zapytania zawierającego co najmniej te
zmienne, algorytm składa się z następujących kroków:
1. Wygeneruj drzewo klasyfikacji dla zmiennych c1 , c2 , . . . , cn .
2. Przypisz każdą krotkę wynikową do najbardziej specyficznej grupy dla danej krotki, uwzględniając wyłącznie zmienne c1 , c2 , . . . , cn .
5.4
Manager zapytań
Zadaniem managera zapytań jest szeregowanie wykonania zapytań zadawanych za pomocą
strony WWW (roz. 5.5.2) lub końcówki SPARQL (roz. 5.5.1).
Zapytanie (obiekt typu put.semantic.asparagus.Query) dostarczane jest do managera w postaci obiektu zawierającego:
• pełną treść zapytania, a także poszczególne jego fragmenty:
– zapytanie SPARQL zgodne z roz. 2.5;
– typ grupowania (CATEGORIZE BY czy CLUSTER BY);
– listę zmiennych, które mają zostać wykorzystane przy grupowaniu;
– algorytm i jego opcje, które mają zostać wykorzystane;
• końcówkę SPARQL, z której mają zostać pobrane dane;
• listę adresów URL bądź ścieżek dostępu do plików, które mają zostać wczytane do domyślnego
grafu.
Przetwarzanie zapytania odbywa się zgodnie z następującym algorytmem:
1. Zbudowanie obiektów pomocniczych dla systemu Pellet, zawierających zapytanie SPARQL,
a także listę adresów URL, z których należy pobrać dane.
2. Przygotowanie planu wykonania zapytania.
3. Wykonanie zapytania i pobranie wyników.
4. Pogrupowanie wyników zgodnie ze wskazanym wcześniej algorytmem.
5. Oznaczenie zapytania jako zakończone.
Jeżeli na którymkolwiek etapie powyższego algorytmu nastąpi błąd, jest on zapamiętywany jako
odpowiedź, a zapytanie jest oznaczane jako zakończone.
W związku z faktem, że aplikacja działa w obrębie serwera aplikacji Java EE (rodział 3.4),
manager zapytań jest uruchamiany jako samodzielny wątek, który korzysta z wielowątkowej kolejki. Kod, przygotowujący zapytanie, wywołuje odpowiednią metodę współdzielonego obiektu,
reprezentującego manager, która dodaje ją do kolejki, a następnie oczekuje na zasygnalizowanie
dostępności odpowiedzi w obiekcie zapytania. Dzięki wykorzystaniu wielowątkowej kolejki w sytuacji, gdy nie ma zadań do przetworzenia, wątek przetwarzający pozostaje w stanie uśpienia.
Konstrukcja taka jest optymalna ze względu na wykorzystanie zasobów systemu, ponieważ nie
istnieje ryzyko wykonywania więcej, niż to przewidział konstruktor systemu, zapytań jednocześnie
(zależy to od liczby jednocześnie wykorzystywanych obiektów typu Manager), a także nie marnuje
zasobów podczas oczekiwania na nowe zlecenia.
48
Implementacja
5.5
Interfejs
5.5.1
Końcówka SPARQL
Końcówka SPARQL jest to usługa zgodna ze specyfikacją protokołu zawartą w [CFT08]. Wymagana obsługa RDF oraz zapytań SPARQL realizowana jest przez framework Jena. W ASPARAGUS -ie zaimplementowany jest podzbiór funkcjonalności wymieniony w rozdziale 2.2 specyfikacji
- bindingi HTTP .
Implementacja zawiera pojedynczy serwlet Java EE przyjmujący zapytania, przekazujący je
do lokalnej instancji managera zapytań i zwracający wynikowy dokument. Rozpoznawane są parametry:
query zawiera zapytanie SPARQL zapisane w formie URL Encoding
default-graph-uri reprezentuje domyślne źródła danych
named-graph-uri reprezentuje nazwane źródła danych
Z powodu braku implementacji obsługi nazwanych źródeł danych są one ignorowane co czyni
ASPARAGUS -a nie w pełni zgodnego ze specyfikacją. W przypadku błędu zwracany jest, zgodnie
ze specyfikacją, błąd 400 protokołu HTTP .
Dokument wynikowy jest konstruowany według [BB07]. Typ zawartości (nagłówek Content-Type)
jest ustawiony na application/xml, a kodowanie znaków na UTF-8. Ponieważ RDF przechowuje
strukturę płaską, a nie drzewiastą, dokument wyjściowy konstruowany jest w następujący sposób
w celu odwzorowania hierarchii grup wygenerowanych przez algorytmy ASPARAGUS -a:
1. Liczona jest wysokość drzewa grup w celu zarezerwowania miejsca w nagłówku.
2. Tworzony jest nagłówek z nazwami zmiennych. W nagłówku tworzone są dodatkowo zmienne
o nazwie path_lv_n gdzie n przyjmuje kolejne wartości od 0 do wysokości drzewa grup.
3. Drzewo jest przeglądane w porządku w głąb (ang. depth-first). Wypisywane są kolejne krotki
wynikowe. Zmienne path_lv_n przyjmują jako wartość nazwy kolejnych grup, do których należy krotka, w porządku od korzenia do liścia. Pozostałe zmienne path_lv_n mają przypisany
literał null. Wypisywane są wartości zmiennych krotki.
4. Wypisywane są znaczniki zamykające.
Wartości zmiennych wypisywane są zgodnie ze swoim typem w sposób przewidziany specyfikacją
protokołu. Konstrukcja dokumentu wynikowego sprawia, że pomijane są grupy nie zawierające
krotek danych.
Przykład:
<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
<head>
<variable name="path_lv_0"/>
<variable name="wykladowca"/>
<variable name="przedmiot"/>
</head>
<results>
<result>
<binding name="path_lv_0">
<literal><Pracownik_uczelni, Zajęcia></literal>
</binding>
49
5.5. Interfejs
<literal>null</literal>
</binding>
<literal>null</literal>
</binding>
<binding name="wykladowca">
<uri>
http://semantic.cs.put.poznan.pl/asparagus/univ.owl#pracownik_uczelni_1
</uri>
</binding>
<binding name="przedmiot">
<uri>
http://semantic.cs.put.poznan.pl/asparagus/univ.owl#zajęcia_1
</uri>
</binding>
</result>

</results>
</sparql>
5.5.2
Interfejs webowy
Implementacja interfejsu składa się z trzech zasadniczych części zawartych w niżej wymienionych pakietach.
put.semantic.asparagus.webgui.shared Współdzielone
obiekty
implementujące
interfejs
IsSerializable. Są one dzięki temu automatycznie serializowane przez GWT , co umożliwia ich wygodne przekazywanie przez kanał HTTP. Służą do komunikacji części klienckiej
z serwerową. Zasadniczą rolę odgrywają trzy klasy:
QueryAttributes Klasa opakowująca zapytanie przekazywane do serwera. Zawiera treść
samego zapytania, adresy lokalnych i zdalnych źródeł danych oraz adres końcówki SPARQL.
QueryResultResponse Klasa przechowująca informację o błędzie w razie niepowodzenia
lub wynik klasyfikacji w przypadku jej prawidłowego zakończenia.
ResultTree Klasa tworząca węzły drzewa klasyfikacji. Zawiera nazwę grupy, listę krotek
należących bezpośrednio do danej grupy oraz listę grup pochodnych.
put.semantic.asparagus.webgui.client Klasy składowe interfejsu oraz interfejsy asynchroniczne
służące do komunikacji z serwerem.
put.semantic.asparagus.webgui.server Implementacje usług pośredniczących pomiędzy GUI ,
a managerem zapytań.
Komunikacja klient-serwer odbywa się za pomocą trzech serwletów:
QueryService jest to usługa rozszerzająca typ RemoteServiceServlet obsługująca wykonanie zapytania. Jako argument wywołania przyjmuje obiekt typu QueryAttributes i na
jego podstawie wypełnia obiekt Query, który jest przekazywany do Managera. Po otrzymaniu powiadomienia o zakończeniu klasyfikacji dane z obiektu Query są przepakowywane
do QueryResultResponse i zwracane do GUI .
FileUpload jest serwletem odbierającym dane formularza z plikiem wysłanym przez użytkownika.
Każdy pobierany plik jest umieszczany we własnym katalogu wewnątrz katalogu przyznanego
50
Implementacja
użytkownikowi na czas sesji. Następnie, za pomocą narzędzia unp, plik jest rozpakowywany
(jeżeli był spakowany), a wszystkie wyszukane w katalogu pliki oraz informacje o postępie są
umieszczane w obiekcie statusu.
UploadStatusService to druga usługa asynchroniczna GWT służąca do pobierania informacji
o postępie wysyłania pliku (ilość odebranych bajtów) oraz o znalezionej zawartości w archiwum po zakończeniu pobierania.
Interfejs jest tworzony z komponentów za pomocą metody w klasie webgui. Metoda ta najpierw tworzy odpowiednie ramki, a następnie wstawia w nie komponenty i dodaje akcje związane
z kliknięciami czy wyborem obiektów w drzewie. Na interfejs składają się zarówno standardowe
panele i obiekty GWT spośród wymienionych w roz. 3.3 oraz kilka z nich odziedziczonych:
EndpointEditPanel panel umożliwiający edycję adresu końcówki SPARQL;
FileContent panel pozwalający zarządzać załadowanymi plikami;
TreeItemWithVars element drzewa reprezentujący grupę, przechowuje informacje o krotkach
należących do danej grupy;
UrlEditLabelPanel panel udostępniający możliwość edycji adresów źródeł danych.
W projekcie znajdują się również dwie klasy zawierające jedynie statyczne treści służące odpowiednio do wypełnienia panelu pomocy (HelpText) oraz do utworzenia listy ze skrótami i przykładami
(HintLabel).
Opis roli oraz działania poszczególnych części GUI znajduje się w rozdziale 6.
Rozdział 6
Podręcznik użytkownika
6.1
Interfejs webowy
ASPARAGUS działa pod adresem http://semantic.cs.put.poznan.pl/Asparagus/ i jest
dostępny z wykorzystaniem każdej współczesnej przeglądarki graficznej obsługującej JavaScript
(np. Mozilla Firefox, Google Chrome). Na rysunku 6.1 znajduje się zrzut ekranu w trakcie jego
typowej pracy.
W górnej części okna znajduje się pole tekstowe służące do wprowadzania zapytań SPARQL
(roz. 2.5). Zapytanie takie musi być zakończone wyrażeniem CLUSTER BY lub CATEGORIZE BY (roz.
5.2, 5.3). Przykładowe zapytanie może mieć postać:
PREFIX univ: <http://semantic.cs.put.poznan.pl/asparagus/univ.owl#>
SELECT *
FROM <http://semantic.cs.put.poznan.pl/asparagus/univ.owl>
WHERE { ?wykladowca univ:prowadzi ?przedmiot }
CATEGORIZE BY ?wykladowca ?przedmiot
Zamiast sekcji CATEGORIZE BY ?wykladowca ?przedmiot można umieścić np.
CLUSTER BY USING <http://semantic.cs.put.poznan.pl/asparagus/cluster-by/kmedoids>
albo
Rysunek 6.1: Interfejs ASPARAGUS -a
52
Podręcznik użytkownika
CLUSTER BY
USING <http://semantic.cs.put.poznan.pl/asparagus/cluster-by/hierarchical>
w celu wykorzystania odpowiednio algorytmu k-Medoids lub aglomeracyjnego grupowania hierarchicznego. W obu przypadkach pomiędzy CLUSTER BY a USING może wystąpić lista nazw zmiennych. Jeżeli lista taka nie jest podana, brane pod uwagę są wszystkie zmienne zwracane przez
zapytanie. Przykład:
CLUSTER BY ?wykladowca
Po prawej stronie znajduje się kolumna zakładek, umożliwiających odpowiednio:
SPARQL endpoint Wskazanie końcówki SPARQL, z której zostaną pobrane dane przeznaczone
do przetworzenia. Należy podać tu adres URL, który może zostać wykorzystany zgodnie
z protokołem SPROT .
Data sources Wskazanie adresu bądź adresów HTTP , z których zostaną automatycznie pobrane
i załadowane pliki OWL lub RDF/XML.
Files Załadowanie na serwer plików z danymi w formatach OWL bądź RDF/XML przechowywanych lokalnie. Limit rozmiaru takiego pliku wynosi 2 MB. Pliki dostępne są w ramach
bieżącej sesji, tzn. przestają być dostępne po odświeżeniu strony.
Options Przełączenie opcji odpowiedzialnej za wyświetlanie bądź ukrywanie pustych grup (czyli
takich, które nie posiadają żadnej krotki, na rysunku 6.1 jest to np. grupa
<Profesor, Wykład obowiązkowy>).
Help Zapoznanie się z podręcznikiem użytkownika.
Hints & Examples Załadowanie jednego z predefiniowanych zapytań bądź dodanie do już wpisanego zapytania wyrażenia grupującego zgodnie z wybranym algorytmem.
W zakładkach odpowiedzialnych za dostarczanie danych, przy każdym z pól dostępne są ikony
j oraz
8 służące, odpowiednio, do usunięcia danego źródła oraz do jego czasowego zablokowania.
Po wpisaniu zapytania i ewentualnym ustawieniu źródeł danych, należy klinąć przycisk Execute query i poczekać na pojawienie się wyników. Czas oczekiwania może być różny, zależnie od
obciążenia serwera, rozmiaru danych do przetworzenia i rozmiaru danych koniecznych do ściągnięcia z Internetu. O konieczności oczekiwania informuje komunikat Processing... wyświetlony u góry
strony.
Po pomyślnym zakończeniu przetwarzania w lewej części okna pojawi się hierarchia grup. Rozwijanie kolejnych gałęzi odbywa się przez kliknięcie znaku + poprzedzającego nazwę grupy, natomiast liczby w nawiasach po nazwie grupy oznaczają liczbę krotek należących (pośrednio lub
bezpośrednio) do danej grupy. Kliknięcie na nazwę grupy powoduje wyświetlenie w prawej części
okna krotek wynikowych powiązanych z tą grupą lub którymiś z jej podgrup. Nazwy kolumn,
odpowiadające nazwom zmiennych, wyróżnione są pogrubieniem. Kliknięcie na nazwę kolumny
powoduje przełączenie w niej sposobu wyświetlania nazw indywiduuów pomiędzy pełnym (pełne
URI ), a skróconym (tylko część wyróżniająca indywiduum w obrębie danej przestrzeni nazw).
Również wskazanie kursorem myszy na indywiduum powoduje wyświetlenie w formie podpowiedzi
pełnego URI .
Na rysunku 6.1 przedstawione są grupy rozwinięte na dwa poziomy w głąb i wybrana do
wyświetlenia grupa <Pracownik naukowo-dydaktyczny, Wykład>.
6.2. Końcówka SPARQL
6.2
53
Końcówka SPARQL
Końcówka SPARQL umożliwiająca dostęp do ASPARAGUS -a działa pod adresem http://
semantic.cs.put.poznan.pl/Asparagus/sparql/ i umożliwia dostęp do tych samych algorytmów i metod grupowania co interfejs webowy. Zapytania należy zadawać zgodnie z protokołem
opisanym w [CFT08]. Obsługiwany jest zakres wymagany protokołem, a więc wywołania HTTP .
Protokół SOAP nie jest obsługiwany.
Zapytanie można przesyłać za pomocą metody GET albo POST w parametrze query. Musi ono
być zapisane w formacie application/x-www-form-urlencoded. Za pomocą parametru
default-graph-uri, podanego dowolną liczbę razy, można wskazać źródła, które mają zostać
załadowane do domyślnego grafu. Jest to równoważne użyciu polecenia FROM w zapytaniu. Parametr named-graph-uri nie jest obsługiwany. By uzyskać jego efekt należy zastosować FROM NAMED
w zapytaniu.
Odpowiedź generowana przez końcówkę SPARQL jest zgodna z [BB07], szczegółowy jej opis
znajduje się w rozdziale 5.5.1.
Dla wygody użytkownika dostępny jest prosty formularz umożliwiający zadawanie zapytań
bezpośrednio do końcówki SPARQL, wysyłany w przypadku niepodania parametru query przy
zapytaniu metodą GET.
Rozdział 7
Testy
7.1
Testy jednostkowe dla algorytmów
W celu zminimalizowania ryzyka popełnienia błędu w implementacji algorytmów, przygotowano
dla nich zestaw testów jednostkowych. Zostały one zaimplementowane z wykorzystaniem pakietu
JUnit. W przypadku algorytmów wykorzystujących miary podobieństwa (roz. 5.2), oznaczało to
konieczność połączenia jednoznaczności i zmienności grupowania.
Na potrzeby testów stworzono bardzo prostą ontologię, której zadaniem nie było wierne odwzorowanie świata rzeczywistego, a dostarczenie niewielu danych o bardzo uporządkowanej strukturze.
Dzięki takiemu zabiegowi, możliwe było napisanie testów jednostkowych opierających się głównie
na porównywaniu łańcuchów znaków. Na rysunku 7.1 znajduje się struktura pojęć w opisywanej
ontologii. Każda z przedstawionych klas posiada dwa indywidua, nazywające się tak samo jak
klasa, ale z dodanym numerem porządkowym na końcu. W sumie w ontologii istnieje więc 28 indywiduuów. Ponadto istnieje relacja prowadzi, o dziedzinie Pracownik uczelni i przeciwdziedzinie
Zajęcia. Relacja ta łączy indywidua w pary zgodnie z tablicą 7.1.
Testy wszystkich trzech algorytmów wykorzystują do pobrania danych następujące zapytanie
SPARQL, które zwraca wszystkie 14 par przedstawionych w tablicy 7.1. Oczywiście prefiks univ
odnosi się do opisywanej ontologii.
Pracownik uczelni
Pracownik dydaktyczny
Starszy wykładowca
Pracownik naukowo - dydaktyczny
Wykładowca
Asystent
Profesor
Zajęcia
Wykład
Wykład fakultatywny
Wykład obowiązkowy
Ćwiczenia
Laboratoria
Ćwiczenia tablicowe
Rysunek 7.1: Schemat pojęć w ontologii wykorzystywanej do testów jednostkowych.
56
Testy
Tablica 7.1: Pary stworzone przez relację prowadzi.
Pracownik uczelni
pracownik uczelni 1
pracownik uczelni 2
pracownik dydaktyczny 1
pracownik dydaktyczny 2
pracownik naukowo - dydaktyczny 1
pracownik naukowo - dydaktyczny 2
starszy wykładowca 1
starszy wykładowca 2
wykładowca 1
wykładowca 2
asystent 1
asystent 2
profesor 1
profesor 2
relacja
prowadzi
Zajęcia
zajęcia 1
zajęcia 2
ćwiczenia 1
ćwiczenia 2
wykład 1
wykład 2
laboratoria 1
laboratoria 2
ćwiczenia tablicowe 1
ćwiczenia tablicowe 2
wykład fakultatywny 1
wykład fakultatywny 2
wykład obowiązkowy 1
wykład obowiązkowy 2
SELECT *
7.1.1
Testy dla algorytmu CATEGORIZE BY
W związku z faktem, że nazwa klasy jest zawsze odwzorowana w nazwie indywiduum testowanie
polega na sprawdzeniu, czy:
1. W wyniku grupowania otrzymano 14 krotek.
2. Klaster przypisany do danej krotki zawiera nazwę klasy wynikającą z nazwy indywiduum
zmiennej, po której następuje grupowanie.
Przykład: krotka (pracownik uczelni 1, zajęcia 1) w przypadku grupowania po obu zmiennych
musi należeć do grupy, która w swojej nazwie zawiera Pracownik uczelni oraz Zajęcia.
Testowaniu podlegają cztery możliwe układy grupowania po dwóch zmiennych:
• ?wykladowca
• ?przedmiot
• ?wykladowca ?przedmiot
• ?przedmiot ?wykladowca
Oczywiście kolejność nie wypływa na kształt wyników, natomiast ma znaczenie ze względów na
fakt, że konstrukcja drzewa klasyfikacji dwóch zmiennych (roz. 5.3) opiera się na parach uporządkowanych, a więc nie jest to operacja przemienna.
7.1.2
Testy dla algorytmu k-Medoids
Algorytm k-Medoids (roz. 5.2.2) nie tworzy hierarchii, testowanie polega więc na sprawdzeniu
czy:
1. W wyniku grupowania otrzymano 14 krotek.
2. Grupy utworzone są zgodnie ze „zdrowym rozsądkiem”, to znaczy, czy pary indywiduuów
różniące się wyłącznie numerem porządkowym znajdują się w tej samej grupie.
Przykład: krotki wynikowe (profesor 1, wykład obowiązkowy 1) i (profesor 2, wykład obowiązkowy 2) muszą znajdować się w tej samej grupie niezależnie od wykorzystanej miary
podobieństwa, ponieważ tych par nie różni nic z wyjątkiem numerów porządkowych kończących nazwy.
57
7.2. Testy akceptacyjne
Testowaniu podlega również pełen możliwy układ grupowania po dwóch zmiennych, tak samo
jak dla algorytmu CATEGORIZE BY (roz. 7.1.1).
7.1.3
Testy dla algorytmu aglomeracyjnego grupowania hierarchicznego
W przypadku tego algorymu (roz. 5.2.1) konieczne jest zarówno przetestowanie poprawności
przypisania indywiduuów do grup jak i powiązania grup w hierarchię. Testowanie obejmuje następujące kroki:
1. Sprawdzenie, czy w wyniku grupowania otrzymano 14 krotek.
2. Sprawdzenie, czy do każdej grupy przynależy bezpośrednio najwyżej jedna krotka.
3. Sprawdzenie, czy nazwa grupy, do której jest bezpośrednio przypisana krotka (jest dokładnie
jedna taka grupa i należy do niego dokładnie jedna krotka) ma nazwę zgodną z nazwami
indywiduuów należących do zawartej w nim krotki, a więc zgodną z nazwami pojęć, do
których należą te indywidua.
Pierwsze dwa punkty testowane są dla wszystkich czterech układów zmiennych (roz. 7.1.1),
natomiast ostatni wyłącznie dla układów z jedną zmienną.
7.2
Testy akceptacyjne
W pracy poddano testom interfejs użytkownika (roz. 5.5) wraz z całym systemem poprzez
stworzenie scenariuszy testowych opartych o założone wymagania funkcjonalne (roz. 4.1) i pozafunkcjonalne (roz. 4.2). Niniejsze scenariusze mogą zostać wykorzystane przez użytkowników
systemu do zapoznania się z nim. W każdym z nich zakładamy, że system znajduje się w stanie
początkowym.
7.2.1
Załadowanie ontologii z wykorzystaniem FROM
Scenariusz testowy:
1. W pole przeznaczone na zapytanie wprowadzić:
SELECT *
2. Kliknąć przycisk Execute Query.
3. Odczekać 60 sekund.
Oczekiwany wynik:
Drzewo grup, które można przeglądać. Po kliknięciu na dowolną grupę
powinny wyświetlić się dane przypisane do tej grupy i wszystkich podgrup. W danych znajdują
się dwie kolumny: wykladowca i przedmiot. W korzeniu hierarchii znajduje się w sumie 14 krotek,
zgodnych z tablicą 7.1.
7.2.2
Załadowanie ontologii przechowywanej lokalnie
Scenariusz testowy:
1. Wybrać zakładkę Files.
2. Wskazać plik univ.owl.
3. Kliknąć przycisk Upload.
58
Testy
SELECT *
Oczekiwany wynik: Patrz: 7.2.1
Warunki początkowe: Zapisany lokalnie plik univ.owl, dostępny do pobrania pod adresem
http://semantic.cs.put.poznan.pl/asparagus/univ.owl
7.2.3
Ukrywanie pustych grup
Scenariusz testowy:
1. Wykonać kroki tak samo jak w 7.2.1.
2. Przejść na zakładkę Options.
3. Zaznaczyć opcję Hide empty sets.
Oczekiwany wynik: Drzewo grup, w którym w każdej grupie wyświetlana jest co najmniej
jedna krotka wynikowa. W sumie 7 grup, licząc wszystkie poziomy i 14 krotek.
7.2.4
Wyświetlanie pustych grup
Scenariusz testowy:
1. Wykonać kroki tak samo jak w 7.2.1.
2. Przejść na zakładkę Options.
3. Odznaczyć opcję Hide empty sets.
Oczekiwany wynik: Drzewo grup, w którym istnieją puste grupy. 14 krotek, w sumie 21 grup
na wszystkich poziomach, w tym 14 pustych.
7.2.5
Grupowanie z wykorzystaniem algorytmu k-Medoids
Scenariusz testowy:
SELECT *
CLUSTER BY
USING <http://semantic.cs.put.poznan.pl/asparagus/cluster-by/kmedoids>
7.2. Testy akceptacyjne
59
Oczekiwany wynik:
Dwupoziomowe drzewo grup. W korzeniu dostępne 14 krotek, w liściach
grupy, każda zawierająca zbiór krotek rozłączny z pozostałymi. Wszystkie grupy, poza korzeniem
hierarchii, opisane wartościami zmiennych którejś z występujących w nich krotek.
7.2.6
Grupowanie z wykorzystaniem algorytmu k-Medoids i specyfikacją
maksymalnej liczby grup
Scenariusz testowy:
SELECT *
CLUSTER BY USING
<http://semantic.cs.put.poznan.pl/asparagus/cluster-by/kmedoids?maxNoOfClusters=10>
Oczekiwany wynik: Tak samo jak w 7.2.5, a ponadto 7 grup drugiego poziomu, w każdym dwie
krotki, różniące się wyłącznie numerami porządkowymi w nazwach indywiduuów.
7.2.7
Grupowanie z wykorzystaniem algorytmu aglomeracyjnego
grupowania hierarchicznego
Scenariusz testowy:
SELECT *
CLUSTER BY USING
<http://semantic.cs.put.poznan.pl/asparagus/cluster-by/hierarchical>
Oczekiwany wynik:
Hierarchia grup, zawierająca w sumie 14 różnych krotek. Korzeń hierar-
chii opisany pojęciami Zajęcia oraz Pracownik uczelni. Podgrupy opisane podpojęciami, zgodnie
z rysunkiem 7.1. W grupach, będących liśćmi, po jednej krotce. Otrzymane drzewo nie musi być
zrównoważone.
7.2.8
Grupowanie po wskazanych zmiennych z wykorzystaniem algorytmu
aglomeracyjnego grupowania hierarchicznego
Scenariusz testowy:
60
Testy
SELECT *
CLUSTER BY ?wykladowca
Oczekiwany wynik: Hierarchia grup, zawierająca w sumie 14 różnych krotek. Korzeń hierarchii
opisany pojęciem Pracownik uczelni. Podgrupy opisane podpojęciami pojęcia Pracownik uczelni,
zgodnie z rysunkiem 7.1. W grupach, będących liśćmi, po jednej krotce. Otrzymane drzewo nie
musi być zrównoważone.
Rozdział 8
Podsumowanie
W prezentowanej pracy zrealizowano system do semantycznego grupowania wyników zapytań
do baz wiedzy: ASPARAGUS . Posiada możliwość przetwarzania danych zapisanych w językach
OWL i RDF dostępnych w postaci plików posiadanych lokalnie przez użytkownika, opublikowanych
w Internecie bądź dostępnych przez końcówki SPARQL.
Grupowanie może odbywać się za pomocą jednego z trzech algorytmów różniących się sposobem
działania i strukturą zwracanych danych:
• Algorytm CATEGORIZE BY, opierający się na hierarchii pojęć wynikającej z ontologii i tworzący hierarchię grup.
• Algorytm k-Medoids, wykorzystujący miarę semantycznego podobieństwa i tworzący płaską
strukturę.
• Algorytm aglomeracyjnego grupowania hierarchicznego, wykorzystujący miarę semantycznego podobieństwa i tworzący hierarchię grup.
Użytkownik ma dostęp do systemu poprzez interfejs WWW albo za pomocą końcówki SPARQL,
dostarczającej interfejs umożliwiający automatyczne wykorzystanie systemu.
Tym samym zrealizowano wszystkie cele wymienione w rozdziale 1.3.
Dzięki ASPARAGUS -owi powinno stać się istotnie łatwiejsze tworzenie systemów dla użytkowników końcowych, a odwołujących się do danych semantycznych. Systemy takie będą pozwalały
na przykład na przeszukiwanie ofert wycieczkowych.
Zauważono następujące możliwe kierunki jej rozwoju:
• Stworzenie wtyczek umożliwiających wykorzystanie ASPARAGUS -a w innych systemach,
np. Protégé.
• Rozszerzenie zakresu dostępnych algorytmów grupowania i miar podobieństwa.
• Skuteczniej działające wnioskowanie na danych pochodzących z końcówek SPARQL, np.
przez pobieranie z nich dodatkowych danych.
• Inne, bardziej czytelne dla użytkownika, sposoby wyświetlania danych.
• Przetwarzanie w środowiskach wieloprocesorowych, takich jak środowiska rozproszone (klastry lub chmury obliczeniowe) czy GPU.
• Implementacja algorytmów z wykorzystaniem układów programowalnych FPGA.
Literatura
[BA05]
M. Ben-Ari. Logika matematyczna w informatyce. WNT, 2005.
[Baa03]
F. Baader, redaktor. The description logic handbook. Cambridge University Press, 2003.
[BB07]
Dave Beckett, Jeen Broekstra. Sparql query results xml format, 2007. Artykuł w sieci
WWW: http://www.w3.org/TR/rdf-sparql-XMLres/. Dostęp dnia: 8.1.2011 r.
[BBL08]
D. Beckett, T. Berners-Lee. Turtle - terse rdf triple language, 2008. Artykuł w sieci WWW:
http://www.w3.org/TeamSubmission/turtle/. Dostęp dnia: 21.11.2010 r.
[Bec05]
Dave Beckett. Sparql rdf query language reference v1.8, 2005. Artykuł w sieci WWW:
http://www.dajobe.org/2005/04-sparql/SPARQLreference-1.8.pdf. Dostęp dnia:
25.11.2010 r.
[BG]
Dan Brickley, R.V. Guha. Rdf vocabulary description language 1.0: Rdf schema. Artykuł w
sieci WWW: http://www.w3.org/TR/rdf-schema/. Dostęp dnia: 12.12.2010 r.
[BS07]
S. Bloehdorn, Y. Sure. Kernel methods for mining instance data in ontologies. Lecture Notes
in Computer Science, 4825/2007:58–71, 2007.
[BvHH+ 04] Sean Bechhofer, Frank van Harmelen, Jim Hendler, Ian Horrocks, Deborah L. McGuinness,
Peter F. Patel-Schneider, Lynn Andrea Stein. Owl web ontology language reference, 2004.
Artykuł w sieci WWW: http://www.w3.org/TR/owl-ref/. Dostęp dnia: 21.11.2010 r.
[CDD+ 03]
J. Carroll, I. Dickinson, C. Dollin, K. Wilkinson, D. Reynolds, A. Seaborne. Jena:
Implementing the semantic web recommendations. Raport instytutowy, Hewlett-Packard
Laboratories, 2003.
[CFT08]
Kendall Grant Clark, Lee Feigenbaum, Elias Torres. Sparql protocol for rdf, 2008. Artykuł
w sieci WWW: http://www.w3.org/TR/rdf-sparql-protocol/. Dostęp dnia: 8.1.2011 r.
[d’A07]
C. d’Amato. Similarity-based Learning Methods for the Semantic Web. Praca doktorska,
Università degli Studi di Bari, 2007.
[dFE08]
C. d’Amato, N. Fanizzi, F. Esposito. Non-parametric statistical learning methods for
inductive classifiers in semantic knowledge bases. IEEE International Conference on
Semantic Computing, strony 291–298, 2008.
[dFL10]
C. d’Amato, N. Fanizzi, A. Lawrynowicz. Categorize by: Deductive aggregation of semantic
web query results. ESWC (1), strony 91–105, 2010.
[DOS03]
M. Daconta, L. Obrst, K. Smith. Semantic Web. Wiley Publishing, Inc., 2003.
[Fd06]
N. Fanizzi, C. d’Amato. A declarative kernel for ALC concept descriptions. Lecture Notes in
Computer Science, 4203/2006:322–331, 2006.
[HFB09]
J. Hebler, M. Fisher, R. Blace. Semantic Web Programming. Wiley Publishing, Inc., 2009.
[Ian06]
L. Iannone. Machine learning for ontology engineering. Praca doktorska, Università degli
Studi di Bari, 2006.
64
[ISO96]
Literatura
ISO. ISO/IEC 14977:1996: Information technology — Syntactic metalanguage — Extended
BNF. International Organization for Standardization, 1996.
[KC04]
Graham Klyne, Jeremy J. Carroll. Resource description framework (rdf): Concepts and
abstract syntax, 2004. Artykuł w sieci WWW:
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Dostęp dnia: 21.11.2010 r.
[Lig06]
[MKS04]
A. Ligęza. Logical Foundations for Rule-Based Systems, 2nd Ed. Springer, 2006.
Deborah L. McGuinness Michael K. Smith, Chris Welty. Owl web ontology language guide,
2004. Artykuł w sieci WWW: http://www.w3.org/TR/owl-guide/. Dostęp dnia:
21.11.2010 r.
[MvH04]
Deborah L. McGuinness, Frank van Harmelen. Owl web ontology language. overview, 2004.
Artykuł w sieci WWW: http://www.w3.org/TR/owl-features/. Dostęp dnia: 21.11.2010 r.
[Pel]
Pellet: Owl 2 reasoner for java. Artykuł w sieci WWW: http://clarkparsia.com/pellet.
Dostęp dnia: 20.11.2010 r.
[SPG+ 07]
E. Sirin, B. Parsia, B. Cuenca Grau, A. Kalyanpur, Y. Katz. Pellet: A practical owl-dl
reasoner. Journal of Web Semantics, 5(2), 2007.
[SSS91]
M. Schmidt-Schauss, G. Smolka. Attributive concept descriptions with complements.
Artificial Intelligence, 48(1):1–26, 1991.
[STC04]
J. Shawe-Taylor, N. Cristianini. Kernel Methords for Pattern Analysis. Cambridge
University Press, 2004.
[TJO01]
Berners-Lee T., Hendler J., , Lassila O. The semantic web. Scientific American, 284(5),
2001.
c 2011 Michał Madziar, Aleksandra Nowak, Krzysztof T. Pawlak, Jędrzej Potoniec
Instytut Informatyki, Wydział Informatyki
Politechnika Poznańska
Skład przy użyciu systemu LATEX.
BibTEX:
@mastersthesis{ key,
author = "Michał Madziar \and Aleksandra Nowak \and Krzysztof T. Pawlak \and Jędrzej
Potoniec",
title = "{ASPARAGUS -- System do semantycznej agregacji wyników zapytań SPARQL}",
school = "Poznan University of Technology",
address = "Pozna{\’n}, Poland",
year = "2011",
}

asparagus – system do semantycznej agregacji wyników zapytań

Transkrypt

Podobne dokumenty

Projekt z przedmiotu Podstawy Inżynierii Wiedzy 2009

Semantic Web – technologie, zastosowania, rozwój

laboratorium 2 Linki do przydatnych aplikacji na stronie 2. Zadanie 1

Semantic Web

Marcin Skowronek - Studia Informatica

Semantyczne usługi sieciowe

Internet Semantyczny – zadania Zasady uzyskania zaliczenia – na

Drogi Rodzicu!