Widok/Otwórz

Transkrypt

Widok/Otwórz

Standardy semantyczne
Spis treści
1.
Topic Maps ................................................................................................................ 3
1.1.
Struktura ............................................................................................................ 3
1.2.
Semantyka i wnioskowanie ................................................................................ 6
1.3.
Zastosowania ..................................................................................................... 7
2.
RDF i RDFS ............................................................................................................... 9
2.1.
Struktura ............................................................................................................ 9
2.2.
Pojęcia i abstrakcyjna składnia..........................................................................17
2.3.
Semantyka ........................................................................................................25
2.4.
Wnioskowanie ...................................................................................................45
2.5.
Zastosowania ....................................................................................................46
2.6.
Języki zapytań ..................................................................................................47
2.7.
OWL .....................................................................................................................81
2.8.
Struktura ...........................................................................................................81
2.9.
Poszczególne języki OWL ...............................................................................102
2.10.
Semantyka ......................................................................................................105
2.11.
Wnioskowanie .................................................................................................139
2.12.
Zastosowania ..................................................................................................151
2.13.
OWL-S ................................................................................................................153
2.14.
Wyższa ontologia usług...................................................................................155
2.15.
Profile usług ....................................................................................................157
2.16.
Modelowanie usług jako procesów ..................................................................161
2.17.
Relacje z innymi specyfikacjami ......................................................................170
2.18.
Zastosowania ..................................................................................................183
2.19.
Rodzina specyfikacji WSMO ...............................................................................185
2.20.
WSMO ............................................................................................................192
2.21.
WSML .............................................................................................................212
2.22.
WSMX.............................................................................................................254
2.23.
SWSF .................................................................................................................265
2.24.
SWSL..............................................................................................................269
2.25.
SWSO .............................................................................................................272
1. Topic Maps
Topic Maps1 jest standardem ISO i powstał w celu usprawnienia tworzenia indeksów,
glosariuszy czy tezaurusów dla zbiorów dokumentów elektronicznych. Dopiero z czasem
rozwój specyfikacji poszedł w kierunku tworzenia ontologii, w związku z czym jest do tego
zadania inaczej przystosowany niż języki z założenia opracowane do konstrukcji ontologii.
Topic Maps bazuje na XML tworząc język XTM (XML Topic Maps). Mapy tworzone przez
specyfikację opisują informacje w dokumencie oraz bazach danych poprzez łączenie ich za
pomocą identyfikatorów URI. Kluczowe pojęcia opisane w bazach danych i dokumentach
łączone są za pomocą relacji niezależnie od tego, co jest napisane o nich w indeksowanej
informacji. Mapa składa się zazwyczaj z różnych zachodzących na siebie hierarchii,
bogatych w semantyczne połączenia wewnątrz.
1.1. Struktura
Podstawowym elementem mapy jest pojęcie reprezentujące podmiot, czyli przedmioty
zarówno materialne jak i abstrakcyjne. Mapa pojęć wprowadza zależności między pojęciami.
Pojęcia mogą posiadać następujące rodzaje charakterystyk: nazwy, typy, wystąpienia oraz
role w powiązaniach.
Opis poszczególnych elementów struktury Topic Maps:
•
podmiot (subject) – rzecz, koncept będący elementem mapy;
•
tożsamość (identity) – suma wszystkich własności danego podmiotu; niezbędna jest jej
prawidłowa identyfikacja w celu zrozumienia ontologii przez maszyny;
•
adres podmiotu (subject address) – bezpośredni wskaźnik (URI) tożsamości podmiotu
elektronicznego (np. strona www);
•
wskaźnik podmiotu (subject indicator) – niebezpośredni wskaźnik tożsamości, wskazuje
zasób, a nie sam podmiot (nieelektroniczny);
•
pojęcie (topic) – reprezentacja podmiotu, może być instancją jednej lub wielu klas;
•
typ pojęcia (topic type) – relacja określająca przynależność pojęcia do kategorii (klasy)
-
klasa pojęć,
-
klasa pojęć określona przez <instanceOf> (pojęcie może należeć do więcej niż
jednej klasy),
1
pojęcie, którego podmiot jest klasą pojęcia;
Por. szerzej http://www.topicmaps.org/xtm/
•
własności pojęcia (topic characteristic) – cechy charakterystyczne pojęcia: nazwa,
wystąpienie, rola;
•
wystąpienie (occurrence) - źródło informacji związane z pojęciem (dla osoby to np.
strona domowa, portret, publikacja z nazwiskiem, CV...), może być instancją klasy;
•
typ wystąpienia (occurrence type) – rodzaj wystąpienia, np. dokument zawierający opis
pojęcia lub wzmiankę o tym pojęciu;
•
powiązanie (association) - relacja między dwoma lub więcej pojęciami, może być
instancją dokładnie jednej klasy, nie ma określonego kierunku, działa w obie strony
określając role w powiązaniach;
•
typ powiązania (association type) – rodzaj (klasa) powiązania;
•
rola – bycie elementem danego powiązania, determinuje znaczenie powiązania, określa
kierunek działania relacji;
•
nazwa (name) – nazwa słowna (zazwyczaj string) danego pojęcia, może istnieć więcej
niż jedna nazwa:
-
nazwa bazowa (base name) – główna nazwa pojęcia, jest tylko jedna, często taka
sama w różnych kontekstach, ale można też określić jej kontekst,
-
alternatywna nazwa (variant name) - alternatywna forma nazwy bazowej,
odpowiednia do kontekstu, w którego obrębie warianty mogą być sortowane i
przedstawiane (przydatne w wyszukiwaniu, istnieje możliwość uwzględniania
synonimów);
•
zakres (scope) - ograniczony kontekst, można go dodawać do pojęć, asocjacji i
wystąpień; kwalifikuje zdania:
•
członek (member) – bycie elementem powiązania lub zbiór pojęć odgrywających
konkretną rolę w powiązaniu;
•
parametr (parameter) – informacja w formie zbioru pojęć wyrażająca odpowiedni
kontekst dla nazwy alternatywnej;
•
wskaźnik podmiotu (subject indicator) – zasób wskazujący tożsamość podmiotu; istnieją
trzy sposoby wskazywania tożsamości:
-
wskazanie przez <topicRef> czyli pojęcie dzielące ten sam podmiot,
-
wskazanie przez <subjectIndicatorRef> czyli wskazanie zasobu wskazującego
podmiot,
-
wskazanie przez <resourceRef> czyli wskazanie zasobu, który jest danym
podmiotem;
•
węzeł (topic mape node) – reprezentacja pojęcia, powiązania i zakresu.
Topic Maps odnosząc się do przedmiotów opisywanych przez mapę mówi o podmiotach,
które są reprezentowane przez pojęcia. Nie ma możliwości określenia, czy dane pojęcie jest
klasą czy instancją, poza sytuacją gdy istnieje inne pojęcie stwierdzające, że jest instancją
pierwszego pojęcia, które wtedy jest klasą – ”sleeping class problem”. Żaden inny element
poza pojęciem, wystąpieniem i powiązaniem nie może być instancją klasy. Powiązania są
automatycznie wielokierunkowe: jeśli „Shakespeare napisał Hamleta” to automatycznie „
Hamlet został napisany przez Shakespeare’a”. Jest to ta sama relacja tylko wyrażona w inny
sposób. Dana relacja może zawierać więcej niż jedną rolę. Każde pojęcie gra rolę elementu
powiązania. Każde powiązanie jest instancją jakiegoś typu powiązań, a kwestia
etykietowania relacji dotyczy nazewnictwa, a nie kierunku.
W Topic Maps istnieje dobrze rozwinięta możliwość tworzenia powiązań między
powiązaniami (reification). Dane powiązanie jest reprezentowane przez pojęcie i można mu
wtedy przypisać powiązanie z innym pojęciem. Specyfikacja dysponuje zapobiegawczym
reprezentowaniem powiązań, co powoduje, że zawsze można dodać coś nowego, unikając
tworzenia zbędnych powiązań lub unieważniania istniejącej wiedzy o połączeniach pojęć
między sobą (tak dzieje się w RDF).
Ważnym elementem Topic Maps jest możliwość łączenia (merging):
-
dwóch map – wtedy wszystkie pojęcia, którym aplikacja determinuje, że mają ten sam
podmiot są łączone i wszystkie dublujące się powiązania są usuwane,
-
dwóch pojęć - powstaje pojedyncze pojęcie, którego własności są sumą własności
oryginalnych pojęć a dublujące się elementy są usuwane.
Konieczność łączenia zdarza się często - w jednej mapie może istnieć tylko jedno pojęcie
reprezentujące jeden podmiot. Istnieje możliwość, że dwa pojęcia wskazują ten sam podmiot
używając różnych wskaźników i dlatego nie są łączone. Takiej sytuacji można uniknąć
poprzez wprowadzenie trzeciego pojęcia ustalającego swoją tożsamość poprzez obydwa
wskaźniki. Zatem TM mogą być wykorzystywane do pośredniczenia między ontologiami.
Dwa pojęcia mają jeden podmiot gdy:
-
mają tę samą nazwę bazową w tym samym kontekście,
-
mają ten sam adres podmiotu,
-
używają
tego
samego
nieelektronicznego).
identyfikatora
do
wskaźnika
(w
przypadku
podmiotu
W ontologiach Topic Maps nie ma potrzeby definiowania klas oraz typów, dopóki sama
ontologia tego nie wymaga. Zaletą specyfikacji jest bardzo duża swoboda wyrażania i
tworzenia ontologii. Nie są określone własności relacji (powiązań) jak w OWL, można je
samemu zdefiniować jako typy. Ponadto nie jest zapewnione wcześniej zdefiniowane
słownictwo do nakładania ograniczeń na typy i moc zbiorów, jak również ułatwiające użycie
mechanizmy wnioskowania z własności relacji czy zasad wnioskowania. Istnieje jednak
możliwość ich zdefiniowania, jednak taka mapa nie jest kompatybilna z innymi mapami, tzn.
inna mapa nie rozpozna zdefiniowanych tam zasad. Zapewniona jest wtedy jedynie
kompatybilność ze standardem.
Najważniejsze zalety Topic Maps:
-
reprezentacja klasy i instancji przez pojedyncze pojęcie,
-
brak skierowania powiązania do wielu pojęć,
-
brak ograniczeń poprzez z góry zdefiniowane zasady,
-
możliwości łączenia map i pojęć,
-
łatwy proces reprezentowania powiązań.
1.2. Semantyka i wnioskowanie
Każda mapa TM zawiera zbiór pojęć, który jest jej fundamentalnym budulcem. Pojęcia oraz
ich charakterystyka obejmująca powiązania między nimi jest ontologią TM. Typy pojęć,
powiązań i aspektów, typy wartości aspektów oraz tematy są przykładami pojęć ontologii.
Można powiedzieć, że w pewnym sensie ontologia zawiera jedynie abstrakcyjne pojęcia,
które powinny być używane jako typy i tematy w rzeczywistej mapie. Hierarchie mogą być
budowane przez tworzenie super-typów i podtypów powiązań. To umożliwia pojęciom
dziedzicznie właściwości od pojęć nadrzędnych. Powiązania między pojęciami ontologii są
istotnym narzędziem, ponieważ są używane jako elementy wnioskowania.
Korzystnym elementem standardu jest brak zdefiniowania ograniczeń na semantyki
użytkownika. Liczba semantyk jest również nieograniczona, a zależą one od opisywanego
świata. Mapy pojęć nie mają ściśle określonych reguł, na jakich można oprzeć interpretację
opisanej informacji, a co za tym idzie wnioskowanie. W celu stworzenia ontologii w TM
należy najpierw zdefiniować reguły (semantykę). TM nie mają żadnego mechanizmu
nadającego ograniczenia na ontologie.
Wnioskowanie w TM jest uważane za właściwość systemów a nie dokumentów i dlatego
reguły wnioskowania są na zewnątrz zasięgu dokumentu. Oczywiście dokumenty TM mogą
zawierać rezultaty wnioskowania oraz efekty innych rodzajów przetwarzania. Nie są
określone również specyficzne typy powiązań i specyficzne właściwości różnych rodzajów
typów powiązań. TopicMaps.Org rozważa możliwość zapewnienia dodatkowej składni dla
reguł wnioskowania, a tym samym rozszerzenie zasięgu specyfikacji.
Hierarchie typów oraz przechodniość w TM pozwalają na wnioskowanie wiedzy
niezakodowanej w mapie, jednak mapa może zawierać informacje, z których odbywa się
wnioskowanie oraz posiada reguły wnioskowania zdefiniowane na poziomie ontologii o
czerpaniu bezpośredniej wiedzy.
Przykład przechodniości:
If $topic1 is a sibling of $topic2
and $topc2 is a male
then topic1 is a brother.
W powyższym przykładzie pojawiają się następujące komponenty reguł:
• „If <warunek> then <wniosek>” definiuje regułę wnioskowania,
• „$topic1”, „$topic2” są zmiennymi, które powinny być instancjami kiedy reguła jest
ewaluowana,
• „is a sibling of” oraz „is a male” są typami powiązań w pytaniu,
• „is a brother” jest wnioskowanym typem powiązania.
1.3. Zastosowania
Topic Maps przede wszystkim przeznaczone są do tradycyjnego publikowania i
segregowania wiedzy, często nazywane są modelem danych, a nie językiem ontologii. Wraz
z upływem czasu i rozwojem standardu wykształciły się inne zastosowania Topic Maps:
•
Topic Maps mogą być podstawą budowy systemów zarządzania wiedzą korporacyjną.
•
Klasyfikowanie zasobów w repozytorium, ułatwienie ich wyszukiwania i przeglądania
przy zastosowaniu takich sposobów jak skorowidze, systemy odsyłaczy, glosariusze,
tezaurusy.
•
Filtrowanie: dostosowanie zbioru informacji do potrzeb określonego użytkownika.
•
Porządkowanie nieustrukturalizowanych danych pozwalające na szybszy i łatwiejszy
dostęp do informacji.
•
Wyszukiwanie właściwej informacji za pomocą odpowiedniego języka zapytań.
•
Definiowanie złożonych struktur wiedzy i wiązanie (w celu uzyskania danych z
zasobów) ich z zasobami informacyjnymi, co umożliwia sprawne systematyzowanie
informacji (klasyfikowanie za pomocą TM ułatwiające wyszukiwanie), jej pozyskiwanie
i współdzielenie w różnych aplikacjach.
•
Organizowanie i zarządzanie zbiorami informacji oraz łączenie ich w taki sposób, aby
zapewnić łatwiejsze poruszanie się między nimi.
•
Usprawnienie następujących problemów:
-
tworzenie, pozyskiwanie i rozpowszechnianie informacji w postaci dokumentów
elektronicznych,
-
umożliwianie pracownikom organizacji dostępu do rozproszonych źródeł danych,
ich klasyfikacji i wyszukiwania,
-
wyszukiwanie informacji za pomocą wyszukiwarek internetowych,
-
poprawa niekompatybilnych formatów dokumentów,
-
uzgadnianie słownika, schematów klasyfikacyjnych oraz barier adaptacyjnych (w
sytuacji gdy słownik nie jest uzgodniony),
•
zarządzanie wiedzą (co wynika z powyższych).
Ujmowanie pojęcia, o którym mówi źródło oraz relacji między poszczególnymi źródłami
w sposób niezależny od implementacji.
•
Tworzenie wirtualnych zbiorów dokumentów oraz interfejsów dla baz wiedzy i baz
danych.
•
Wymiana i przesyłanie zakodowanej wiedzy.
•
Budowanie stron bazujących na Topic Maps, ułatwiających i usprawniających
wyszukiwanie.
•
Organizacja zawartości w systemach zarządzających wiedzą– integracja informacji z
różnych źródeł (merging), kierowanie systemami eksperckimi.
2. RDF i RDFS
RDF2
(Resource
Description
Framework)
jest
językiem
ogólnego
stosowania
do
reprezentacji informacji w sieci www, przeznaczonym do wyrażania logicznych zdań przy
użyciu ścisłego formalnego słownictwa. Jest narzędziem stanowiącym podstawy dla innych
bardziej zaawansowanych języków twierdzeń. Język definiujący RDF składa się ze zbioru
zasobów RDF, które mogą być używane do opisu innych zasobów RDF (w tym również
właściwości). Rdzeniowe słownictwo jest zdefiniowane w przestrzeni nazw nieformalnie
nazywanej
„rdfs”.
Przestrzeń
nazw
http://www.w3.org/2000/01/rdf-schema#
jest
i
jest
identyfikowana
skojarzona
przez
z
referencję
przedrostkiem
URI
„rdfs”.
Specyfikacja używa również przedrostka „rdf” odnoszącego się do przestrzeni nazw
http://www.w3.org/1999/02/22-rdf-syntax-ns#.
RDFS3 (RDF Schema) jest semantycznym rozszerzeniem RDF wzbogacającym go o
dodatkową
funkcjonalność
pozwalajacą
na
tworzenie
prostych
ontologii.
Obydwie
specyfikacje zostaną opisane razem w poniższych sekcjach rodziału 3.2.
2.1. Struktura
Podstawowe elementy RDF to węzły reprezentujące pojęcia oraz łuki między węzłami
reprezentujące binarne relacje4 między pojęciami (jeden łuk łączy tylko dwa węzły:
początkowy i końcowy).
1) Klasy
Zasoby RDF mogą być podzielone na grupy zwane klasami. Elementami klas są instancje.
Klasy same są zasobami. Są identyfikowane referencjami URI i mogą być opisywane za
pomocą właściwości RDF. Właściwość rdf:type jest używana do określania, że dany zasób
jest instancją klasy.
RDF rozróżnia klasę i zbiór jej instancji. Z każdą klasą skojarzony jest zbiór nazywany
wnętrzem klasy i będący zbiorem jej instancji. Dwie klasy mogą mieć ten sam zbiór instancji,
ale być różnymi klasami. Instancje takich klas mają wtedy różne właściwości. Klasa może
być elementem swojego własnego wnętrza i swoją własną instancją. Grupa zasobów
stanowiących klasy RDF jest klasą nazywaną rdfs:Class.
2
3
4
Por. szerzej http://www.w3.org/TR/rdf-concepts/
Por. szerzej http://www.w3.org/TR/rdf-schema/
Relacja binarna (dwuargumentowa, nazywana również relacją) jest zbiorem uporządkowanych par (x,y), co oznacza, że x jest
w relacji z y.
Jeżeli klasa A jest podklasą klasy B, to wszystkie instancje klasy A są również instancjami
klasy B. Pojęcie super-klasa jest używane jako odwrotność podklasy.
Wszystkie typy danych są klasami. Instancje klasy, która jest typem danych, są elementami
przestrzeni wartości tego typu.
rdfs:Resorce – zasób, nazywa wszystkie rzeczy opisywane przez RDF, są one instancjami
tej klasy, która jest klasą wszystkiego i wszystkie inne klasy są jej podklasami. rdfs:Resorce
jest instancją rdfs:Class.
rdfs:Class – jest klasą zasobów będących klasami RDF.
rdfs:Literal – jest klasą wartości liczbowo-literowych, takich jak integer czy string. Wartości
liczbowo-literowe mogą być proste lub mieć pewien typ. Te posiadające typ są instancjami
klasy typów danych. rdfs:Literal jest instancją rdfs:Class i podklasą rdfs:Resorce.
rdfs:Datatype – klasa typów danych. Wszystkie jej instancje korespondują z modelem typów
danych RDF. rdfs:Datatype jest zarówno instancją jak i podklasą rdfs:Class. Każda jej
instancja jest podklasą rdfs:Literal.
rdf:XMLLiteral – klasa wartości liczbowo-literowych XML. Jest instancją rdfs:Datatype i
podklasą rdfs:Literal.
rdf:Property – klasa właściwości RDF, jest instancją rdfs:Class.
2) Właściwości
Właściwości są relacjami między podmiotem a obiektem. Istnieje również pojęcie
podwłaściwości. Jeżeli P jest podwłaściwością Q, to wszystkie pary zasobów powiązane
właściwością P są również powiązane właściwością Q. Termin super-właściwość jest
używany jako odwrotność podwłaściwości.
rdfs:range – zasięg, jest instancją klasy rdf:Property używaną do określania, że wartości
danej właściwości są instancjami jednej lub więcej klas.
Trójka P rdfs:range C oznacza, że P jest instancją klasy rdf:Property, że C jest instancją
rdfs:Class i zasoby wskazywane przez obiekty zdania, których predykatem jest P są
instancjami klasy C.
Jeśli P ma więcej niż jedną właściwość rdfs:range to zasoby wskazywane przez obiekty
zdania z predykatem P są instancjami wszystkich klas wskazywanych przez właściwości
rdfs:range.
Ta właściwość może być zastosowana sama do siebie. Zasięg właściwości rdfs:range jest
klasą rdfs:Class i wskazuje, że każdy zasób będący wartością tej właściwości jest instancją
klasy rdfs:Class.
Właściwość rdfs:range jest stosowana do właściwości, co może być reprezentowane za
pomocą właściwości rdfs:domain. Dziedzina właściwości rdfs:range jest klasą rdf:Property,
co oznacza, że każdy zasób z właściwością rdfs:range jest instancją klasy rdf:Property.
rdfs:domain – dziedzina, jest instancją rdf:Property używaną do wskazywania, że każdy
zasób mający daną właściwość jest instancją jednej lub więcej klas. Trójka postaci P
rdfs:domain C stwierdza, że zasoby wskazywane przez podmiot zdania, którego predykatem
jest P są instancjami klasy C. Jeżeli P ma więcej niż jedną właściwość rdfs:domain, wtedy
zasoby wskazywane przez podmioty trójki z predykatem P są instancjami wszystkich klas
wskazywanych przez właściwości rdfs:domain.
Ta właściwość może być zastosowana sama do siebie. Dziedziną właściwości rdfs:domain
jest klasa rdf:Property i wskazuje, że każdy zasób będący wartością tej właściwości jest
instancją klasy rdf:Property. Zasięgiem właściwości rdfs:domain jest klasa rdfs:Class, to
znaczy, że każdy zasób będący wartością rdfs:domain jest instancją rdfs:Class.
rdf:type – typ, jest instancją rdf:Property stwierdzającą, że zasób jest instancją klasy. Trójka
postaci R rdf:type C oznacza, że C jest klasą a R jest jej instancją. Dziedziną właściwości
rdf:type jest rdfs:Resorce, a zasięgiem rdfs:Class.
rdfs:subClassOf – podklasa, jest instancją rdf:Property stwierdzającą, że wszystkie
instancje jednej klasy są instancjami innej klasy. Trójka postaci C rdfs:subClassOf D
oznacza, że C i D są klasami i że C jest podklasą D. Ta właściwość jest przechodnia, jej
dziedziną i zasięgiem jest rdfs:Class.
rdfs:subPropertyOf – podwłaściwość, jest instancją rdf:Property używaną do wskazywania,
że wszystkie zasoby związane jedną właściwością są jednocześnie powiązane drugą
właściwością. Zdanie postaci P rdfs:subPropertyOf Q stwierdza, że P i Q są właściwościami,
a P jest podwłaściwością Q. Ta właściwość jest przechodnia, jej dziedziną i zasięgiem jest
rdf:Property.
rdfs:label – etykieta, jest instancją rdf:Property, która może być używana do nadawania
czytelnych dla człowieka nazw zasobów. Trójka postaci R rdfs:label L stwierdza, że L jest
czytelną dla człowieka nazwą R.
Dziedziną właściwości rdfs:label jest rdfs:Resorce, a jej zasięgiem rdfs:Literal. Wspierane są
również wielojęzykowe etykiety.
rdfs:comment – komentarz, jest instancją rdf:Property do zapewnienia czytelnego dla
człowieka opisu zasobu (dokumentu). Trójka postaci R rdfs:comment L stwierdza, że L jest
czytelnym dla człowieka opisem R. Dziedziną właściwości rdfs:comment jest rdfs:Resorce a
jej zasięgiem rdfs:Literal.
Tekstowe komentarze pomagają wyjaśniać znaczenie klas i właściwości RDF. Taka
szeregowa dokumentacja uzupełnia użycie obu formalnych technik (ontologii i zasad języka)
oraz nieformalnych (dokumentacja, przykłady, przypadki testowe). Różnorodność form
dokumentacji może być łączona do wskazywania zamierzonego znaczenia klas i właściwości
opisywanych w słownictwie RDF. Jeżeli to słownictwo jest wyrażone w postaci grafów RDF,
to słownictwa definiowane w innych przestrzeniach nazw mogą być wykorzystywane do
zapewnienia bogatszej dokumentacji. Wielojęzykowa dokumentacja jest wspierana przez
wykorzystanie językowego etykietowania.
Specyfikacja wprowadza słownictwo RDF do opisu sensownego użycia klas i właściwości
danych RDF. Na przykład słownictwo RDF może opisywać ograniczenia typów wartości,
które są odpowiednie dla danej właściwości lub klasy, do których przypisane są dane
właściwości.
Język RDF zapewnia mechanizm opisywania tych informacji, ale nie mówi czy lub jak
aplikacja powinna ich używać. Na przykład jeżeli słownictwo RDF zapewnia, że właściwość
autor jest używana do wskazania zasobów, które są instancjami klasy Osoba, to nie
informuje czy i w jaki sposób aplikacja powinna dokonywać przetwarzania, które obejmie te
informacje. Różne aplikacje będą używać jej w różny sposób. Na przykład narzędzia
sprawdzające dane mogą używać tego do odkrywania błędów w niektórych zbiorach danych,
interaktywny edytor może sugerować odpowiednie wartości, a aplikacja wnioskująca może
być używana do wnioskowania dodatkowych informacji z danych.
Słownictwo RDF może opisywać relacje między elementami z różnego, niezależnie
rozwijanego słownictwa. Jeżeli referencje URI są używane do identyfikowania klas i
właściwości w sieci, możliwe jest tworzenie nowych właściwości mających dziedzinę lub
zasięg, których wartość jest klasą zdefiniowaną w innej przestrzeni nazw.
3) Kontenery klas i właściwości
Kontenery RDF są zasobami używanymi do reprezentowania zbiorów. Ten sam zasób może
pojawiać się w kontenerze więcej niż raz. Kontener może być zawarty w samym sobie.
Są zdefiniowane trzy różne rodzaje kontenerów. Podczas gdy formalne semantyki
wszystkich trzech klas kontenerów są identyczne, różne klasy mogą być używane do
wskazywania formalnie dalszych informacji. Właściwość danego kontenera nie musi być
właściwością wszystkich jego elementów, na przykład jeśli kurnik ma właściwość, że jest
zrobiony z drewna to nie znaczy, że wszystkie kury wewnątrz są drewniane.
Kontenery są definiowane za pomocą następujących klas i właściwości.
rdfs:Container – klasa kontener, jest super-klasą wszystkich klas kontenerów RDF rdf:Bag,
rdf:Seq i rdf:Alt.
rdf:Bag – klasa „torebek”, jest podklasą rdfs:Container. Formalnie nie ma różnicy między
poszczególnymi rodzajami kontenerów, ale kontener „torebka” jest konwencjonalnie używany
do wskazywania człowiekowi nieuporządkowanych elementów zawartości.
rdf:Seq – klasa sekwencji, jest podklasą rdfs:Container. Sekwencja jest konwencjonalnie
używana do wskazywania człowiekowi, że kontener jest uporządkowany, istnieje
uporządkowanie właściwości elementów kontenera (container membership properties).
rdf:Alt – klasa alternatyw, jest podklasą rdfs:Container. Alternatywa wskazuje człowiekowi,
że typowe przetwarzanie będzie polegało na wyselekcjonowaniu jednego z elementów
kontenera. Pierwszy element kontenera jest pustym wyborem.
rdfs:ContainerMembershipProperty – klasa właściwości elementów kontenera posiada
jako instancje właściwości rdf:_1, rdf:_2, rdf:_3 ..., które są używane do stwierdzenia, że zasób
jest elementem kontenera. Jest podklasą rdf:Property, każda instancja tej klasy jest
podwłaściwością rdfs:member.
Przy danym kontenerze C trójka postaci C rdf:_nnn O, gdzie nnn jest dziesiętną
reprezentacją liczby całkowitej większej od zera i bez zer z przodu, stwierdza, że O jest
elementem kontenera C.
Właściwości elementów kontenera mogą być stosowane do zasobów innych kontenerów.
rdfs:member – element, jest instancją rdf:Property, która jest super-właściwością wszystkich
właściwości elementów kontenerów, np. każda taka właściwość ma relację podwłaściwości
do właściwości rdfs:member. Dziedziną i zasięgiem rdfs:member jest rdfs:Resorce.
4) Zbiory RDF
Kontenery RDF są otwarte w tym sensie, że rdzeń specyfikacji nie definiuje mechanizmu
określającego, że nie ma więcej elementów kontenera. Słownictwo zbiorów klas i
właściwości może opisywać zamknięte zbiory, takie które nie mają więcej elementów.
Zbiór jest reprezentowany jako lista elementów, która może być pusta.
rdf:List – lista jest instancją rdfs:Class używaną do tworzenia opisów list i podobnych
struktur.
rdf:first – pierwszy element listy, jest instancją rdf:Property używaną do tworzenia opisów
list i podobnych struktur. Trójka postaci L rdf:first O stwierdza, że O jest pierwszym
elementem listy L. Dziedziną rdf:first jest lista, zasięgiem rdfs:Resorce.
rdf:rest – reszta listy, jest instancją rdf:Property używaną do tworzenia opisów list i
podobnych struktur. Trójka postaci L rdf:rest O stwierdza, że O jest resztą listy L. Dziedziną i
zasięgiem reszty jest lista.
rdf:nil – zero, jest instancją rdf:List używaną do reprezentowania pustej listy lub podobnej
struktury. Trójka postaci L rdf:rest rdf:nil stwierdza, że L jest listą mającą jeden element. Ten
element może być określony za pomocą rdf:first.
5) Słownictwo reifikacji
Oryginalna specyfikacja składni i modelu RDF definiowała słownictwo do opisu zdań RDF
bez stwierdzania (wygłaszania) ich. Specyfikacja nie zapewniała formalnej semantyki dla
tego słownictwa a formalne definicje były sprzeczne. Obecna specyfikacja RDF nie
przydziela formalnych semantyk temu słownictwu.
rdf:Statement – zdanie, jest instancją rdfs:Class przeznaczoną do reprezentacji klasy zdań
RDF. Zdanie RDF jest zbudowane z trójek RDF. Podmiot zdania jest instancją rdfs:Resorce
identyfikowaną przez podmiot trójki. Predykat zdania RDF jest instancją rdf:Property
identyfikowaną przez predykat trójki. Obiekt zdania RDF jest instancją rdfs:Resorce
identyfikowaną przez obiekt trójki. Zdanie jest w dziedzinie właściwości rdf:predicate,
rdf:subject, rdf:object. Różne pojedyncze instancje zdania mogą mieć te same wartości dla
właściwości ich podmiotów, predykatów i obiektów.
rdf:subject – podmiot, jest instancją rdf:Property używaną do określania podmiotu zdania.
Trójka postaci S rdf:subject R stwierdza, że R jest podmiotem zdania S. Dziedziną
rdf:subject jest rdf:Statement a zasięgiem rdfs:Resource.
rdf:predicate – predykat, jest instancją rdf:Property używaną do określania predykatu
zdania. Trójka postaci S rdf:predicate P stwierdza, że właściwość P jest predykatem zdania
S. Dziedziną rdf:predicate jest rdf:Statement, a zasięgiem rdfs:Resource.
rdf:object – obiekt, jest instancją rdf:Property używaną do określania obiektu zdania. Trójka
postaci S rdf:object O stwierdza, że O jest obiektem zdana S. Dziedziną rdf:object jest
rdf:Statement, a zasięgiem rdfs:Resorce.
6) Właściwości użyteczności
Klasy i właściwości są zdefiniowane w RDF w rdzeniowych przestrzeniach nazw.
rdfs:seeAlso – „zobacz też”, jest instancją rdf:Property wskazującą zasób mogący
dostarczyć dodatkowych informacji o zasobie podmiotu. Trójka postaci S rdfs:seeAlso O
stwierdza, że zasób O może zapewnić dodatkowe informacje o S. Jest możliwe
odzyskiwanie reprezentacji O z sieci WWW, ale nie jest wymagane. Przy odzyskiwaniu tych
reprezentacji nie są narzucone żadne ograniczenia na ich format. Dziedziną i zasięgiem
rdfs:seeAlso jest rdfs:Resorce.
rdfs:isDefinedBy – „zdefiniowany przez”, jest instancją rdf:Property używaną do
wskazywania zasobu definiującego zasób podmiotu. Ta właściwość może być używana do
wskazywania słownictwa RDF, w jakim dany zasób jest opisany. Trójka postaci S
rdfs:isDefinedBy O stwierdza, że zasób O definiuje S. rdfs:isDefinedBy jest podwłaściwością
rdfs:seeAlso. Dziedziną i zasięgiem rdfs:isDefinedBy jest rdfs:Resorce.
rdf:value – wartość, jest instancją rdf:Property używaną do opisu ustrukturalizowanych
wartości. Wartość ma znaczenie w samej sobie, zapewnia fragment słownictwa możliwy do
wykorzystania w idiomach. Dziedziną i zasięgiem wartości jest rdfs:Resorce.
7) Podsumowanie informacji o klasach i właściwościach
Poniższe tabele prezentują przegląd słownictwa RDF, przedstawiając je oryginalnie
zdefiniowane w specyfikacji RDF wraz z klasami i właściwościami wywodzącymi się z RDF
Schema.
Nazwa klasy
rdfs:Resource
Komentarz
Zasób klas, wszystko.
Klasa wartości liczbowo-literowych, np. stringi tekstowe,
rdfs:Literal
liczby całkowite.
rdf:XMLLiteral
Klasa wartości liczbowo-literowych XML.
rdfs:Class
Klasa wszystkich klas.
rdf:Property
Klasa właściwości RDF.
rdfs:Datatype
Klasa typów danych RDF.
rdf:Statement
Klasa zdań RDF.
rdf:Bag
Klasa nieuporządkowanych kontenerów.
rdf:Seq
Klasa uporządkowanych kontenerów.
rdf:Alt
Klasa kontenerów alternatyw.
rdfs:Container
Klasa kontenerów RDF.
rdfs:ContainerMembershipProperty
rdf:List
Klasa właściwości elementów kontenerów, rdf:_1, rdf:_2,
wszystkie, które są podwłaściwościami 'member'.
Klasa list RDF.
Tabela 1 Klasy RDF i RDFS
Nazwa
właściwości
Komentarz
Dziedzina
Zasięg
rdf:type
Podmiot jest instancją klasy.
rdfs:Resource rdfs:Class
rdfs:subClassOf
Podmiot jest podklasą klasy.
rdfs:Class
rdfs:subPropertyOf Podmiot jest podwłaściwością właściwości. rdf:Property
rdfs:Class
rdf:Property
Nazwa
Komentarz
właściwości
Dziedzina
Zasięg
rdfs:domain
Dziedzina właściwości podmiotu.
rdf:Property
rdfs:Class
rdfs:range
Zasięg właściwości podmiotu.
rdf:Property
rdfs:Class
rdfs:label
Czytelna dla człowieka nazwa podmiotu.
rdfs:Resource rdfs:Literal
rdfs:comment
Opis zasobu podmiotu.
rdfs:Resource rdfs:Literal
rdfs:member
Element zasobu podmiotu.
rdfs:Resource rdfs:Resource
rdf:first
Pierwszy element listy RDF.
rdf:List
rdfs:Resource
rdf:List
rdf:List
rdf:rest
Reszta listy RDF, to, co za pierwszym
elementem.
rdfs:seeAlso
Dalsze informacje o zasobie podmiotu.
rdfs:isDefinedBy
Definicja zasobu podmiotu.
rdf:value
Idiomatyczna
właściwość
używana
uporządkowanych wartości.
do
rdf:subject
Podmiot zdania RDF.
rdf:Statement rdfs:Resource
rdf:predicate
Predykat zdania RDF.
rdf:object
Obiekt zdania RDF.
Tabela 2 Właściwości RDF i RDFS
Oprócz powyższych klas i właściwości RDF używa również właściwości rdf:_1, rdf:_2, rdf:_3
itd., z których każda jest jednocześnie podwłaściwością rdfs:member i instancją klasy
rdfs:ContainerMembershipProperty. Istnieje również instancja listy rdf:nil będąca pustą listą.
2.2. Pojęcia i abstrakcyjna składnia
W tej sekcji zajmiemy się abstrakcyjną składnią, na której bazuje RDF i która służy do
łączenia jego konkretnej składni z formalnymi semantykami.
1) Motywacje i cele RDF
Abstrakcyjna składnia RDF odzwierciedla prosty model bazujący na grafach oraz formalne
semantyki z rygorystycznie zdefiniowaną notacją wymagań, zapewniające podstawy dla
dobrze uzasadnionego wnioskowania w RDF.
Rozwój RDF był motywowany następującymi możliwościami wykorzystania:
• Meta-dane sieci www zapewniające informacje o zasobach sieci i systemach, które ją
wykorzystują (np. ocena zawartości, opis możliwości, preferencje prywatności).
• Aplikacje wymagające otwartych, a nie ograniczonych modeli informacji (np. czynności
harmonogramu, procesy organizacyjne, adnotacje zasobów sieci itp.).
• Uczynienie informacji (danych aplikacji) przetwarzalną dla maszyn, pozwolenie na
przetwarzanie danych na zewnątrz środowiska, w którym zostały stworzone.
• Interakcje wewnętrzne pomiędzy aplikacjami, łączenie danych z różnych aplikacji do
otrzymania nowej informacji.
• Zautomatyzowane przetwarzanie informacji z sieci przez agentów oprogramowania:
sieć przekształca się z zawierającej tylko informację czytelną dla człowieka do
światowej
sieci
współpracujących
ze
sobą
procesów.
RDF
zapewni
język
porozumiewania się do tych procesów.
RDF jest zaprojektowany do reprezentowania informacji w minimalnie ograniczony,
elastyczny sposób. Może być używany w samodzielnych aplikacjach, ale jego ogólność
oferuje możliwości dzielenia. W ten sposób wartość informacji wzrasta, ponieważ staje się
ona dostępna dla większej ilości aplikacji w Internecie.
Cele projektowe RDF:
• prosty model danych,
• formalne semantyki i dające się udowodnić wnioskowanie,
• elastyczne, bazujące na URI słownictwo,
• wykorzystanie składni bazującej na XML,
• wspieranie użycia typów danych XML Schema,
• możliwość tworzenia zdań o dowolnym źródle.
RDF posiada prosty model danych, łatwy do przetwarzania przez aplikacje, który jest
niezależny od konkretnych składni. RDF ma formalne semantyki zapewniające podstawy do
wnioskowania znaczenia wyrażeń RDF. Wspiera definiowanie wymogów zapewniających
podstawy do określania reguł wnioskowania. Słownictwo jest elastyczne, rozszerzalne i
bazuje
na
URI
z
opcjonalnymi
identyfikatorami.
RDF
może
używać
wartości
reprezentowanych zgodnie z typami danych XML Schema, w ten sposób wspomaga
wymianę informacji z aplikacjami XML.
Nie zakłada się, że o dowolnym źródle dostępna jest kompletna informacja. RDF nie
zapobiega tworzeniu bezsensownych lub niespójnych z innymi zdań. Projektanci aplikacji
używających RDF powinni mieć świadomość tego i projektować aplikacje tak, aby
akceptowały niekompletne lub niepełne źródła informacji.
2) Pojęcia
RDF używa następujących kluczowych pojęć:
a) graficzny model danych (grafy),
b) słownictwo bazujące na URI,
c) typy danych,
d) dane liczbowo-literowe (literals),
e) wyrażenia o prostych faktach,
f) konsekwencje (wnioski).
a) Graficzny model danych
Podstawowa struktura każdego wyrażenia RDF jest zbiorem trójek (zdań). Każda trójka
składa się z podmiotu, predykatu i obiektu. Zbiór takich trójek nazywamy grafem. Może
być on zilustrowany jako diagram, składający się z węzłów i skierowanych łuków.
Zdanie:
Każda trójka reprezentuje zdanie wyrażające relację między rzeczami wskazywanymi
przez węzły. Każde zdanie składa się z podmiotu, predykatu (właściwości) i obiektu.
Kierunek łuku jest ważny i zawsze idzie w stronę obiektu. Węzły grafu to jego obiekt i
podmiot, a łuk to relacja.
Twierdzenie o trójkach RDF mówi, że niektóre relacje wskazywane przez predykaty
obowiązują między rzeczami wskazywanymi przez podmiot i obiekt trójki. Znaczenie grafu
jest logiczną koniunkcją zdań korespondujących ze wszystkimi jego trójkami.
b) Słownictwo bazujące na URI
Węzły mogą mieć wskaźniki URI z opcjonalnymi identyfikatorami fragmentów, danymi
liczbowo-literowymi albo mogą być puste (nie mające oddzielnej formy identyfikacji).
Właściwości są referencjami URI. Referencje URI używane jako węzły identyfikują to, co
reprezentują węzły. URI używany jako predykat identyfikuje relację między rzeczami
reprezentowanymi przez węzły, które zawiera. Referencja predykatu może być również
węzłem grafu. Pusty węzeł jest węzłem nie będącym referencją URI ani daną liczbowoliterową. Pusty węzeł jest specyficznym węzłem, który może być używany w więcej niż
jednym zdaniu, ale nie ma wrodzonej nazwy.
Konwencja używana przez niektóre liniowe reprezentacje grafów RDF, pozwalająca
różnym zdaniom odwoływać się do tych samych niezidentyfikowanych zasobów, używa
identyfikatorów pustych węzłów, będących lokalnymi identyfikatorami, które mogą być
rozróżniane od URI oraz danych liczbowo-literowych. Gdy grafy są łączone, ich puste
węzły muszą być trzymane osobno, jeśli ma zostać zachowane znaczenie. To może
wymagać ponownego przydziału identyfikatorów pustym węzłom. Identyfikatory pustych
węzłów nie są częścią abstrakcyjnej składni RDF i reprezentacja trójek je zawierających
jest całkowicie zależna od konkretnej, używanej w danym momencie składni.
c) Typy danych
Typy danych są używane w reprezentacji danych liczbowo-literowych. Typ danych składa
się z leksykalnej przestrzeni, przestrzeni wartości oraz mapowania słownictwa do
wartości.
Przykład mapowania typu danych xsd:boolean, gdzie każdy element przestrzeni wartości
ma dwie leksykalne reprezentacje.
Przestrzeń wartości
{T, F}
Przestrzeń leksykalna
{"0", "1", "true", "false"}
Mapowanie słownictwo-wartości {<"true", T>, <"1", T>, <"0", F>, <"false", F>}
Tabela 3 Mapowanie danych xsd:boolean [1]
RDF predefiniuje tylko jeden typ danych rdf:XMLLiteral, używany do umieszczania XML w
RDF. Nie ma żadnego wbudowanego pojęcia liczb lub dat. RDF wykorzystuje typy danych
zdefiniowane osobno i identyfikowane poprzez referencje URI. W tym celu szeroko
wykorzystywane są predefiniowane typy danych XML Schema. Ponadto RDF nie
zapewnia mechanizmu definiującego nowe typy danych.
d) Dane liczbowo-literowe
Dane liczbowo-literowe reprezentują wartości takie jak liczby i daty w znaczeniu
lreprezentacji leksykalnej. Wszystko co jest przez nie reprezentowane, może być również
reprezentowane przez URI, ale wygodniej jest używać leksykalnej reprezentacji. Dane
liczbowo-literowe mogą być obiektami zdań, nie mogą być podmiotami ani predykatami.
Mogą być proste lub typowane:
• Proste wartości są stringami łączonymi z opcjonalnymi etykietami językowymi. Mogą
być używane do zwykłych tekstów w naturalnym języku.
• Wartości typowane to stringi łączone z identyfikatorami URI. Wskazują elementy
identyfikowanej przestrzeni wartości.
Kontynuacja poprzedniego przykładu:
Typ leksykalny
Mapowanie słownictwo-wartości Wartość
<xsd:boolean, "true">
<"true", T>
T
<xsd:boolean, "1">
<"1", T>
T
<xsd:boolean, "false">
<"false", F>
F
<xsd:boolean, "0">
<"0", F>
F
Tabela 4 Mapowanie danych xsd:boolean [2]
Jeżeli wymagane są adnotacje językowe, muszą być zawarte jako znacznik, zwykle za
pośrednictwem atrybutu xml:Lang.
e) Wyrażenia prostych faktów
Niektóre proste fakty wskazują relacje między dwoma rzeczami. Taki fakt może być
reprezentowany przez trójkę RDF, w której predykat nazywa relację, a podmiot i obiekt
wskazują rzeczy połączone relacją. Dobrze znaną reprezentacją takiego faktu może być
wiersz tabeli relacyjnej bazy danych. Tabela ma dwie kolumny odpowiadające podmiotowi
i obiektowi w trójkach RDF. Nazwa tabeli odpowiada predykatowi. Inna znajoma
reprezentacja to predykaty miejsc w logice pierwszego rzędu.
Relacyjne bazy danych pozwalają tabeli mieć dowolną liczbę kolumn, wiersz każdej
informacji wyrażenia odpowiada predykatowi logiki pierwszego rzędu z dowolną liczbą
miejsc. Taki wiersz lub predykat musi być dekomponowany dla reprezentacji jako trójka
RDF. Prosta forma dekompozycji tworzy nowy pusty węzeł odpowiadający wierszowi i
nowa trójka jest tworzona dla każdej komórki wiersza. Podmiot każdej trójki jest nowym
pustym węzłem, predykat odpowiada nazwie kolumny a obiekt wartości w komórce. Nowy
pusty węzeł może mieć również właściwość rdf:type, której wartość odpowiada nazwie
tabeli.
Bardziej złożone fakty są wyrażone w RDF za pomocą koniunkcji prostych binarnych
relacji. RDF nie zapewnia środków do reprezentacji negacji i alternatywy.
f) Konsekwencje (wnioski)
Idea znaczenia i wnioskowania w RDF jest podbudowana formalnymi pojęciami
wniosków. Wyrażenie A implikuje wyrażenie B, jeżeli każde wydarzenie powodujące, że A
jest prawdziwe, pociąga w konsekwencji prawdziwość B. Na tej podstawie, jeżeli
zakładana jest prawdziwość wyrażenia A, to prawdziwość wyrażenia B może być
wnioskowana.
3) Słownictwo URI i przestrzeń nazw
RDF używa referencji URI do identyfikacji zasobów i właściwości. Konkretne referencje URI
otrzymują określone znaczenia w RDF. URI o następującym wyglądzie są zdefiniowane
przez specyfikację RDF:
http://www.w3.org/1999/02/22-rdf-syntax-ns#
(konwencjonalnie
skojarzone z prefiksem przestrzeni nazw rdf:). Używany z RDF/XML
prefiks koresponduje z przestrzenią nazw XML i jest skojarzony ze
słownictwem RDF.
4) Typy danych
Abstrakcyjne
typy
danych
abstrakcyjnym
językiem
XML
używane
Schema.
w
Typy
RDF
są
danych
kompatybilne
z
składają
z
się
przestrzeni
leksykalnej
Unicode5),
(zbiór
przestrzeni
wartości
i
mapowania pomiędzy nimi (zbiór par elementów, z których pierwszy
jest z przestrzeni leksykalnej, a drugi z przestrzeni wartości).
Każdy element z przestrzeni leksykalnej jest mapowany do dokładnie
jednego elementu z przestrzeni wartości. Każdy element z przestrzeni
wartości może mieć parę z dowolną liczbą (również zero) elementów
przestrzeni leksykalnej. Typ danych jest identyfikowany przez jedną
lub więcej referencji URI. RDF może używać dowolnych typów danych,
również
niezdefiniowanych
podporządkowują
się
one
w
XML
powyższemu
Schema
pod
schematowi.
warunkiem,
Istnieją
że
również
wbudowane typy danych XML Schema niekompatybilne z RDF, np. QName.
5) Zawartość XML wewnątrz grafów RDF
RDF zapewnia zawartość XML jako dane liczbowo-literowe. Powstają one przy
użyciu rdf:parseType="Literal"
w składni XML/RDF. Taka zawartość
jest
przy
wskazywana
które
w
posiadają
grafach
specjalny
RDF
typ
pomocy
danych
danych liczbowo-literowych,
rdf:XMLLiteral,
identyfikowany
następującym URI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral.
6) Abstrakcyjna składnia
Abstrakcyjna składnia RDF jest zbiorem trójek nazywanych grafami RDF. Nad abstrakcyjną
składnią zdefiniowane są formalne semantyki. Aplikacje mogą reprezentować grafy w
dowolnej ekwiwalentnej formie.
Trójka RDF zawiera trzy elementy:
• podmiot, może być referencją URI lub pustym węzłem,
• predykat nazywany również właściwością trójki, może być referencją URI,
• obiekt mogący być referencją URI, daną liczbowo-literową albo pustym węzłem.
Graf RDF jest zbiorem trójek, zbiór jego węzłów jest zbiorem podmiotów i obiektów.
Dwa grafy RDF G i F są równoważne, jeśli istnieje bijekcja M między zbiorami ich węzłów
taka, że
(1) M odwzorowuje puste węzły w puste węzły,
(2) M(lit)=lit dla każdej danej liczbowo-literowej lit, która jest węzłem grafu G,
5
Unicode jest komputerowym zestawem znaków, w zamierzeniu mającym obejmować wszystkie pisma na świecie.
(3) M(Uri)=Uri dla każdej referencji URI Uri, która jest węzłem grafu G,
(4) trójka (s,p,o) należy do grafu G wtedy i tylko wtedy, gdy trójka (M(s),p,M(o)) należy
do grafu F.
Dwie referencje URI w RDF są równe wtedy i tylko wtedy, gdy stringi Unicode mają
identyczne kolejne znaki. URI są kompatybilne z typem danych anyURI zdefiniowanym w
XML Schema oraz z IRI (International Resource Identifiers)6.
Dana liczbowo-literowa zawiera w grafie RDF jeden lub dwa nazwane komponenty.
Wszystkie takie dane mają leksykalną postać będącą stringiem Unicode. Proste dane mają
postać leksykalną i opcjonalnie etykietę językową. Typowane dane mają formę leksykalną i
URI.
Dwie wartości liczbowo-literowe są równe wtedy i tylko wtedy, gdy spełnione są następujące
warunki:
• stringi ich form leksykalnych są dokładnie takie same (z uwzględnieniem kolejności),
• obydwie lub żadna mają etykiety językowe,
• etykiety językowe, jeśli występują, są takie same,
• obydwie lub żadne mają URI,
• dwa URI, jeśli występują, są takie same znak po znaku.
Puste grafy w RDF są wyciągane z nieskończonego zbioru. Zbiór pustych węzłów, zbiór
referencji URI oraz zbiór danych liczbowo-literowych są parami rozłączne. Zbiór pustych
węzłów jest zupełnie dowolny. RDF nie tworzy referencji do wewnętrznych struktur pustych
węzłów. Mając dwa puste węzły można określić, czy są one takie same czy nie.
6
IRI jest międzynarodowym identyfikatorem zasobów będącym sekwencją znaków Unicode.
7) Identyfikatory fragmentowe
RDF używa referencji URI, które mogą zawierać fragmentowe identyfikatory dla zasobu,
wolne od kontekstu. Część URI (z wyłączeniem identyfikatora fragmentowego) identyfikuje
zasób. Podejście fragmentowych identyfikatorów pozwala na wskazywanie elementów
całkowicie na zewnątrz dokumentu lub nawet na zewnątrz sieci. W ten sposób dokumenty
(lub aplikacje rdf+xml)
odzyskiwanymi
działają
dokumentami
a
jako
pośrednicy
zbiorami
między
możliwych
niektórymi
abstrakcji
lub
pozasieciowymi elementami opisywanymi przez RDF.
To zapewnia działanie referencji URI oraz ich oznaczanie, które jest
zgodne z teorią i wykorzystaniem modelu RDF i normalnym zachowaniem
sieci. Warto zauważyć, że nigdzie nie jest wymagane aby aplikacja
RDF była zdolna do odzyskiwania jakiejkolwiek reprezentacji zasobów
identyfikowanych przez URI w grafach RDF.
2.3. Semantyka7
To, co jest uważane za znaczenie zdań w RDF może zależeć od wielu elementów, takich jak
społeczne konwencje, komentarze w naturalnym języku lub inne dokumenty. Większość tego
znaczenia jest niedostępna dla maszyn przetwarzających i jest wymieniona tutaj do
podkreślenia, że formalne semantyki nie są przeznaczone do pełnej analizy znaczenia w tak
szerokim sensie. Formalne semantyki ograniczają się same do formalnej notacji znaczenia,
które może być scharakteryzowane jako część znana pozostałym składowym znaczenia i
może być objęte mechanicznymi zasadami wnioskowania.
W celu określenia semantyk formalnego języka używana jest technika nazywana teorią
modelowania. Teoria modelowania zakłada, że język odnosi się do „świata” i opisuje
warunki, które ten „świat” musi spełnić w celu przekazywania poprawnego znaczenia dla
każdego wyrażenia w języku. Konkretny „świat” jest nazywany interpretacją, więc teoria
modelowania może być nazywana teorią interpretacji. Najważniejszą ideą jest zapewnienie
abstrakcyjnego, matematycznego opisu właściwości, które posiada każda taka interpretacja,
poprzez tworzenie możliwie dużej liczby założeń o właściwej naturze lub wewnętrznej
strukturze, zachowując w ten sposób tak dużo ogólności jak to możliwe. Najważniejszym
wykorzystaniem
formalnych
semantyk
jest
zapewnienie
technicznego
sposobu
determinowania, kiedy procesy wnioskowania są uzasadnione, czyli np. kiedy zachowują
prawdę.
7
Por. http://www.w3.org/TR/rdf-mt/
Innym sposobem określania semantyk jest zastosowanie translacji z RDF do formalnej logiki
wraz
z
teorią
modelowania.
Takie
podejście
aksjomatycznych
semantyk
zostało
zasugerowane i było wcześniej używane z różnymi alternatywnymi wersjami języków.
Konkretne wykorzystania RDF zawierające podstawy dla bardziej zaawansowanych języków
takich jak OWL, mogą nakładać dalsze semantyczne warunki. Takie dodatkowe warunki
mogą odwoływać się do semantycznych rozszerzeń RDF. Semantyczne rozszerzenia są
ograniczone przez użycie słów kluczowych must, must not, should, may
1) Interpretacje
RDF nie nakłada logicznych ograniczeń na zasięg i dziedzinę właściwości, w szczególności
właściwość może być zastosowana sama do siebie. Jednak semantyczny model rozróżnia
właściwości i klasy rozważane jako obiekty od ich wnętrza. Klasy RDF nie są rozważane
jedynie jako proste zbiory, ale są również uważane za klasyfikacje lub pojęcia mające silnie
zdeterminowaną notację równości, która przekracza proste relacje wewnętrzne. Ta
właściwość teorii modelowania ma znaczące konsekwencje w bardziej ekspresyjnych
językach opartych na RDF, takich jak OWL, które są zdolne do wyrażania bezpośrednio
identyczności między pojęciami i klasami. Ta intencjonalna natura klas i właściwości jest
często użyteczną właściwością języków deskrypcyjnych.
Referencje URI mają zawsze takie samo znaczenie kiedy tylko się pojawiają. Zapewnienie
adekwatnych semantyk wrażliwych na tymczasowe zmiany jest problemem badań.
Semantyki nie zakładają żadnych konkretnych relacji między wskazaniami URI a zasobami
sieci, otrzymywanymi przy użyciu tych referencji lub innymi elementami będącymi źródłami
takich dokumentów.
Nie istnieje jedna interpretacja grafu RDF (nie jest możliwe wyrażenie wystarczającej liczby
założeń do określenia jednej interpretacji). Im większy graf i więcej można powiedzieć na
jego podstawie o „świecie”, tym mniejszy jest zbiór prawdziwych interpretacji, na które
pozwala graf.
Wszystkie interpretacje związane są ze zbiorem nazw, nazywanym słownictwem
interpretacji. Niektóre z nich mogą nakładać specjalne znaczenia na symbole w konkretnym
słownictwie. Interpretacja bez ekstra-warunków na słownictwo nazywana jest prostą
interpretacją.
Główna semantyczna charakterystyka danych liczbowo-literowych zakłada, że ich znaczenie
jest mocno zdeterminowane przez formę stringów, jakie zawierają. Proste dane są zawsze
interpretowane jako odnoszące się do samych siebie. W przypadku typowanych danych,
pełna specyfikacja znaczenia zależy od możliwości dostępu do informacji o typie danych,
który jest zewnętrznym elementem RDF.
Definicja prostej interpretacji I słownictwa V :
1. IR – niepusty zbiór zasobów, nazywany dziedziną przestrzeni I
2. IP – zbiór właściwości I
3. IEXT – mapowanie ze zbioru IP do IR × IR, np. zbiór zbiorów par (x,y), gdzie x, y ∈ IR
4. IS – mapowanie referencji URI w V do IR ∪ IP
5. IL – mapowanie typowanych danych liczbowo-literowych w V do IR
6. LV ⊂ IR - zbiór danych liczbowo-literowych zawierający wszystkie proste dane w V.
IEXT(x) jest zbiorem par identyfikujących argumenty, dla których właściwość jest prawdziwa.
Założenie, że LV jest podzbiorem IR oznacza, że wartości liczbowo-literowe są uważane za
realne jednostki, które „istnieją”, czyli są one zasobami. To nie implikuje jednak
identyfikowania ich za pomocą URI.
Symbole podstawowych grafów RDF w I są zadane rekurencyjnie za pomocą reguł
rozszerzających interpretację mapowania oraz nazw podstawowych grafów. Reguły te
pracują przez definiowanie oznaczania każdego elementu składni RDF E w terminach
oznaczania bezpośrednich składników E.
Przyjmujemy następujące oznaczenia:
= oznacza równość,
(x,y) – uporządkowana para elementów x oraz y,
” ” – podwójny cudzysłów obejmuje stringi,
@ - wskazuje etykiety językowe,
. – trójki są zakończone kropką.
Semantyczne warunki dla podstawowych grafów
1. Jeżeli E jest prostą wartością liczbowo-literową ”aaa” w V, wtedy I(E)=aaa.
2. Jeżeli E jest prostą wartością liczbowo-literową ”aaa”@ttt w V, wtedy I(E)=(aaa,ttt).
3. Jeżeli E jest typowaną wartością liczbowo-literową w V, to I(E)=IL(E).
4. Jeżeli E jest referencją URI w V, to I(E)=IS(E).
5. Jeżeli
E
jest
podstawową
trójką
s
p
o.
wtedy
I(E)=true,
jeżeli
s, p, o∈V , I ( p) ∈ IP, ( I ( s), I (o)) ∈ IEXT ( I ( p)) , w przeciwnym wypadku I(E)=false.
6. Jeżeli E jest podstawowym grafem RDF, to I(E)=false, jeżeli I(E’)=false dla pewnej
trójki E’ w E. W przeciwnym wypadku I(E)=true.
Jeżeli słownictwo RDF nie daje semantycznej wartości pewnej nazwie w grafie, to wtedy
powyższe warunki będą zawsze zwracać wartość false dla niektórych trójek grafu, a co za
tym idzie, dla całego grafu. Odwracając to, dowolne twierdzenie o grafie zakłada, że
wszystkie nazwy w grafie właściwie odnoszą się do czegoś realnego w świecie. Ostatni
warunek implikuje, że pusty graf (pusty zbiór trójek) jest w sposób trywialny prawdziwy.
Każda referencja URI pojawiająca się w grafie jako predykat, podmiot lub obiekt musi
wskazywać coś z przecięcia IR oraz IP w każdej interpretacji spełniającej graf.
Puste węzły są traktowane jako struktury wskazujące istnienie rzeczy bez używania, a nawet
wspominania o ich nazwie. Pusty węzeł nie zakłada istnienia referencji URI odnoszącej się
do danej rzeczy. Interpretacja może określać prawdziwość grafów zawierających puste
węzły, będzie jedynie wymagać pewnych definicji zapewniających znaczenie pustych
węzłów. Załóżmy, że I jest interpretacją, A mapowaniem z pewnego zbioru pustych węzłów
do IR i niech I+A będzie rozszerzoną interpretacją I używającą A do dostarczenia
interpretacji pustych węzłów. Ponadto niech blank(E) będzie zbiorem pustych węzłów w E.
Wtedy powyższe reguły są rozszerzane o dwa nowe przypadki dla sytuacji, kiedy w grafie
występują puste węzły.
Semantyczne warunki dla pustych węzłów
1. Jeżeli E jest pustym węzłem i zdefiniowane jest A(E), to [I+A](E) = A(E).
2. Jeżeli E jest grafem RDF wtedy I(E) = true, jeśli [I+A'](E) = true dla pewnego
mapowania A’ z blank(E) do IR, w przeciwnym wypadku I(E)= false.
Należy zauważyć, że te warunki nie zmieniają definicji interpretacji, jak również że puste
węzły są bardzo dobrze zdefiniowane, a od innych węzłów różnią się jedynie tym, że nie
mają ustalonych symboli przez interpretację i nie mają globalnego znaczenia (na zewnątrz
grafu, w którym się znajdują).
Puste węzły są traktowane jak posiadające takie samo znaczenie jak egzystencjalne
zmienne w grafie, w którym się pojawiają i które mają zasięg całego grafu.
Istnieje pewna subtelna, choć istotna różnica między tworzeniem sumy grafów a łączeniem
ich. Prosta suma dwóch grafów odpowiada koniunkcji wszystkich trójek, utrzymującej
tożsamość wszystkich pustych węzłów pojawiających się w grafie. Najlepiej jest, kiedy
informacja w grafach pochodzi z jednego źródła lub gdy jedna wywodzi się z drugiej w
znaczeniu pewnego procesu wnioskowania, jak np. w sytuacji, kiedy stosuje się regułę
wnioskowania, aby dodać trójkę do grafu. Natomiast łączenie grafów traktuje puste węzły w
każdym grafie jako zmienne egzystencjalne, więc żaden z pustych węzłów z jednego grafu
nie może odłączyć się od zasięgu innych elementów otaczających graf. Zatem prawidłowo
jest, kiedy grafy pochodzą z różnych źródeł i nie ma podstaw do zakładania, że pusty węzeł
w jednym grafie odnosi się do tej samej jednostki co pusty węzeł w drugim grafie.
2) Wnioskowanie między grafami RDF
Wnioskowanie to główna idea języka jakim jest RDF. Jest elementem łączącym teoretyczne
semantyki z realnymi aplikacjami. Tworzenie twierdzeń oznacza
żądanie, że świat jest
interpretacją, która przenosi prawdziwe wartości z twierdzeń. Jeżeli A implikuje B, to wtedy
każda interpretacja traktująca A jako prawdziwe, czyni również prawdziwym B, więc
twierdzenie o A zawiera już to samo znaczenie co twierdzenie o B. Jeżeli A jest równoważne
B, to obydwa znaczą to samo w tym sensie, że twierdzą lub żądają tego samego od świata.
Zaciekawienie tą informacją znaczenie wzrasta, gdy A i B są różnymi wyrażeniami. W takiej
sytuacji relacja wnioskowania jest właśnie odpowiednim semantycznym zezwoleniem na
uzasadnianie aplikacji wnioskujących lub generujących jedną z nich. Poprzez notacje
spełniania reguł, wnioskowania i prawdziwości formalna semantyka daje rygorystyczną
definicję do notacji „znaczenia”, które może być związane bezpośrednio z obliczeniowymi
metodami determinowania tego, czy znaczenie jest zachowywane przez jakieś transformacje
w reprezentacji wiedzy.
Każdy proces, który konstruuje graf E z innego lub innych grafów S jest obowiązujący, jeżeli
S implikuje E w każdym przypadku, w przeciwnym wypadku jest błędny. Warto zauważyć, że
jeśli proces jest błędny, to konkluzje niekoniecznie będą nieprawdziwe. Poprawny proces nie
gwarantuje prawdy. Jednak poprawność zapewnia najlepsze gwarancje, jakie taki język
może zaoferować. W przypadku podania prawdziwych danych wejściowych, nigdy nie
wyniknie z nich fałszywa konkluzja.
Lemat o pustym grafie
Pusty zbiór trójek jest implikowany przez dowolny graf, a nie implikuje żadnego grafu oprócz
samego siebie.
Lemat o podgrafie
Graf implikuje wszystkie swoje podgrafy.
Lemat o instancji
Graf jest implikowany przez każdą swoją instancję.
Różnica między implikowaniem a łączeniem jest oczywista i prosta do zrozumienia na
podstawie poniższej definicji.
Lemat o łączeniu
Łączenie zbioru S grafów RDF jest implikowane przez S, samo implikuje każdego członka S.
To oznacza, że zbiór grafów może być traktowany jako równoważność swojego własnego
łączenia.
Lemat o interpolacji
S implikuje graf E wtedy i tylko wtedy, gdy podgraf S jest instancją E.
Lemat o interpolacji kompletnie charakteryzuje proste implikowanie w syntaktycznych
terminach. Aby powiedzieć czy zbiór grafów implikuje inny, należy sprawdzić czy są instancje
implikowanego grafu, które są podzbiorem łączenia oryginalnego zbioru grafów. Oczywiście
nie ma potrzeby konstruowania łączenia. Efektywną techniką będzie traktowanie pustych
węzłów jak zmiennych w procesie dopasowywania podgrafów, pozwalając im łączyć
pasujące nazwy w poprzednich grafach w S, np. te, które mogą implikować późniejszy graf.
Lemat o interpolacji pokazuje, że ten proces jest poprawny i kompletny. Istnienie algorytmu
kompletnego dopasowywania podgrafów pokazuje również, że wnioskowanie RDF jest
rozstrzygalne8, np. kończący algorytm, który będzie określać dla dowolnego skończonego
zbioru S i dowolnego grafu E czy S implikuje E.
Lemat o anonimowości
Przypuśćmy, że E jest grafem „lean” (tzn. nie ma żadnej instancji będącej jego właściwym
podgrafem) a E’ jego odpowiednią instancją, wtedy E nie implikuje E’.
8
Problem jest rozstrzygalny (decydowalny), jeśli zawsze można określić czy odpowiedź na pytanie stawiane przez ten problem
jest poprawna.
Ten lemat ma zastosowanie tylko dla prostego wnioskowania.
Lemat o monotoniczności
Niech S będzie podgrafem S’ i S implikuje E. Wtedy S’ implikuje E.
Właściwość skończonych wyrażeń zawsze wywodząca się ze skończonego zbioru
poprzedników jest nazywana zwięzłością. Semantyczne teorie wspierające niezwięzłe
notacje wnioskowania nie mają korespondujących obliczeniowych systemów wnioskowania.
Lemat o ścisłości
Jeżeli S implikuje E i E jest skończonym grafem, to niektóre skończone podzbiory S implikują
E.
3) Interpretowanie słownictwa RDF
Słownictwo RDF rdfV jest zbiorem referencji URI w przestrzeni nazw RDF.
Słownictwo RDF
rdf:type, rdf:Property, rdf:XMLLiteral, rdf:nil, rdf:List, rdf:Statement, rdf:subject, rdf:predicate,
rdf:object, rdf:first, rdf:rest, rdf:Seq, rdf:Bag, rdf:Alt, rdf:_1, rdf:_2 ... rdf:value
Interpretacja RDF nakłada specjalne semantyczne warunki na rdfV i typowane wartości
liczbowo-literowe z typem rdf:XMLLiteral, który odnosi się do wbudowanych typów danych
RDF. Interpretacja RDF słownictwa V jest prostą interpretacją V ∪ rdfV , która spełnia
specjalne warunki opisane poniżej oraz wszystkie trójki w następnej tabeli, które są
nazywane aksjomatycznymi trójkami.
Semantyczne warunki RDF
x ∈ P ⇔ (x, I(rdf:Property)) ∈ IEXT(I(rdf:type))
Jeśli "xxx"^^rdf:XMLLiteral jest w V i xxx jest dobrze określonym stringiem XML
literal, wtedy:
IL("xxx"^^rdf:XMLLiteral) jest wartością XML xxx;
IL("xxx"^^rdf:XMLLiteral) jest w LV;
IEXT(I(rdf:type)) zawiera (IL("xxx"^^rdf:XMLLiteral), I(rdf:XMLLiteral))
Jeśli "xxx"^^rdf:XMLLiteral jest w V i xxx jest źle określonym stringiem XML
literal, wtedy
IL("xxx"^^rdf:XMLLiteral) nie należy do LV;
IEXT(I(rdf:type)) nie zawiera (IL("xxx"^^rdf:XMLLiteral), I(rdf:XMLLiteral)).
Semantyczne warunki RDF nakładają ważne formalne ograniczenia na znaczenie tylko
centralnego słownictwa RDF, więc notacja wnioskowania i interpretacji RDF stosuje się do
reszty słownictwa bez późniejszych zmian. Semantyczne rozszerzenia mogą ograniczać
formalne interpretacje tego słownictwa aby dostosować się do zamierzonego znaczenia.
4) Interpretowanie słownictwa RDFS
RDF Schema (RDFS) rozszerza RDF o większą ilość wykorzystywanego słownictwa rdfsV z
bardziej złożonymi semantycznymi ograniczeniami.
Słownictwo RDFS:
rdfs:domain, rdfs:range, rdfs:Resorce, rdfs:Literal, rdfs:Datatype, rdfs:Class, rdfs:subClassOf,
rdfs:subPropertyOf,
rdfs:member,
rdfs:Container,
rdfs:ContainerMembershipProperty,
rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, rdfs:label.
Zbiór wszystkich klas RDFS w interpretacji będzie oznaczany IC, a semantyczne warunki
wyrażone w terminach mapowania ICEXT z IC do zbioru podzbiorów IR. Warto zauważyć, że
klasa może mieć puste wnętrze, dwie różne klasy mogą mieć to samo wnętrze oraz że
wnętrze klasy rdfs:Class zawiera samą klasę rdfs:Class.
Interpretacja RDFS słownictwa V jest interpretacją RDF I zbioru V ∪ rdfV ∪ rdfsV , która
spełnia następujące semantyczne warunki oraz wszystkie aksjomatyczne trójki RDFS w
poniżej tabeli.
Semantyczne warunki RDFS
x ∈ ICEXT(y) ⇔ (x,y) ∈ IEXT(I(rdf:type))
IC = ICEXT(I(rdfs:Class))
IR = ICEXT(I(rdfs:Resource))
LV = ICEXT(I(rdfs:Literal))
Jeśli (x,y) jest w IEXT(I(rdfs:domain)) i (u,v) jest w IEXT(x) wtedy u jest w ICEXT(y)
Jeśli (x,y) jest w IEXT(I(rdfs:range)) i (u,v) jest w IEXT(x) wtedy v jest w ICEXT(y)
IEXT(I(rdfs:subPropertyOf)) jest przechodnia i zwrotna na IP
Jeśli (x,y) jest w IEXT(I(rdfs:subPropertyOf)) wtedy x i y są w IP i IEXT(x) jest podzbiorem
IEXT(y)
Jeśli x jest w IC wtedy (x, I(rdfs:Resource)) jest w IEXT(I(rdfs:subClassOf))
Jeśli (x,y) jest w IEXT(I(rdfs:subClassOf)) wtedy x i y są w IC i ICEXT(x) jest podzbiorem
ICEXT(y)
IEXT(I(rdfs:subClassOf)) jest przechodnia i zwrotna na IC
Jeśli x jest w ICEXT(I(rdfs:ContainerMembershipProperty)) wtedy:
(x, I(rdfs:member)) jest w IEXT(I(rdfs:subPropertyOf))
Jeśli x jest w ICEXT(I(rdfs:Datatype)) wtedy (x, I(rdfs:Literal)) jest w IEXT(I(rdfs:subClassOf))
Powyższa semantyka jest celowo wybrana jako najsłabsza, „racjonalna” interpretacja
słownictwa RDFS. Jej rozszerzenie może wzmocnić semantyczne warunki zakresu,
dziedziny, podklasy i podwłaściwości.
Alternatywa rozszerzenia niektórych semantycznych warunków RDFS
(x,y) ∈ IEXT(I(rdfs:subClassOf)) ⇔ x, y ∈ IC i ICEXT(x) jest podzbiorem ICEXT(y)
(x,y) ∈ IEXT(I(rdfs:subPropertyOf)) ⇔ x, y ∈ IP i IEXT(x) jest podzbiorem EXT(y)
(x,y) ∈ IEXT(I(rdfs:range)) ⇔ (if <u,v> ∈ IEXT(x), wtedy v ∈ ICEXT(y))
(x,y) ∈ IEXT(I(rdfs:domain)) ⇔ (if <u,v> is in IEXT(x), wtedy u ∈ ICEXT(y))
Powyższe warunki gwarantują przechodniość i zwrotność podwłaściwości oraz właściwości
podklasy, jednak mają również inne późniejsze konsekwencje.
Te silniejsze warunki byłyby spełnione w sposób trywialny, jeśli właściwości byłyby
identyfikowane z wnętrzami właściwości, a klasy z wnętrzami klas, rdfs:SubClassOf byłaby
rozumiana jako podzbiór i w ten sposób byłaby spełniona przez rozszerzoną semantykę dla
RDFS. W niektórych przypadkach rozszerzone wersje mogą zapewniać prostszą semantykę,
ale wymagają bardziej złożonych reguł wnioskowania.
5) Interpretowanie typów danych
RDF
zapewnia
możliwość
użycia
typów
danych
zdefiniowanych
na
zewnątrz,
identyfikowanych przez poszczególne referencje URI. RDF nakłada minimalne warunki na
typy danych oraz zawiera jeden wbudowany zewnętrzny typ danych rdf:XMLLiteral.
Semantyka dla typów danych jest minimalna, co nie nakłada zabezpieczeń na kojarzenie
typu danych z właściwością, więc stosuje się to do wszystkich wartości właściwości i nie
zapewnia sposobu bezpośredniego twierdzenia, że puste węzły wskazują konkretne wartości
typów danych. Rozszerzenia semantyki RDF mogą się odnosić do innych rodzajów
informacji o typach danych, takich jak porządkowanie przestrzeni wartości.
Typ danych jest jednostką charakteryzowaną przez zbiór napisów nazywanych formami
leksykalnymi oraz przez mapowanie z tego zbioru do zbioru wartości.
Formalnie typ danych d jest zdefiniowany przez trzy elementy:
1. Niepusty zbiór stringów znakowych nazywany leksykalną przestrzenią d.
2. Niepusty zbiór nazywany przestrzenią wartości d.
3. Mapowanie z przestrzeni leksykalnej d do przestrzeni wartości d, nazywany
mapowaniem słownictwo-wartości, zapisywanym L2V(d).
Określając semantykę zakładamy, że interpretacje są związane z konkretnym zbiorem typów
danych, z których każdy jest identyfikowany referencją URI.
Niech D będzie zbiorem par składających się z referencji URI i typu danych takiego, że
żadna referencja URI nie pojawia się dwa razy w zbiorze. Wtedy D może być uważane za
funkcję odwzorowującą zbiór referencji URI w zbiór typów danych. Nazywamy ją mapą typów
danych. Każda mapa typów danych zakłada zawieranie (rdf:XMLLiteral, x), x jest
wbudowanym typem danych XML LIteral, którego przestrzenie i mapowanie są zdefiniowane
w pojęciowo-abstrakcyjnej składni RDF.
Do
mapy
typów
danych,
która
zawiera
również
zbiór
wszystkich
par
postaci
(http://www.w3.org/2001/XMLSchema#sss, sss), gdzie sss jest wbudowanym typem danych
wymienionych poniżej, odwołuje się za pomocą przedrostka xsd.
Typy danych XSD:
xsd:string, xsd:boolean, xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time, xsd:date,
xsd:gYearMonth,
xsd:gYear,
xsd:gMonthDay,
xsd:gDay,
xsd:gMonth,
xsd:hexBinary,
xsd:base64Binary, xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN,
xsd:Name, xsd:NCName, xsd:integer, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int,
xsd:short, xsd:byte, xsd:nonNegativeInteger, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort,
xsd:unsignedByte, xsd:positiveInteger
Inne typy danych XML Schema nie powinny być używane w RDF.
Jeżeli D jest mapą typów danych, to D-interpretacja słownictwa V jest RDFS-interpretacją I
słownictwa V ∪ {aaa : (aaa, x) ∈ D dla niektórych x} , która spełnia specjalne warunki dla
każdej pary (aaa, x) ∈ D :
Ogólne semantyczne warunki dla typów danych
Jeśli (aaa,x) jest w D to I(aaa) = x
Jeśli (aaa,x) jest w D to ICEXT(x) jest przestrzenią wartości x oraz podzbiorem LV
Jeśli (aaa,x) jest w D to dla dowolnej typowanej wartości liczbowo-literowej "sss"^^ddd w V,
gdzie I(ddd) = x,
jeśli sss jest w leksykalnej przestrzeni elementu x wtedy
IL("sss"^^ddd) = 2V(x)(sss), w przeciwnym wypadku
IL("sss"^^ddd) nie należy do LV
Jeśli (aaa,x) jest w D to I(aaa) jest w ICEXT(I(rdfs:Datatype))
Pierwszy warunek zapewnia interpretację referencji URI zgodnie z tym, co zapewnia mapa
typów danych. Nie zapobiega to jednak sytuacji, w której inne referencje URI wskazują typ
danych. Drugi warunek zapewnia, że referencja URI typów danych używana jako nazwa
klasy, odnosi się do przestrzeni wartości typów danych i wszystkie elementy tej przestrzeni
muszą być wartościami liczbowo-literowymi. Trzeci warunek zapewnia, że typowane wartości
liczbowo-literowe dotyczą typów danych mapowania słownictwo-wartości. Na przykład jeśli I
jest XSD-interpretacją wtedy I("15"^^xsd:decimal) musi być liczbą piętnaście. Trzeci warunek
odnosi się jedynie do typów danych w zasięgu mapy D. Typowane wartości liczbowoliterowe, których typ nie należy do danej mapy traktowane są jak wcześniej, np. wskazując
nieznane rzeczy. Natomiast czwarty warunek zapewnia, że klasa rdfs:Datatype zawiera typy
danych używane w dowolnej, spełniającej D-interpretacji. Warto zauważyć, że jest to
warunek konieczny, ale nie wystarczający, pozwala klasie I(rdfs:Datatype) zawierać inne typy
danych.
Semantyczne warunki dla interpretacji RDF nakładają poprawną interpretację na wartości
liczbowo-literowe typowane przez rdf:XMLLiteral. D-interpretacja rozpoznaje typy danych
raczej jako jednostki niż semantyczne warunki nakładane przez składnię typowanych
wartości liczbowo-literowych. Semantyczne rozszerzenia mogące wyrażać identyczność
warunków na zasobach, mogłyby wyciągać silniejsze wnioski z D-interpretacji niż z
interpretacji RDFS.
Może się zdarzyć, że graf zgodny w jednym słownictwie nie jest zgodny w semantycznym
rozszerzeniu zdefiniowanym na obszerniejszym słownictwie, a D-interpretacja pozwala na
niezgodności w grafie RDF. Wnioskowanie słownictwa oznacza, że niezgodny graf implikuje
dowolny graf w silniejszym słownictwie. Jednak zazwyczaj nie jest poprawne rozważanie tak
trywialnego wyciągania wniosków jako użytecznej konsekwencji, dopóki nie będą one
obowiązującymi jednostkami w mniejszym słownictwie.
6) Monotoniczność semantycznych rozszerzeń
Posiadamy dany zbiór grafów RDF. Są różne sposoby dodawania do nich informacji. Każdy
graf może mieć dodane trójki, zbiór grafów może być rozszerzony do ekstra-grafów lub
słownictwo grafu może być interpretowane zgodnie z silniejszą notacją wnioskowania ze
słownictwa, np. kiedy większy zbiór semantycznych warunków jest rozumiany jako
nakładany na interpretację. Wszystko z tych elementów może być rozumiane jako
dodatkowa informacja i może tworzyć więcej wniosków. Wszystkie takie dodawania są
monotoniczne w takim sensie, że wnioski, które obowiązują przed dodaniem informacji,
obowiązują również po dodaniu. Można to podsumować w następującym lemacie:
Ogólny lemat o monotoniczności
Niech S i S’ będą zbiorami grafów RDF, gdzie każdy członek S jest podzbiorem jakiegoś
członka S’. Ponadto niech Y wskazuje semantyczne rozszerzenie X, S X-implikuje E oraz S i
E spełniają dowolną syntaktyczną restrykcję Y. Wtedy S’ Y-implikuje E.
W szczególności jeśli D’ jest mapą typów danych, D podzbiorem D’ i jeśli S D-implikuje E, to
S D’-implikuje E.
7) Zasady wnioskowania
Poniższa tabela przedstawia niektóre wzory wnioskowania, które obejmują różne formy
wyciągania wniosków ze słownictwa i mogłyby być wykorzystane jako przewodnik dla
projektantów oprogramowania sprawdzającego grafy RDF dla wniosków RDF i RDFS.
Implementacja może bazować na zastosowaniu reguł w przód lub traktowaniu wniosku jako
wzoru do rozpoznania w konsekwencji zaproponowanego wnioskowania i szukania wstecz
odpowiednich połączeń z innymi wnioskami lub zaproponowanymi poprzednikami. Możliwe
są również inne strategie.
Reguły są zadane w postaci “add a triple to a graph when it contains triples conforming to a
pattern” (dodaj trójkę do grafu kiedy zawiera trójki pasujące do wzoru) i są obowiązujące w
następującym sensie. Graf implikuje dowolny, większy graf otrzymywany poprzez
zastosowanie reguł do oryginalnego grafu. Zastosowanie takiej reguły do grafu przyczynia
się do tworzenia raczej prostej sumy z warunku a nie łączenia i w ten sposób zachowuje
puste węzły w grafie.
Lemat o interpolacji może być scharakteryzowany przez następujące reguły wnioskowania,
które generują uogólnienia, np. grafy mające oryginalny graf jako instancję. Bycie podgrafem
nie wymaga bezpośredniej informacji jako reguły wnioskowania na trójkach.
Nazwa reguły
Jeśli E zawiera
Wtedy dodaj
uuu aaa _:nnn .
se1
uuu aaa xxx .
gdzie _:nnn identyfikuje pusty węzeł przydzielony do
xxx przez regułę se1 lub se2.
_:nnn aaa xxx .
se2
uuu aaa xxx .
uuu przez regułę se1 lub se2.
Tabela 5 Proste reguły wnioskowania [1]
Termin „przydzielony do” oznacza, że pusty węzeł musiał być stworzony przez wcześniejszą
aplikację określonych reguł na tej samej referencji URI, pustym węźle lub wartości liczbowoliterowej albo, jeśli nie ma takiego pustego węzła, to musi istnieć „nowy” węzeł nie
występujący w grafie. Ten warunek zapewnia, że wynikowy graf otrzymywany przez
dodawanie nowej trójki pustego węzła ma oryginalny graf jako właściwą instancję i że
dowolny taki graf będzie miał podgraf, który jest taki sam jak graf, który może być
generowany przez reguły.
Kolejny zbiór reguł używa specjalnego przypadku reguły se1 stosującego się tylko do
wartości liczbowo-literowych:
Nazwa reguły Jeśli E zawiera Wtedy dodaj
uuu aaa _:nnn .
lg
uuu aaa lll .
wartości liczbowo-literowej lll przez tę regułę.
Ta reguła jest wystarczająca do odtwarzania dowolnego podgrafu E składającego się z trójek
zawierających daną wartość liczbowo-literową jako izomorficzny podgraf, w którym dana
wartość jest zastępowana specjalnym pustym węzłem. Znaczenie tego leży w fakcie, że
puste węzły mogą występować jako podmioty w trójce RDF, pozwalając na wyciąganie
wniosków z
innych
reguł,
które
wyrażają
wskazywanej przez odpowiedni element.
właściwości
wartości
liczbowo-literowej
Dla RDFS implikowanie dodatkowej reguły jest wymagane, odwraca regułę lg:
Nazwa reguły
Jeśli E zawiera
Wtedy dodaj
uuu aaa _:nnn .
gl
gdzie _:nnn identyfikuje pusty węzeł przydzielony do uuu aaa lll .
wartości lll przez regułę lg.
W prosty sposób reguła gl tworzy pewien nadmiar, z wyjątkiem przypadków, gdzie
przydzielony węzeł został wprowadzony na pozycję obiektu nowej trójki przez jakąś inną
regułę wnioskowania. Efektem tej reguły jest zapewnienie, że trójka zawierająca wartość
liczbowo-literową i podobna trójka zawierająca przydzielony węzeł, zawsze pochodzą jedna
od drugiej, zatem wartość liczbowo-literowa może być identyfikowana ze swoim
przydzielonym pustym węzłem dla celów zastosowania tych reguł.
Nazwa reguły
Jeśli E zawiera
Wtedy dodaj
rdf1
uuu aaa yyy .
aaa rdf:type rdf:Property .
uuu aaa lll .
rdf2
_:nnn rdf:type rdf:XMLLiteral .
gdzie lll jest well-typed
XML literal .
lll przez regułę lg.
Tabela 8 Reguły wnioskowania RDF
Powyższe reguły są kompletne w następującym sensie.
Lemat o wnioskowaniu RDF
S rdf-implikuje E wtedy i tylko wtedy, gdy istnieje graf, który może wywodzić się z S i
aksjomatycznych trójek RDF przez zastosowanie reguły lg i reguł wnioskowania RDF, który
w prosty sposób implikuje E.
Warto zwrócić uwagę, że powyższy lemat nie wymaga zastosowania reguły gl.
Nazwa reguły
Jeśli E zawiera:
wtedy dodaj:
uuu aaa lll.
rdfs1
gdzie
lll
_:nnn rdf:type rdfs:Literal .
jest
prostą
liczbowo-literową
wartością gdzie _:nnn identyfikuje pusty węzeł
etykietą
przydzielony do lll przez regułę lg.
(z
językową lub bez).
rdfs2
rdfs3
aaa
rdfs:domain
xxx
.
uuu rdf:type xxx .
xxx
.
vvv rdf:type xxx .
uuu aaa yyy .
aaa
rdfs:range
uuu aaa vvv .
rdfs4a
uuu aaa xxx .
uuu rdf:type rdfs:Resource .
rdfs4b
uuu aaa vvv.
vvv rdf:type rdfs:Resource .
rdfs5
rdfs6
rdfs7
rdfs8
rdfs9
rdfs10
rdfs11
uuu
rdfs:subPropertyOf
rdfs13
.
vvv rdfs:subPropertyOf xxx .
uuu rdf:type rdf:Property .
aaa
rdfs:subPropertyOf
bbb
.
rdfs:subClassOf
xxx
.
vvv rdf:type uuu .
uuu rdf:type rdfs:Class .
uuu
rdfs:subClassOf
vvv
.
rdf:type
rdfs:ContainerMembershipProperty .
Tabela 9 Reguły wnioskowania RDFS
vvv rdf:type xxx .
uuu rdfs:subClassOf uuu .
vvv rdfs:subClassOf xxx .
uuu rdf:type rdfs:Datatype .
uuu bbb yyy .
uuu rdfs:subClassOf rdfs:Resource .
uuu rdf:type rdfs:Class .
uuu
uuu rdfs:subPropertyOf xxx .
uuu rdfs:subPropertyOf uuu .
uuu aaa yyy .
uuu
rdfs12
vvv
uuu rdfs:subClassOf xxx .
uuu rdfs:subPropertyOf rdfs:member .
uuu rdfs:subClassOf rdfs:Literal .
Lemat o wnioskowaniu RDFS
S rdfs-implikuje E wtedy i tylko wtedy, gdy istnieje graf mogący wywodzić się z S oraz RDF i
RDFS aksjomatycznych trójek przez zastosowanie reguły lg, gl oraz reguł wnioskowania
RDF i RDFS i który w prosty sposób implikuje E lub zawiera konflikt XML.
Reguły RDFS są w pewien sposób zbędne. Wszystkie oprócz jednej aksjomatycznie trójki
RDF mogą wywodzić się z reguł rdfs2 irdfs3 oraz z aksjomatycznych trójek RDFS.
Silniejsze semantyczne warunki rozszerzające zezwalają na dalsze wnioskowanie nieobjęte
regułami RDFS. Poniższa tabela wymienia niektóre wzory wnioskowania obowiązujące w
silniejszych semantykach, nie jest to jednak kompletny zbiór reguł. Żadna z tych reguł nie
jest obowiązująca w RDFS, stosują się one jedynie do semantycznych rozszerzeń, które
stosują wzmocnione semantyczne warunki rozszerzające. Reguły te skutkują innymi
konsekwencjami, np. rdfs:Resource jest zasięgiem każdej właściwości.
Reguły ext5-ext9 podążają za następującym wzorem; przedstawiają fakt, że wzmocnione
warunki rozszerzające wymagają tak dużych jak to możliwe dziedzin właściwości (i zasięgów
przechodnich właściwości) w słownictwie rdfV i rdfsV tak, że próby ograniczenia ich będą
podważane przez warunki semantyczne. Podobne reguły stosuje się do podwłaściwości
dziedziny i zasięgu. Żaden z tych przypadków nie jest prawdopodobny do powstania w
praktyce.
ext1
ext2
ext3
ext4
ext5
ext6
uuu rdfs:domain vvv .
vvv rdfs:subClassOf zzz .
uuu rdfs:range vvv .
vvv rdfs:subClassOf zzz .
uuu rdfs:domain vvv .
www rdfs:subPropertyOf uuu .
uuu rdfs:range vvv .
www rdfs:subPropertyOf uuu .
uuu rdfs:domain zzz .
uuu rdfs:range zzz .
www rdfs:domain vvv .
www rdfs:range vvv .
rdf:type rdfs:subPropertyOf www .
rdfs:Resource rdfs:subClassOf vvv
.
rdfs:subClassOf rdfs:subPropertyOf www .
ext7 rdfs:subPropertyOf rdfs:subPropertyOf www .
rdfs:Class rdfs:subClassOf vvv .
rdf:Property rdfs:subClassOf vvv .
ext8
ext9
rdfs:subClassOf rdfs:subPropertyOf www .
rdfs:subPropertyOf rdfs:subPropertyOf www .
rdfs:Class rdfs:subClassOf vvv .
rdf:Property rdfs:subClassOf vvv .
Tabela 10 Rozszerzona wersja semantycznych warunków RDFS
W celu objęcia wnioskowania z typów danych w terminach twierdzeń i reguł, muszą one
odnosić się do informacji dostarczanej przez same typy danych. Do określenia odpowiednich
reguł niezbędne jest przyjęcie syntaktycznych warunków, które mogą być sprawdzane
jedynie przez konsultację z zasobami typów danych.
Dla każdego rodzaju dostępnej informacji o typach danych reguły wnioskowania dla
informacji tego rodzaju mogą być określane i uważane za rozszerzenie tabeli reguł
wnioskowania RDFS. Te powinny być rozumiane jako zastosowanie do typów danych innych
niż wbudowane. Reguły kreślone poniżej przyjmują, że dostępna informacja o typach danych
jest wskazywana przez rozpoznawane referencje URI i wykorzystują te referencje do
odnoszenia się do typów danych.
Podstawowa informacja określa dla każdego stringa, czy ma on poprawną formę leksykalną
dla typu danych. To koresponduje z następującą regułą, dla której każdy string sss jest
poprawną leksykalną formą wskazywaną przez ddd:
_:nnn rdf:type ddd .
ddd
rdf:type
rdfD1 rdfs:Datatype
uuu aaa "sss"^^ddd .
. gdzie _:nnn identyfikuje pusty węzeł przydzielony
do
"sss"^^ddd przez regułę lg.
Załóżmy, że dane są dwie leksykalne formy sss i mapa ttt do tej samej wartości pod typem
danych, wskazanym przez ddd, wtedy zastosowanie ma następująca reguła:
rdfD2
ddd rdf:type rdfs:Datatype .
uuu aaa "ttt"^^ddd .
Przypuśćmy, że dana jest leksykalna forma sss typu danych wskazywanego przez ddd i
leksykalna forma ttt typu danych wskazywanego przez eee mapuje do tej samej wartości.
Wtedy ma zastosowanie następująca reguła:
ddd
rdf:type
rdfs:Datatype
.
rdfD3 eee
rdf:type
rdfs:Datatype
. uuu aaa "ttt"^^eee .
Dodatkowo wiadomo, że przestrzeń wartości typu danych wskazywanego przez ddd jest
podzbiorem typu danych wskazywanego przez eee, wtedy poprawne byłoby stwierdzenie, że
ddd rdfs:subClassOf eee .
Powinno to jednak być stwierdzone explicite, a nie jako wniosek z podzbioru relacji.
Zakładając, że informacja zakodowana w tych regułach jest prawdziwa, stosując te i
wcześniejsze reguły powstaje graf, który jest D-implikowany przez oryginał.
Przestrzeń wartości i mapowanie słownictwo-wartości typu danych xsd:string sankcjonuje
identyfikację typowanych wartości liczbowo-literowych z prostymi wartościami liczbowoliterowymi bez etykiet językowych dla wszystkich stringów, które są w przestrzeni wartości
typu danych, dopóki obydwa z nich wskazują stringi znaków Unicode. Poniższa reguła
wnioskowania obowiązuje we wszystkich interpretacjach XSD. sss wskazuje dowolny string
RDF w leksykalnej przestrzeni xsd:string.
xsd 1a uuu aaa "sss".
uuu aaa "sss"^^xsd:string .
xsd 1b uuu aaa "sss"^^xsd:string . uuu aaa "sss".
Podobnie jak z regułami rdfD2 i rdfD3 aplikacje mogą wykorzystywać raczej systematyczne
zastępowanie jednej z tych ekwiwalentnych form, niż bezpośrednie stosowanie tych reguł.
2.4. Wnioskowanie
Najważniejsze właściwości wnioskowania RDF i RDFS.
• Dziedziczenie przez podklasę.
(rdf:type Morris Kot)
(rdfs:subClassOf Kot Ssak)
implikuje
(rdf:type Morris Ssak)
To znaczy, że jeśli instancja Morris należy do klasy Kot, która jest podklasą klasy Ssak, to
Morris jest jednocześnie ssakiem.
• Zwrotność podklasy oraz podwłaściwości.
Dla dowolnej właściwości rdf:Property p wnioskowane jest rdfs:subPropertyOf p p, czyli że
jest ona swoją własną podwłaściwością. Analogicznie dzieje się dla klas.
• Typ wnioskowany przez dziedzinę oraz zasięg.
(rdfs:domain uczy Nauczyciel)
(rdfs:range uczy Student)
(uczy X Y)
implikuje
(rdf:type X Nauczyciel)
(rdf:type Y Student)
To znaczy, że jeśli dziedziną właściwości uczy jest klasa Nauczyciel, a zasięgiem klasa
Student, to po określeniu tej relacji na konkretnych jednostkach wnioskuje się, że X jest
nauczycielem a Y studentem.
• Przechodniość podklasy i podwłaściwości.
(rdfs:subClassOf Pies Ssak)
(rdfs:subClassOf Ssak Zwierzę)
implikuje
(rdfs:subClassOf Pies Zwierzę)
To znaczy, że jeśli klasa Pies jest podklasą klasy Ssak, a ta jest podklasą klasy Zwierzę,
to klasa Pies jest również podklasą klasy Zwierzę. Analogicznie dzieje się dla
właściwości.
2.5. Zastosowania
RDF i RDFS są jednym w z pierwszych kroków w stronę semantyki. Konstrukcja grafów
pozwala na tworzenie zdań o zasobach oraz modelowanie relacji między nimi. Umożliwia to
odpowiednią organizację zasobów sieci www w taki sposób, aby
łatwo było odnaleźć
interesujące użytkownika zasoby. RDF pozwala na współdzielenie oraz ponowne
wykorzystanie danych z sieci, przechowuje informacje o jej zasobach z możliwością
odniesienia się przez użytkownika do konkretnego kontekstu danych informacji.
Szczegółowe zadania realizowane przez RDF:
• Tworzenie opisów dokumentów za pomocą meta-danych (najbardziej obiecujący
element do wykorzystania w zakresie sieci semantycznej).
• Identyfikowanie danych znajdujących się poza siecią.
• Współdzielenie informacji przez wielu użytkowników sieci.
• Ponowne wykorzystywanie tej samej informacji.
• Ułatwienie wyszukiwania danych.
• Identyfikowanie zasobów poprzez URI.
• Organizacja wiedzy bez użycia baz danych w sytuacjach, gdy nie jest konieczne użycie
bardziej zaawansowanych reprezentacji wiedzy jakimi są ontologie.
• Rozwiązywanie problemu dostępu do zasobów w następujących sytuacjach:
− uproszczona i posiadająca adnotacje treść, wymagająca dostępu dla konkretnej
grupy,
− zawartość
polegająca
na
językach
znaczników
nie
wspierających
interoperacyjności,
− oryginalna treść niezdolna do zmian (gdy używane zbyt zaawansowane narzędzia i
języki).
• Umieszczanie profilów użytkowników w sieci, co optymalizuje wykonanie dla
indywidualnych użytkowników.
• Adnotacje schematu XML, co znacznie zwiększa liczbę dokumentów bazujących na
tym schemacie.
• Wykorzystanie jako Friend-of-a-Friend (FOAF) – pozwala na wyrażanie informacji
osobistych i relacji między osobami, wykorzystywany do tworzenia bloków systemów
informacyjnych wspierających grupy użytkowników online.
• Zapewnienie interoperacyjności między aplikacjami wymieniającymi dane.
• Umożliwienie tworzenia prostych, ale wyrazistych i wykonywalnych semantyk zasobów
(koncentracja na znaczeniu, przeznaczenie dla wiedzy a nie danych).
• Rozwój prostych reguł przetwarzania zasobów sieci.
• Integracja danych z różnych źródeł o różnym formacie.
2.6. Języki zapytań
2.6.1.1. RDQL Data Query Language
RDQL9 jest językiem używanym do tworzenia zapytań do plików RDF. Pozwala wyciągać z
nich zawężone dane według kryteriów określonych poprzez predykaty RDF.
Język RDQL został zaimplementowany w pewnej ilości systemów do odzyskiwania informacji
zapisanej w grafach RDF. Najpierw był opublikowany dla Jena 1.2.0, ale bez problemów
można go stosować wraz z innymi systemami, które wywodzą się z tej samej gramatyki.
• Jena,
• RDF Store,
• Sesame,
• PHP XML Classes,
• 3Store,
• RAP – RDF API for PHP.
RDQL składa się z wzoru grafów wyrażonych jako lista wzorów trójek. Każdy wzór trójki
obejmuje nazwane zmienne oraz wartości RDF (referencje URI i wartości liczbowo-literowe).
Zapytanie RDQL może mieć dodatkowo zbiór ograniczeń wartości tych zmiennych i listę
zmiennych wymaganych w zbiorze odpowiedzi.
RDQL tworzy zapytania do dokumentów RDF używających składni podobnej do SQL. W celu
stworzenia zapytania wskazuje się URL dokumentów (http://) lub ścieżki dostępu, jeśli są
one umieszczone na lokalnym komputerze. Jeżeli zapytanie jest skierowane do więcej niż
jednego dokumentu, wówczas rozważane są wszystkie zdania tego dokumentu.
9
Por. szerzej http://www.w3.org/Submission/RDQL/
Typowa forma zapytania RDQL:
SELECT zmienne
FROM dokumenty
WHERE wyrażenia
AND filtry
USING deklaracje przestrzeni nazw
Przykład:
SELECT ?x,?y
FROM <http://example.com/sample.rdf>
WHERE (?x,<dc:name>,?y)
USING dc for <http://www.dc.com#>
Powyższy przykład zwróci wszystkie krotki ?x-?y wskazujące nazwę zasobu i wartość
właściwości dc:name dla każdego zasobu.
Składnia
• SELECT –wskazuje, które zmienne RDQL powinny być zwrócone przez zapytanie.
Jeśli użytkownik użyje SELECT ?x, ?y, ?z, to otrzyma tablicę krotek zawierających
wartości dla ?x, ?y, ?z. Można używać innych oznaczeń na zmienne, ale nie zostaną
one zwrócone dopóki nie są wymienione w formule SELECT.
• FROM – wskazuje źródło RDF, w którym zapytanie ma szukać odpowiedzi; każde
źródło jest otoczone nawiasami <&>. Jeśli wskazywane jest więcej niż jedno źródło,
powinny one być oddzielone przecinkami. Źródłem może być URL lub ścieżka dostępu
do lokalnych dokumentów RDF.
Przykład:
FROM <doc.rdf>, <http://example.com/sample.rdf>, <rdfs/other.rdf>
• WHERE – najważniejsza cześć wyrażenia RDQL, wskazująca ograniczenia, które
muszą spełniać trójki RDF (podmioty, predykaty, obiekty) aby zostały zwrócone
odpowiedzi. Część WHERE jest zapisywana w postaci listy ograniczeń oddzielonych
przecinkami; każde ograniczenie przyjmuje formę (podmiot, predykat, obiekt), gdzie
poszczególne elementy są wartościami liczbowo-literowymi lub zmiennymi RDQL.
Przykład:
(?x,<foo:has^gt;,?y),
(?y,<foo:color>,?z)
Przykład ten szuka zdań, w których podmiot „x” ma właściwość „has” wskazującą
zasób, który ma właściwość „color”. Gdyby użytkownik chciał określić konkretny kolor
jakiego chce szukać powinien użyć formuły AND.
• AND – wskazuje ograniczenia, które muszą być spełnione przez zmienne RDQL.
Przykład: Znajdź wszystkie podmioty mające „coś” niebieskiego
SELECT ?x
FROM <doc.rdf>
WHERE (?x,<foo:has>,?y),
(?y,<foo:color>,?z)
AND ?z=="blue"
USING foo for
Za pomocą AND można łączyć następujące elementy:
arytmetyczne warunki (zawierające multiplikatywne i addytywne operatory), na
przykład:
AND (10 + ?age)*2 <= 60/2, ?weight == 75
„jakościowe” wyrażenia, gdzie EQ oznacza „jednakowy” a NE „niejednakowy”
AND ?name EQ "Radoslaw Oldakowski", ?resource NE <http://example.org/>
regularne wyrażenia w stylu Perl, gdzie „~~” lub „=~” oznacza „równy, łączy się” a
„!~” oznacza „różny, nie łączy się”
AND ?document ~~ "/\.html$/i"
wraz z AND można również tworzyć filtrujące wyrażenia używające operatorów
logicznych "&&" (i), "||" (lub) oraz „!” (negacja)
AND ( (10 + ?age)*2 <= 60/2) && (?name EQ "Radoslaw Oldakowski") )
AND !( ((10 + ?age)*2 <= 60/2) && (?name1 EQ ?name2) )
• USING – ta sekcja deklaruje wszystkie przestrzenie nazw, które będą używane dla
właściwości RDF. Deklaracje są oddzielone przecinkami i używają następującej notacji:
prefix for
Przykład:
USING foo for <http://foo.org/properties#>, col for <http://props.com/catalog#>
Poniższy przykład przedstawia dokument RDF i pracujące dla niego zapytania RDQL.
Dokument opisuje informacje o pewnej grupie ludzi. Wskazuje ich nazwiska, wiek, pozycję i
inne relacje między nimi.
people.rdf
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dt="http://foo.org#">
<rdf:Description about="http://foo.org/persons/john">
<dt:name>John</dt:name>
<dt:age>26</dt:age>
</rdf:Description>
<rdf:Description about="http://foo.org/persons/Peter">
<dt:name>Peter</dt:name>
<dt:position>foo2</dt:position>
<dt:age>25</dt:age>
<dt:friend rdf:resource="http://foo.org/persons/john" />
<dt:friend rdf:resource="http://foo.org/persons/Carl" />
</rdf:Description>
<rdf:Description about="http://foo.org/persons/Micky">
<dt:name>Micky</dt:name>
<dt:position>foo</dt:position>
<dt:age>16</dt:age>
</rdf:Description>
<rdf:Description about="http://foo.org/persons/Carl">
<dt:name>Carl</dt:name>
<dt:position>foo</dt:position>
<dt:age>28</dt:age>
<dt:friend rdf:resource="http://foo.org/persons/Peter" />
</rdf:Description>
<rdf:Description about="http://foo.org/team">
<dt:members>
<rdf:Bag>
<rdf:li rdf:resource="http://foo.org/persons/Peter" />
<rdf:li>Kim</rdf:li>
</rdf:Bag>
</dt:members>
</rdf:Description>
</rdf:RDF>
Przykłady zapytań i odpowiedzi
1) Wskaż wszystkie osoby w wieku powyżej 20 lat.
SELECT ?y
FROM <people.rdf>
WHERE (?x,<dt:age>,?z),(?x,<dt:name>,?y)
AND ?z>20
USING dt for <http://foo.org#>, rdf for <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Odpowiedź:
Array ( [0] => Array ( [?y] => John ) [1] => Array ( [?y] => Peter ) [2] => Array ( [?y] => Carl ) )
Wyszukane osoby spełniające odpowiednie kryteria to: John, Peter, Carl.
2) Wyszukaj osoby A, B takie, że A jest przyjacielem B i B jest przyjacielem A.
SELECT ?x,?y
FROM <people.rdf>
WHERE (?x,<dt:friend>,?y),(?y,<dt:friend>,?x)
AND ?x<^gt;?y
USING dt for <http://foo.org#>, rdf for <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Odpowiedź:
Array ( [0] => Array ( [?x] => http://foo.org/persons/Carl [?y] => http://foo.org/persons/Peter )
[1] => Array ( [?x] => http://foo.org/persons/Peter [?y] => http://foo.org/persons/Carl ) )
Wyszukane osoby to Carl i Peter.
3) Znajdź wszystkich członków drużyny.
SELECT ?z
FROM
WHERE (?x,,?y),(?y,?w,?z)
AND ?z<>"http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" && ?x=="http://foo.org/team"
USING dt for , rdf for
Odpowiedź:
Array ( [0] => Array ( [?z] => http://foo.org/persons/Peter ) [1] => Array ( [?z] => Kim ) )
Inne przykłady
Przykład 1:
SELECT ?x
WHERE (?x, <http:// www.w3.org/1999/02/22-rdf-syntax-ns#type>,
<http://example.com/someType>)
Powyższy
wzór
szuka
wszystkich
zdań
w
grafie
mających
za
predykat
http://www.w3.org/1999/02/22-rdf-syntax-ns#type a za obiekt http://example.com/someType.
Zmienna „?x” będzie łączona z etykietą zasobu podmiotu. Zwracane są wszytki takie „x”. x
jest nazwą zmiennej, ? przedstawia zmienną ale nie jest częścią jej nazwy.
Zapytanie RDQL traktuje graf RDF jak dane. Jeśli implementacja grafu zapewnia
wnioskowanie pojawiające się jako wirtualne trójki (pojawiające się w grafie, ale nie w
faktach ugruntowania), to RDQL obejmuje te trójki jako możliwe połączenia we wzorach
trójek. RDQL nie robi różnicy między trójkami wnioskowanymi a ugruntowanymi.
Terminy objęte „<>” są referencjami URI.
Powyższe zapytanie ma tylko jeden wzór trójki tworzący pojedynczą krawędź we wzorze
grafu. Bardziej skomplikowane grafy są tworzone przez zapisywanie wszystkich krawędzi w
języku zapytań i jak w RDF są interpretowane koniunkcyjne, co oznacza, że wszystkie
muszą pasować do rezultatów aby zostały dodane do zbioru wyników zapytania. To
oznacza, że zmienne są używane do łączenia wzorów trójek.
Przykład 2:
SELECT ?family , ?given
WHERE (?vcard vcard:FN "John Smith")
(?vcard vcard:N ?name)
(?name vcard:Family ?family)
(?name vcard:Given ?given)
USING vcard FOR <http://www.w3.org/2001/vcard-rdf/3.0#>
Powyższe zapytanie bazuje na słownictwie vCard. Ma za zadanie znaleźć nazwisko i dane
nazwisko z dowolnej vCard ze sformatowanym (FN) nazwiskiem „John Smith”. Takie
słownictwo ma strukturalizowane wartości dla nazwisk wykorzystując właściwość vcard:N do
wskazywania innego węzła w grafie RDF. Ten węzeł ma elementy nazwy jako późniejsze
zdania.
Przecinek między zmiennymi w części SELECT jest opcjonalny i zależy wyłącznie od stylu
piszącego aplikację.
Przykład 3:
SELECT ?resource
WHERE (?resource info:age ?age)
AND ?age >= 24
USING info FOR <http://example.org /peopleInfo#>
Powyższy przykład zawiera ograniczenia wartości obiektu zaznaczonego zdania.
Przykład 4:
SELECT ?resource
FROM <http://example.org/someWebPage>
WHERE (?resource info:age ?age)
AND
?age >= 24
USING info FOR <http:// example.org/peopleInfo#>
W powyższym przykładnie źródło danych jest podane. Gdyby nie było podane, to skojarzenie
zapytania z wymaganym grafem leży w gestii środowiska wykonawczego.
2.6.1.2. SPARQL Protocol And RDF Query Language
1. Informacje ogólne
SPARQL10 jest językiem zapytań i protokołem dla plików RDF, pozwala wyciągać z nich
dane zawężone według kryteriów określonych przez predykaty RDF. Jest opisany przez kilka
specyfikacji W3C. W chwili obecnej wszystkie są w trakcie prac.
Graf RDF składa się z trójek, które mogą pochodzić z różnych źródeł, na przykład
bezpośrednio z dokumentu RDF, mogą być wnioskowane z innych trójek lub mogą być
wyrażeniami RDF złożonymi
z danych o innych formatach jak XML czy relacyjne bazy
danych. SPARQL jest językiem zapytań zdobywającym informacje z takich grafów RDF i
zapewnia możliwości:
• zdobywania informacji w postaci referencji URI, pustych węzłów lub wartości liczbowoliterowych,
• wydobywania całych podgrafów RDF,
• konstruowania nowych grafów RDF bazujących na informacji z grafów, do których
skierowane jest zapytanie.
Możliwe jest zarówno lokalne jak i zdalne wykorzystanie SPARQL jako języka dostępu do
danych.
SPARQL bazuje na łączeniu wzorów grafów. Najprostszy wzór grafu jest wzorem trójki, który
wygląda jak trójka RDF, ale pozwala na wykorzystanie zmiennych w miejscu podmiotu,
predykatu lub obiektu.
Poniższy przykład ilustruje tworzenie prostego zapytania szukającego tytułu książki na
podstawie informacji w zadanym grafie. Zapytanie składa się z dwóch formuł, SELECT oraz
WHERE, mających takie samo zastosowanie jak dla RDQL.
Dane:
10
Por. szerzej http://www.w3.org/TR/rdf-sparql-query/ szerzej http://www.w3.org/TR/rdf-sparql-query/
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .
Zapytanie:
SELECT ?title
WHERE
{ <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> ?title . }
Odpowiedzią jest tytuł "SPARQL Tutorial".
2. Składnia
a) Identyfikatory IRI
Terminy objęte nawiasami „< >” są referencjami IRI. Są one uogólnieniem referencji URI i
całkowicie kompatybilne z nimi oraz z URL. SPARQL zapewnia dwa skrócone
mechanizmy dla IRI, nazw prefiksów oraz względnych IRI.
Słowo kluczowe PREFIX kojarzy etykietę prefiksu z IRI. Nazwa prefiksu jest jego etykietą i
lokalną częścią oddzieloną dwukropkiem. Względne IRI składają się z bazowych IRI
używających tylko bazowych algorytmów. Słowo kluczowe BASE definiuje bazowy IRI.
b) Wartości liczbowo-literowe
Ogólna składnia wartości liczbowo-literowych to stringi zamknięte w podwójnych
cudzysłowach z opcjonalnie dodaną etykietą językową (poprzedzoną znakiem @), typem
danych lub nazwą prefiksu (poprzedzoną symbolem ^^). Dla wygody liczby całkowite
mogą być zapisywane bezpośrednio i są interpretowane jako typ danych xsd:integer,
ułamki dziesiętne z kropką oddzielającą część całkowitą od ułamka są interpretowane
jako xsd:decimal, a liczby zapisane w postaci potęgi z wykładnikiem jako xsd:double.
Istnieje również możliwość zapisywania logicznej wartości wyrażeń za pomocą true lub
false.
c) Zmienne
Zmienne w zapytaniach SPARQL mają globalny zasięg. Dana nazwa w całym zapytaniu
jest tą samą zmienną. Zmienne są poprzedzone znakiem zapytania „?” lub znakiem „$”, a
co za tym idzie w danym zapytaniu ?x oraz $x oznacza tą samą zmienną.
d) Puste węzły
Puste węzły mogą pojawiać się we wzorach zapytań i biorą udział w ich łączeniu. Są one
wskazywane formułą "_:a" lub przy użyciu "[ ]".
e) Wzory trójek
Wzory trójek są zapisywane w postaci listy elementów, podmiotu, predykatu i obiektu.
Istnieją skrócone formy zapisu pewnych popularnych trójek.
f) Przykład składni zapytania
BASE
http://example.org/book/
PREFIX dc: http://purl.org/dc/elements/1.1/
SELECT $title
WHERE { <book1> dc:title ?title }
Nazwa prefiksu nie ma wpływu na zapytanie.
3. Podstawowe definicje.
Niech:
I będzie zbiorem wszystkich identyfikatorów IRI,
L zbiorem wszystkich wartości liczbowo-literowych RDF,
B zbiorem wszystkich pustych węzłów w grafie RDF,
Wtedy zbiór terminów RDF T = L ∪ B nad zbiorem I.
Taka definicja terminów RDF obejmuje razem wszystkie podstawowe notacje modelu RDF
uaktualnione do odnoszenia się do IRI a nie referencji URI.
Zmienne należą do zbioru V, który jest nieskończony i rozłączny ze zbiorem T.
Każde zapytanie SPARQL jest krotką (GP, DS., SM, R), gdzie GP jest wzorem grafu, DS.
zbiorem danych RDF, SM jest zbiorem modyfikatorów rozwiązań, a R jest postacią rezultatu
(odpowiedzi). Wzór grafu zapytania jest nazywany wzorem zapytania.
Bloki zapytań są wzorami trójek. Każdy wzór trójki jest elementem następującego zbioru
(T ∪ V ) × ( I ∪ V ) × (T ∪ V ) . Ta definicja obejmuje wartości liczbowo-literowe jako podmioty,
jednak żadne zapytanie posiadające wartość liczbowo-literową jako podmiot nie będzie
pasować do żadnego grafu RDF. Ponadto powyższa definicja pozwala również na
występowanie
pustych
węzłów
jako
predykatów,
co
może
okazać
się
równie
problematyczne.
Rozwiązanie zmiennej polega na podstawieniu funkcji ze zbioru zmiennych V do zbioru T.
Zbiór rozwiązania S jest podstawieniem zmiennej, której dziedzina zawiera wszystkie
zmienne w V i której zasięg jest podzbiorem zbioru terminów RDF. Rezultat zastępowania
każdej zmiennej v w grafie wzorem P przez S(v) jest zapisywany jako S(P). Jeśli v nie należy
do dziedziny S to wtedy S(v) jest zdefiniowane jako v.
Na przykład zapytanie
PREFIX dc: <http:// purl.org/dc/elements/1.1/>
SELECT ?book ?title
WHERE { ?book dc:title ?title }
ma pojedynczy wzór trójki jako wzór zapytania łączy graf pojedynczej trójki
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL" .
z rozwiązaniem
book: <http://example.org/book/book1>
title: “SPARQL”
4. Podstawowe zbiory grafów
Podstawowy zbiór grafów jest zbiorem wzorów trójek oraz formą łączenia zapytań SPARQL.
Dwa podstawowe zbiory grafów są równoważne jeżeli istnieje bijekcja M między wzorem
trójki, która odwzorowuje puste węzły w puste węzły, zmienne, wartości liczbowo-literowe i
IRI w siebie same w taki sposób, że trójka (s, p, o) jest w pierwszym wzorze wtedy i tylko
wtedy, gdy trójka (M(s), M(p), M(o)) jest w drugim wzorze.
Powyższa definicja rozszerza równoważność grafów RDF do podstawowych zbiorów grafów
zachowując nazwy zmiennych w równoważnym grafie.
5. Ogólne ramy
Zbiór zakresu (scoping set) B ogranicza wartości wyznaczonych w rozwiązaniu zmiennych.
Graf zakresu G’ dla grafu RDF G jest grafem równoważnym do G i pozwala na łączenie
danego grafu niezależnie od wyboru nazw pustych węzłów. Ten sam zbiór zakresu i graf
zakresu są używane do łączenia wszystkich podstawowych wzorów grafów w pojedynczym
zapytaniu.
E-łączenie (E-matching) podstawowych wzorów grafów:
Dany jest podstawowy wzór grafu BGP, graf G oraz jego graf zakresu G’, wtedy BGP łączy
się z wzorem rozwiązania S na grafie G z uwzględnieniem zbioru zakresu B, jeśli:
• BGP’ jest podstawowym wzorem grafu, który jest równoważny do BGP,
• G’ i BGP’ nie współdzielą żadnych etykiet pustych węzłów,
• G '∪S ( BGP' ) jest dobrze określonym grafem RDF do wnioskowania,
• G E-implikuje G '∪S ( BGP' ) ,
• wszystkie terminy RDF określone w S pojawiają się w B.
Przykład łączenia
Dane:
@prefix foaf:
<http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Johnny Lee Outlaw" .
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "A. N. Other" .
_:b foaf:mbox <mailto:[email protected]> .
Zapytanie:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?mbox
WHERE
{ ?x foaf:name "Johnny Lee Outlaw" .
?x foaf:mbox ?mbox }
Rezultat:
mbox: <mailto:[email protected]>
To zapytanie składa się z podstawowych wzorów grafów dwóch trójek. Wzór rozwiązania
łączący podstawowy wzór grafu odwzorowuje zmienną ‘x’ do pustego węzła _:a i zmienną
‘mbox’ do IRI mailto:[email protected]. Zapytanie zwraca tylko zmienną ‘mbox’.
6. Wielokrotne połączenia
Rezultatem
zapytania jest
zbiór
wzorów rozwiązań,
które łączą wzór
zapytania
przedstawiając wszystkie sposoby, na jakie zapytanie może łączyć się z grafem, do którego
się odnosi. Każdy rezultat jest jednym rozwiązaniem dla zapytania, a może istnieć zero,
jeden lub więcej rezultatów dla danego zapytania.
Dane:
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "Peter Goodguy" .
_:b foaf:mbox <mailto:[email protected]> .
Zapytanie:
SELECT ?name ?mbox
WHERE
{ ?x foaf:name ?name .
?x foaf:mbox ?mbox }
Rezultat:
name: "Johnny Lee Outlaw", "Peter Goodguy"
mbox: <mailto:[email protected]>, <mailto:[email protected]>
Rezultat wymienia terminy RDF, do których mogą być połączone wyselekcjonowane
zmienne wzoru zapytania. W powyższym przykładzie następujące dwa podzbiory danych
zapewniają dwa połączenia:
_:a foaf:box <mailto:[email protected]> .
_:b foaf:name "Peter Goodguy" .
_:b foaf:box <mailto:[email protected]> .
7. Puste węzły w rezultatach
Obecność pustych węzłów w rezultatach zapytania może być wskazywana przez etykiety.
Puste węzły w rezultatach są identyczne z tymi pojawiającymi się w grafach, dopóki
wszystkie węzły zapytania są traktowane jako lokalne w zapytaniu.
Dane:
_:a foaf:name "Alice" .
_:b foaf:name "Bob" .
Zapytanie:
SELECT ?x ?name
WHERE { ?x foaf:name ?name }
Rezultat:
x
name
_:c
“Alice”
_:d
“Bob”
Powyższy rezultat może być zapisany z innymi etykietami pustych węzłów, ponieważ tutaj
wskazują one tylko, czy terminy RDF w rozwiązaniu są takie same czy różne.
8. Inne formy syntaktyczne
W języku SPARQL istnieją formy syntaktyczne skracające pewne sekwencje trójek,
jednocześnie nie zmieniając ich znaczenia.
Wzory trójek z popularnymi podmiotami mogą być zapisywane w taki sposób, że podmiot
jest zapisywany tylko raz i używany do innych wzorów trójek za pomocą średnika „ ; ”.
Przykład:
?x foaf:name ?name .
?x foaf:mbox ?mbox .
?x foaf:name ?name ;
foaf:mbox ?mbox .
Wzory trójek mające ten sam podmiot i predykat mogą być zapisane przy użyciu przecinka.
Przykład:
?x foaf:nick "Alice" .
?x foaf:nick "Alice_" .
?x foaf:nick "Alice" , "Alice_" .
Listy obiektów mogą być tworzone z list predykat-obiekt:
?x foaf:nick "Alice" .
?x foaf:nick "Alice_" .
?x foaf:name ?name ; foaf:nick "Alice" , "Alice_" .
Puste węzły mają etykiety lokalne dla zapytań. Zapisujemy „_:a” dla pustego węzła z etykietą
„a”. Pusty węzeł używany tylko w jednym miejscu zapytania może być skrócony za pomocą
nawiasu kwadratowego [ ]. Zostanie wtedy utworzony unikalny węzeł używany do tworzenia
wzoru trójki. Konstrukcja [:p :v] może być używana do tworzenia etykiety pustego węzła
używanego jako podmiot wszystkich par predykat-obiekt. Taki pusty węzeł może być również
używany w późniejszych wzorach trójek na miejscu podmiotu i obiektu.
Następujące dwie formy
[ :p "v" ] .
[] :p "v" .
przydzielają etykietę unikalnemu pustemu węzłowi (tutaj „b57”) i są równoważne z zapisem:
_:b57 :p "v" .
Tak przydzielona etykieta może być używana jako podmiot lub obiekt późniejszych wzorów
trójek, na przykład jako podmiot:
[ :p "v" ] :q "w" .
i jest równoważna dwóm trójkom:
_:b57 :p "v" .
_:b57 :q "w" .
Skrócona składnia pustych węzłów może być łączona z innymi skróconymi formami:
[ foaf:name ?name ;
foaf:mbox <mailto:[email protected]> ]
Powyższy zapis jest równoważny następującemu wzorowi grafu:
_:b18 foaf:name ?name .
_:b18 foaf:mbox <mailto:[email protected]> .
Zbiory elementów RDF mogą być zapisywane we wzorach trójek przy użyciu nawiasów
okrągłych. Kiedy używamy ich ze zbiorem elementów, na przykład (1 ?x 3 4), wtedy do
zbioru przydzielane są wzory trójek i puste węzły, a pusty węzeł w nagłówku zbioru może
być używany jako podmiot lub obiekt w innych wzorach trójek.
(1 ?x 3 4) :p "w" .
Jest skróconą formą dla
_:b0 rdf:first 1 ;
rdf:rest _:b1 .
_:b1 rdf:first ?x ;
rdf:rest _:b2 .
_:b2 rdf:first 3 ;
rdf:rest _:b3 .
_:b3 rdf:first 4 ;
rdf:rest rdf:nil .
_:b0 :p
"w" .
Zbiory RDF mogą być zagnieżdżane i łączone z innymi skróconymi formami:
(1 [:p :q] ( 2 ) ) .
jest skrótem od
_:b0 rdf:first 1 ;
rdf:rest _:b1 .
_:b1 rdf:first _:b2 .
_:b2 :p
:q .
_:b1 rdf:rest _:b3 .
_:b3 rdf:first _:b4 .
_:b4 rdf:first 2 ;
rdf:rest rdf:nil .
_:b3 rdf:rest rdf:nil .
Litera “a” może być używana jako predykat we wzorach trójek i zastępuje rdf:type:
?x a :Class1 .
[ a :appClass ] :p "v" .
skraca zapis
?x
rdf:type :Class1 .
_:b0 rdf:type :appClass .
_:b0 :p
"v" .
9. Współpraca z wartościami liczbowo-literowymi RDF
W języku SPARQL wartości liczbowo-literowe zapisywane są jako stringi zawierające ich
leksykalną formę, opcjonalnie występuje po nich etykieta językowa lub typ danych. Są pewne
wygodne formuły dla numerycznych wartości typu xsd:integer, xsd:decimal, xsd:double jak
również dla xsd:boolean.
Przykładowe dane zawierające wartości liczbowo-literowe, do których będą odnosić się
kolejne przykłady:
@prefix dt: <http://example.org/datatype#> .
@prefix ns: <http://example.org/ns#> .
@prefix :
<http://example.org/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
:x ns:p
"42"^^xsd:integer .
:y ns:p
"abc"^^dt:specialDatatype .
:z ns:p
"cat"@en .
Przykładowe zapytania:
SELECT ?v WHERE { ?v ?p 42 }
Odpowiedzią na pierwsze pytanie jest :x ponieważ liczba 42 jest składnią dla
"42"^^<http://www.w3.org/2001/XMLSchema#integer>.
SELECT ?v WHERE { ?v ?p "abc"^^<http://example.org/datatype#specialDatatype> }
Powyższe zapytanie ma odpowiedź ze zmienną v będącą :y. Procesor zapytań nie
dysponuje zrozumieniem wartości w przestrzeni typów danych, ponieważ w tym przypadku
leksykalna forma i typ danych IRI całkowicie się łączą (oznaczają to samo).
Następujące zapytanie nie ma żadnej odpowiedzi, ponieważ „cat” nie jest tą samą wartością
RDF co „cat”@en.
SELECT ?x WHERE { ?x ?p "cat" }
Ale rozwiązanie zostanie znalezione gdy zmienna :x zostanie zastąpiona przez zmienną :z
SELECT ?x WHERE { ?x ?p "cat"@en }
Łączenie wzorów grafów tworzy połączenia zmiennych. Jest możliwe późniejsze
ograniczanie rozwiązania. Ograniczenia wartości przyjmują formę wyrażeń z wartościami
typu Boolean, również język pozwala na specyficzne ograniczenia wartości w rozwiązaniu.
Dane do poniższego zapytania:
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix :
<http://example.org/book/> .
:book1 dc:title "SPARQL Tutorial" .
:book1 ns:price 42 .
:book2 dc:title "The Semantic Web" .
Zapytanie:
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ns: <http://example.org/ns#>
SELECT ?title ?price
WHERE { ?x ns:price ?price .
FILTER (?price < 30) .
?x dc:title ?title . }
Rezultat:
title: "The Semantic Web",
price: 23
Poprzez ograniczenie na zmiennej price tylko book2 pasuje do tego pytania, ponieważ
ograniczenie dopuszcza jedynie wartości mniejsze od pewnej granicznej wartości, a to
spełnione jest tylko przez book2.
Dla ograniczenia wartości C rozwiązanie S pasuje do C, jeśli S(C) jest prawdziwe i jest
wyrażeniem otrzymanym przez podstawienie zmiennych wymienionych w C.
Ograniczenia mogą ograniczać wartości terminów RDF albo niektóre ich części, takie jak
forma leksykalna. Zdarza się, że mogą prowadzić do błędnych warunków przy testowaniu
niektórych terminów. Właściwy błąd będzie zależał od ograniczenia. Na przykład w
numerycznych operatorach rozwiązania bez powiązań zmiennych do nienumerycznych lub
pustych węzłów będzie on prowadzić do błędu. Potencjalne rozwiązanie powodujące błąd w
ograniczeniach nie stanie się częścią rezultatów, ale nie spowoduje również niepowodzenia
zapytania.
10.
Wzory grafów
Wzory złożonych grafów mogą powstawać jako kombinacje wzorów prostych grafów.
Sposoby ich tworzenia to:
• Wzory podstawowych grafów, gdzie zbiór wzorów trójek musi być połączony.
• Grupowanie wzorów grafów, gdzie zbiór wzorów musi pasować do wszystkich
używając tych samych podstawień zmiennych.
Wzór grupy grafów GP jest zbiorem grafów GPi . Rozwiązanie wzoru grupy grafów na
grafie G jest dowolnym rozwianiem S takim, że dla każdego elementu GPi S jest
rozwiązaniem GPi .
Dla dowolnego rozwiązania ta sama zmienna ma daną tą samą wartość wszędzie w
zbiorze wzorów grafów tworzących wzór grupy grafów.
Wzór grupy grafów w zapytaniu jest zawsze ograniczony nawiasami klamrowymi { }.
PREFIX foaf:
<http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE {
?x foaf:mbox ?mbox .
}
Takie samo rozwiązanie zostałoby otrzymane z zapytania grupującego wzory trójek jak
w poniższym przykładzie:
PREFIX foaf:
SELECT ?name ?mbox
WHERE { { ?x foaf:name ?name . }
{ ?x foaf:mbox ?mbox . }
}
• Ograniczenia wartości, które ograniczają terminy RDF w rozwiązaniu.
• Opcjonalne wzory grafów, gdzie dodatkowe wzory mogą rozszerzać rozwiązanie.
• Alternatywne wzory grafów, gdzie wzory są łączone z nazwanymi grafami.
Rozwiązania niekoniecznie muszą mieć zmienne połączone w każdym rozwiązaniu. Wzory
zapytań SPARQL są zbudowane z podstawowych wzorów, które kojarzą terminy RDF z
każdą zmienną wymienioną we wzorze a opcjonalne i sumowane wzory grafów mogą
prowadzić do rezultatów, w których zmienna może być połączona w niektórych
rozwiązaniach, a w innych nie.
W SPARQL nie ma określonego porządku wzorów grafów wewnątrz wzoru grupy grafów.
Każde rozwiązanie dla wzoru grupy spełniające wszystkie wzory jest obowiązujące
niezależnie od kolejności.
11.
Zawieranie opcjonalnych wartości
Podstawowe wzory grafów pozwalają aplikacjom tworzyć zapytania, w których wejściowy
wzór zapytania musi dopasowywać się do bycia rozwiązaniem. Dla każdego rozwiązania
każda zmienna jest łączona z terminem RDF we wzorze rozwiązania. Jednak regularne,
kompletne struktury nie mogą być rozważane we wszystkich grafach i użytecznym jest
posiadanie zapytań pozwalających na dodawanie informacji do rozwiązania, gdzie jest ona
dostępna, ale rozwiązanie nie jest odrzucane z powodu niepasowania niektórych części
wzoru zapytania. Łączenie opcjonalne zapewnia to udogodnienie. Jeśli opcjonalna część nie
prowadzi do żadnego rozwiązania, to zmienne mogą pozostać niepołączone.
Opcjonalne części wzorów grafów mogą być syntaktycznie specyfikowane za pomocą słowa
kluczowego OPTIONAL.
Dane:
@prefix foaf:
@prefix rdf:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
_:a rdf:type
foaf:Person .
_:a foaf:name
"Alice" .
_:a foaf:mbox
<mailto:[email protected]> .
_:a foaf:mbox
_:b rdf:type
foaf:Person .
_:b foaf:name
"Bob" .
Zapytanie:
SELECT ?name ?mbox
WHERE { ?x foaf:name ?name .
OPTIONAL { ?x foaf:mbox ?mbox }
}
Z powyższych danych rezultatem zapytania są następujące odpowiedzi:
name
mbox
”Alice”
<mailto:[email protected]>
”Alice”
”Bob”
Powyższe zapytanie znajduje imiona osób w danych. Jeśli istnieje predykat mbox z jakimś
podmiotem, to rozwiązanie zawiera również obiekt tej trójki. W przykładzie opcjonalnie dany
jest pojedynczy wzór. Cały wzór grafu dany opcjonalnie musi pasować, aby został dodany do
rozwiązania.
Dane:
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix :
<http://example.org/book/> .
:book1 dc:title "SPARQL Tutorial" .
:book2 dc:title "The Semantic Web" .
Zapytanie:
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ns: <http://example.org/ns#>
SELECT ?title ?price
WHERE { ?x dc:title ?title .
OPTIONAL { ?x ns:price ?price . FILTER (?price < 30) }
}
Odpowiedź:
title
price
"SPARQL Tutorial"
"The Semantic Web"
23
W przypadku pierwszego tytułu nie pojawia się informacja o cenie, ponieważ opcjonalny
wzór grafu nie prowadzi do rozwiązania zawierającego zmienną „price”.
W zapytaniach może pojawić się więcej niż jeden opcjonalny wzór:
SELECT ?name ?mbox ?hpage
WHERE { ?x foaf:name ?name .
OPTIONAL { ?x foaf:mbox ?mbox } .
OPTIONAL { ?x foaf:homepage ?hpage }
}
Definicja:
Opcjonalny wzór grafu jest kombinacją pary wzorów grafu. Drugi wzór modyfikuje
rozwiązania wzorów pierwszego wzoru i łączy cały ogólny opcjonalny wzór grafu. Jeśli
Opt(A,B) jest opcjonalnym wzorem grafu, gdzie A i B są wzorami grafów, wtedy S jest
rozwiązaniem, jeśli jest rozwiązaniem wzoru A i B, w przeciwnym wypadku, gdy S jest
rozwiązaniem dla A, ale nie dla A i B.
Opcjonalne wzory grafów mogą występować w dowolnych zbiorach wzorów grafów, również
w takich, które same są opcjonalne tworząc w ten sposób wzór siatkowy.
Przykładowe dane:
@prefix foaf:
@prefix vcard:
<http://www.w3.org/2001/vcard-rdf/3.0#> .
_:a foaf:name
"Alice" .
_:a foaf:mbox
_:a vcard:N
_:x .
_:x vcard:Family "Hacker" .
_:x vcard:Given "Alice" .
_:b foaf:name
"Bob" .
_:b foaf:mbox
_:b foaf:N
_:z .
_:z vcard:Family "Hacker" .
_:e foaf:name
_:e vcard:N
"Ella" .
_:y .
_:y vcard:Given "Eleanor" .
Zapytanie:
PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?foafName ?mbox ?gname ?fname
WHERE
{ ?x foaf:name ?foafName .
OPTIONAL { ?x foaf:mbox ?mbox } .
OPTIONAL { ?x vcard:N ?vc .
?vc vcard:Given ?gname .
OPTIONAL { ?vc vcard:Family ?fname }
}
}
Odpowiedź:
foafName
mbox
gname
fname
“Alice”
"Alice"
"Hacker"
“Bob”
“Ella”
"Eleanor"
Powyższe zapytanie znajduje imię, opcjonalnie mbox oraz imię dane vCard i jeśli jest
podane nazwisko vCard znajduje również imię Given. Poprzez tworzenie siatki opcjonalnego
wzoru zawierającego vcard:Family zapytanie wskazuje tylko te, które są odpowiednimi
trójkami vcard:N i vcard:Given. Tutaj wyrażenie jest prostym wzorem trójki na vcard:N, ale
mogłoby być złożonym wzorem grafu z ograniczeniami wartości.
12.
Łączenie alternatyw
SPARQL zapewnia znaczenie kombinacji wzorów grafów w taki sposób, że różne,
alternatywne wzory grafów mogą pasować do zapytania. Jeżeli pasuje więcej niż jedna
alternatywa, to znajdowane są wszystkie możliwe rozwiązania wzorów.
Słowem kluczowym dla alternatywy jest suma (UNION).
Dane:
@prefix dc10: <http://purl.org/dc/elements/1.0/> .
@prefix dc11: <http://purl.org/dc/elements/1.1/> .
_:a dc10:title
"SPARQL Query Language Tutorial" .
_:b dc11:title
"SPARQL Protocol Tutorial" .
_:c dc10:title
"SPARQL" .
_:c dc11:title
"SPARQL (updated)" .
Zapytanie:
PREFIX dc10: <http://purl.org/dc/elements/1.0/>
SELECT ?title
WHERE { { ?book dc10:title ?title } UNION { ?book dc11:title ?title } }
Odpowiedzi:
title
"SPARQL Protocol Tutorial"
"SPARQL"
"SPARQL (updated)"
"SPARQL Query Language Tutorial"
Powyższe zapytanie szuka tytułów książek wymienionych w danych, zarówno gdy
informacja została zapisana przy pomocy właściwości Dubline Core11 w wersji 1.0, jak i w
wersji 1.1. Jeżeli aplikacja potrzebuje wiedzieć jak dokładnie informacja została zapisana, to
zapytanie postaci
SELECT ?x ?y
WHERE { { ?book dc10:title ?x } UNION { ?book dc11:title ?y } }
zwróci wyniki dla zmiennych ?x oraz ?y ograniczone w zależności od formatu zapisu
informacji.
x
y
"SPARQL (updated)"
"SPARQL Protocol Tutorial"
"SPARQL"
"SPARQL Query Language Tutorial"
Warto zauważyć, że w przeciwieństwie do wzoru OPTIONAL, gdy żadna część wzoru sumy
nie pasuje, to wówczas taki wzór grafu nie zostanie wskazany.
Operator sumy łączy wzory grafów, zatem więcej niż jeden wzór trójki może być dany w
miejscu każdego z elementów alternatywy.
11
Dubline Core jest ogólnym standardem metadanych do opisu zasobów (standard ISO).
Definicja:
Wzór sumy grafów jest zbiorem wzorów grafów GPi . Taka suma łączy graf G z
rozwiązaniem S, jeśli istnieją GPi łączące G z rozwiązaniem S.
Odpowiedź zawierająca na przykład wzory GP1 i GP2 będzie zawierać osobne rozwiązania
dla każdego połączenia z różnymi zbiorami.
13.
Zbiory danych RDF
Zapytania SPARQL są wykonywane dla zbiorów danych RDF reprezentujących zbiory
grafów. Różne części zapytań mogą pasować do różnych grafów. Istnieje jeden graf, tzw.
domyślny graf nie posiadający nazwy oraz zero lub więcej nazwanych grafów
identyfikowanych przez IRI.
Definicja:
Zbiór danych RDF jest zbiorem {G, (< u1 >, G1 ), (, G2 ), ... , (, Gn )} , gdzie G oraz
Gi są grafami, a różnymi identyfikatorami IRI. G jest grafem domyślnym, a
(, Gi ) nazwanymi grafami.
Do tej pory opisywane przykłady przedstawiały zapytania dla pojedynczego grafu będącego
domyślnym grafem zbioru danych RDF. Zapytanie nie musi jednak zawierać połączenia do
grafu domyślnego, wystarczy jak posiada połączenia z nazwanymi grafami.
Przy tworzeniu zapytań do zbiorów grafów używa się słowa kluczowego GRAPH łączącego
wzory z nazwanymi grafami. Robi się to albo za pomocą IRI, albo używając zmienną o
zasięgu IRI nazywających grafy.
Definicja:
Wzór grafu zbioru danych RDF.
Jeżeli D jest zbiorem {G, (< u1 >, G1 ), ...} a P wzorem grafu, wtedy S jest wzorem
rozwiązania wzoru grafu zbioru danych RDF GRAPH(g, P), jeżeli spełnione są warunki:
• g jest wskaźnikiem IRI, gdzie g = dla niektórych i, a S jest rozwiązaniem dla P
na zbiorze danych {Gi , (< u1 >, G1 ), ...}
• g jest zmienną, S odwzorowuje g do będącego IRI z nazwanego grafu D i S
jest rozwiązaniem P na zbiorze danych {G j , (< u1 >, G1 ), ...} .
Poniższe dwa grafy stanowią dane dla następnych zapytań:
# Named graph: http://example.org/foaf/aliceFoaf
@prefix rdf:
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
_:a foaf:name
"Alice" .
_:a foaf:mbox
_:a foaf:knows
_:b .
_:b foaf:name
"Bob" .
_:b foaf:mbox
_:b foaf:nick
"Bobby" .
_:b rdfs:seeAlso <http://example.org/foaf/bobFoaf> .
<http://example.org/foaf/bobFoaf>
rdf:type
foaf:PersonalProfileDocument .
# Named graph: http://example.org/foaf/bobFoaf
@prefix rdf:
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
_:z foaf:mbox
_:z rdfs:seeAlso <http://example.org/foaf/bobFoaf> .
_:z foaf:nick
"Robert" .
rdf:type
foaf:PersonalProfileDocument .
Poniższe zapytanie łączy wzór grafu w każdym z nazwanych grafów w zbiorze danych i
tworzy rozwiązania, które mają src zmienną kojarzącą się z IRI łączącego się grafu.
SELECT ?src ?bobNick
WHERE
{
GRAPH ?src
{ ?x foaf:mbox <mailto:[email protected]> .
?x foaf:nick ?bobNick
}
Rezultat grafu w odpowiedzi daje nazwy grafów, w których informacja została znaleziona i
wartość nicka Boby’ego.
src
bobNick
<http://example.org/foaf/aliceFoaf>
„Bobby”
„Robert”
Zapytanie może ograniczać połączenia pasujące do konkretnego grafu poprzez dostarczenie
IRI.
Zmienne używane w formule GRAPH mogą być także używane przez inną taką formułę lub
we wzorze grafu, który jest połączony z domyślnym grafem ze zbioru danych. Taki sposób
wykorzystania zmiennych może być używany do znajdowania informacji w jednej części
zapytania i w ten sposób ograniczania grafów połączonych w innej części zapytania.
Wzory zapytań mogą zawierać zarówno domyślne jak i nazwane grafy. Może wystąpić
sytuacja, że za każdym razem czytania grafu jest mu nadawany IRI przez lokalny system.
Tak powstałe grafy są prawie identyczne, ale zmieniają się nieznacznie dane wewnątrz ( np.
w zależności od momentu wczytywania).
SPARQKL może określać zbiór danych przeznaczony do łączenia. Wyrażenie FROM podaje
IRI, jakie procesor zapytań może użyć do tworzenia domyślnego grafu oraz FROM NAMED
używane do specyfikowania nazwanych grafów. Do kojarzenia zbioru danych RDF z
zapytaniem używany jest procesor zapytań. Może on na przykład używać IRI do
odzyskiwania dokumentów, analizować je a wynikające trójki używa jako jeden z grafów.
Wyrażenia FROM i FROM NAMED pozwalają zapytaniu na specyfikowanie zbioru danych
RDF za pomocą referencji. Wskazują one, że zbiór danych powinien zawierać grafy
otrzymane z reprezentacji zasobów identyfikowanych przez dane IRI. Zbiór danych
wynikający z tych wyrażeń jest:
• domyślnym grafem składającym się z połączenia grafów, do których odnośniki zawarte
są z wyrażeniu FROM,
• zbiorem par (IRI< graf) z każdego wyrażenia FROM NAMED.
Jeżeli zapytanie zapewnia taki opis zbioru danych, to jest używane w miejscu dowolnego
zbioru danych, którego użyłaby usługa zapytania, gdyby żaden opis nie był zapewniony w
zapytaniu.
14.
Formy rezultatów zapytania.
SPARQL ma cztery formy rezultatów zapytań, które używają rozwiązań z wzorów łączących
się ze zbiorami rezultatów lub grafami RDF.
• SELECT – zwraca wszystkie zmienne (lub tylko podzbiór) związane z poszukiwanymi
elementami we wzorze zapytania.
• CONSTRUCT – zwraca graf RDF skonstruowany przez podstawienie zmiennych w
zbiorze szablonów trójek.
•
DESCRIBE – zwraca graf RDF opisujący znalezione zasoby.
• ASK – zwraca pewne wartości (np. liczbowe) wskazujące, czy wzór zapytania łączy się
danymi.
Wzory zapytań generują nieuporządkowane zbiory rozwiązań. Każde z nich jest funkcją
zmiennych dla terminów RDF. Te rozwiązania są traktowane jako sekwencja, początkowo
nie posiadająca konkretnego porządku, do której stosowane są modyfikatory tworzące inne
sekwencje. Te ostatnie sekwencje używane są do generowania jednej z form rezultatów.
Innymi słowy, sekwencja rozwiązania jest nieuporządkowanym zbiorem złożonym z
rozwiązań poszczególnych wzorów zapytań.
Modyfikator sekwencji rozwiązania jest jednym z następujących:
a) Modyfikator projekcji, polecenie PROJECTION
Sekwencja rozwiązania może być transformowana do jednej, zawierającej tylko podzbiór
zmiennych. Dla każdego rozwiązania w sekwencji nowe rozwiązanie jest tworzone przy
określonej selekcji zmiennych.
Definicja:
Projekcja
rozwiązania
QS
nad
zbiorem
zmiennych
VS
jest
rozwiązaniem
project (QS ,VS ) = {(v, QS (v)) : v ∈ VS} . Dla sekwencji rozwiązania S = ( S1 , S 2 , ... , S n ) i
skończonego zbioru zmiennych VS projekcja wygląda następująco:
project ( S ,VS ) = { project( S i ,VS ) : i = 1,...n}
Poniższy przykład przedstawia zapytanie do pewnego fragmentu z nazwiskami ludzi
opisanymi grafem RDF.
Dane:
@prefix foaf:
_:a foaf:name
"Alice" .
_:a foaf:mbox
_:b foaf:name
"Bob" .
_:b foaf:mbox
Zapytanie:
PREFIX foaf:
SELECT ?name
WHERE
{ ?x foaf:name ?name }
Rezultat:
name
“Bob”
“Alice”
b) Modyfikator rozłączności, polecenie DISTINCT, zapewnia, że rozwiązanie w sekwencji
jest jedyne.
Sekwencja rozwiązania może być modyfikowana za pomocą tego słowa kluczowego,
które zapewnia, że każda kombinacja powiązań zmiennych (w tym każde rozwiązanie) w
sekwencji jest jedyna. Inaczej mówiąc, rozłączna sekwencja rozwiązania jest taką
sekwencją, w której żadne dwa rozwiązania nie są takie same.
Dane:
_:a
foaf:name "Alice" .
_:a
foaf:mbox <mailto:alice@org> .
_:z
foaf:name "Alice" .
_:z
foaf:mbox <mailto:smith@work> .
Zapytanie:
PREFIX foaf:
SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }
Rezultat:
name “Alice”
c) Modyfikator porządku (polecenie ORDER BY) ustawia rozwiązania w porządku
Wyrażenie ORDER BY stosuje warunki porządkujące do sekwencji rozwiązania. Warunki
porządkujące mogą być zmiennymi lub wywołaniami funkcji. Warunki porządkujące są
podnoszone (zwiększane) lub obniżane za pomocą poleceń odpowiednio ACS() lub
DESC(). Jeśli danych jest kilka różnorodnych warunków, to wówczas są one stosowane
po kolei, dopóki nie uzyska się odpowiedniego uporządkowania.
PREFIX foaf:
SELECT ?name
ORDER BY ?name
PREFIX
:
<http://example.org/ns#>
PREFIX foaf:
PREFIX xsd:
<http://www.w3.org/2001/XMLSchema#>
SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY DESC(?emp)
PREFIX foaf:
SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY ?name DESC(?emp)
Użycie ORDER BY na sekwencji rozwiązania dla formy rezultatu innej niż SELECT nie da
żadnego bezpośredniego efektu, gdyż tylko polecenie SELECT zwraca sekwencję
rezultatów. W połączeniu z poleceniami LIMIT oraz OFFSET może być używane do
zwracania częściowych rezultatów.
Definicja:
Uporządkowana sekwencja rozwiązania (ordered solution sequence) jest częściowo
uporządkowana z uwzględnieniem pewnych warunków porządkujących.
Sekwencja S = ( S1 , ... , S n ) jest uporządkowana według warunku porządkującego C, jeżeli
dla S i , S j z faktu, że C porządkuje S i przed S j wynika, że i < j.
Warunek porządkujący nie potrzebuje podawać pełnego uporządkowania sekwencji
rezultatów. Operator mniejszości „<” definiuje relatywny porządek par elementów
numerycznych, stringów oraz czasu i daty. IRI porządkowane są przez porównywanie
znaków. Ponadto SPARQL określa z góry zadany porządek między niektórymi terminami
RDF. Ten z góry nadany porządek jest potrzebny do zapewnienia rozdrabniania
rozwiązań poprzez użycie wyrażeń LIMIT i OFFSET.
1. zmienna bez przypisanej wartości lub wyrażenie w rozwiązaniu [najniższy],
2. puste węzły,
3. IRI,
4. wartości liczbowo-literowe RDF,
5. pusta (nieetykietowana) wartość liczbowo-literowa jest niższa niż wartość typu
xsd:string o tej samej leksykalnej formie.
Jeżeli kryteria porządkujące nie określają porządku wartości, wtedy porządek w sekwencji
rozwiązania nie jest zdefiniowany. Porządkowanie sekwencji rozwiązania zawsze daje w
efekcie sekwencję pewnej liczby rozwiązań, nawet jeśli kryteria porządkujące nie
rozróżniają dwóch rozwiązań.
d) Modyfikator limitu (polecenie LIMIT) ogranicza ilość rozwiązań przetwarzanych dla
rezultatu zapytania
Polecenie LIMIT daje wyższe ograniczenia na liczbę zwracanych rozwiązań. Jeśli ilość
aktualnych rozwiązań jest większa niż limit, to zostanie zwrócona co najwyżej taka liczba
rozwiązań, jaką dopuszcza limit.
PREFIX foaf:
SELECT ?name
LIMIT 20
Dla powyższego zapytania zostanie zwróconych maksymalnie 20 rozwiązań, o ile tyle
istnieje.
Definicja:
Ograniczona sekwencja rozwiązania ma zadaną maksymalną liczbę elementów.
( S1 , ... , S m ) dla m < n
( S1 , ... , S n ) dla n ≤ m
Limitem sekwencji rozwiązania S = ( S1 , ... , S n ) jest li mit ( S , m) = 
e) Modyfikator wskaźnika skoku (polecenie OFFSET) kontroluje gdzie zaczynają się
przetwarzane rozwiązania w ogólnej sekwencji rozwiązań
Polecenie OFFSET powoduje, że generowanie rozwiązań rozpoczyna się dopiero po
określonej liczbie rozwiązań. OFFST zero nie daje żadnego efektu. Porządek, w jakim
zwracane są rozwiązania, nie jest na początku zdefiniowany. Używanie poleceń LIMIT i
OFFSET do selekcjonowania różnych podzbiorów rozwiązań zapytania nie będzie
użyteczne, dopóki nie zostanie wcześniej zdefiniowany porządek za pomocą ORDER BY.
PREFIX foaf:
SELECT ?name
ORDER BY ?name
LIMIT 5
OFFSET 10
Definicja:
Dla
sekwencji
rozwiązania
S = ( S1 , ... , S n )
sekwencją
rozwiązania
offset
offset ( S , k ), k ≥ 0 jest sekwencja S = ( S k , S k +1 , ... , S n ) dla k ≤ n albo sekwencja pusta
jeśli k > n .
Selekcjonowanie (SELECT) zwraca bezpośrednio zmienne. Polecenie SELECT * jest
skrótem selekcjonującym wszystkie zmienne.
Dane:
_:a
foaf:name "Alice" .
_:a
foaf:knows _:b .
_:a
foaf:knows _:c .
_:b
foaf:name "Bob" .
_:c
foaf:name "Clare" .
_:c
foaf:nick "CT" .
Zapytanie:
PREFIX foaf:
SELECT ?nameX ?nameY ?nickY
WHERE
{ ?x foaf:knows ?y ;
foaf:name ?nameX .
?y foaf:name ?nameY .
OPTIONAL { ?y foaf:nick ?nickY }
}
Rezultat:
nameX
nameY
“Alice”
“Bob”
“Alice”
“Clare”
nickY
“CT”
Rezultaty zapytania mogą być rozważane jako tabele zbiorów rezultatów, gdzie jeden rząd
odpowiada jednemu rozwiązaniu. Niektóre komórki mogą być puste, ponieważ zmienna nie
jest powiązana z konkretnym rozwiązaniem. Zbiór rozwiązań może być dostępny przez
lokalne API, ale również może być sformatowany do XML albo do grafu RDF.
Konstrukcja grafu wyjściowego bazuje na poleceniu CONSTRUCT , które zwraca pojedynczy
graf określony szablonem grafów. Rezultat jest grafem uformowanym poprzez pobieranie
każdego rozwiązania w sekwencji, podstawienie do zmiennych w szablonie grafu i
utworzeniu trójek dla pojedynczego grafu RDF prze sumę zbiorów. Jeśli w takim procesie
powstanie trójka zawierająca niepołączone zmienne lub konstrukcję niedozwoloną w RDF,
to taka trójka nie zostanie zawarta w wynikowym grafie. Szablon może zawierać trójki bez
zmiennych, które również pojawiają się w grafie wyjściowym zwracanym przez polecenie
CONSTRUCT.
Schemat może tworzyć grafy zawierające puste węzły. Etykiety pustych węzłów są
ograniczone do zakresu szablonu dla każdego rozwiązania. Jeśli ta sama etykieta pojawia
się dwa razy w szablonie, to będzie jeden pusty węzeł stworzony dla każdego rozwiązania,
ale będą one różne poprzez trójki tworzone dla różnych rozwiązań.
W języku SPARQL możliwe jest zadawanie pytań „tak lub nie”. Aplikacja może używać formy
ASK do testowania, czy dany wzór zapytania ma rozwiązanie czy nie. W takiej sytuacji nie
jest zwracana żadna informacji o możliwej postaci rozwiązania, a jedynie o tym, czy serwer
może znaleźć jakieś rozwiązanie czy nie.
Dane:
@prefix foaf:
_:a foaf:name
"Alice" .
_:a foaf:homepage <http://work.example.org/alice/> .
_:b foaf:name
"Bob" .
_:b foaf:mbox
Zapytanie:
PREFIX foaf:
ASK { ?x foaf:name "Alice" }
Odpowiedź: tak
Definicja:
Niech Q=(GP, DS, SM, ASK), gdzie GP jest wzorem grafu, DS zbiorem danych RDF, SM
zbiorem modyfikatorów rozwiązań i QS jest zbiorem rozwiązań stworzonym przez łączenie
zbioru danych DS ze wzorem grafu GP wówczas rezultatem formuły ASK jest prawda (true),
jeśli SM(QS) jest zbiorem niepustym, w przeciwnym wypadku rezultat jest fałszywy.
W języku SPARQL możliwe jest testowanie wartości. Filtry SPARQL (FILTER) ograniczają
zbiór rozwiązań zgodnie z danym wyrażeniem. Filtry eliminują rozwiązanie kiedy
podstawione do wyrażenia daje w wyniku wartość „false” lub powoduje błąd.
Wyrażenia SPARQL są konstruowane zgodnie z gramatyką i zapewniają dostęp do funkcji
(nazwane za pomocą IRI) i operacji. Typy danych argumentów tych funkcji i operatorów są
podzbiorami typów danych XML Schema i typów danych dostarczanych przez xsd:decimal.
Gramatyka SPARQL identyfikuje zbiór operatorów do konstrukcji ograniczeń. Poniższa
tabela kojarzy poszczególne produkty gramatyczne z operatorami podczas selekcjonowania
definicji operatorów dla danego zbioru parametrów. Na przykład szacując, że xsd:integer =
xsd:signedInt, ma zastosowanie definicja równości dwóch numerycznych parametrów.
Operator
Typ operatora
Funkcja
Typ rezultatu
!A
xsd:bolean
fn:not(A)
xsd:bolean
+A
numeryczny
op:numeric-unary-plus(A)
numeryczny
-A
numeryczny
op:numeric-unary-minus(A)
numeryczny
BOUND(A)
zmienna
isBound(A)
xsd:bolean
isLITERAL(A)
termin RDF
isLiteral(A)
xsd:bolean
Tabela 11 Operatory SPARQL
Operator
Typ A i B
Funkcja
Typ rezultatu
A || B
xsd:bolean
logical-or(A, B)
xsd:bolean
A && B
xsd:bolean
logical-and(A, B)
xsd:bolean
A=B
numeryczny
op:numeric-equal(A, B)
xsd:bolean
A=B
xsd:dateTime
op:dateTime-equal(A, B)
xsd:bolean
A != B
numeryczny
fn:not(op:numeric-equal(A, B))
xsd:bolean
AB
numeryczny
op:numeric-greater-than(A, B)
xsd:bolean
A <= B
xsd:dateTime
fn:not(op:dateTime-greater-than(A, B))
xsd:bolean
A >= B
xsd:string
fn:not(op:numeric-equal(fn:compare(STR(A),
xsd:bolean
STR(B)), -1))
A*B
numeryczny
op:numeric-multiply(A, B)
xsd:bolean
A/B
numeryczny
op:numeric-divide(A, B)
xsd:bolean
A+B
numeryczny
op:numeric-add(A, B)
xsd:bolean
A-B
numeryczny
op:numeric-subtract(A, B)
xsd:bolean
Tabela 12 Operatory binarne SPARQL
OWL
OWL12 jest używany przez aplikacje przetwarzające zawartość informacji, a nie jedynie
prezentujące ją użytkownikowi. OWL ułatwia interpretację zawartości informacji, jest
wspierany przez XML, RDF i RDF Scheme. W OWL tworzy się zaawansowane ontologie
oraz możliwe są na nich operacje logiczne. OWL składa się z trzech „podjęzyków”: OWL
Lite, OWL DL i OWL Full.
2.7. Struktura
Dokument OWL to informacje zebrane w ontologiach, które mogą być segregowane jako
dokumenty w sieci www. Jeden z aspektów OWL, importowanie ontologii, zależy właśnie od
możliwości publikowania ontologii w sieci internetowej. Dokument OWL składa się z
opcjonalnych nagłówków oraz aksjomatów (definicji), ich własności oraz faktów o
jednostkach. Specyfikacja nie wymaga umieszczania elementów w określonym porządku,
zachowanie porządku wynika z wygody i ułatwia użytkownikowi zrozumienie.
Opis poszczególnych elementów struktury OWL:
•
zasób (resource) – rzecz, koncept będący elementem ontologii i reprezentowany przez
jednostki,
•
klasa (class) – reprezentuje grupę jednostek o tych samych właściwościach,
•
podklasa (subclass)
-
grupa jednostek danej klasy wyróżniająca się jakąś
właściwością, element strukturalizacji klas,
•
jednostka (individual) – konkretny, istniejący element, będący instancją klasy, dający się
posegregować w klasy i połączony przez pewne relacje (właściwości),
•
właściwości (properties) – określają relacje pomiędzy elementami ontologii
-
właściwości danych (data properties) – relacje między jednostkami a typami
danych,
-
właściwości obiektów (object properties) – relacje między dwoma jednostkami;
•
podwłaściwości (subproperties) – hierarchizują właściwości,
•
dziedzina (domain) – dziedzina właściwości ogranicza jednostki (po stronie podmiotu
relacji) do takich, do których dana właściwość może być zastosowana,
•
zasięg (range) – zasięg właściwości ogranicza jednostki (po stronie obiektu relacji) w
taki sposób, że właściwość może mieć ich wartość.
12
Por. http://www.w3.org/TR/owl-guide/; http://www.w3.org/TR/owl-features/; http://www.w3.org/TR/owl-ref/
Ponadto występują jeszcze inne elementy (szczegółowo opisane w dalszych rozdziałach)
mające następujące zadania ułatwiające wnioskowanie:
•
określanie identyczności i przeciwieństw (relacji, klas, jednostek),
•
określanie własności i charakteru relacji,
•
ograniczenie właściwości,
•
ograniczenie mocy zbiorów wartości danej właściwości.
Jednostki OWL identyfikowane są poprzez identyfikator URI, jedna jednostka (węzeł) ma
dokładnie jeden URI, natomiast jednostka nieelektroniczna dostaje URI lub publiczny
identyfikator podmiotu (public subject identifier). RDF daje możliwość tworzenia pustych
węzłów (blank nodes) reprezentujących anonimowe pojęcia (nieposiadające URI). Klasy
posiadają nazwy lub są anonimowe i reprezentowane wtedy przez jedną z konstrukcji:
-
wyliczanie jednostek,
-
ograniczanie właściwości,
-
wynik działania na innych klasach (suma, przecięcie, dopełnienie),
-
klasa równoważna lub rozłączna.
Relacje między jednostkami są binarne, łączą dokładnie dwie jednostki i mają określony
kierunek. Relacje odwrotną do podanej trzeba stworzyć, nie jest to automatyczne.
OWL składa się z trzech języków pozwalających użytkownikowi dostosować możliwości
języka do swoich oczekiwań:
-
OWL Lite – umożliwia podstawową klasyfikację i hierarchizację, ma najmniej
skomplikowaną składnię ze wszystkich trzech i w związku z tym najmniejsze
możliwości.
-
OWL DL – zapewnia lepszą wyrazistość i szczegółowość, zachowuje kompletną
informację, zawiera wszystkie dostępne konstrukcje OWL, ale można ich używać
jedynie pod pewnymi warunkami.
-
OWL Full – zapewnia maksymalną wyrazistość i swobodę syntaktyczną, dając bardzo
duże możliwości interpretacyjne użytkownikowi, pozwala na znaczne rozszerzanie
ontologii oraz znaczenia pierwotnie zdefiniowanych terminów.
Wbudowane są narzędzia ułatwiające wnioskowanie (własności relacji, ograniczenia), ale nie
można wprowadzać nowych narzędzi. Specyfikacja OWL jest językiem interpretowalnym
przez narzędzia wnioskujące.
Specyfikacja OWL daje możliwość tworzenia i uwzględniania różnych wersji tej samej
ontologii zmieniającej się w czasie. Jest to element pozwalający odwoływać się do starej
wersji ontologii z równoczesnym posiadaniem nowej, aktualnej wersji. Pozwala również na
importowanie istniejących już ontologii lub ich części z równoczesnym sprawdzaniem
kompatybilności występujących tam elementów.
W OWL istnieje możliwość twierdzenia o twierdzeniach (reification), ale jest to czynność
bardzo skomplikowana, wymagająca sporej ingerencji w ontologię. Trzeba dodać nowe
pojęcie reprezentujące zdanie i mające trzy właściwości „has-subject”, „has-poredicate” i
„has-object”, natomiast oryginalne zdanie ulega zmianie, a nowa wersja jest bardziej
abstrakcyjna i wymaga odmiennej interpretacji, a co za tym idzie bardziej skomplikowanych
narzędzi interpretacyjnych.
Najważniejsze zalety OWL:
-
bardzo dobra klasyfikacja danych,
-
bardzo dobre wsparcie wnioskowania,
-
wsparcie semantyczne,
-
z góry zdefiniowane zasady, brak konieczności definiowania nowych,
-
bazowanie na zasadach matematycznych.
1) Klasy
Klasy zapewniają abstrakcyjny mechanizm grupowania zasobów o podobnych własnościach.
Każda klasa jest zbiorem jednostek nazywanym wnętrzem klasy. Jednostki należące do
wnętrza danej klasy nazywamy instancjami klasy. Dwie klasy mogą mieć to samo wnętrze,
ale być różnymi klasami. W OWL lite i OWL DL jednostka nie może być jednocześnie klasą,
na taką swobodę RDF Schema pozwala natomiast OWL Full.
Opis klas.
Opis klas określa klasę OWL poprzez nazwę lub wymienianie elementów jej wnętrza (gdy
klasa jest anonimowa). Istnieje sześć możliwości opisu klasy dostępnych w OWL:
a)
identyfikator URI (gdy klasa opisywana jest za pomocą nazwy),
b)
numerowanie instancji klasy,
c)
ograniczanie właściwości,
d)
sumowanie klas,
e)
mnożenie klas,
f)
dopełnianie innej klasy.
Ostatnie pięć sposobów opisuje klasy anonimowe poprzez nakładanie pewnych warunków
na ich wnętrze, trzy ostatnie korzystają z logicznych operatorów AND, OR, NOT.
a)
Opisywanie klasy za pomocą nazwy.
owl:Class – pozwala zdefiniować klasę OWL
<owl:Class rdf:ID="Human"/> - definicja klasy o nazwie Human
W OWL Lite i OWL DL owl:Class jest podklasą rdfs:Class, natomiast w OWL Full te pojęcia
są równoważne. Pozostałe pięć sposobów opisu klas składa się z trójek RDF, w których
pusty węzeł reprezentuje opisywaną klasę, ma właściwość rdf:type z wartością owl:Class.
W specyfikacji są zdefiniowane dwie klasy owl:Thing i owl:Nothing. Wnętrze pierwszej jest
zbiorem wszystkich jednostek, każda klasa OWL jest jej podklasą, wnętrze drugiej jest
puste.
b)
Numerowanie instancji klasy.
owl:oneOf – właściwość pozwalająca na numerowanie instancji klasy. Wartością tej
właściwości jest lista instancji danej klasy, która jest reprezentowana za pomocą
konstrukcji RDF rdf:parseType="Collection" zapewniającej odpowiednie skróty zapisywania
wymienianych elementów. Korzysta również z konstrukcji <owl:Thing rdf:about="..."/>
odwołującej się do danej jednostki.
Przykład klasy kontynentów:
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Eurasia"/>
<owl:Thing rdf:about="#Africa"/>
<owl:Thing rdf:about="#NorthAmerica"/>
<owl:Thing rdf:about="#SouthAmerica"/>
<owl:Thing rdf:about="#Australia"/>
<owl:Thing rdf:about="#Antarctica"/>
</owl:oneOf>
</owl:Class>
c)
Ograniczenie właściwości.
Ograniczanie właściwości opisuje anonimowe klasy składające się z jednostek
spełniających dane ograniczenia. OWL zapewnia dwa rodzaje ograniczeń: ograniczenie
wartości właściwości i ograniczenie mocy zbioru wartości.
Ograniczenie wartości nakłada warunki na zasięg danej właściwości w opisywanej klasie.
Ograniczenie mocy zbioru wartości nakłada warunki na ilość wartości, jakie może
przyjmować dana właściwość w opisywanej klasie. Obie restrykcje są lokalne, odnoszą się
do właściwości zastosowanej w konkretnej klasie, w innych klasach ta sama właściwość
nie posiada tak zdefiniowanych ograniczeń. Do zdefiniowania ograniczeń wykorzystuje się
konstrukcje owl:Restriction i owl:onProperty. Pierwsza definiuje podklasę, a druga
wskazuje trójkę łączącą ograniczenie z konkretną właściwością. Ograniczenia te mogą być
stosowane zarówno do właściwości danych jak i właściwości obiektów.
Ogólna postać zapisu ograniczenia :
<owl:Restriction>
<owl:onProperty rdf:resource="(some property)" />
(jedna wartość lub ograniczenie mocy…)
</owl:Restriction>
owl:allValuesFrom - ograniczenie właściwości do wartości (zasięgu) z danej klasy
wymaga, żeby dla każdej instancji danej klasy mającej tą właściwość, wszystkie wartości
danej właściwości były elementami klasy wymienionej w formule owl:allValuesFrom.
Przykład – opisuje klasę, która na właściwości hasParent przyjmuje wartości tylko z klasy
Human:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:allValuesFrom rdf:resource="#Human" />
</owl:Restriction>
Konstrukcja owl:allValuesFrom jest odpowiednikiem logicznego kwantyfikatora „dla
każdego” i oznacza: Dla każdej instancji opisywanej klasy każda wartość danej
właściwości spełnia warunek.
owl:someValuesFrom
-
opisuje klasę, w której przynajmniej jedna wartość danej
właściwości jest z klasy wskazywanej przez someValuesFrom.
Przykład – opisuje klasę jednostek, które na właściwości hasParent mają przynajmniej
jedną wartość z klasy Physician:
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#Physician" />
</owl:Restriction>
Konstrukcja owl:someValuesFrom jest odpowiednikiem logicznego kwantyfikatora „istnieje”
i oznacza: Dla każdej instancji opisywanej klasy istnieje przynajmniej jedna wartość danej
właściwości spełniająca warunek.
owl:hasValue – określa klasy bazujące na konkretnych wartościach właściwości, opisuje
klasę jednostek, dla których dana właściwość ma przynajmniej jedną wartość semantycznie
taką samą jak w formule owl:hasValue.
„semantycznie taki sam” oznacza dla jednostek posiadanie tego samego identyfikatora URI
lub zdefiniowanie jako te same jednostki, natomiast dla typów danych oznacza identyczną
leksykalną reprezentację.
Przykład – opisuje klasę jednostek, które na właściwości hasParent mają konkretną
wartość Clinton:
<owl:Restriction>
<owl:hasValue rdf:resource="#Clinton" />
</owl:Restriction>
Ograniczenie mocy zbioru wartości opiera się na tym, że każda instancja klasy może mieć
określoną liczbę wartości danej właściwości. Pozwala określić konkretną ilość wartości
właściwości lub stwierdzić, że dana właściwość nie może występować. OWL zapewnia trzy
konstrukcje ograniczające ilość wartości, OWL Lite pozwala na ich użycie dla ograniczenia
wartości do 0 lub 1.
owl:maxCardinality – łączy klasę z wartościami danych będących nieujemnymi liczbami
całkowitymi. Opisuje klasę jednostek mających co najwyżej N semantycznie różnych
wartości danej właściwości, gdzie N jest wartością z ograniczenia owl:maxCardinality.
Przykład - opisuje klasę jednostek mających co najwyżej dwóch rodziców:
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality>
</owl:Restriction>
owl:minCardinality – działa podobnie jak owl:maxCardinality, tylko określa minimalną
liczbę semantycznie różnych wartości danej właściwości. Ta konstrukcja mając wartość
większą lub równą od 1 oznacza również, że wszystkie instancje klasy muszą mieć co
najmniej jedną wartość danej właściwości.
owl:cardinality - opisuje klasę jednostek mających dokładnie N semantycznie różnych
wartości danej właściwości, gdzie N jest wartością z ograniczenia owl:cardinality.
Przykład – opisuje klasę jednostek mających dokładnie dwóch rodziców:
<owl:Restriction>
<owl:cardinality
rdf:datatype="&xsd;nonNegativeInteger">2</owl:cardinality>
</owl:Restriction>
d)
Suma klas
owl:unionOf – opisuje klasę będącą sumą innych klas, co oznacza, że do danej klasy
należą elementy będące instancjami przynajmniej jednej z klas sumowanych.
Przykład – opisuje klasę mającą trzy instancje Tosca, Salome, i Turandot, o ile są to różne
elementy:
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class>
<owl:Thing rdf:about="#Tosca" />
<owl:Thing rdf:about="#Salome" />
</owl:oneOf>
</owl:Class>
<owl:Class>
<owl:Thing rdf:about="#Turandot" />
</owl:oneOf>
</owl:Class>
</owl:unionOf>
</owl:Class>
Dana konstrukcja jest analogiczna do logicznej alternatywy. Nie jest częścią OWL Lite.
e)
Przecięcie (iloczyn) klas
owl:intersectionOf – opisuje klasę, której instancje należą do każdej z klas przecięcia, jest
analogiczna do logicznej koniunkcji.
Przykład – opisuje klasę mającą jedną instancję Tosca, będącą jedyną reprezentacją obu
klas przecięcia (zakłada on, że wszystkie trzy występujące instancje klas są różnymi
jednostkami, co niekoniecznie musi być prawdą, bo różne URI mogą odnosić się do tych
samych jednostek, gdyż OWL nie ma identyfikacji po unikatowych nazwach):
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class>
<owl:Thing rdf:about="#Salome" />
</owl:oneOf>
</owl:Class>
<owl:Class>
<owl:Thing rdf:about="#Turandot" />
</owl:oneOf>
</owl:Class>
</owl:intersectionOf>
</owl:Class>
f)
Dopełnienie klasy
owl:complementOf - łączy opisywaną klasę z dokładnie jedną inną klasą, opisuje klasę
składającą się z takich jednostek, które nie należą do klasy będącej obiektem zdania.
Konstrukcja owl:complementOf jest analogiczna do logicznego zaprzeczenia. Nie jest
częścią OWL Lite.
Przykład – opisuje wszystko, co nie jest mięsem:
<owl:Class>
<owl:complementOf>
<owl:Class rdf:about="#Meat"/>
</owl:complementOf>
</owl:Class>
Aksjomaty (definicje) klas.
Przedstawiony powyżej opis klas konstruuje bloki do definiowania klas za pomocą
aksjomatów. Najprostszym aksjomatem jest opis klasy za pomocą jej nazwy. Jest on
poprawny, ale niewiele mówi o samej klasie. Aksjomaty zawierają zazwyczaj dodatkowe
komponenty określające konieczne i/lub wystarczające własności. OWL zawiera trzy
konstrukcje językowe pozwalające na tworzenie aksjomatów klas z wykorzystaniem opisów
klas:
a)
podklasa – pozwala wyrazić, że wnętrze opisywanej klasy jest podzbiorem wnętrza
innej klasy,
b)
klasa równoważna – pozwala wyrazić, że wnętrze opisywanej klasy jest dokładnie
takie samo jak wnętrze innej klasy,
c)
klasa rozłączna – pozwala stwierdzić, że wnętrze opisywanej klasy nie ma elementów
wspólnych z wnętrzem innej klasy.
Trzy powyższe konstrukcje są właściwościami opisującymi zarówno dziedzinę, jak i zasięg
klasy.
a)
Podklasa
schemat aksjomatu: opis klasy rdfs:subclassOf opis klasy
rdfs:subclassOf - podklasa jest również klasą zawartą w innej klasie, wszystkie jednostki
podklasy mają te same właściwości co jednostki klasy nadrzędnej, dana klasa jest własną
podklasą.
Przykład – opisuje klasę Opera jako podklasę klasy MusicalWork (oznacza to, że dana
jednostka aby być operą musi być dziełem muzycznym):
<owl:Class rdf:ID="Opera">
<rdfs:subClassOf rdf:resource="#MusicalWork" />
</owl:Class>
W OWL Lite podmiot zdania z podklasą musi być wskaźnikiem klasy, natomiast obiekt
wskaźnikiem klasy albo ograniczeniem właściwości.
Przykład zawierający ograniczenie właściwości – opisuje klasę Opera jako podklasę
anonimowej klasy jednostek mających co najmniej jedną wartość właściwości hasLibrettist
(tzn. opera powinna mieć co najmniej jednego autora libretta):
<owl:Class rdf:about="#Opera">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasLibrettist" />
<owl:minCardinality
rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Definicje mogą być bardziej skomplikowane gdy ograniczenia są zagnieżdżone.
b)
Klasa równoważna
schemat: opis klasy owl:equivalentClass opis klasy
owl:equivalentClass – jest własnością łączącą opisywaną klasę z inną klasą. Oznacza, że
wnętrza dwóch klas zawierają dokładnie te same jednostki. Może wskazywać
równoważność dwóch nazwanych klas lub klas anonimowych. Konstrukcja nie oznacza
identyczności klas (określania tego samego konceptu).
Przykład – opisuje równoważne nazwane klasy:
<owl:Class rdf:about="#US_President">
<equivalentClass rdf:resource="#PrincipalResidentOfWhiteHouse"/>
</owl:Class>
Przykład – opisuje klasę oper razem reprezentujących „Da Ponte Opera of Mozart”
<owl:Class rdf:ID="DaPonteOperaOfMozart">
<owl:equivalentClass>
<owl:Class>
<Opera rdf:about="#Nozze_di_Figaro"/>
<Opera rdf:about="#Don_Giovanni"/>
<Opera rdf:about="#Cosi_fan_tutte"/>
</owl:oneOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
W ontologii może istnieć wiele aksjomatów określających równoważne klasy i definiujących
tę samą klasę, pod warunkiem, że oba aksjomaty prowadzą do takiego samego rezultatu.
c)
Klasa rozłączna
schemat:
opis klasy owl:disjointWith opis klasy
owl:disjointWith – stwierdza, iż opisywana klasa nie ma elementów wspólnych z drugą
klasą ze zdania owl:disjointWith. Aksjomat deklarujący rozłączność dwóch klas jest
częściową definicją, ponieważ narzuca konieczny, ale nie wystarczający warunek na klasę.
Przykład rozłącznych klas:
<owl:Class rdf:about="#Man">
<owl:disjointWith rdf:resource="#Woman"/>
</owl:Class>
Przykład innego, a popularnego użycia rozłączności klas w hierarchiach podklas
(wykorzystywane często w modelowaniu danych) – definiuje klasę MusicDrama
równoważną sumie klas Opera, Operetta, Musical, a następnie określa te składowe jako
podklasy klasy MusicDrama uwzględniając ich rozłączność.
<owl:Class rdf:about="#MusicDrama">
<owl:equivalentClass>
<owl:Class>
<owl:Class rdf:about="#Opera"/>
<owl:Class rdf:about="#Operetta"/>
<owl:Class rdf:about="#Musical"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
<owl:Class rdf:about="#Opera">
<rdfs:subClassOf rdf:resource="#MusicDrama"/>
</owl:Class>
<owl:Class rdf:about="#Operetta">
<owl:disjointWith rdf:resource="#Opera"/>
</owl:Class>
<owl:Class rdf:about="#Musical">
<owl:disjointWith rdf:resource="#Opera"/>
<owl:disjointWith rdf:resource="#Operetta"/>
</owl:Class>
2) Właściwości
Właściwości określają relacje między elementami ontologii. OWL rozróżnia dwie główne
kategorie właściwości:
a)
właściwości obiektów: owl:ObjectProperty – łączą jednostkę z jednostką, są podklasą
klasy rdf:Property,
b)
właściwości typów danych: owl:DatatypeProperty – łączą jednostkę z wartością
danych, są podklasą klasy rdf:Property.
OWL posiada właściwości adnotacji oraz właściwości ontologii, które wykorzystuje OWL DL
do semantycznego wnioskowania. W OWL Full właściwości obiektów o danych nie są
rozłączne, ponieważ typy danych mogą być traktowane jak jednostki.
Aksjomaty właściwości definiują cechy właściwości. OWL zapewnia następujące konstrukcje
aksjomatów właściwości:
a)
podwłaściwość – rdfs:subPropertyOf,
b)
dziedzina właściwości – rdfs:domain,
c)
zasięg właściwości – rdfs:range,
d)
właściwość równoważna – owl:equivalentProperty,
e)
właściwość odwrotna – owl:inverseOf,
f)
właściwość o nie więcej niż jednej wartości dla każdej jednostki (funkcyjna lub
funkcjonalna) – owl:FunctionalProperty,
g)
właściwość
odwrotna
mająca
co
najwyżej
jedną
wartość
–
owl:InverseFunctionalProperty,
h)
właściwość przechodnia – owl:TransitiveProperty,
i)
właściwość symetryczna – owl:SymmetricProperty.
Szczegółowy opis aksjomatów właściwości oraz ich konstrukcji.
a)
rdfs:subPropertyOf
–
definiuje,
że
właściwość
jest
podwłaściwością
innej
właściwości. Oznacza to, że zbiór par jednostek podwłaściwości jest podzbiorem
właściwości nadrzędnej.
Przykład – opisuje właściwość hasMother jako podwłaściwość hasParent:
<owl:ObjectProperty rdf:ID="hasMother">
<rdfs:subPropertyOf rdf:resource="#hasParent"/>
</owl:ObjectProperty>
b)
rdfs:domain – łączy właściwości z opisem klasy, mówi, że podmiot zdania z tą
relacją musi należeć do klasy wskazywanej przez opis klasy.
Dozwolone są wielokrotne aksjomaty dziedziny i powinny być one interpretowane jak
koniunkcja. Gdy chcemy aby dziedzina była interpretowana jako alternatywa musimy
skorzystać z sumy klas.
Przykład – opisuje dziedzinę właściwości hasBankAccount, do której należą osoby lub
korporacje:
<owl:ObjectProperty rdf:ID="hasBankAccount">
<rdfs:domain>
<owl:Class>
<owl:Class rdf:about="#Person"/>
<owl:Class rdf:about="#Corporation"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
c)
rdfs:range – łączy właściwości z opisem klasy lub pewnym zakresem danych. Mówi,
że wartości tej właściwości muszą należeć do klasy wskazanej przez ten opis lub że
są wartościami wskazanego zakresu danych.
Kilka ograniczeń zasięgu jest traktowane jak przecięcie wszystkich zasięgów i
podobnie jak w przypadku dziedziny ograniczenia alternatywne trzeba wymieniać jako
sumę klas.
Dziedzina i zasięg są restrykcjami globalnymi, to znaczy ograniczają właściwości
same w sobie a nie tylko w przypadku, gdy są one związane z konkretną klasą.
d)
owl:equivalentProperty – pozwala stwierdzić, że dwie właściwości łączą te same
pary elementów. Nie oznacza to jednak identyczności właściwości. Są tylko takie
same wartości, może być inne znaczenie relacji. Identyczność właściwości można
wyrazić jedynie w OWL Full za pomocą owl:sameAs traktując właściwości jako
jednostki.
e)
owl:inverseOf – wyraża, że relacja zachodzi w obu kierunkach.
Przykład – relacja hasParent i hasChild są do siebie odwrotne:
<owl:ObjectProperty rdf:ID="hasChild">
<owl:inverseOf rdf:resource="#hasParent"/>
f)
owl:FunctionalProperty – definiuje właściwość mającą maksymalnie jedną wartość
dla każdej instancji. Dotyczy właściwości obiektów i typów danych.
Przykład – opisuje, że kobieta może mieć co najwyżej jednego męża (przykład na
kulturowe zróżnicowanie ontologii):
<owl:ObjectProperty rdf:ID="husband">
<rdf:type
rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Woman" />
<rdfs:range rdf:resource="#Man" />
Inny zapis syntaktyczny tego samego:
<owl:ObjectProperty rdf:ID="husband">
<rdfs:domain rdf:resource="#Woman" />
<rdfs:range rdf:resource="#Man" />
<owl:FunctionalProperty rdf:about="#husband" />
g)
owl:InverseFunctionalProperty – obiekt zdania z taką właściwością jednoznacznie
definiuje podmiot. Jeśli P jest taką właściwością to y może być wartością tylko dla
jednej instancji x.
Dotyczy tylko właściwości obiektów. W OWL Full również właściwości typów danych
mogą być odwracalne o co najwyżej jedną wartość.
Przykład – właściwość biologicalMother jednoznacznie definiuje podmiot (każdy
człowiek ma dokładnie jedną matkę biologiczną):
<owl:InverseFunctionalProperty
rdf:ID="biologicalMotherOf">
<rdfs:domain rdf:resource="#Woman"/>
<rdfs:range rdf:resource="#Human"/>
</owl:InverseFunctionalProperty>
Dwie powyższe właściwości są restrykcjami globalnymi.
h)
owl:TransitiveProperty – przechodniość właściwości oznacza, że jeśli pary (x,y)
oraz (y,z) są instancjami relacji P to również para (x,z) jest instancją tej relacji.
Przykład – opisuje relację subRegionOf jako przechodnią:
<owl:TransitiveProperty rdf:ID="subRegionOf">
<rdfs:domain rdf:resource="#Region"/>
<rdfs:range rdf:resource="#Region"/>
</owl:TransitiveProperty>
Narzędzie wnioskujące powinno z niego wiedzieć, że jeśli np. Polska, Małopolska i
Jura Krakowsko-Częstochowska są regionami oraz Małopolska jest podregionem
Polski a Jura podregionem Małopolski to znaczy, że Jura jest również podregionem
Polski.
Inny sposób zapisania tego samego:
<owl:ObjectProperty rdf:ID="subRegionOf">
<rdf:type rdf:resource="&owl;TransitiveProperty"/>
<rdfs:domain rdf:resource="#Region"/>
<rdfs:range rdf:resource="#Region"/>
i)
owl:SymmetricProperty – opisuje właściwość, w której jeśli para (x,y) jest instancją
relacji P to para (y,x) jest również instancją tej relacji. Dziedzina i zasięg relacji
symetrycznej są tymi samymi zbiorami.
Przykład - relacja friendOf jest symetryczna, jeśli osoba X jest przyjacielem osoby Y to
osoba Y jest przyjacielem osoby X:
<owl:SymmetricProperty rdf:ID="friendOf">
<rdfs:domain rdf:resource="#Human"/>
<rdfs:range rdf:resource="#Human"/>
</owl:SymmetricProperty>
3) Jednostki
Jednostki
są
instancjami
klas
zdefiniowanymi
za
pomocą
aksjomatów
jednostek
(nazywanych też faktami o jednostkach). Istnieją dwa typy faktów:
a)
fakty o członkostwie w danej klasie i wartościach właściwości jednostek
Wiele faktów jest zdaniami wskazującymi członków klasy oraz wartości właściwości
jednostek.
Przykład – zbiór zdań o instancjach klasy Opera, zawiera informacje o jednostce Tosca
będącej instancją klasy Opera:
<Opera rdf:ID="Tosca">
<hasComposer rdf:resource="#Giacomo_Puccini"/>
<hasLibrettist rdf:resource="#Victorien_Sardou"/>
<hasLibrettist rdf:resource="#Giuseppe_Giacosa"/>
<hasLibrettist rdf:resource="#Luigi_Illica"/>
<premiereDate rdf:datatype="&xsd;date">1900-0114</premiereDate>
<premierePlace rdf:resource="#Roma"/>
<numberOfActs
rdf:datatype="&xsd;positiveInteger">3</numberOfActs>
</Opera>
Pojedyncze fakty niekoniecznie muszą opisywać nazwane jednostki, mogą również
odnosić się do jednostek anonimowych.
Przykład – opisuje anonimową jednostkę z klasy Measurement
<Measurement>
<observedSubject rdf:resource="#JaneDoe"/>
<observedPhenomenon rdf:resource="#Weight"/>
<observedValue>
<Quantity>
<quantityValue
rdf:datatype="&xsd;float">59.5</quantityValue>
<quantityUnit rdf:resource="#Kilogram"/>
</Quantity>
</observedValue>
<timeStamp rdf:datatype="&xsd;dateTime">2003-0124T09:00:08+01:00</timeStamp>
</Measurement>
b)
fakty o tożsamości jednostek
Wiele języków posiada indywidualne nazwy jednostek co oznacza, że różne nazwy
odnoszą się do różnych elementów. W sieci www takie założenie nie jest możliwe. Dlatego
OWL nie wnioskuje z nazw w taki sposób. Dopóki zdanie nie wyjaśnia czy dwa
identyfikatory URI odnoszą się do tej samej czy do równych jednostek, to narzędzia OWL
powinny przyjąć którąś wersję za możliwą.
OWL zapewnia trzy konstrukcje faktów o jednostkach:
a)
owl:sameAs – wskazanie tej samej jednostki przez dwie różne referencje URI,
b)
owl:diffrentFrom – wskazanie, że dwa URI wskazują różne jednostki,
c)
owl:AllDifferent – stwierdzenie, że lista jednostek stanowi różne między sobą
elementy.
Szczegółowy opis powyższych konstrukcji.
a)
owl:sameAs – łączy jednostkę z jednostką, stwierdza, że jednostki o różnych URI
(nazwach) mają tą samą tożsamość.
Przykład – dwie różne referencje URI odnoszące się do tej samej osoby:
<rdf:Description rdf:about="#William_Jefferson_Clinton">
<owl:sameAs rdf:resource="#BillClinton"/>
</rdf:Description>
Konstrukcja używana często w definiowaniu mapowania między ontologiami. W OWL Full
sameAs można użyć do określenia tej samej tożsamości klas (bo można je traktować jako
jednostki).
Przykład takich samych klas o różnych nazwach:
<owl:Class rdf:ID="FootballTeam">
<owl:sameAs
rdf:resource="http://sports.org/US#SoccerTeam"/>
</owl:Class>
b)
owl:diffrentFrom – łączy jednostkę z jednostką, stwierdza, że dwie referencje URI
odnoszą się do różnych jednostek.
Przykład – trzy wzajemnie różne opery:
<Opera rdf:ID="Don_Giovanni"/>
<Opera rdf:ID="Nozze_di_Figaro">
<owl:differentFrom rdf:resource="#Don_Giovanni"/>
</Opera>
<Opera rdf:ID="Cosi_fan_tutte">
<owl:differentFrom rdf:resource="#Don_Giovanni"/>
<owl:differentFrom rdf:resource="#Nozze_di_Figaro"/>
</Opera>
c)
owl:AllDifferent – aby uniknąć wielokrotnego użycia konstrukcji owl:differentFrom i
tworzenia długich i skomplikowanych zdań OWL zapewnia konstrukcję owl:AllDifferent
oraz właściwość owl:distinctMembers, która łączy instancje klasy owl:AllDifferent w
listę wzajemnie różnych jednostek.
Przykład – wskazuje różne opery:
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<Opera rdf:about="#Don_Giovanni"/>
<Opera rdf:about="#Nozze_di_Figaro"/>
<Opera rdf:about="#Cosi_fan_tutte"/>
<Opera rdf:about="#Tosca"/>
<Opera rdf:about="#Turandot"/>
<Opera rdf:about="#Salome"/>
</owl:distinctMembers>
</owl:AllDifferent>
4) Typy danych
OWL pozwala na trzy typy specyfikacji danych:
– typy danych obecne w RDF
– rdfs:Literal – klasa RDF
– wyliczanie typów danych za pomocą konstrukcji owl:oneOf
a)
Typy danych RDF
OWL używa schematu danych RDF, który zapewnia mechanizm odnoszenia się do danych
XML-Schema. Wartości są instancjami klasy rdfs:Literal, mogą być proste lub posiadać
typy. Typy danych są instancjami klasy rdfs:Datatype i są specyfikowane za pomocą
atrybutu rdf:datatype, którego wartość powinna być jedną z następujących:
–
kanoniczna referencja do typów danych XML Schema w postaci
http://www.w3.org/2001/XMLSchema#NAME
–
referencja URI do typu danych rdf:XMLLiteral; jest używana do przedstawiania
zawartości XML w dokumencie RDF/OWL
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
Przykładowe wykorzystywane przez OWL typy danych:
xsd:string, xsd:language, xsd:Name, xsd:int, xsd:positiveInteger, xsd:gYear, xsd:anyURI...
Istnieje możliwość tworzenia własnych typów danych, chociaż nie jest ono zalecane,
ponieważ nowe typy danych mogą nie być rozpoznawane przez niektóre narzędzia.
Używając typów danych należy zwrócić uwagę, że pomimo iż właściwość ma zdefiniowany
zakres pewnego typu danych XML/RDF to wymaga specyfikacji typu za każdym razem gdy
właściwość jest używana.
Przykład:
<owl:DatatypeProperty rdf:about="#timeStamp">
<rdfs:domain rdf:resource="#Measurement"/>
<rdf:range rdf:resource="&xsd;dateTime"/>
</owl:DatatypeProperty>
<Measurement>
<timeStamp rdf:datatype="&xsd;dateTime">2003-0124T09:00:08+01:00</timeStamp>
</Measurement>
b)
Wyliczanie typów danych
OWL zapewnia jedną konstrukcję numerowania typów do definiowania zakresu wartości
danych. Używa on konstrukcji owl:oneOf. W tym wypadku podmiotem zdania jest pusty
węzeł klasy owl:DataRange a obiektem lista wartości. Elementy tej listy wymieniane są za
pomocą konstrukcji rdf:first, rdf:rest, rdf:nill. Numerowanie typów danych nie jest możliwe
do wykonania w OWL Lite.
Przykład – specyfikacja zakresu właściwości tennisGameScore jako lista wartości
będących liczbami naturalnymi:
<owl:DatatypeProperty rdf:ID="tennisGameScore">
<rdfs:range>
<owl:DataRange>
<owl:oneOf>
<rdf:List>
<rdf:first rdf:datatype="&xsd;integer">0</rdf:first>
<rdf:rest>
<rdf:List>
<rdf:first
rdf:datatype="&xsd;integer">15</rdf:first>
<rdf:rest>
<rdf:List>
<rdf:first
<rdf:rest>
<rdf:List>
<rdf:first
<rdf:rest rdf:resource="&rdf;nil" />
</rdf:List>
</rdf:rest>
</rdf:List>
</rdf:rest>
</rdf:List>
</rdf:rest>
</rdf:List>
</owl:oneOf>
</owl:DataRange>
</rdfs:range>
c)
Wspieranie wnioskowania z typów danych
Narzędzia mogą różnić się we wspieraniu wnioskowania. Jako minimum narzędzia muszą
wspierać wnioskowanie dla typów XML-Schema xsd:string i xsd:integer. Narzędzia OWL
Full muszą także wspierać xdf:XMLLiteral.
5) Adnotacje, nagłówki ontologii, importowanie i wersje informacji
a)
Adnotacje
OWL Full nie nakłada żadnych ograniczeń na adnotacje w ontologii. OWL DL pozwala
konstruować adnotacje o klasach, właściwościach, jednostkach i nagłówkach ale tylko pod
pewnymi warunkami:
–
zbiory właściwości obiektów, typów danych, adnotacji i ontologii muszą być
wzajemnie rozłączne
–
właściwości adnotacji muszą mieć następującą jawną formę
AnnotationPropertyID rdf:type owl:AnnotationProperty
–
właściwości adnotacji nie mogą być używane jako aksjomaty właściwości, tzn. nie da
się tworzyć ich podwłaściwości lub dziedziny czy zakresu
–
obiekt właściwości adnotacji musi być albo wartością danych albo referencją URI
albo jednostką
Istnieje pięć zdefiniowanych w OWL właściwości adnotacji:
–
owl:versionInfo
–
rdfs:label
–
rdfs:comment
–
rdfs:seeAlso
–
rdfs:isDefinedBy
Przykład użycia właściwości adnotacji w OWL DL:
<owl:AnnotationProperty rdf:about="&dc;creator"/>
<owl:Class rdf:about="#MusicalWork">
<rdfs:label>Musical work</rdfs:label>
<dc:creator>N.N.</dc:creator>
</owl:Class>
b)
Nagłówki ontologii
Dokument opisujący ontologię zazwyczaj zawiera informacje opisujące ją samą. Ontologia
jest pewnym zasobem więc może być opisana przy użyciu właściwości OWL oraz innych
przestrzeni nazw.
Przykład – pokazuje typowy nagłówek ontologii, który znajduje się zaraz na początku
dokumentu:
<owl:Ontology rdf:about="">
<owl:versionInfo> ... </owl:versionInfo>
<rdfs:comment>...</rdfs:comment>
<owl:imports rdf:resource="..."/>
</owl:Ontology>
Linijka pierwsza <owl:Ontology rdf:about=""> wskazuje, że dany blok opisuje aktualną
ontologię. Dokładniej mówiąc wskazuje bazowy URI definiujący instancje klasy
owl:Ontology. Oznacza to ponadto, że URI będzie definiowany za pomocą atrybutu
xml:base w elemencie <rdf:RDF> na początku dokumentu.
Przykład – inny nagłówek ontologii:
<owl:versionInfo>v 1.17 2003/02/26 12:56:51
mdean</owl:versionInfo>
<rdfs:comment>An example ontology</rdfs:comment>
<owl:imports rdf:resource="http://www.example.org/foo"/>
</owl:Ontology>
c)
Importowanie ontologii
Zdanie owl:imports odwołuje się do innej ontologii zawierającej definicje, których
znaczenie ma być częścią importującej ontologii. Każde odwołanie składa się z URI
określającego miejsce importowanej ontologii. Syntaktycznie owl:imports jest właściwością
z klasą owl:Ontology jako jej dziedzina i zasięg. Zdania owl:imports są przechodnie, tzn.
jeśli ontologia A importuje ontologię B, która importuje ontologię C, to wtedy ontologia A
importuje również ontologię C. Jeżeli ontologia A importuje ontologię B i B importuje A to
są one uważane za równoważne. Kwestia uwzględnienia przez narzędzia OWL
importowanych ontologii zależy od intencji narzędzi. Jeżeli narzędzie zawiera kompletne
elementy wnioskujące (kompletne sprawdzanie zawartości), to wówczas musi uwzględniać
i załadować wszystkie importowane ontologie. Inne narzędzia, proste edytory i narzędzia
niekompletnie wnioskujące, mogą sprawdzać do załadowania tylko niektóre albo żadne z
importowanych ontologii.
owl:imports jest instancją klasy owl:OntologyProperty.
d)
Różne wersje informacji
owl:versionInfo – jest instancją klasy owl:AnnotationProperty. Obiektem takiego zdania
jest string dający informację o wersji. Zdanie nie przyczynia się do logicznego znaczenia
ontologii. Pomimo, że dana właściwość jest zazwyczaj używana do tworzenia zdań o
ontologii, może być ona wykorzystana w dowolnej konstrukcji OWL (np. można zastosować
tę konstrukcję do określenia wersji klasy).
owl:priorVersion – jest instancją klasy owl:OntologyProperty. Zdanie zawiera odwołanie
do innej ontologii. Identyfikuje konkretną ontologię jako wcześniejszą wersję bieżącej
ontologii. Może być wykorzystywane przez oprogramowanie do organizacji ontologii z
punktu widzenia wersji.
owl:backwardCompatibleWith - jest instancją klasy owl:OntologyProperty. Zdanie odnosi
się do innej ontologii. Identyfikuje konkretną ontologię jako wcześniejszą wersję bieżącej
ontologii a następnie wskazuje, że ta jest z wcześniejszą kompatybilna wstecz. Oznacza
to, że wszystkie identyfikatory wcześniejszej wersji mają taką samą interpretację w bieżącej
wersji. Jest to wskazówką dla autorów, że mogą bezpiecznie zmieniać dokumenty w celu
otrzymania nowej wersji (przez proste uaktualnianie deklaracji przestrzeni nazw i zdań
owl:imports do odwołania się do URL nowej wersji). Jeżeli dana konstrukcja nie zostanie
zdefiniowana dla dwóch wersji ontologii wtedy kompatybilność nie jest uwzględniana.
owl:incompatibleWith – jest instancją klasy owl:OntologyProperty. Zdanie odnosi się do
innej ontologii, wskazuje, że bieżąca ontologia jest późniejszą wersją ontologii, do której
jest odwołanie ale nie jest z nią kompatybilna wstecz. Jest to wykorzystywane przez
autorów ontologii, którzy chcą wyraźnie zaznaczyć, że dokument nie może poprawiać
użycia nowej wersji ontologii bez sprawdzania czy zmiany są konieczne.
owl:DeprecatedClass, owl:DeprecatedProperty – aspekt dezaprobaty jest powszechnie
używany w tworzeniu wersji oprogramowania (np. język programowania Java) do
wskazania, że konkretna cecha jest zachowywana dla celów kompatybilności wstecz, ale
może być zaprzestana w przyszłości. Tutaj konstrukcja musi być typu owl:DeprecatedClass
lub owl:DeprecatedProperty, gdzie pierwszy jest podklasą rdfs:Class a drugi rdf:Property.
Deprecjonując dany termin, stwierdza się, że nie powinien on być używany w nowym
dokumencie, który posiada ontologię. To pozwala ontologii na zachowanie kompatybilności
wstecz gdy stare słownictwo przestaje być używane (zatem używanie deprecjacji ma sens
tylko w połączeniu z kompatybilnością wstecz). W rezultacie stare dane i aplikacje mogą
łatwiej „przedostać się” do nowej wersji, co zwiększa poziom adaptacji nowej wersji.
Przykład – użycie deprecjacji:
<rdfs:comment>Vehicle Ontology, v. 1.1</rdfs:comment>
<owl:backwardCompatibleWith
rdf:resource="http://www.example.org/vehicle-1.0"/>
<owl:priorVersion
rdf:resource="http://www.example.org/vehicle-1.0"/>
</owl:Ontology>
<owl:DeprecatedClass rdf:ID="Car">
<rdfs:comment>Automobile is now preferred</rdfs:comment>
<owl:equivalentClass rdf:resource="#Automobile"/>

</owl:DeprecatedClass>
<owl:Class rdf:ID="Automobile" />
<owl:DeprecatedProperty rdf:ID="hasDriver">
<rdfs:comment>inverse property drives is now
preferred</rdfs:comment>
<owl:inverseOf rdf:resource="#drives" />
</owl:DeprecatedProperty>
<owl:ObjectProperty rdf:ID="drives" />
2.8. Poszczególne języki OWL
Wszystkie trzy składowe języka OWL różnią się od siebie zaawansowaniem składni i służą
do innych celów. Poniżej zostaną przedstawione różnice między tymi częściami.
1) OWL FullOWL Full formalnie nie jest podjęzykiem, zawiera wszystkie konstrukcje OWL i
pozwala na swobodne, nieograniczone użycie konstrukcji RDF. owl:Class jest równoważna
rdfs:Class. Klasy mogą być traktowane jak jednostki (jeden identyfikator może funkcjonować
jednocześnie jako nazwa klasy oraz jednostki). Wartości danych są rozważane również jako
części pojedynczej dziedziny. Przestrzeń jednostek składa się ze wszystkich zasobów
(owl:Thing jest równoważna rdfs:Resource), oznacza to, że właściwości obiektów i typów
danych nie są rozłączne. owl:ObjectProperty jest równoważna rdf:Property, w konsekwencji
właściwości typów danych są podklasą właściwości obiektów.
OWL Full jest użyteczny dla autorów potrzebujących wyrazistości OWL, elastyczności i
narzędzi metamodelowania RDF. Jednak użycie właściwości OWL Full oznacza stratę
niektórych gwarancji OWL DL i OWL Lite dla systemu wnioskowania. Dokument RDF będzie
zazwyczaj w OWL Full dopóki nie zostanie zdefiniowane, że jest to OWL DL lub OWL Lite.
2) OWL DLOWL DL jest podjęzykiem OWL nakładającym pewne ograniczenia na jego
konstrukcje:
– wszystkie elementy (klasy, jednostki, typy danych, wartości danych, właściwości
obiektów, właściwości typów danych, właściwości adnotacji, właściwości ontologii oraz
wbudowane słownictwo) są parami rozłączne,zbiory właściwości obiektów i typów
danych są rozłączne; oznacza to, że następujące cechy właściwości nie mogą być
specyfikowane dla właściwości typów danych: inverse of, inverse functional, symmetric,
transitive,żadne ograniczenia liczebności (lokalne i globalne) nie mogą być stosowane
do przechodnich właściwości, ich odwrotności ani podwłaściwości,
– adnotacje są możliwe tylko pod pewnymi warunkami,
– większość słownictwa RDF(S) nie może być używane w OWL DL,
– wszystkie
aksjomaty
muszą
być
poprawnie
sformułowane
bez
brakujących
komponentów,
– fakty o identyczności oraz różności jednostek muszą odnosić się do nazwanych
jednostek.
Ograniczenia OWL DL bazują na pracy w zakresie narzędzi wnioskujących dla Description
Logic, które wymagają takich restrykcji w celu zapewnienia tworzącemu ontologię lub
użytkownikowi wsparcia wnioskowania. Ograniczenia OWL DL udostępniają maksymalny
podzbiór OWL Full, dla którego istnieje pewność, że decydujące procedury wnioskowania
będą zrozumiałe przez narzędzia wnioskujące OWL.
3) OWL Lite
OWL Lite przestrzegając wszystkich ograniczeń OWL DL nakłada nowe na użycie
konstrukcji językowych.
Zabrania używania:
– owl:oneOf
– owl:unionOf
– owl:complementOf
– owl:hasValue
– owl:disjointWith
– owl:dataRange
Ponadto wymaga, że:
– podmiot owl:equivalentClass musi być nazwą klasy a obiekt owl:equivalentClass musi
być nazwą klasy lub restrykcją
Przykład – prawidłowe użycie owl:intersectionOf w OWL Lite:
<owl:Class rdf:ID="Woman">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Female"/>
<owl:Class rdf:about="#Human"/>
</owl:intersectionOf>
</owl:Class/>
– obiekt owl:allValuesFrom i owl:someValuesFrom musi być nazwą klasy lub typu danych
– obiekt rdf:type musi być nazwą klasy lub ograniczeniem
– obiekt rdfs:domain mus być nazwą klasy
– obiekt rdfs:range musi być nazwą klasy lub ograniczeniem
Idea ograniczeń wyrazistości OWL Lite zapewnia minimalną użyteczność zbiorów i własności
języka, które są bezpośrednie dla rozwoju narzędzi niezbędnych do wsparcia. Konstrukcje
języka zapewniają podstawy hierarchii. OWL Lite pozwala na czynienie właściwości
opcjonalnymi lub wymaganymi. Dzięki najmniejszej złożoności posiada on kompletne
narzędzia wnioskujące.
Implementacje wspierające tylko słownictwo OWL Lite nie mogą uwzględniać niektórych
wymagań obliczeniowych. Jednak takie implementacje mogą być przydatne w zapewnieniu
interoperacyjności systemów OWL z modelami RDFS, bazami danych, narzędziami
wskaźników i innymi nie wnioskującymi narzędziami.
2.9. Semantyka13
OWL zawiera abstrakcyjną składnię wysokiego poziomu zarówno dla OWL DL jak i OWL
Lite. Dana jest teoretyczna semantyka do zapewnienia formalnego znaczenia ontologii OWL
zapisanych za pomocą abstrakcyjnej składni. Semantyka OWL ma formę rozszerzenia
semantyki RDF i zapewnia formalne znaczenia ontologii OWL danych w postaci grafów RDF
(OWL Full). Dane jest również mapowanie z abstrakcyjnej składni do grafów RDF.
Poniżej opisane są dwie formalne semantyki OWL. Jedna z nich jest bezpośrednim,
standardowym modelem teoretycznej semantyki dla ontologii OWL zapisanych w
abstrakcyjnej składni. Druga jest rozszerzeniem słownictwa semantyki RDF, zapewniającą
semantykę dla ontologii OWL w formie grafów RDF.
1) Abstrakcyjna składnia
Abstrakcyjna składnia OWL ma ramowy styl, gdzie zbiór informacji o klasie lub właściwości
zadany jest w postaci jednej dużej syntaktycznej konstrukcji, niepodzielonej na kilka
abstrakcyjnych elementów (jak w logice deskrypcyjnej) oraz niepodzielonej na więcej trójek
(jak przy zapisywaniu języka OWL w postaci grafów RDF).
Nazwy w składni OWL są referencjami URI, często ich nazwy są skracane do nazw
kwalifikowanych z wykorzystaniem nazwy jednej z poniższych przestrzeni nazw:
Nazwa przestrzeni nazw
Przestrzeń nazw
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
xsd
http://www.w3.org/2001/XMLSchema#
owl
http://www.w3.org/2002/07/owl#
Tabela 13 Przestrzenie nazw
Abstrakcyjna składnia nie pozwala na tworzenie samo-wnioskujących się konstrukcji, jest
przeznaczona do użycia w przypadkach gdy klasy, właściwości i jednostki są rozłącznymi
zbiorami.
Są
to
ograniczenia
rozstrzygalnym.
a) Ontologie
13
Por. http://www.w3.org/TR/owl-semantics/
wymagane
do
uczynienia
wnioskowania
w
OWL
Ontologia OWL w abstrakcyjnej składni zawiera sekwencję adnotacji, aksjomatów i
faktów. Ontologie OWL mogą mieć swoje nazwy. Adnotacje na ontologii OWL mogą być
używane do notowania autorstwa oraz innych informacji związanych z ontologią oraz
zawierają referencje importu do innych ontologii. Główna zawartość ontologii jest
umieszczona
w
aksjomatach
i
faktach
zapewniających
informacje
o
klasach,
właściwościach i jednostkach.
ontology ::= 'Ontology(' [ ontologyID ] { directive } ')'
directive ::= 'Annotation(' ontologyPropertyID ontologyID ')'
| 'Annotation(' annotationPropertyID URIreference ')'
| 'Annotation(' annotationPropertyID dataLiteral ')'
| 'Annotation(' annotationPropertyID individual ')'
| axiom
| fact
Nazwa ontologii w abstrakcyjnej składni jest referencją URI określającą miejsce publikacji
ontologii w sieci www, nie jest częścią formalnego znaczenia ontologii. Adnotacje importu
są wskazówkami do wydobycia odpowiednich dokumentów z sieci i traktowania ich jako
ontologii. Większość aspektów i zasobów sieci, wszystko co ma referencję URI, może być
dołączone do ontologii.
Ontologie łączą informacje o klasach, właściwościach i jednostkach, z których każda
może mieć identyfikator URI. Niektóre z tych identyfikatorów muszą być dane w postaci
aksjomatów.
datatypeID ::= URIreference
classID ::= URIreference
individualID ::= URIreference
ontologyID ::= URIreference
datavaluedPropertyID ::= URIreference
individualvaluedPropertyID ::= URIreference
annotationPropertyID ::= URIreference
ontologyPropertyID ::= URIreference
W OWL typy danych wskazują zbiór wartości danych, który jest przestrzenią wartości dla
danego typu. Klasy wskazują zbiory jednostek, właściwości łączą jednostki z innymi
informacjami i dzielą się na cztery rozłączne grupy: właściwości danych (łączą jednostki z
wartościami danych), właściwości jednostek (łączą jednostki z innymi jednostkami),
właściwości adnotacji (umieszczają adnotacje o jednostkach, nazwach klas, właściwości i
ontologii) oraz właściwości ontologii (łączą ontologię z innymi ontologiami, w
szczególności są używane do importowania informacji z innych ontologii). Identyfikatory
jednostek są używane do odnoszenia się do zasobów a dane liczbowo-literowe do
odwoływania się do wartości danych.
b) Fakty
Występują dwa rodzaje faktów w abstrakcyjnej składni OWL. Pierwszy rodzaj faktu
określa informację o konkretnej jednostce w formie klas, do których ta jednostka należy,
wraz z właściwościami i wartościami tej jednostki. Niektóre jednostki posiadają swój
identyfikator (individualID) a inne, anonimowe jednostki, nie posiadają identyfikatora, co
oznacza brak bezpośredniego odniesienia do nich.
fact ::= individual
individual ::= 'Individual(' [ individualID ] { annotation } { 'type(' type ')' } { value } ')'
value ::= 'value(' individualvaluedPropertyID individualID ')'
| 'value(' individualvaluedPropertyID individual ')'
| 'value(' datavaluedPropertyID dataLiteral ')'
Fakty w OWL DL I OWL Lite mają taką samą składnię, z wyjątkiem typu. W OWL Lite typy
mogą być identyfikatorami klas lub pewnym ograniczeniem.
type ::= classID
| restriction
W OWL DL typy mogą być ogólnymi opisami, które zawierają identyfikatory klas i
ograniczenia OWL Lite oraz inne konstrukcje.
type ::= description
Dane liczbowo-literowe są albo proste (składają się ze stringa Unicode i opcjonalnie
etykiety językowej) albo typowane (składają się z leksykalnej reprezentacji referencji URI).
dataLiteral ::= typedLiteral | plainLiteral
typedLiteral ::= lexicalForm^^URIreference
plainLiteral ::= lexicalForm | lexicalForm@languageTag
lexicalForm ::= as in RDF, a unicode string in normal form C
languageTag ::= as in RDF, an XML language tag
Drugi rodzaj faktów może być używany do ujednolicania lub rozróżniania identyfikatorów
jednostek.
fact ::= 'SameIndividual(' individualID individualID {individualID} ')'
| 'DifferentIndividuals(' individualID individualID {individualID} ')'
c) Aksjomaty
Największą różnicę między składnią OWL DL a OWL Lite przedstawiają aksjomaty
zapewniające informacje o klasach i właściwościach. Aksjomaty są używane do
kojarzenia identyfikatorów klas i właściwości z częściowymi lub pełnymi specyfikacjami ich
własności. Aksjomaty często nazywa się definicjami, chociaż nie są nimi w normalnym
tego słowa znaczeniu.
Każdy aksjomat klasy w OWL Lite zawiera zbiór ogólnych klas i zbiór ograniczeń
właściwości lokalnych. Konstrukcja ograniczeń określa lokalny zasięg właściwości, liczbę
dopuszczalnych wartości i/lub zbiór wymaganych wartości. Klasa jest zadana jako
równoważność podzbioru przecięcia tych ogólnych klas i ograniczeń. W OWL DL
aksjomaty
klas
zawierają
zbiory
opisów,
które
mogą
być
ogólnymi
klasami,
ograniczeniami zbiorów jednostek oraz kombinacjami opisów. Klasy mogą być również
określane za pomocą wymieniania elementów, a także poprzez równoważność albo
rozłączność z innymi klasami.
Właściwości mogą być równoważne do innych lub mogą być podwłaściwościami, mogą
być funkcjonalne, odwrotne, symetryczne lub przechodnie, mogą mieć określoną globalną
dziedzinę i zasięg. Jednak większość informacji o właściwościach jest w naturalny sposób
wyrażona w ograniczeniach, które pozwalają na określanie lokalnego zasięgu i ilości
wartości.
Aksjomaty OWL Lite
W OWL Lite aksjomaty klas są używane do stwierdzenia, że klasa jest równoważna do
innej lub jest podklasą innej klasy lub przecięciem zbiorów super-klas.
axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { super } ')'
modality ::= 'complete' | 'partial'
super ::= classID | restriction
axiom ::= 'EquivalentClasses(' classID classID { classID } ')'
axiom ::= 'Datatype(' datatypeID ['Deprecated'] { annotation } )'
Ograniczenia aksjomatów klas w OWL Lite są używane do zapewnienia lokalnych
ograniczeń właściwości w klasie.
restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent ')'
| 'restriction(' individualvaluedPropertyID individualRestrictionComponent ')'
dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')'
| 'someValuesFrom(' dataRange ')'
| cardinality
individualRestrictionComponent ::= 'allValuesFrom(' classID ')'
| 'someValuesFrom(' classID ')'
| cardinality
cardinality ::= 'minCardinality(0)' | 'minCardinality(1)'
| 'maxCardinality(0)' | 'maxCardinality(1)'
| 'cardinality(0)'
| 'cardinality(1)'
Dwa rodzaje właściwości (właściwości danych i jednostek) mogą mieć zadane superwłaściwości pozwalające na hierarchizację właściwości. Właściwości mogą mieć zadaną
dziedzinę i zasięg. Dziedzina właściwości określa potencjalne podmioty zdania mającego
daną właściwość za predykat. Dziedziny właściwości są klasami. Mogą być różne
dziedziny, w których przypadku jednostki należące do wszystkich dziedzin są
potencjalnymi podmiotami. Zakres właściwości określa, które jednostki lub wartości
danych mogą być obiektami zdań mających daną właściwość za predykat. Mogą też być
różnorodne zasięgi, w których przypadku jednostki lub wartości danych należące do
wszystkich zasięgów są potencjalnymi obiektami. Zasięgi właściwości jednostek są
klasami, a właściwości danych typami danych.
Właściwości danych mogą być funkcjonalne (tzn. dla danej jednostki może być co
najwyżej jedna relacja do wartości danych dla tej jednostki we właściwości). Właściwości
jednostek mogą być odwrotnością innych właściwości, mogą być symetryczne oraz
częściowo funkcjonalne, częściowo odwrotnie funkcjonalne lub przechodnie.
Aby zachować rozstrzygalność wnioskowania OWL Lite, nie wszystkie właściwości mogą
mieć ograniczenie ilości wartości lub być funkcjonalne lub odwrotnie funkcjonalne.
Właściwość jednostki jest złożona gdy (1) jest określona jako funkcjonalna lub odwrotnie
funkcjonalna, (2) są pewne ograniczenia ilości wartości używające jej, (3) ma właściwość
odwrotną, która jest złożona lub (4) ma zoczoną super-właściwość. Złożone właściwości
nie mogą być przechodnie.
Właściwości adnotacji i ontologii są znacznie prostsze niż właściwości danych i jednostek.
Jedyną informacją w aksjomatach dla nich jest adnotacja.
axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' datavaluedPropertyID ')' } ['Functional']
{ 'domain(' classID' ')' } { 'range(' dataRange ')' } ')'
| 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' individualvaluedPropertyID ')' }
[ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ]
[ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ]
{ 'domain(' classID ')' } { 'range(' classID ')' } ')'
| 'AnnotationProperty(' annotationPropertyID { annotation } ')'
| 'OntologyProperty(' ontologyPropertyID { annotation } ')'
dataRange ::= datatypeID | 'rdfs:Literal'
Poniższe aksjomaty określają różne właściwości jako równoważne lub określają jedną
właściwość jako podwłaściwość innej.
axiom
::=
'EquivalentProperties('
datavaluedPropertyID
{
datavaluedPropertyID } ')'
| 'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')'
| 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID
{
individualvaluedPropertyID } ')'
| 'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'
Aksjomaty OWL DL
Składnia OWL DL jest bardziej ogólną wersją składni OWL Lite. Konstrukcje aksjomatów
klas nazywane są opisami.
axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { description } ')'
modality ::= 'complete' | 'partial'
W OWL DL klasa może być zdefiniowana poprzez dokładne wymienienie jej elementów.
axiom ::= 'EnumeratedClass(' classID ['Deprecated'] { annotation } { individualID } ')'
Jest możliwe wymaganie, aby zbiór opisów był parami rozłączny, miał takie same
instancje lub aby opis był podklasą innego.
axiom ::= 'DisjointClasses(' description description { description } ')'
| 'EquivalentClasses(' description { description } ')'
| 'SubClassOf(' description description ')'
W OWL DL możliwe jest posiadanie tylko jednego opisu w konstrukcji równoważnych
klas. To pozwala ontologiom na zawieranie opisów niezwiązanych z niczym,
semantycznie bezużytecznych.
Aksjomaty typów danych są takie same jak w OWL Lite.
axiom ::= 'Datatype(' datatypeID ['Deprecated'] { annotation } )'
Opisy zawierają identyfikatory klas i ograniczenia, mogą być również kombinacją innych
opisów lub zbiorów jednostek.
description ::= classID
| restriction
| 'unionOf(' { description } ')'
| 'intersectionOf(' { description } ')'
| 'complementOf(' description ')'
| 'oneOf(' { individualID } ')'
Ograniczenia OWL DL uogólniają ograniczenia OWL Lite, pozwalając na opisy w miejsce
klas OWL Lite oraz na zbiory wartości danych oraz typów danych. Kombinacja typów
danych i zbiorów wartości danych jest nazywana zasięgiem danych. Wartości mogą być
zadane również dla właściwości w klasach.
restriction
::=
'restriction('
dataRestrictionComponent
{
individualRestrictionComponent
{
dataRestrictionComponent } ')'
|
'restriction('
individualvaluedPropertyID
individualRestrictionComponent } ')'
dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')'
| 'someValuesFrom(' dataRange ')'
| 'value(' dataLiteral ')'
| cardinality
individualRestrictionComponent ::= 'allValuesFrom(' description ')'
| 'someValuesFrom(' description ')'
| 'value(' individualID ')'
| cardinality
cardinality ::= 'minCardinality(' non-negative-integer ')'
| 'maxCardinality(' non-negative-integer ')'
| 'cardinality(' non-negative-integer ')'
Zasięg danych używany jako zasięg właściwości danych jest raczej typem danych lub
zbiorem wartości danych.
dataRange ::= datatypeID | 'rdfs:Literal'
| 'oneOf(' { dataLiteral } ')'
Aksjomaty właściwości OWL DL podobnie jak poprzednie są uogólnieniem odpowiednich
aksjomatów OWL Lite przez pozwolenie na opisy w miejscu klas oraz na zasięg w miejsce
typów danych w dziedzinie lub zasięgu.
axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' datavaluedPropertyID ')'} ['Functional']
{ 'domain(' description ')' } { 'range(' dataRange ')' } ')'
| 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' individualvaluedPropertyID ')' }
[ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ]
[ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ]
{ 'domain(' description ')' } { 'range(' description ')' } ')'
| 'AnnotationProperty(' annotationPropertyID { annotation } ')'
| 'OntologyProperty(' ontologyPropertyID { annotation } ')'
Ograniczenia, na których właściwości mogą być określane jako funkcjonalne lub
odwrotnie funkcjonalne są obecne również w OWL DL.
2) Teoretyczna semantyka – bezpośredni model
Ten teoretyczny model semantyki dla OWL wywodzi się bezpośrednio z abstrakcyjnej
składni OWL DL.
a) Słownictwo i interpretacja
Rozważając ontologie OWL słownictwo musi zawierać wszystkie referencje URI, wartości
liczbowo-literowe w tej ontologii oraz ontologie importowane, ale może również zawierać
inne referencje URI oraz wartości.
Niech VOP będzie zbiorem referencji URI dla wbudowanych właściwości ontologii OWL.
Definicja
Słownictwo OWL V składa się ze zbioru danych liczbowo-literowych V L oraz siedmiu
zbiorów referencji URI VC , VD , VI , VDP , VIP , V AP , VO . W dowolnym słownictwie VC i V D
są rozłączne oraz VDP , V IP , V AP , VOP są parami rozłączne. VC - zbiór nazw klas
słownictwa zawierający owl:Thing i owl:Nothing. V D
- zbiór nazw typów danych
zawierający referencje URI dla wbudowanych typów danych OWL oraz rdfs:Literal. V AP zbiór nazw właściwości adnotacji zawierający owl:versionInfo, rdfs:label, rdfs:comment,
rdfs:seeAlso, i rdfs:isDefinedBy. V IP - zbiór nazw właściwości jednostek, V DP - zbiór nazw
właściwości danych, V I - zbiór nazw jednostek, VO - zbiór nazw ontologii, nie ma
żadnych wymaganych członków.
Definicja
Podobnie jak w RDF typ danych d jest scharakteryzowany przez leksykalną przestrzeń
L(d), która jest zbiorem stringów Unicode, przestrzeń wartości V(d) oraz całkowite
mapowanie L2V(d) z przestrzeni leksykalnej do przestrzeni wartości.
Definicja
A datatype map D jest częściowym mapowaniem referencji URI do typów danych, które
mapuje xsd:string i xsd:integer do odpowiednich typów danych XML Schema.
Mapa typów danych może zawierać typy danych dla innych wbudowanych typów danych
OWL. Może również zawierać inne typy danych. Składnia OWL nie zapewnia konwersji
typów danych.
Definicja
Niech D będzie mapą typów danych a P operatorem na zbiorach. Abstrakcyjna
interpretacja OWL pod względem D ze słownictwem VL , VC , V D , VI , VDP , V IP , V AP , VO jest
krotką postaci I = <R, EC, ER, L, S, LV>, gdzie:
• R jest niepustym zbiorem zasobów I,
• LV – liczbowo-literowe wartości I, podzbiór R zawierający zbiór par stringów
Unicode, etykiety językowe i przestrzeń wartości dla każdego typu danych w D,
•
EC : VC → P(O) ,
•
EC : VD → P( LV ) ,
•
ER : VDP → P(O × LV ) ,
•
ER : VIP → P (O × O) ,
•
ER : V AP ∪ {rdf : type} → R × R ,
•
ER : VOP → P ( R × R) ,
•
L : TL → LV , gdzie TL jest zbiorem typowanych danych liczbowo-literowych w V L ,
•
S : VI ∪VC ∪VD ∪VDP ∪ VIP ∪V AP ∪VO ∪ {owl:Ontology,
owl:DeprecatedClass,
owl:DeprecatedProperty} → R ,
•
S (VI ) ⊆ O ,
•
EC (owl : Thing ) = O ⊆ R , gdzie O jest niepusty i rozłączny z LV,
• EC(owl:Nothing) = { },
• EC(rdfs:Literal) = LV,
• Jeśli D(d') = d, to EC(d') = V(d),
• Jeśli D(d') = d, to L("v"^^d') ∈ V(d),
• Jeśli D(d') = d i v ∈ L(d), to L("v"^^d') = L2V(d)(v),
• Jeśli D(d') = d i v ∉ L(d), to L("v"^^d') ∈ R – LV.
EC zapewnia znaczenie dla referencji URI, które są używane jako klasy i typy danych
OWL, ER zapewnia znaczenie dla referencji URI używanych jako właściwości OWL. L
zapewnia znaczenie dla typowanych danych liczbowo-literowych. S zapewnia znaczenie
dla referencji URI używanych do wskazywania jednostek OWL i pomaga zapewnić
znaczenie dla adnotacji. Nie ma interpretacji mogących spełnić wszystkie wymagania
umieszczone na źle sformułowanych danych liczbowo-literowych, na przykład takich,
których leksykalna forma jest źle określona dla typu danych, jak na przykład
1.5^^xsd:integer.
S jest rozszerzone do prostych danych liczbowo-literowych w V L przez mapowanie ich do
samych siebie, np. S("l") = l dla l będącego prostą wartością liczbowo-literową bez
etykiety językowej, S("l"@t) = <l,t> dla l będącego prostą wartością liczbowo-literową z
etykietą językową. S jest rozszerzane do typowanych wartości przy użyciu L, S(l)=L(l) dla l
będącego typowaną wartością liczbowo-literową.
b) Interpretacja zakorzenionych konstrukcji
EC jest rozszerzane do syntaktycznej konstrukcji opisów, zasięgów danych, jednostek,
wartości i adnotacji, zgodnie z poniższa tabelą:
Abstrakcyjna składnia
Interpretacja (wartość EC)
complementOf(c)
O - EC(c) (dopełnienie c)
unionOf(c1 … cn)
EC(c1) ∪ … ∪ EC(cn) (suma elementów)
intersectionOf(c1 … cn)
EC(c1) ∩... ∩ EC(cn) (iloczyn elementów)
oneOf(i1
…
in),
dla
ij
identyfikatorów jednostek
oneOf(v1 … vn), dla vj danych
liczbowo-literowych
{S(i1), …, S(in)} (zbiór identyfikatorów jednostek)
{S(v1), …, S(vn)} (zbiór danych liczbowo-literowych)
EC(restriction(p x1)) ∩... ∩ EC(restriction(p xn)) (iloczyn
restriction(p x1 … xn), dla n > 1
pewnych ograniczeń)
restriction(p allValuesFrom(r))
{x ∈ O : <x,y> ∈ ER(p) ⇒ y ∈ EC(r)}
restriction(p
{x ∈ O : ∃ <x,y> ∈ ER(p) /\ y ∈ EC(e)}
someValuesFrom(e))
restriction(p value(i)), dla i ID
jednostek
restriction(p
value(v)),
dla
v
danej liczbowo-literowej
{x ∈ O : <x,S(i)> ∈ ER(p)}
{x ∈ O : <x,S(v)> ∈ ER(p)}
restriction(p minCardinality(n))
{x ∈ O : card ({y ∈ O ∪ LV : <x,y> ∈ ER(p)}) ≥ n}
restriction(p maxCardinality(n))
{x ∈ O : card ({y ∈ O ∪ LV : <x,y> ∈ ER(p)}) ≤ n}
restriction(p cardinality(n))
{x ∈ O : card ({y ∈ O ∪ LV : <x,y> ∈ ER(p)}) = n}
Individual(annotation(p1 o1) …
annotation(pk
ok) EC(annotation(p1 o1)) ∩... ∩ EC(annotation(pk ok)) ∩
type(c1) … type(cm) pv1 … EC(c1) ∩... ∩ EC(cm) ∩ EC(pv1) ∩... ∩ EC(pvn)
pvn)
Individual(i annotation(p1 o1) …
annotation(pk
ok)
type(c1) … type(cm) pv1 …
pvn)
{S(i)} ∩ EC(annotation(p1 o1)) ∩... ∩ EC(annotation(pk
ok))
EC(c1) ∩... ∩ EC(cm) ∩ EC(pv1) ∩... ∩ EC(pvn)
value(p Individual(…))
{x ∈ O : ∃ y ∈ EC(Individual(…)) : <x,y> ∈ ER(p)}
value(p id) dla identyfikatora
{x ∈ O : <x,S(id)> ∈ ER(p) }
jednostki id
value(p v) dla wartości liczbowoliterowej v
{x ∈ O : <x,S(v)> ∈ ER(p) }
∩
annotation(p o) dla referencji
URI o
annotation(p Individual(…))
{x ∈ R : <x,S(o)> ∈ ER(p) }
{x ∈ ∈ R : ∃ y ∈ EC(Individual(…)) : <x,y> ∈ ER(p) }
Tabela 14 Interpretacja abstrakcyjnej składni OWL
c) Interpretacja aksjomatów i faktów
Abstrakcyjna interpretacja OWL I spełnia aksjomaty i fakty OWL w sposób podany w
poniższej tabeli, opcjonalne części aksjomatów i faktów zapisane są w nawiasach
kwadratowych, posiadane przez nie opcjonalne warunki również zapisane są w
nawiasach kwadratowych.
Dyrektywa
Class(c [Deprecated] complete
Warunki interpretacji
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ]
annotation(p1 o1) … annotation(pk S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈
ok)
descr1 … descrn)
Class(c [Deprecated] partial
EC(annotation(pk ok))
EC(c) = EC(descr1) ∩... ∩ EC(descrn)
ok)
descr1 … descrn)
EnumeratedClass(c [Deprecated]
EC(c) ⊆ EC(descr1) ∩... ∩ EC(descrn)
ok)
i1 … in)
Datatype(c [Deprecated]
EC(c) = { S(i1), …, S(in) }
ok) )
EC(c) ⊆ LV
DisjointClasses(d1 … dn)
EC(di) ∩ EC(dj) = { } for 1 ≤ i < j ≤ n
EquivalentClasses(d1 … dn)
EC(di) = EC(dj) for 1 ≤ i < j ≤ n
SubClassOf(d1 d2)
EC(d1) ⊆ EC(d2)
Dyrektywa
DatatypeProperty(p [Deprecated]
Warunki interpretacji
[ <S(c),S(owl:DeprecatedProperty)> ∈
annotation(p1 o1) … annotation(pk ER(rdf:type) ]
S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈
ok)
super(s1) … super(sn)
domain(d1) … domain(dn) range(r1) ER(p) ⊆ O×LV ∩ ER(s1) ∩... ∩ ER(sn) ∩
EC(d1)×LV ∩... ∩ EC(dn)×LV ∩ O×EC(r1)
… range(rn)
[Functional])
∩... ∩ O×EC(rn)
[ER(p) jest funkcjonalne]
ObjectProperty(p [Deprecated]
[ <S(c),S(owl:DeprecatedProperty)> ∈
annotation(p1 o1) … annotation(pk ER(rdf:type)]
ok)
super(s1) … super(sn)
domain(d1) … domain(dn) range(r1) ER(p) ⊆ O×O ∩ ER(s1) ∩... ∩ ER(sn) ∩
EC(d1)×O ∩... ∩ EC(dn)×O ∩ O×EC(r1)
… range(rn)
[inverse(i)] [Symmetric]
[Functional] [ InverseFunctional]
[Transitive])
∩... ∩ O×EC(rn)
[ER(p) jest odwrotne do ER(i)] [ER(p) jest
symetryczne]
[ER(p) jest funkcjonalne] [ER(p) jest odwrotnie
funkcjonalne]
[ER(p) jest przechodnie]
AnnotationProperty(p annotation(p1
o1) … annotation(pk ok))
OntologyProperty(p annotation(p1 o1) S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈
… annotation(pk ok))
EquivalentProperties(p1 … pn)
ER(pi) = ER(pj) for 1 ≤ i < j ≤ n
SubPropertyOf(p1 p2)
ER(p1) ⊆ ER(p2)
SameIndividual(i1 … in)
S(ij) = S(ik) for 1 ≤ j < k ≤ n
DifferentIndividuals(i1 … in)
S(ij) ≠ S(ik) for 1 ≤ j < k ≤ n
Individual([i] annotation(p1 o1) …
EC(Individual([i] annotation(p1 o1) … annotation(pk
annotation(pk ok)
ok)
type(c1) … type(cm) pv1 … pvn)
Tabela 15 Interpretacja dyrektyw OWL
type(c1) … type(cm) pv1 … pvn)) jest niepusty
d) Interpretacja ontologii
Ontologia może mieć adnotacje wymagające swoich własnych semantycznych warunków.
Oprócz tego lokalnego znaczenia adnotacje importu dostarczają zawartość innych
ontologii do ontologii aktualnej. Importowana ontologia ma jako nazwę argument
konstrukcji importującej. (Takie traktowanie importu nie jest poprawne w sieci www;.
zamierzone użycie nazw ontologii OWL to zlokalizowanie ontologii w sieci poprzez jej
nazwę, jednak ten przypadek jest poza formalnym traktowaniem).
Definicja
Niech D będzie mapą typów danych. Abstrakcyjna interpretacja OWL I względem D ze
słownictwem składającym się z VL , VC , V D , VI , VDP , V IP , V AP , VO spełnia ontologię OWL
O, jeżeli:
• każda referencja URI w O używana jako identyfikator klasy (typu danych, jednostki,
właściwości danych, właściwości jednostek, adnotacji, ontologii) należy odpowiednio
do VC (VD , VI , VDP , VIP , V AP , VO ) ,
• każda dana liczbowo-literowa w O należy do V L ,
• I spełnia każdą dyrektywę w O z wyjątkiem adnotacji ontologii,
• istnieją o ∈ R , <o,S(owl:Ontology)> ∈ ER(rdf:type) takie, że dla każdej adnotacji
ontologii postaci Annotation(p v), <o,S(v)> ∈ ER(p) i jeśli O ma nazwę n to S(n) = o,
• I spełnia każdą ontologię wymienioną w dyrektywie O adnotacji owl:imports.
Definicja
A, zbiór abstrakcyjnych ontologii, aksjomatów i faktów jest zgodny z mapą typów danych
D jeżeli istnieje pewna interpretacja I względem mapy D taka, że I spełnia każdą
ontologię, aksjomat i fakt w zbiorze.
Definicja
A, zbiór abstrakcyjnych ontologii, aksjomatów i faktów implikuje abstrakcyjną ontologię,
aksjomat lub fakt O’ względem mapy D, jeżeli każda interpretacja względem mapy D
spełniająca każdą ontologię, aksjomat lub fakt O, spełnia również O’.
3) Mapowanie do grafów RDF
Mapowanie abstrakcyjnej składni OWL do grafów RDF zapewnia relację między składniami
oraz wymianę składni. Takie mapowanie zachowuje znaczenie ontologii OWL DL. Wymiana
składni dla OWL to RDF/XML. Znaczenie ontologii OWL w RDF/XML jest określane tylko z
grafów RDF, które pochodzą z konstruowania grafów w dokumencie RDF/XML. Jeden
sposób translacji ontologii OWL polega na transformacji każdej dyrektywy do zbioru trójek.
Jako że wszystkie konstrukcje OWL Lite są szczególnymi przypadkami w pełnej
abstrakcyjnej składni, zapewniona jest tylko transformacja dla wersji OWL DL.
OWL DL ma semantykę zdefiniowaną na abstrakcyjnej składni oraz konkretnej składni
składającej się z podzbioru grafów RDF. Zatem niezbędne jest powiązanie ontologii w
abstrakcyjnej składni z dokumentami RDF/XML oraz korespondującymi z nimi grafami.
Istnieją takie relacje wiele-do-wielu konstruowane przy użyciu zbioru niedeterministycznych
reguł mapowania. Aby zastosować semantykę do konkretnego grafu niezbędne jest
znalezienie ontologii korespondującej z grafem zgodnie z regułami mapowania oraz
zastosowanie semantyki do abstrakcyjnej ontologii. Mapowanie jest zaprojektowane w taki
sposób, że dowolny graf RDF korespondujący z konkretną abstrakcyjną ontologią ma takie
samo znaczenie co każda abstrakcyjna ontologia korespondująca z tym konkretnym grafem.
Ponadto, jeśli proces ten nie może być zastosowany do grafów RDF, które nie mają
odpowiednio korespondującej formy, reguły mapowania precyzyjnie definiują zbór grafów,
który syntaktycznie charakteryzuje OWL DL w RDF/XML.
a) Translacja do grafów RDF
Poniżej przedstawiona tabela pokazuje reguły transformacji abstrakcyjnej składni do
wymiennej składni OWL. W kilku przypadkach są różne zasady transformowania. W tych
przypadkach może być wybrana każda z reguł. W kilku innych przypadkach są trójki, które
mogą lub nie mogą być generowane. Te trójki są wskazywane przez flagowanie ich. W
kilku innych przypadkach musi być generowana jedna z dwóch trójek, co jest wskazywane
przez oddzielanie trójek spójnikiem „OR”. Ten brak determinizmu pozwala na
generowanie większej ilości grafów.
Tabela zbudowana jest z trzech kolumn, których zawartość opisana jest w pierwszym
wierszu. Powtarzające się elementy są wymieniane przy użyciu okrągłych nawiasów, taka
forma pozwala na łatwą specyfikację transformacji dla wszystkich wartości n dozwolonych
w składni. Opcjonalne elementy składni są opcjonalnymi elementami transformacji i
zapisywane są w nawiasach kwadratowych. Dla wbudowanych elementów OWL pierwsza
trójka rdf:type w translacji lub każdy aksjomat jest opcjonalny.
Transformacje w tabeli są albo dla całych dyrektyw albo tylko dla ich części. Ostatnia
transformacja jest dla sekwencji, które same w sobie nie są częścią składni abstrakcyjnej.
Ta ostatnia transformacja jest używana do konstruowania innych, bardziej zwartych i
czytelnych transformacji.
Dla wielu dyrektyw te reguły wymagają transformacji komponentów dyrektyw używających
innych reguł. Kiedy transformacja komponentu jest używana jako podmiot, predykat lub
obiekt trójki, jest ona wtedy częścią produkcji i główny węzeł transformacji powinien być
użyty w trójce.
Transformacja T(S)
(i sekwencje) S
Ontology(O directive1 … directiven)
Ontology(directive1 … directiven)
Główny
węzeł M(T(S))
O rdf:type owl:Ontology .
T(directive1) … T(directiven)
O rdf:type owl:Ontology .
T(directive1) … T(directiven)
ontologyPropertyID rdf:type
Annotation(ontologyPropertyID
owl:OntologyProperty .
URIreference)
O ontologyPropertyID URIreference .
URIreference rdf:type owl:Ontology .
annotationPropertyID rdf:type
owl:AnnotationProperty .
Annotation(annotationPropertyID
URIreference)
rdf:Property . [opt]
O annotationPropertyID URIreference
.
dataLiteral)
O annotationPropertyID T(dataLiteral)
.
individual)
O annotationPropertyID T(individual) .
rdfs:Literal
rdfs:Literal
(i sekwencje) S
datatypeID
classID
Transformacja T(S)
datatypeID rdf:type rdfs:Datatype .
classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
individualID
Główny
węzeł M(T(S))
datatypeID
classID
individualID
datavaluedPropertyID rdf:type
owl:DatatypeProperty .
datavalued-
datavaluedPropertyID rdf:type
PropertyID
individualvaluedPropertyID rdf:type
owl:ObjectProperty . [opcjonalne jeżeli
istnieje trójka w translacji w ontologii,
która nadaje typ
individualvaluedPropertyID
individualvaluedPropertyID jako
owl:InverseFunctionalProperty,
owl:TransitiveProperty, lub
individualvalu
edPropertyID
owl:SymmetricProperty] .
individualvaluedPropertyID rdf:type
dataLiteral
dataLiteral
Individual(iID annotation1 …
iID T(annotation1) … iID
annotationm
T(annotationm)
type(type1)… type(typen)
iID rdf:type T(type1) . … iID rdf:type
dataLiteral
iID
value(pID1 v1) … value(pIDk vk)) T(typen) .
iID T(pID1) T(v1) . … iID T(pIDk) T(vk) .
Individual(annotation1 …
_:x T(annotation1) … _:x
annotationm
T(annotationm)
type(type1)…type(typen)
_:x rdf:type T(type1) . … _:x rdf:type
_:x
value(pID1 v1) … value(pIDk vk)) T(typen) .
(Z co najmniej jednym typem.)
_:x T(pID1) T(v1) . … _:x T(pIDk) T(vk) .
Individual(annotation1 …
_:x T(annotation1) … _:x
annotationm
T(annotationm)
value(pID1 v1) … value(pIDk vk)) _:x rdf:type owl:Thing .
_:x T(pID1) T(v1) . … _:x T(pIDk) T(vk) .
_:x
Transformacja T(S)
(i sekwencje) S
SameIndividual(iID1 … iIDn)
iIDi owl:sameAs iIDi+1 . 1≤i<n
iIDi owl:sameAs iIDj . [opt] 1≤i≠j≤n
DifferentIndividuals(iID1 … iIDn)
iIDi owl:differentFrom iIDj . OR
iIDj owl:differentFrom iIDi . 1≤i<j≤n
iIDj owl:differentFrom iIDi . [opt]
1≤i≠j≤n
DifferentIndividuals(iID1 … iIDn)
_:x rdf:type owl:AllDifferent .
_:x owl:distinctMembers T(SEQ iID1
… iIDn) .
Class(classID [Deprecated] partial
annotation1 … annotationm
description1 … descriptionn)
[classID rdf:type owl:DeprecatedClass
.]
classID T(annotation1) … classID
T(annotationm)
classID rdfs:subClassOf
T(description1) . …
classID rdfs:subClassOf
T(descriptionn) .
Class(classID [Deprecated]
complete
description1 … descriptionn)
.]
T(annotationm)
classID owl:intersectionOf T(SEQ
description1…descriptionn) .
Główny
węzeł M(T(S))
Transformacja T(S)
(i sekwencje) S
complete
description)
.]
T(annotationm)
classID owl:equivalentClass
T(description) .
complete
unionOf(description1 …
.]
descriptionn))
T(annotationm)
classID owl:unionOf T(SEQ
complete
complementOf(description))
.]
T(annotationm)
classID owl:complementOf
T(description) .
EnumeratedClass(classID
[Deprecated]
iID1 … iIDn)
.]
T(annotationm) .
classID owl:oneOf T(SEQ iID1…iIDn) .
Główny
węzeł M(T(S))
(i sekwencje) S
Transformacja T(S)
DisjointClasses(description1 …
T(descriptioni) owl:disjointWith
descriptionn)
T(descriptionj) . OR
Główny
węzeł M(T(S))
T(descriptionj) owl:disjointWith
T(descriptioni) . 1≤i<j≤n
T(descriptioni) owl:disjointWith
T(descriptionj) . [opt] 1≤i≠j≤n
EquivalentClasses(description1 …
T(descriptioni) owl:equivalentClass
descriptionn)
T(descriptionj) .
dla każdego <i,j> ∈ G gdzie G jest
zbiorem par {1,...,n}x{1,...,n},
który interpretowany jako
niebezpośredni graf konstruuje
powiązany graf dla {1,...,n}
SubClassOf(description1
T(description1) rdfs:subClassOf
description2)
T(description2) .
Datatype(datatypeID [Deprecated]
datatypeID rdf:type rdfs:Datatype .
annotation1 … annotationm )
datatypeID rdf:type rdfs:Class . [opt]
[datatypeID rdf:type
owl:DeprecatedClass .]
datatypeID T(annotation1) …
datatypeID T(annotationm)
unionOf(description1 …
_:x rdf:type owl:Class .
descriptionn)
_:x rdf:type rdfs:Class . [opt]
_:x owl:unionOf T(SEQ
_:x
intersectionOf(description1 …
descriptionn)
_:x owl:intersectionOf T(SEQ
_:x
complementOf(description)
_:x owl:complementOf T(description) .
_:x
(i sekwencje) S
oneOf(iID1 … iIDn)
Transformacja T(S)
Główny
węzeł M(T(S))
_:x
_:x owl:oneOf T(SEQ iID1…iIDn) .
oneOf(v1 … vn)
_:x rdf:type owl:DataRange .
_:x
_:x owl:oneOf T(SEQ v1 … vn) .
restriction(ID component1 …
componentn)
(With at least two components)
_:x owl:intersectionOf
_:x
T(SEQ(restriction(ID component1) …
restriction(ID componentn))) .
restriction(ID allValuesFrom(range)) _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x
_:x owl:onProperty T(ID) .
_:x owl:allValuesFrom T(range) .
restriction(ID
_:x rdf:type owl:Restriction .
someValuesFrom(required))
_:x
_:x owl:someValuesFrom T(required) .
restriction(ID value(value))
_:x
_:x owl:hasValue T(value) .
restriction(ID minCardinality(min))
_:x owl:minCardinality
"min"^^xsd:nonNegativeInteger .
_:x
(i sekwencje) S
Transformacja T(S)
Główny
węzeł M(T(S))
restriction(ID maxCardinality(max)) _:x rdf:type owl:Restriction .
_:x
_:x owl:maxCardinality
"max"^^xsd:nonNegativeInteger .
restriction(ID cardinality(card))
_:x owl:cardinality
"card"^^xsd:nonNegativeInteger .
DatatypeProperty(ID [Deprecated]
ID rdf:type owl:DatatypeProperty .
ID rdf:type rdf:Property . [opt]
super(super1)… super(supern)
[ID rdf:type owl:DeprecatedProperty .]
domain(domain1)…
ID T(annotation1) … ID T(annotationm)
domain(domaink)
ID rdfs:subPropertyOf T(super1) . …
range(range1)…
ID rdfs:subPropertyOf T(supern) .
range(rangeh)
ID rdfs:domain T(domain1) . …
[Functional])
ID rdfs:domain T(domaink) .
ID rdfs:range T(range1) . …
ID rdfs:range T(rangeh) .
[ID rdf:type owl:FunctionalProperty . ]
_:x
Transformacja T(S)
(i sekwencje) S
ObjectProperty(ID [Deprecated]
ID rdf:type owl:ObjectProperty .
[opcjonalne jeśli zawarta jest jedna
super(super1)… super(supern)
z ostatnich trójek]
domain(domain1)…
domain(domaink)
[ID rdf:type owl:DeprecatedProperty .]
range(range1)…
range(rangeh)
ID rdfs:subPropertyOf T(super1) . …
[inverseOf(inverse)]
ID rdfs:subPropertyOf T(supern) .
[Functional |
ID rdfs:domain T(domain1) . …
InverseFunctional |
ID rdfs:domain T(domaink) .
Transitive])
ID rdfs:range T(range1) . …
[Symmetric]
ID rdfs:range T(rangeh) .
[ID owl:inverseOf T(inverse) .]
[ID rdf:type owl:FunctionalProperty . ]
[ID rdf:type
owl:InverseFunctionalProperty . ]
[ID rdf:type owl:TransitiveProperty . ]
[ID rdf:type owl:SymmetricProperty . ]
AnnotationProperty(ID
annotation1 … annotationm)
ID rdf:type owl:AnnotationProperty .
OntologyProperty(ID
annotation1 … annotationm)
ID rdf:type owl:OntologyProperty .
EquivalentProperties(dvpID1 …
T(dvpIDi) owl:equivalentProperty
dvpIDn)
T(dvpIDi+1) . 1≤i<n
SubPropertyOf(dvpID1 dvpID2)
T(dvpID1) rdfs:subPropertyOf
T(dvpID2) .
EquivalentProperties(ivpID1 …
T(ivpIDi) owl:equivalentProperty
ivpIDn)
T(ivpIDi+1) . 1≤i<n
SubPropertyOf(ivpID1 ivpID2)
T(ivpID1) rdfs:subPropertyOf T(ivpID2)
.
Główny
węzeł M(T(S))
Transformacja T(S)
(i sekwencje) S
annotation(annotationPropertyID
annotationPropertyID URIreference .
URIreference)
Główny
węzeł M(T(S))
annotationPropertyID T(dataLiteral) .
dataLiteral)
annotationPropertyID T(individual) .
individual)
SEQ
SEQ item1…itemn
rdf:nil
_:l1 rdf:type rdf:List . [opt]
_:l1 rdf:first T(item1) . _:l1 rdf:rest _:l2 .
…
_:ln rdf:type rdf:List . [opt]
_:l1
_:ln rdf:first T(itemn) . _:ln rdf:rest
rdf:nil .
Tabela 16 Transformacja składni OWL do trójek
Powyższa transformacja nie jest iniekcją, są abstrakcyjne ontologie OWL, które nie
używają powyższego słownictwa, a mogą mapować do grafów RDF. Jednak jedynym
przypadkiem, w którym zachodzi ten proces, są konstrukcje mające takie samo znaczenie
jak aksjomaty klas rozłącznych mające te same efekty co jeden większy. Istnieje
możliwość zdefiniowania transformacji odwrotnej.
b) Definicje ontologii OWL DL i OWL Lite w postaci grafów RDF
Rozważając ontologie OWL w formie grafów należy zadbać o niedopuszczenie do użycia
niektórego słownictwa jako klas, właściwości lub jednostek OWL. Jeśli nie jest to
zrobione, to wbudowane definicje lub wykorzystanie tego słownictwa poszerzy informacje
w ontologii.
Definicja
Niedopuszczalnym słownictwem z RDF są: df:type, rdf:Property, rdf:nil, rdf:List, rdf:first,
rdf:rest,
rdfs:domain,
rdfs:subClassOf,
rdfs:range,
rdfs:Resource,
rdfs:subPropertyOf,
rdfs:ContainerMembershipProperty.
rdfs:Datatype,
rdfs:member,
Niedopuszczalne
rdfs:Class,
rdfs:Container
słownictwo
z
OWL
i
to
owl:AllDifferent, owl:allValuesFrom, owl:AnnotationProperty, owl:cardinality, owl:Class,
owl:complementOf,
owl:DataRange,
owl:DeprecatedProperty,
owl:equivalentClass,
owl:DatatypeProperty,
owl:differentFrom,
owl:equivalentProperty,
owl:disjointWith,
owl:DeprecatedClass,
owl:distinctMembers,
owl:FunctionalProperty,
owl:hasValue,
owl:intersectionOf, owl:InverseFunctionalProperty, owl:inverseOf, owl:maxCardinality,
owl:minCardinality,
owl:ObjectProperty,
owl:OntologyProperty,
owl:Restriction,
owl:oneOf,
owl:onProperty,
owl:sameAs,
owl:Ontology,
owl:someValuesFrom,
owl:SymmetricProperty, owl:TransitiveProperty, i owl:unionOf. Całe niedopuszczalne
słownictwo jest sumą dwóch wymienionych.
Definicja
Słownictwo klas (tylko) to rdf:Statement, rdf:Seq, rdf:Bag, i rdf:Alt. Słownictwo tylko typów
danych to wbudowane typy danych OWL. Słownictwo właściwości to rdf:subject,
rdf:predicate, rdf:object oraz wszystkie właściwości elementów kontenerów, np. rdf:_1,
rdf:_2, ….
Definicja
Zbiór ontologii, aksjomatów i faktów OWL DL w formie abstrakcyjnej składni O ma osobne
słownictwo, jeśli:
• ontologie w O, brane razem, nie używają referencji URI więcej niż identyfikatory
klas, typów danych, jednostek, właściwości danych, właściwości jednostek,
adnotacji i ontologii oraz identyfikatorów ontologii,
• ontologie w O, brane razem, zapewniają typ dla każdego identyfikatora jednostki,
• ontologie w O oprócz wartości adnotacji używają tylko słownictwa klas jako
identyfikatorów klas, słownictwa typów danych jako identyfikatorów typów danych,
tylko rdfs:Literal w zasięgach danych, tylko słownictwa właściwości jako
identyfikatorów właściwości danych, jednostek lub adnotacji, wbudowanych klas
jako identyfikatorów klas, wbudowanych typów danych jako identyfikatorów typów
danych, wbudowanych właściwości adnotacji jako identyfikatorów właściwości
adnotacji, wbudowanych właściwości ontologii jako identyfikatorów właściwości
ontologii i nie wymieniają niedopuszczalnego słownictwa.
Definicja
Graf RDF jest ontologią OWL DL w postaci grafu RDF, jeżeli jest identyczny z rezultatem
transformacji do trójek wyżej wymienionych zbiorów ontologii OWL DL, aksjomatów i
faktów w postaci abstrakcyjnej składni, która ma osobne słownictwo. Praktycznie
określając, czy graf RDF jest ontologią OWL DL w formie grafu, ograniczenia mocy mogą
używać konstrukcji takich jak "1"^^xsd:integer dopóki zakodowane w ten sposób wartości
są nieujemnymi liczbami całkowitymi.
Definicja
Graf RDF jest ontologią OWL Lite w postaci grafu RDF, jeżeli jest tak jak powyżej z
wyjątkiem tego, że zawartością O są ontologie OWL Lite oraz ich aksjomaty lub fakty.
4) Teoretyczna semantyka – kompatybilny model RDF
Ten teoretyczny model semantyki OWL jest rozszerzeniem semantyki RDF. Warto
zauważyć, że nie ma żadnego silnego powiązania między semantyką dla OWL DL
zdefiniowaną w tej części dokumentu, a teoretycznym modelem zdefiniowanym w sekcji 3).
Gdyby pojawił się konflikt między nimi, to pierwszeństwo bierze bezpośredni model
semantyki.
a) Światy OWL i RDF
Wszystko o OWL jest zdefiniowane w „świecie OWL”, który jest podziałem części „świata
RDF” na trzy składowe tj. jednostki OWL, klasy OWL i właściwości OWL. Wnętrze klasy
owl:Thing obejmuje jednostki świata OWL. Wnętrze klasy owl:Class obejmuje klasy świata
OWL.
Suma
wnętrz
klas
owl:ObjectProperty,
owl:DatatypeProperty,
owl:AnnotationProperty, oraz owl:OntologyProperty obejmuje właściwości świata OWL.
Istnieją dwa różne style użycia OWL. W bardziej dowolnym z nich, nazywanym OWL Full,
trzy części świata OWL identyfikowane są odpowiednikami RDF, mianowicie wnętrzami
klas rdfs:Resource, rdfs:Class, i rdf:Property. W bardziej restrykcyjnym stylu OWL DL trzy
części świata OWL są różne od ich odpowiedników RDF i parami rozłączne. OWL DL traci
na mocy ekspresyjności w zamian za lepszą rozstrzygalność wnioskowania.
Główną praktyczną różnicą między oboma stylami jest dbanie o pewność, że referencje
URI są właściwie umieszczone w odpowiedniej części świata OWL. W OWL Full nie ma
potrzeby martwienia się o to. W OWL DL informacja o lokalizacji musi być zapewniona dla
wielu używanych referencji URI. Założenia lokalizacji są trywialnie prawdziwe w OWL Full
i mogą być również ignorowane przy użyciu abstrakcyjnej składni korespondującej blisko
z OWL DL. Natomiast opisując OWL DL za pomocą trójek, należy zwrócić uwagę na to,
które elementy słownictwa należą do jakich elementów świata.
b) Interpretacje OWL
Semantyki OWL DL i OWL Full są bardzo podobne.
Z semantyki RDF dla V zbioru referencji URI i danych liczbowo-literowych, zawierającego
słownictwo RDF i RDFS oraz mapę typów danych D, D-interpretacja V jest krotką
I =< RI , PI , EXTI , S I , LI , LVI > , gdzie
•
RI jest dziedziną rozprawy o świecie, np. niepustym zbiorem zawierającym
oznaczenia referencji URI oraz danych liczbowo-literowych w V,
•
PI jest podzbiorem RI zawierającym właściwości I,
•
EXTI jest używane do przekazania znaczenia do właściwości i jest mapowaniem z
PI do P( RI × RI ) ,
•
S I jest mapowaniem zbioru referencji URI w V do ich oznaczeń w RI ,
•
LI jest mapowaniem ze zbioru typowanych wartości liczbowo-literowych do ich
oznaczeń w R I ,
•
LVI jest podzbiorem RI zawierającym przynajmniej zbiór stringów Unicode, zbiór
par stringów Unicode i etykiety językowe oraz przestrzeń wartości dla każdego typu
danych w D,
• CI
jest zbiorem klas zdefiniowanym jako CI = { x ∈ RI: <x,SI(rdfs:Class)>∈
EXTI(SI(rdf:type))},
• mapowanie CEXTI : C I → P( RI ) jest zdefiniowane jako CEXTI(c) = {x ∈ RI: <x,c>∈
EXTI(SI(rdf:type)) },
• D-interpretacja musi spełniać inne warunki, zdefiniowane w semantyce RDF,
• EXTI(SI(rdfs:subClassOf)) musi być relacją przechodnią, a wnętrze klasy wszystkich
typów danych musi być podzbiorem LV I .
Definicja
Niech D będzie mapą typów danych zawierającą typy dla rdf:XMLLiteral, xsd:integer i
xsd:string.
Interpretacja
I =< RI , PI , EXTI , S I , LI , LVI >
OWL
słownictwa
V
(zawierającego słownictwo RDF, RDFS i OWL) jest D-interpretacją V spełniającą
wszystkie ograniczenia tej sekcji.
wtedy
Jeśli E jest
owl:Class
SI(E) ∈
CI
rdfs:Datatype
Uwagi
CEXTI(
oraz
SI(E))=
IOC
IOC ⊆ CI
Definiuje IOC jako zbiór
IDC
IDC ⊆ CI
Definiuje IDC jako zbiór
klas OWL.
typów danych OWL
owl:Restriction
CI
IOR
IOR ⊆ IOC
Definiuje IOR jako zbiór
owl:Thing
IOC
IOT
IOT ⊆ RI i IOT ≠ ∅
Definiuje IOT jako zbiór
owl:Nothing
IOC
{}
rdfs:Literal
IDC
LVI
ograniczeń OWL.
jednostek OWL.
LVI ⊆ RI
Definiuje
owl:ObjectProperty
CI
IOOP
IOOP ⊆ PI
zbiór
IOOP
jako
właściwości
jednostek OWL.
Definiuje
owl:DatatypeProperty
CI
IODP
IODP ⊆ PI
IODP
jako
zbiór właściwości typów
danych OWL.
owl:AnnotationProperty CI
IOAP
IOAP ⊆ PI
Definiuje
IOAP
jako
zbiór
właściwości
adnotacji OWL.
owl:OntologyProperty
CI
IOXP
IOXP ⊆ PI
Definiuje
IOXP
jako
zbiór
właściwości
ontologii OWL.
owl:Ontology
CI
IX
owl:AllDifferent
CI
IAD
rdf:List
IL
Definiuje IX jako zbiór
ontologii OWL.
IL ⊆ RI
Definiuje IL jako zbiór
wtedy
Jeśli E jest
SI(E) ∈
Uwagi
CEXTI(
oraz
SI(E))=
list OWL.
rdf:nil
IL
Typowane
CEXTI(SI(
"l"^^d
SI("l"^^d) ∈ LVI
d))
dane
liczbowo-literowe
dobrze
są
określone
w
OWL.
Tabela 17 Warunki dotyczące części świata OWL i syntaktycznych kategorii
wtedy jeśli e ∈
Jeśli E jest
Uwagi
CEXTI(SI(E)) to
owl:Class
CEXTI(e) ⊆ IOT
rdfs:Datatype
CEXTI(e) ⊆ LVI
Instancje
CEXTI(e) ⊆ LVI
OWL
s
OWL
są
jednostkami OWL.
Zasięgi
owl:DataRange
klas
danych
specyficznymi rodzajami typów
danych.
owl:ObjectProperty
EXTI(e) ⊆ IOT×IOT
Wartości właściwości jednostek
są jednostkami OWL.
Wartości
owl:DatatypeProperty
EXTI(e) ⊆ IOT×LVI
właściwości
danych
są
typów
wartościami
liczbowo-literowymi.
owl:AnnotationProperty
owl:OntologyProperty
Jeśli E jest
owl:FunctionalProperty
Jeśli E jest
EXTI(e) ⊆ IOT×(IOT ∪ Wartości właściwości adnotacji
LVI)
są mniej swobodne.
EXTI(e) ⊆ IX×IX
Właściwości
wtedy c ∈ CEXTI(SI(E))
jeśli c ∈ IOOP ∪ IODP i
ontologii
łączą
ontologie z innymi ontologiami.
Uwagi
<x,y1>, <x,y2> ∈ EXTI(c) Właściwości jednostek i typów
⇒ y1 = y2
wtedy c ∈ CEXTI(SI(E))
danych mogą być funkcjonalne.
Uwagi
wtedy jeśli e ∈
Jeśli E jest
Uwagi
CEXTI(SI(E)) to
jeśli c ∈ IOOP i
<x1,y>, <x2,y> ∈ EXTI(c)
owl:InverseFunctionalProperty
⇒ x1 = x2
owl:SymmetricProperty
Tylko
właściwości
jednostek
mogą
być
odwrotnie
funkcjonalne.
<x,y> ∈ EXTI(c) ⇒
Tylko
<y,x> ∈ EXTI(c)
mogą być symetryczne.
<x,y>, <y,z> ∈ EXTI(c) Tylko
owl:TransitiveProperty
⇒ <x,z> ∈ EXTI(c)
właściwości
właściwości
jednostek
jednostek
mogą być przechodnie.
Tabela 18 Charakterystyka klas, typów danych i właściwości OWL
Jeśli E jest
rdfs:subClassOf
wtedy dla
<x,y> ∈ EXTI(SI(E)) jeśli
CEXTI(x) ⊆ CEXTI(y)
x, y ∈ IOC
rdfs:subPropertyOf x, y ∈ IOOP
EXTI(x) ⊆ EXTI(y)
rdfs:subPropertyOf x, y ∈ IODP
EXTI(x) ⊆ EXTI(y)
rdfs:domain
rdfs:range
x ∈ IOOP ∪ IODP, y ∈ IOC
x ∈ IOOP ∪ IODP,
y ∈ IOC ∪ IDC
<z,w> ∈ EXTI(x) ⇒ z ∈ CEXTI(y)
<w,z> ∈ EXTI(x) ⇒ z ∈ CEXTI(y)
Tabela 19 Warunki konieczne i wystarczające dla rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain i
rdfs:range
wtedy <x,y> ∈ EXTI(SI(E)) jeśli
Jeśli E jest
owl:equivalentClass
x,y ∈ IOC oraz CEXTI(x) = CEXTI(y)
owl:disjointWith
x,y ∈ IOC oraz CEXTI(x) ∩ CEXTI(y) = {}
owl:equivalentProperty
x,y ∈ IOOP ∪ IODP oraz EXTI(x) = EXTI(y)
owl:inverseOf
x,y ∈ IOOP oraz <u,v> ∈ EXTI(x), jeśli <v,u> ∈ EXTI(y)
owl:sameAs
x=y
owl:differentFrom
x≠y
Tabela 20 Charakterystyka słownictwa OWL [1]
Warunki na słownictwo OWL związane z logicznymi operacjami i zbiorami
Mówimy, że I 1 jest sekwencją y1 , ... , y n nad C, jeśli n = 0 i I 1 = S I (rdf : nil)
lub n > 0 i I 1 ∈ IL oraz
∃ I 2 , ... , I n ∈ IL : < l1 , y1 >∈ EXTI ( S I (rdf : first )), y1 ∈ C , < l1 , l 2 >∈ EXTI ( S I (rdf : rest )), ... ,
< l n1 , y n >∈ EXTI ( S I (rdf : first )), y n ∈ C , < l n , S I (rdf : nil ) >∈ EXTI ( S I (rdf : rest )).
wtedy <x,y> ∈ EXTI(SI(E)) jeśli
Jeśli E jest
owl:complementOf
x ∈ IOC i y jest sekwencją y1,…yn nad IOC i CEXTI(x) = CEXTI(y1)
owl:unionOf
∪ ... ∪ CEXTI(yn)
owl:intersectionOf
owl:oneOf
x, y ∈ IOC i CEXTI(x)=IOT-CEXTI(y)
x ∈ IOC i y jest sekwencją y1,…yn nad IOC i CEXTI(x) = CEXTI(y1)
∩ ... ∩ CEXTI(yn)
x ∈ CI i y jest sekwencją y1,…yn nad IOT lub nad LVI i CEXTI(x) =
{y1,..., yn}
Jeśli E jest
wtedy, jeśli <x,l> ∈ EXTI(SI(E)) to
oraz
owl:oneOf
l jest sekwencją y1,…yn nad LVI
x ∈ IDC
owl:oneOf
l jest sekwencją y1,…yn nad IOT
x ∈ IOC
to x ∈ IOR, y ∈ IOC∈ IDC, p ∈ IOOP ∪ IODP i
Jeśli
<x,y> ∈ EXTI(SI(owl:allValuesFrom)))
CEXTI(x) =
/\
<x,p> ∈ EXTI(SI(owl:onProperty)))
{u ∈ IOT : <u,v> ∈ EXTI(p) ⇒ v ∈ CEXTI(y) }
<x,y> ∈ EXTI(SI(owl:someValuesFrom))) {u ∈ IOT :
/\ <x,p>∈EXTI(SI(owl:onProperty)))
CEXTI(y) }
to x ∈ IOR, y ∈ IOT ∪ LVI, p ∈ IOOP ∪ IODP i
Jeśli
<x,y> ∈ EXTI(SI(owl:hasValue)))
<x,p>∈EXTI(SI(owl:onProperty)))
Jeśli
<x,y> ∈ EXTI(SI(owl:minCardinality)))
∃ <u,v> ∈ EXTI(p) takie, że v ∈
CEXTI(x) =
/\
{u ∈ IOT : <u, y> ∈ EXTI(p) }
to x ∈ IOR, y ∈ LVI, y jest nieujemną liczbą
całkowitą, p ∈ IOOP ∪ IODP, and CEXTI(x) =
/\ {u ∈ IOT : card({v ∈ IOT ∪ LV : <u,v>∈
EXTI(p)}) ≥ y }
<x,y> ∈ EXTI(SI(owl:maxCardinality))) /\ {u ∈ IOT : card({v ∈ IOT ∪ LV : <u,v>∈
EXTI(p)}) ≤ y }
<x,y> ∈ EXTI(SI(owl:cardinality)))
/\ {u ∈ IOT : card({v ∈ IOT ∪ LV : <u,v>∈
EXTI(p)}) = y }
Tabela 23 Warunki na ograniczenia OWL
Zrozumienie warunków (zasady)
Pierwsze dwa warunki zrozumienia wymagają istnienia skończonych sekwencji
używanych
w konstrukcjach OWL.
Trzeci
warunek
wymaga
istnienia
instancji
owl:AllDifferent. Pozostałe warunki wymagają istnienia odpowiednich opisów OWL i
zasięgów danych.
wtedy istnieją l1,…,ln ∈ IL takie, że
Jeżeli istnieją
∈
<l1,x1>
EXTI(SI(rdf:first)),
<l1,l2>
EXTI(SI(rdf:rest)),
x1, …, xn ∈ IOC
<ln,xn>
∈
∈
…
<ln,SI(rdf:nil)>
∈
EXTI(SI(rdf:rest))
∈
<l1,x1>
<l1,l2>
EXTI(SI(rdf:rest)),
x1, …, xn ∈ IOT ∪ LVI
<ln,xn>
∈
∈
…
<ln,SI(rdf:nil)>
∈
EXTI(SI(rdf:rest))
Jeżeli istnieje
l,
sekwencja
x1,…,xn
wtedy istnieje y takie, że
nad
gdzie xi≠xj dla 1≤i<j≤n
IOT,
y ∈ IAD, <y,l> ∈ EXTI(SI(owl:distinctMembers))
Jeżeli istnieje
wtedy istnieje y takie, że
l, sekwencja x1,…,xn nad IOC
y ∈ IOC, <y,l> ∈ EXTI(SI(owl:unionOf))
l, sekwencja x1,…,xn nad IOC
y ∈ IOC, <y,l> ∈ EXTI(SI(owl:intersectionOf))
l, sekwencja x1,…,xn nad IOT
y ∈ IOC, <y,l> ∈ EXTI(SI(owl:oneOf))
l, sekwencja x1,…,xn nad LVI
y ∈ IDC, <y,l> ∈ EXTI(SI(owl:oneOf))
wtedy istnieje y ∈ IOC takie, że
Jeżeli istnieje
x ∈ IOC
<y,x> ∈ EXTI(SI(owl:complementOf))
Jeżeli istnieje
x ∈ IOOP ∪ IODP /\ w ∈ IOC ∪ IDC <y,x>
wtedy istnieje y ∈ IOR takie, że
∈
EXTI(SI(owl:onProperty))
/\
<y,w> ∈ EXTI(SI(owl:allValuesFrom))
x ∈ IOOP ∪ IODP /\ w ∈ IOC ∪ IDC
x ∈ IOOP ∪ IODP /\ w ∈ IOT ∪ LVI
<y,x> ∈ EXTI(SI(owl:onProperty)) /\
<y,w> ∈ EXTI(SI(owl:someValuesFrom))
<y,x>
∈
/\
∈
/\
<y,w> ∈ ∈ EXTI(SI(owl:maxCardinality))
x ∈ IOOP ∪ IODP /\ w ∈ LVI /\ w jest <y,x>
nieujemną liczbą całkowitą
/\
<y,w> ∈ EXTI(SI(owl:minCardinality))
<y,w> ∈ EXTI(SI(owl:hasValue))
∈
∈
/\
<y,w> ∈ EXTI(SI(owl:cardinality))
Tabela 24 Zrozumienie warunków OWL
c) OWL Full
OWL Full poszerza ogólne warunki o warunki zmuszające części świata OWL do tego,
aby były takie same jak ich odpowiedniki w RDF. Te nowe warunki wchodzą w silną
interakcję z ogólnymi warunkami. Na przykład drugi warunek zrozumienia dla list,
ponieważ w OWL Full IOT jest całą dziedziną RDF, generuje listę dowolnego rodzaju, w
tym listę list.
Definicja
Interpretacja OWL Full słownictwa V jest interpretacją OWL spełniającą następujące
warunki (przypominamy, że interpretacja OWL jest związana z mapą typów danych):
•
IOT = RI ,
•
IOOP = PI ,
•
IOC = C I ,
Definicja
Niech K będzie zbiorem grafów RDF. K jest importowo zamknięty (imports closed), jeśli
dla każdej trójki w dowolnym elemencie K postaci x owl:imports u . K zawiera graf, który
jest efektem przetwarzania dokumentu XML/RDF dostępnego na u (jeśli istnieje) do grafu
RDF. Importowe domknięcie zbioru grafów RDF jest najmniejszym importowo zamkniętym
zbiorem zawierającym grafy.
Definicja
Niech K i Q będą zbiorami grafów RDF, a D mapą typów danych. Wtedy K implikuje (OWL
Full) Q w związku z D, jeżeli interpretacja OWL Full w związku z D (dowolnego słownictwa
V zawierającego słownictwa RDF i RDFS oraz słownictwo OWL), która spełnia wszystkie
grafy RDF w K, spełnia również wszystkie grafy RDF w Q. K jest OWL Full zgodny jeżeli
istnieje interpretacja OWL Full spełniająca wszystkie grafy RDF w K.
d) OW DL
OWL DL rozszerza warunki przedstawione w podpunkcie b) o rozdzielenie dziedziny na
kilka mniejszych części. Taki podział ma dwie konsekwencje. Po pierwsze, części
dziedziny OWL stają się standardowo pierwszego rzędu, w których predykaty i jednostki
są rozłączne. Po drugie, części OWL interpretacji OWL DL mogą być postrzegane jako
interpretacja logiki deskrypcyjnej dla poszczególnych deskrypcyjnych logik.
Definicja
Interpretacja OWL DL słownictwa V jest interpretacją OWL spełniającą następujące
warunki:
• LVI, IOT, IOC, IDC, IOOP, IODP, IOAP, IOXP, IL, i IX są wszystkie parami
rozłączne,
• dla V z niedopuszczalnego słownictwa S I (V ) ∈ RI − ( LVI ∪ IOT ∪ IOC ∪ IDC ∪
∪ IOOP ∪ IODP ∪ IOAP ∪ IOXP ∪ IL ∪ IX ) .
Wnioskowanie w OWL DL jest zdefiniowane podobnie jak dla OWL Full.
Definicja
Niech K i Q będą zbiorami grafów RDF, a D mapą typów danych. Wtedy K implikuje (OWL
DL) Q w związku z D, jeżeli każda interpretacja OWL DL w związku z D (dowolnego
słownictwa V zawierającego słownictwa RDF i RDFS oraz słownictwo OWL), która spełnia
wszystkie grafy RDF w K, spełnia również wszystkie grafy RDF w Q. K jest OWL DL
zgodny, jeżeli istnieje interpretacja OWL Full spełniająca wszystkie grafy RDF w K.
Istnieje silny związek między bezpośrednim modelem teoretycznej semantyki a
semantyką OWL DL (ale w przypadku jakichkolwiek konfliktów bezpośredni model ma
pierwszeństwo). Zasadniczo ontologia, która może być zapisana w abstrakcyjnej składni
OWL DL, implikuje za sobą inną dokładnie wtedy, kiedy implikuje ją w bezpośredniej
semantyce. Jest kilka utrudnień z tym związanych, mających do czynienia z rozdzielaniem
się słownictwa.
Aby takie korespondowanie było poprawne musi być kilka powiązań między ontologią w
abstrakcyjnej składni z konkretną nazwą i dokumentem dostępnym w sieci pod danym
URI. To powiązanie jest na zewnątrz semantyki, w związku z tym musi być osobno
zaaranżowane.
Definicja
Niech T będzie mapowaniem abstrakcyjnej składnie do grafów RDF, niech O będzie
zbiorem ontologii, aksjomatów i faktów OWL DL w formie abstrakcyjnej składni. O
nazywamy importowo zamkniętym, jeśli dla każdego URI, u, w dyrektywie importu w
dowolnej ontologii w O, rozbiór RDF dokumentu dostępnego na sieci na u, daje rezultat w
T(K), gdzie K jest ontologią w O o nazwie u.
Twierdzenie
Niech O i O’ będą importowo zamkniętymi zbiorami ontologii, aksjomatów i faktów OWL
DL w formie abstrakcyjnej składni takimi, że ich suma jest osobnym słownictwem. Jeżeli
dana jest mapa typów danych mapująca xsd:string i xsd:integer do odpowiednich typów
danych XML Schema, która zawiera mapowanie RDF dla rdf:XMLLiteral, wtedy O
implikuje O’ w związku z D wtedy i tylko wtedy, gdy translacja O implikuje (OWL DL)
translację O’ w związku z D.
Prostym wnioskiem z powyższego twierdzenia jest fakt, że O jest zgodne w związku z D
wtedy i tyko wtedy, gdy translacja O jest zgodna w związku z D.
Twierdzenie
Niech O i O’ będą importowo zamkniętymi zbiorami ontologii, aksjomatów i faktów OWL
DL w formie abstrakcyjnej składni takimi, że ich suma jest osobnym słownictwem. Jeżeli
dana jest mapa typów danych mapująca xsd:string i xsd:integer do odpowiednich typów
danych XML Schema, która zawiera mapowanie RDF dla rdf:XMLLiteral, wtedy translacja
O implikuje (OWL Full) translację O’ w związku z D, jeżeli translacja O implikuje (OWL DL)
translację O’ w związku z D.
2.10. Wnioskowanie
Własności wnioskowania OWL obejmują własności wnioskowania RDF i RDFS opisane w
poprzednich rozdziałach oraz inne dodatkowe.
• Wymuszanie przechodniości za pomocą owl:TransitiveProperty, na przykład:
(rdf:type przodek owl:TransitiveProperty)
(przodek Marta Maria)
(przodek Maria Anna)
implikuje
(przodek Marta Anna)
• Wymuszanie symetryczności właściwości za pomocą owl:SymmetricProperty.
• Wnioskowanie przy pomocy właściwości odwrotnej owl:inverseOf, na przykład:
(owl:inverseOf rodzic ma_rodzica)
(parentOf Anna Katarzyna)
implikuje
(ma_rodzica Kate Goldie)
Jeśli relacja ma_rodzica jest odwrotna do relacji rodzic, to jeśli określimy relację rodzic na
dwóch konkretnych instancjach, to znaczy, że zachodzi między nimi relacja odwrotna
ma_rodzica.
• Dziedziczenie warunku rozłączności, na przykład:
(owl:disjointWith Roślina Zwierzę)
implikuje
(owl:disjointWith Roślina Ssak)
Jeśli dwie klasy są rozłączne, to podklasa jednej z nich jest również rozłączna z tą drugą.
• Jeśli pojawia się relacja owl:sameAs między dwoma jednostkami, które są klasami,
wnioskuje się relację owl:equivalentClass między nimi. Podobnie, kiedy pojawia się
relacja
owl:sameAs
między
dwoma
właściwościami,
wnioskowana
jest
owl:equivalentProperty. Na przykład:
(owl:sameAs Człowiek Osoba)
(rdf:type Człowiek rdfs:Class)
(rdf:type Osoba rdfs:Class)
implikuje
(owl:equivalentClass Człowiek Osoba)
• Wszystkie podklasy danej klasy są rozłączne z dopełnieniem klasy, na przykład:
(owl:complementOf Zwierzę Nie_zwierzę)
implikuje
relacja
(owl:disjointWith Ssak Nie_zwierzę)
Podklasa Ssak klasy Zwierzę jest rozłączna z dopełnieniem Nie_zwierzę swojej superklasy.
• Inne wnioskowanie o dopełnieniu:
(=> (and (owl:complementOf ?c1 ?c2)
(rdfs:subClassOf ?c3 ?c1)
(rdfs:subClassOf ?c4 ?c2)
(owl:complementOf ?c4 ?c5))
(rdfs:subClassOf ?c3 c5))
• Wnioskowanie
relacji
owl:sameAs
przez
owl:FunctionalProperty
oraz
owl:InverseFunctionalProperty, na przykład:
(rdf:type matka owl:FunctionalProperty)
(matka Jola Maria)
(matka Jola Magda)
implikuje
(owl:sameAs Maria Magda)
Jeśli właściwość matka jest funkcjonalna, to jeśli jednostka Jola ma matkę Maria oraz
Magda, to te instancje są takie same.
• Jeśli A jest jednym z listy kilku elementów (owl:oneOf), to wtedy każdy z tych elementów
jest typu A (rdf:type).
• Jeżeli owl:hasValue owl:Restriction ogranicza konkretną właściwość do konkretnej
wartości i obiekt ma tę wartość dla tej właściwości, wtedy obiekt ma ograniczony typ.
• Jeżeli obiekt jest typu owl:allValuesFrom owl:Restriction i ma wartości dla określonej
właściwości, to te wartości są wymienionego typu, na przykład:
(owl:onProperty Restriction_kocię dziecko)
(owl:allValuesFrom Restriction_kocię Kot)
(rdf:type Mru RestrictionCatChildren)
(child Mru Fru)
implikuje
(rdf:type Fru Cat)
Jeśli na danej właściwości wprowadzimy jej ograniczony podzbiór, tzn. na właściwości
dziecko wprowadzimy właściwość kocię o wszystkich wartościach z klasy Kot, to jeśli
wiadomo, że Mru jest kociakiem i jest jednocześnie dzieckiem Fru to wnioskuje się, że
Fru jest kotem.
• Jeśli
owl:someValuesFrom
owl:Restriction
ogranicza
konkretną
właściwość
do
konkretnego typu i jeśli dany obiekt ma niektóre wartości tego typu dla wymienionej
właściwości, to wtedy obiekt ma ograniczenie jako typ.
• Jeżeli właściwość q jest odwrotna do właściwości p, a p jest właściwością przechodnią, to
wtedy q jest również właściwością przechodnią.
• Wszystkie
różne
elementy
(owl:AllDifferent)
posiadają
jednocześnie
właściwość
owl:differentFrom określoną między każdą parą.
Inne reguły.
• Wszystkie klasy są podklasami owl:Thing.
• Jeśli klasa A jest sumą innych klas, to każda z klas sumy jest podklasą klasy A.
• Jeśli klasa A jest iloczynem innych klas, to jest ona podklasą każdej z klas przecięcia.
• Jeśli klasa A jest iloczynem pewnych klas składowych i klasa B jest iloczynem pewnych
klas składowych, to A jest podklasą B, jeśli każda składowa A jest podklasą jakiejś
składowej B.
• Jeśli klasa A jest sumą pewnych klas składowych i klasa B jest sumą pewnych klas
składowych, wtedy A jest podklasą B, jeśli każda składowa B jest super-klasą pewnej
składowej A.
• Jeśli klasa A jest iloczynem pewnych klas składowych, a klasa B jest sumą pewnych klas
składowych, wtedy A jest podklasą B, jeśli każda składowa A jest podklasą każdej
składowej B.
• owl:hasValue owl:Restriction A obejmuje inne ograniczenia B wartości, jeśli właściwość
ograniczona przez B jest podwłaściwością właściwości ograniczonej przez A, a
ograniczana wartość jest taka sama.
• owl:allValuesFrom owl:Restriction A obejmuje inne ograniczenie B allValuesFrom, jeśli
właściwość ograniczana przez B jest podwłaściwością właściwości ograniczanej przez A i
ograniczana klasa B jest podklasą ograniczanej klasy A. warto zauważyć, że każda klasa
jest swoją własną podklasą i każda właściwość jest swoją własną podwłaściwością.
• Jeśli obiekt jest typu owl:maxCardinality owl:Restriction, gdzie dana właściwość jest
ograniczona maksymalnie do liczby wartości 1, wtedy wszystkie wartości, które są
obiektem danej właściwości są takie same (owl:sameAs).
• owl:minCardinality owl:Restriction A jest rozłączne z owl:maxCardinality owl:Restriction B,
jeśli właściwość ograniczona przez A jest podwłaściwością właściwości ograniczonej
przez B, a liczba wartości wymienianych przez A jest większa niż liczba wartości
wymienianych przez B.
• owl:minCardinality owl:Restriction A obejmuje inne owl:minCardinality restriction B, jeśli
właściwość ograniczona przez B jest podwłaściwoscią właściwości ograniczonej przez A i
ilość wartości określanych przez A jest mniejsza lub równa ilości wartości określanych
przez B.
• owl:maxCardinality owl:Restriction A obejmuje inne owl:maxCardinality restriction B, jeżeli
właściwość ograniczana przez B jest podwłaściwością właściwości ograniczanej przez A i
ilość wartości specyfikowanych prze A jest większa lub równa liczbie wartości określanych
prze B.
Język OWL posiada formalną semantykę, dzięki której możliwe jest wnioskowanie o ontologii
i jednostkach. Proces wnioskowania jest nadal przedmiotem zainteresowania badań a stan
efektywności jest cały czas w sferze oczekiwań.
Przykłady wnioskowania.
1) Wnioskowanie o klasach
Class
(a:kierowca_autobusu
complete
intersectionOf(a:osoba
restriction(a:kieruje
someValuesFrom(a:autobus))))
Class
(a:kierowca
complete
restriction(a:kieruje
someValuesFrom(a:pojazd))))
Class (a:autobus partial a:pojazd)
Z powyższych zapisów wynikają następujące wnioski:
• Kierowca autobusu jest osobą kierującą autobusem.
• Autobus jest pojazdem.
• Kierowca autobusu kieruje pojazdem, zatem musi być kierowcą.
Class (a:właściciel_kota complete intersectionOf(a:osoba restriction(a:ma_zwierzę_domowe
someValuesFrom(a:kot))))
SubpropertyOf (a:ma_zwierzę_domowe a:lubi)
Class
(a:miłośnik_kotów
complete
restriction(a:lubi
someValuesFrom(a:kot))))
• Właściciele kotów mają koty jako zwierzęta domowe.
• ma_zwierzę_domowe jest podwłaściwością właściwości lubi, zatem każdy, kto ma
zwierzę domowe musi lubić zwierzęta domowe.
• Właściciele kotów muszą lubić koty.
Class
(a:kierowca
complete
intersectionOf
(a:osoba
restriction
(a:kieruje
someValuesFrom(a:pojazd))))
Class (a:kierowca partial a:dorosły)
Class (a:pełnoletni complete intersectionOf(a:dorosły a:osoba))
• Kierowcy są zdefiniowani jako osoby kierujące pojazdami (kompletna definicja).
• Kierowcy są dorośli (częściowa definicja).
• Zatem wszyscy kierowcy muszą być dorosłymi osobami (tj.. pełnoletnimi).
Powyższy przykład ilustruje aksjomaty wykorzystywane do dodatkowych, ważnych informacji
o klasie. Nie musimy wiedzieć, że kierowca jest dorosły w celu zidentyfikowania go, ale jeśli
rozpoznaliśmy konkretnego kierowcę, wiemy, że jest on dorosły.
Class (a:owca partial restriction (a:je allValuesFrom (a:trawa)) a:zwierzę)
Class (a:trawa partial a:roślina)
DisjointClass (unionOf (restriction (a:część someValuesFrom (a:zwierzę)) a:zwierzę)
unionOf (a:roślina restriction (a:część someValuesFrom (a:roślina))))
Class (a:wegetarianin complete intersectionOf (restriction (a:je allValuesFrom
(complementOf (restriction (a:część someValuesFrom (a:zwierzę))))) restriction
(a:je allValuesFrom (complementOf (a:zwierzę))) a:zwierzę))
• Owce jedzą tylko trawę.
• Trwa jest rośliną.
• Rośliny oraz części roślin nie mają części wspólnych (są rozłączne) ze zwierzętami i
ich częściami.
• Wegetarianie jedzą tylko rzeczy, które nie są zwierzętami lub ich częściami.
• Owce są wegetarianami.
Kompletna definicja pozawala rozpoznać kiedy rzeczy (osoby) są wegetarianami.
Class (a:żyrafa partial a:zwierzę restriction (a:je allvaluesFrom (a:liść)))
Class (a:liść partial restriction (a:część someValuesFrom (a:drzewo)))
Class (a:drzewo partial a:roślina)
DisjointClass (unionOf (restriction (a:część someValuesFrom (a:zwierzę)) a:zwierzę)
(complementOf (restriction (a:część someValuesFrom (a:zwierzę)))))
• Żyrafy jedzą tylko liście.
• Liście są częściami drzew, które są roślinami.
• Rośliny i części roślin są rozłączne od zwierząt i ich części.
• Wegetarianie jedzą tylko rzeczy, które nie są zwierzętami lub ich częściami.
• Żyrafy są wegetarianami.
Podobnie do poprzedniego przykładu, dodatkowy wniosek wynika z ograniczenia w definicji
liścia.
Class (a:stara_kobieta complete intersectionOf (a:osoba a:płeć_żeńska a:starszy))
Class (a:stara_kobieta partial intersectioOf (restriction (a:ma_zwierzę_domowe allvaluesFrom
(a:kot)) restriction (a:ma_zwierzę_domowe someValuesFrom (a:zwierzę))))
Class (a:właściciel_kota complete intersectionOf (a:osoba restriction (a:ma_zwierzę_domowe
someValuesFrom (a:kot))))
• Stare kobiety muszą mieć zwierzę domowe.
• Wszystkie zwierzęta, jakie mają stare kobiety muszą być kotami.
• Stara kobieta musi mieć zwierzę domowe, które jest kotem.
Powyższy przykład przedstawia przecięcie egzystencjalnego ujęcia ilościowego (założenie
istnienia zwierzęcia domowego) oraz uniwersalnego ujęcia ilościowego (określenie
dozwolonego typu domowego zwierzęcia). Ilustruje on również, że ontologia jest
subiektywnym spojrzeniem na świat, można nie zgodzić się z takim modelem.
Class (a:krowa partial a:wegetarianin)
DisjointClasses (unionOf (restriction (a:część someValuesFrom (a:zwierzę)) a:zwierzę)
(complementOf (restriction (a:część someValuesFrom (a:zwierzę))))) restriction
(a:je allValuesFrom (complementOf (a:zwierzę))) a:zwierzę))
Class (a:szalona_krowa complete intersectionOf (a:krowa restriction (a:je someValuesFrom
(intersection (restriction (a:część someValuesFrom (a:owca)) a:mózg)))))
Class (a:owca partial a:zwierzę restriction (a:je allValuesFrom (a:trawa)))
• Krowy naturalnie są wegetarianami.
• Szalona krowa je mózg owcy.
• Owca jest zwierzęciem.
Zatem szalona krowa je części zwierząt, co jest niezgodne i niekonsekwentne z definicją
wegetarianina.
2) Wnioskowanie o instancjach
Individual (a:Super_Express type (owl:Thing))
Individual (a:Michał type (a:płeć_męska) value (a:kieruje a:Q123ABC) value (a:czyta
s:Super_Express))
Individual (a:Q123ABC type (a:furgonetka) type (a:biała_rzecz))
Class (a:mężczyzna_w_białej_furgonetce complete intersectionOf (a:mężczyzna restriction
(a:kieruje someValuesFrom (intersectionOf (a:furgonetka a:biała_rzecz)))))
Class (a:mężczyzna_w_białej_furgonetce partial restriction (a:czyta allvaluesFrom (a:dziennik)))
• Michał kieruje białą furgonetką.
• Michał musi być dorosłą osobą, zatem jest mężczyzną.
• Michał jest mężczyzną, który kieruje białą furgonetką, zatem jest mężczyzną w białej
furgonetce.
• Mężczyzna w białej furgonetce czyta tylko dzienniki a Michał czyta Super Express,
więc Super Express jest dziennikiem.
Aksjomaty przedstawiają przykład interakcji między kompletnymi a częściowymi definicjami
wraz z uniwersalnym ujęciem ilościowym pozwalającym na wnioskowanie o wypełnianej roli.
Individual
(a:Reks
type
(owl:Thing)
value
(a:jest_zwierzęciem_domowym_należącym_do
a:Piotr))
Individual (a:Piotr type (owl:Thing))
ObjectProperty (a:ma_zwierzę_domowe domain (a:osoba) range (a:zwierzę))
ObjectProperty
(a:
jest_zwierzęciem_domowym_należącym_do
inverseOf
(a:ma_zwierzę_domowe))
• Reks jest zwierzęciem domowym Piotra.
• Piotr jest właścicielem Reksa.
• Piotr musi być osobą.
• Reks musi być zwierzęciem.
W powyższym przykładzie pojawia się zależność między relacją odwrotną, dziedziną a
zasięgiem określającym daną właściwość.
Individual
(a:Wojciech
type
(a:osoba)
value
(a:ma_zwierzę_domowe
(a:ma_zwierzę_domowe a:Kuku) value (a:ma_zwierzę_domowe Kiki))
a:Koko)
value
Individual (a:Koko type (a:kaczka))
Individual (a:Kuku type (a:kaczka))
Individual (a:Kiki type (a:kaczka))
DifferentIndovoduals (a:Koko a:Kuku a:Kiki)
Class (a:miłośnik_zwierząt complete intersectionOf (a:osoba restriction (a:ma_zwierzę_domowe
minCardinality (3))))
• Wojciech ma zwierzęta domowe Koko, Kuku i Kiki.
• Koko, Kuku, Kiki są różnymi jednostkami (kaczkami).
• Wojciech ma przynajmniej trzy zwierzęta, więc jest miłośnikiem zwierząt.
Warto zauważyć, że w tym przypadku nie potrzeba zawierać osoby w definicji miłośnika
zwierząt, ponieważ ograniczenie dziedziny pozwala wyciągnąć taki wniosek.
Individual (a:Marta type (a:osoba_płci_żeńskiej) type (a:starszy) value (a:ma_zwierzę_domowe
a:Tom))
Individual (a:Tom type (owl:Thing))
ObjectProprty (a:ma_zwierzę_domowe domain (a:osoba) range (a:zwierzę))
Class (a:stara_kobieta complete intersectionOf (a:osoba a:płeć_żenska a:starszy))
Class (a:stara_kobieta partial intersectionOf (restriction (a:ma_zwierzę_domowe allValuesFrom
(a:kot)) restriction (a:ma_zwierzę_domowe someValuesFrom (a:zwierzę))))
• Marta jest starszą osobą płci żeńskiej i ma zwierzę domowe Toma.
• Marta musi być osobą.
• Marta jest starą kobietą.
• Wszystkie zwierzęta Marty muszą być kotami.
Ograniczenie dziedziny daje dodatkowe informacje, które pozwalają wnioskować o bardziej
specyficznych typach.
3) Dystrybucja reguł.
Zachowanie się reguł dla egzystencjalnych ujęć ilościowych jest podobne do zachowania
działań na zbiorach (suma, iloczyn):
A
(B
C) = (A
B)
(A
C)
Kwantyfikator szczegółowy
Wyrażenie
∃ p. (A
B) ≡ ( ∃ p. A)
( ∃ p. B)
w terminach OWL wyraża się następująco:
restriction (some p unionOf (A B))
≡
unionOf (restriction (some (p A)) restriction (some (p B)))
Są też inne wnioski słabsze niż równoważność:
∃ p. (A
( ∃ p. A)
B)
( ∃ p. A)
( ∃ p. B) )
( ∃ p. A)
( ∃ p. B)
( ∃ p. A)
( ∃ p. B)
∃ p. (A
( ∃ p. B)
B),
które w terminach OWL wyrażają się następująco:
restriction (some p intersectionOf (A B) ⊆
intersectionOf (restriction (some (p A)) restriction (some p B)))
intersectionOf (restriction (some (p A)) restriction (some p B))) ⊆
ubinOf (restriction (some (p A)) restriction (some p B)))
intersectionOf (restriction (some (p A)) restriction (some p B))) ⊆
restriction (some p unionOf (A B))
Względem kwantyfikatora szczegółowego suma jest rozdzielna, iloczyn nie.
Kwantyfikator ogólny
Reguły dla kwantyfikatorów ogólnych są podobne.
Wyrażenie
∀ p. (A
B) ≡ ( ∀ p. A)
( ∀ p. B)
W terminach OWL zapisywane jest następująco:
restriction (all p intersectionOf (A B))
≡
intersectionOf (restriction (all (p A)) restriction (all (p B)))
Analogicznie są wnioski słabsze niż równoważność:
( ∀ p. A)
( ∀ p. B) )
∀ p. (A
( ∀ p. A)
B)
( ∀ p. A)
( ∀ p. A)
( ∀ p. B)
( ∀ p. B)
( ∀ p. (A
W terminach OWL wyrażające się następująco:
intersectionOf (restriction (all (p A)) restriction (all p B)))
( ∀ p. B)
B)),
unionOf (restriction (all (p A)) restriction (all p B)))
restriction (all p intersectionOf (A B)
restriction (all p unionOf (A B))
Iloczyn jest rozdzielny względem kwantyfikatora ogólnego, suma nie.
4) Zamknięte i otwarte światy.
Jeśli coś nie wynika z ontologii, nie można się z niej czegoś dowiedzieć, to nie można
zakładać, że nie jest to prawda. Jest to tak zwane założenie otwartego świata (Open World
Assumption). Wnioskowanie w DL jest monotoniczne, jeśli wiadomo, że x jest instancją A, to
dodawanie dodatkowej informacji do modelu nie może spowodować, że stanie się on
fałszywy. Tak dzieje się w przypadku, gdy nie ma ograniczenia na ilość wartości, a co za tym
idzie, możliwe jest dodawanie kolejnych, nie stojących w sprzeczności z poprzednimi.
Niektóre jednostki ontologii mogą mieć dodatkowe ograniczenia mocy zbioru wartości danej
właściwości, które zamykają relację, pozwalając na dalsze wnioskowanie o wszystkich
wartościach właściwości i nie pozwalając na dodawanie nowych elementów.
Częstym przykładem powstawania zamieszania w semantyce OWL jest pojawienie się
ogólnego kwantyfikatora nad pustym zbiorem.
Individual (a:Tomek type(restriction (a:ma_przyjaciela cardinality(0))))
Powyższy przykład mówi, że Tomek nie ma przyjaciół. Zatem instancją jakiej klasy jest
Tomek? Ogólny kwantyfikator nad pustym zbiorem jest zawsze prawdziwy w trywialny
sposób.
2.11. Zastosowania
OWL jest językiem opierającym się na RDF, rozszerzającym go o dodatkowe narzędzia i
elementy w celu ułatwienia logicznego wnioskowania i wykorzystania inteligentnych
narzędzi. OWL znacznie rozszerzył zakres ontologii pozwalając na reprezentowanie
dowolnej wiedzy (nie tylko sztuczna inteligencja) oraz zastosowanie autonomicznych
wirtualnych agentów. Umożliwia:
•
Tworzenie ontologii (OWL jest częścią sieci semantycznej, której informacja ma
określone znaczenie, zapewnia strukturyzację metadanych).
•
Używanie, zmienianie i integrowanie różnych ontologii.
•
Przetwarzanie informacji, publikowanie ontologii w sieci www.
•
Tworzenie reprezentacji wiedzy o tym czym jest dany obiekt i jakie są jego relacje z
innymi pojęciami w danej ontologii oraz poza nią.
•
Opisywanie semantyki pojęć (OWL daje agentowi możliwość „zrozumienia” o czym jest
mowa w danych).
•
Tworzenie wystarczająco bogatego i użytecznego spisu metadanych (umożliwia to
wyszukiwanie żądanych informacji).
•
Tworzenie
semantyki
obrazów
multimedialnych,
danych
audio
oraz
innych
nietekstowych dokumentów.
•
Tworzenie ontologii dokumentacji firm w celu zapewnienia lepszego wyszukiwania. Ma
to szczególne zastosowanie w dużych korporacjach posiadających strony internetowe o
bogatej zawartości (oferty usług i produktów, relacje prasowe, opisy działalności,
procedur, procesów, technologii i osiągnięć, dane statystyczne itp.) Ontologie OWL
katalogują te dokumenty i usprawniają wyszukiwania niezbędnych danych i informacji.
•
Budowanie modeli informacyjnych pozwalających na wykorzystanie wszystkich
elementów informacji (własności pojęć, relacji między nimi, linków do dokumentacji
definiującej i opisującej je). Ma to zastosowanie na przykład w dużych dokumentacjach
inżynieryjnych składających się z różnych części; dokumentacji projektu, produkcji,
testów itp., różniących się między sobą strukturą hierarchiczną.
•
Zapewnienie agentów rozumiejących i integrujących różne źródła informacji (np.
planowanie zajęć uwzględniające możliwości i preferencje użytkownika, znajdowanie
najlepiej pasujących rozwiązań).
•
Zapewnienie interoperacyjności pod niezintegrowanymi warunkami, np. urządzenia czy
mechanizmy niezaprojektowane do wspólnego działania, różniące się przeznaczeniem,
producentem, czasem działania. Ontologia umożliwia zrozumienie i połączenie tych
elementów.
OWL-S
Siec semantyczna powinna zapewniać dostęp nie tylko do swojej zawartości ale również do
usług w sieci. Użytkownicy i wirtualni agenci powinni mieć możliwość wyszukiwania,
wywoływania, komponowania i monitorowania zasobów sieci oferujących usługi na wysokim
poziomie automatyzacji. OWL-S14 (wcześniej DAML-S) jest ontologią usług, która czyni tą
funkcjonalność możliwą.
Starania w kierunku tworzenia usług sieciowych są gigantyczne. Wkrótce będzie możliwy
dostęp do zasobów sieci przez jej zawartość, nie tyko przez słowa kluczowe. Znaczącą siłą
jest rozwój nowej generacji sieciowych języków znaczników takich jak OWL. Języki te
umożliwiają tworzenie ontologii dla dowolnych domen i są podatne na procedury
efektywnego wnioskowania. W ten sposób aplikacje wnioskujące mogą być rozwijane o
automatyczne determinowanie logicznych konsekwencji zdań logicznych.
Pośród najważniejszych zasobów sieci są strony zapewniające usługi. Przez „usługi”
rozumiemy strony dostarczające nie tyko statyczną informację ale oferujące również pewne
akcje, takie jak na przykład sprzedaż produktów. Sieć semantyczna powinna umożliwić
użytkownikowi lokalizację, selekcję, kompozycję i monitorowanie usług w sposób
automatyczny.
W celu skorzystania z usługi wirtualny agent musi mieć dostęp do interpretowalnego przez
komputer opisu usługi oraz sposobu dostępu do niej. Ważnym celem semantycznych
języków jest założenie pewnych ram, wewnątrz których takie opisy mogą być tworzone i
wykorzystywane. Strony www powinny być zdolne do używania standardowych ontologii
składających się ze zbioru podstawowych klas i właściwości do deklaracji i opisu usług.
Mechanizmy
OWL
zapewniają
odpowiedni,
kompatybilny
z
siecią
ramy
języków
reprezentacji, wewnątrz których się to odbywa.
Będziemy rozważać zarówno proste jak i złożone usługi. Proste usługi to takie, gdzie
pojedynczy, dostępny dla sieci program komputerowy jest wywoływany poprzez zapytanie,
wykonuje on swoje zadanie i tworzy (być może) pojedynczą odpowiedź na zapytanie. Z
pojedynczymi usługami użytkownik nie ma ciągłej interakcji. W przeciwieństwie do tego,
złożone usługi składają się z wielu prostszych (prymitywnych) usług i mogą wymagać
14
Por. http://www.w3.org/Submission/OWL-S/
szerokiej interakcji lub rozmowy między użytkownikiem a świadczoną usługą. OWL-S jest
przeznaczony do wspierania obu rodzajów usług.
Zadania oczekiwane od OWL-S
1) Automatyczne wykrywanie usług sieciowych. Jest to automatyczny proces do
lokalizacji usług. Zapewnia on poszczególne klasy możliwości usług. Na przykład
użytkownik może szukać strony sprzedającej bilety lotnicze między dwoma danymi
miastami i akceptującej konkretną kartę kredytową. Aktualnie to zadanie musi być
wykonywane przez człowieka, który może użyć wyszukiwarki w celu znalezienia usługi,
czytać strony www i wykonywać usługi manualnie, w zależności od spełniania jego
oczekiwań. Dzięki OWL-S informacja niezbędna do wykrycia danej usługi mogłaby być
zdefiniowana jako zrozumiały przez komputer semantyczny znacznik na stronie www i
katalog usług lub ulepszone narzędzie wyszukujące mogłoby być wykorzystane do
automatycznego zlokalizowania usługi. Ewentualnie alternatywnie świadczący daną
usługę mógłby wcześniej zareklamować się w katalogu usług OWL-S w taki sposób, że
użytkownik może znaleźć usługę zapytawszy katalog. OWL-S umożliwia zatem
ogłaszanie właściwości i możliwości usług.
2) Automatyczne wywoływanie usług. Jest to automatyczne wywoływanie usługi przez
komputer lub wirtualnego agenta mając dany jedynie deklaratywny opis usługi w
przeciwieństwie do sytuacji, kiedy agent został zaprogramowany do nazywania
poszczególnych usług. Jest to konieczne, gdy na przykład użytkownik może poprosić o
zakup biletu na konkretny lot ze strony znalezionej w czasie wyszukiwania i wybranej
przez niego. Wykonanie usługi może być rozważane jako zbiór wywołań odległych
procedur. OWL-S zapewnia deklaratywny, interpretowalny przez komputer API
zawierający semantykę argumentów niezbędnych do wyspecyfikowania w czasie
wykonywania tych wywołań i semantyka tego jest zwracana w wiadomości kiedy
usługa została wykonana lub realizacja się nie powiodła. Agent komputerowy winien
mieć zdolność interpretacji języka, zrozumienia jakie elementy wejściowe są potrzebne
do wywołania usługi oraz zrozumienia jaka informacja zostanie zwrócona. OWL-S w
połączeniu z domenowymi ontologiami napisanymi w OWL zapewnia standardowe
środki deklaratywnej specyfikacji API dla usług sieciowych, które umożliwiają taki
rodzaj automatycznego wykonania usług sieciowych.
3) Automatyczna kompozycja i interoperacyjność usług sieciowych. To zadanie
zawiera automatyczną selekcję, kompozycję i interoperacyjne działania między
usługami sieciowymi do wykonania niektórych złożonych zadań. Na przykład
użytkownik może chcieć dokonać wszystkich przygotowań i rezerwacji związanych z
podróżą służbową.
ą. Aktualnie musi wybrać
wybra usługę, dokonaćć swojej kompozycji
manualnie i upewnićć się,
się żże ma dostępne niezbędne
dne oprogramowanie umo
umożliwiające
współpracę usług i dzielenie informacji. W celu wsparcia tego procesu OWL-S
OWL
zapewnia deklaratywną specyfikację
specyfikacj warunków wstępnych
pnych i konsekwencji aplikacji
poszczególnych usług oraz język
j
do opisu kompozycji usług.
2.12. Wyższa
sza ontologia usług
Tworzenie ontologii
gii usług wynika z potrzeby zapewnienia trzech głównych rodzajów wiedzy
o usługach, które przedstawia poniższy
poni
rysunek.
Rysunek 1 Rodzaje wiedzy o usługach
Klasa Service zapewnia organizacyjny punkt odwołania do zadeklarowanej usługi sieciowej.
Właściwości
presents,
describedBy
describedBy,
i
supports
są
właściwościami
ciami
usługi.
Klasy
ServiceProfile, ServiceModel, i ServiceGrounding są zakresami tych właś
właściwości. Każda
instancja klasy Service będzie
ędzie prezentowa
prezentować (presents) opis ServiceProfile,
ServiceProfile będzie opisana
przez (describedBy) ServiceModel i będzie wspierać (supports)) opis ServiceGrounding.
Detale tych elementów mogą
ą różnić
róż
się między sobą w poszczególnych usługach. Ale ka
każda
z tych trzech perspektyw na usługę
usług zapewnia niezbędny
dny typ informacji o usłudze.
providedBy
Usługa
Zasób
supports
presents
describedBy
Ugruntowanie
usługi
Profil usługi
Co robi
usługa
Jaki jest
dostęp do
usługi
Model usługi
Jak
działa
usługa
Rysunek 2 Podklasy klasy Service
Profil usługi odpowiada na pytanie co dana usługa robi w sposób odpowiedni dla
wyszukującego usługi agenta. Taka forma reprezentacji zawiera opis co jest realizowane dla
usługi, ograniczenia możliwości aplikacyjnych usługi, jej jakości i wymagań, które muszą być
spełnione w celu satysfakcjonującej realizacji usługi. Model usługi mówi klientowi jak
korzystać z usługi przez uszczegółowianie semantycznej zawartości zapytania i pod jakimi
warunkami wystąpią poszczególne efekty końcowe. Dla nietrywialnych usług (składających
się z wielu kroków) opis ten może być użyty przez wyszukującego agenta na przynajmniej
cztery różne sposoby: (1) wykonanie większej ilości dogłębnych analiz tego czy usługa
realizuje oczekiwania, (2) skomponowanie opisu usługi z różnych usług do wykonania
określonego
zadania,
(3)
koordynacja
czynnościami
różnych
elementów
podczas
zarządzania usługą, (4) monitorowanie wykonania usługi.
ServiceGrounding (ugruntowanie) określa szczegóły dostępu agenta do usługi, określa
protokoły komunikacji, formaty wiadomości i specyficzne dla usługi szczegóły, takie jak
numer portu do kontaktowania się z usługą. Ponadto specyfikuje dla każdego
semantycznego typu wejścia lub wyjścia jednoznaczną drogę wymiany elementów tego typu
z usługą.
Wyższa ontologia usług określa tylko dwa ograniczenia mocy zbiorów: usługa może być
piana przez co najwyżej jeden model usługi a ugruntowanie musi być skojarzone z dokładnie
jedną usługą. Wyższa ontologia nie określa z premedytacją minimalnej ilości właściwości
presents lub describedBy. Nie określa również maksymalnej mocy dla właściwości presents
lub supports.
Na koniec należy zauważyć, że oprócz definiowania wyższej ontologii dla profili, jeden dla
modeli, jeden dla gruntowania, OWL-S pozwala na konstruowanie alternatywnych podejść w
każdym przypadku.
2.13. Profile usług
Każda usługa sieciowa zawiera trzy elementy: pytającego o usługę, świadczącego usługę
oraz komponenty infrastruktury. Pytający o usługę zazwyczaj jest użytkownikiem szukającym
interesującej go usługi w sieci www, świadczący usługę to osoba lub instytucja (np.
sprzedawca) zapewniający realizację danej usługi. Szukający opiera swoje wyszukiwanie na
komponentach infrastruktury, które działają jak
rejestr
usług w celu
znalezienia
najodpowiedniejszej. Rolą rejestru jest dopasowanie najlepszej usługi do zadanego
zapytania. Wewnątrz ram OWL-S profil usługi zapewnia odpowiedni sposób opisu usług
oferowanych
i
poszukiwanych,
czyli
reprezentuje
to,
co
dana
usługa
zapewnia
użytkownikowi.
Dwa podstawowe zastosowania profilów usług to:
• prezentowanie w sieci możliwości usług sieciowych,
• zapytanie o usługi sieciowe z danym zbiorem możliwości.
Dzięki
wykorzystaniu
podklas
OWL
możliwe
jest
stworzenie
wyspecjalizowanych
reprezentacji usług, które mogą być wykorzystywane jako profile usług. Profil OWL-S jest
funkcją trzech podstawowych typów informacji: jaka organizacja dostarcza usługę, jaką
funkcję spełnia usługa oraz dostarcza pełen zakres cech charakteryzujących usługę. Te trzy
informacje są badane w następującym porządku:
• Informacja o świadczącym usługę to przede wszystkim informacje o kontakcie z
odpowiednią jednostką.
• Funkcjonalny opis usługi jest wyrażony w terminach przekształceń zapewnianych przez
usługę. Określa elementy wejściowe wymagane przez usługę i gwarantowane
elementy wyjściowe, ponadto jeśli usługa wymaga zewnętrznych warunków, profil
opisuje te warunki i oczekiwane efekty wynikające z wykonania usługi. Na przykład
usługa sprzedaży może wymagać ważnej karty kredytowej jako warunku wstępnego,
elementem wejściowym jest numer karty i termin ważności. Jako element wyjściowy
generowane jest potwierdzenie i jako efekt następuje realizacja transakcji.
• Profil pozwala na opis właściwości używanych do opisu cech usługi: kategoria usługi,
ocena jakości (użytkownik może chcieć sprawdzić rodzaj usługi z jakiej korzysta a
świadczący może chcieć opublikować oceny jej użytkowników aby zaprezentować
jakość świadczonych przez siebie usług) oraz nieograniczona lista parametrów usługi,
mogąca zawierać dowolne informacje. OWL-S zapewnia mechanizm reprezentujący te
parametry, którymi mogą być parametry pozwalające na ocenę maksymalnego czasu
odpowiedzi czy geograficznych aspektów dostępności usługi.
1) Zestawianie profilu: relacje z modelem procesów
Profil usługi zapewnia zwięzły opis usługi do rejestru; kiedy usługa została wybrana profil
staje się niepotrzebny. Klient będzie używał modelu procesów do kontroli interakcji z
usługą. Profile modeli odgrywają różne role, są różnymi reprezentacjami tej samej usługi.
OWL-S nie dyktuje żadnych ograniczeń między profilem a modelem, zatem oba opisy
mogą zawierać pewne niezgodności bez wpływu na wiarygodność wyrażeń OWL. Jeżeli
profil opisuje usługę niezgodną z usługą w modelu proces zostanie przerwany.
Profil jasno specyfikuje zamierzony cel usługi, pokazuje funkcjonalność, którą usługa
zamierza zapewnić, może ukrywać niektóre elementy (niedostępne publicznie).
Model rejestru zawierający możliwości usługi i łączący je z oczekiwaniami to model
adaptowany przez rejestry takie jak UDDI, ale inne rodzaje rejestrów też są możliwe.
2) Właściwości profili
Podstawowe części modelu profilu można sklasyfikować w czterech sekcjach: pierwsza
opisująca właściwości łączące klasę profilu usługi z klasą modelu procesu, druga
opisująca formę informacji kontaktu i opisu profili – jest to informacja przeznaczona dla
odbiorców usługi, trzecia rozważająca funkcjonalność reprezentacji w terminach IOPE
(Input, Output, Precondition and Effect) oraz czwarta opisująca atrybuty profilu.
a) Profil usługi
Klasa ServiceProfile zapewnia super-klasę wszystkich typów wysokiego poziomu opisów
usługi. Klasa ta wymaga podstawowych informacji łączących każdą instancję profilu z
instancją usługi, między którymi istnieje dwukierunkowa relacja:
• presents – mówi, że usługa jest opisana przez dany profil,
• presentedBy – relacja odwrotna do powyższej, określa dany profil opisujący
usługę.
b) Nazwa usługi, kontakty i opis
Profile zawierają informacje zależne od człowieka, nieprzetwarzane automatycznie, takie
jak serviceName, textDescription i contactInformation. Dany profil może mieć dokładnie
jedną nazwę usługi i opis, ale wiele informacji dotyczących kontaktu.
• serviceName – odnosi się do nazwy oferowanej usługi,
• textDescription – zapewnia krótki opis usługi, podsumowuje ofertę usługi,
wymagania niezbędne do jej pracy itp.
• contactInformation zapewnia mechanizm pozwalający skontaktować się z osobą
lub jednostką odpowiedzialną za usługę. OWL-S nie ogranicza ilości tych informacji.
c) Opis funkcjonalności
Istotnym elementem jest opis funkcjonalności usługi, zawierający takie informacje jak
warunki niezbędne do spełnienia a także warunki wynikające z wykonania usługi zarówno
oczekiwane, jak i nieoczekiwane. OWL-S przedstawia dwa aspekty tej funkcjonalności:
informacja o transformacji (reprezentowane przez dane wejściowe i wyjściowe) i stan
zmian powstały w wyniku wykonania usługi (reprezentowany przez warunki wstępne i
efekty).
Ontologia profilu definiuje następujące właściwości klasy profilu dla wskazania IOPE:
• hasParameter – zakresy wokół instancji klasy Parameter ontologii profilu,
• hasInput - zakresy wokół instancji klasy Input,
• hasOutput - zakresy wokół instancji typu Output,
• hasPrecondition – określa jeden z warunków wstępnych oraz zakresy nad
instancjami klasy Precondiion zdefiniowanych zgodnie ze schematem ontologii
procesu,
• hasResult – określa jeden z rezultatów usługi, pod jakimi warunkami powstają
elementy wyjściowe oraz jak powstają zmiany domeny podczas wykonywania
usługi.
d) Atrybuty profili
Dodatkowe atrybuty zawierające informacje o gwarancji jakości, klasyfikacji usługi i inne
informacje, których użytkownik powinien być świadomy.
• serviceParameter – jest rozszerzalną listą właściwości, których wartościami są
instancje klasy ServiceParameter,
• serviceCategory – odnosi się do wejścia do ontologii czy taksonomii usług, jej
wartościami są instancje klasy ServiceCategory.
e) ServiceParameter
• serviceParameterName – nazwa aktualnego parametru (symbole liczbowe,
literowe lub URI),
• sParameter – wskazanie wartości parametru wewnątrz ontologii OWL.
f) ServiceCategory
Opisuje kategorie usług na bazie pewnych kategorii zewnętrznych (spoza OWL-S i OWL).
Może to wymagać specjalnych narzędzi wnioskujących.
• categoryName – nazwa właściwej kategorii (symbole liczbowe, literowe lub URI),
• taxonomy – zasoby referencji do schematu taksonomii (URI lub URL),
• value – wskazuje wartość konkretnej taksonomii, może być więcej niż jedna
wartość, nie ma na to ograniczeń,
• code – każdy typ usług dysponuje kodem skojarzonym z taksonomią.
g) Specyfikowanie typu usługi i produktu
Są dwie właściwości używane do określenia typu oferowanej usługi i produktów, z którymi
ma do czynienia usługa. Wartości tych właściwości są instancjami klas usług i produktów
ontologii OWL.
• serviceClassification – definiuje mapowanie z profilu do ontologii usługi w OWL,
• serviceProduct – definiuje mapowanie z profilu do ontologii usługi w OWL.
2.14. Modelowanie usług jako procesów
Istotnym jest zrozumienie czym jest proces. Nie jest to program do wykonania a określenie
sposobu, w jaki klient może wejść w interakcję z usługą. Pojedynczy proces jest opisem
usługi wymagającej jednej (może być złożona) wiadomości i zwracającej jedną (może być
złożona) widomość w odpowiedzi. Złożony proces to utrzymujący się pewien stan, każda
wiadomość od klienta posuwa do przodu stan wewnątrz procesu.
Model procesu jest elementem OWL-S odpowiedzialnym za opis działania usługi i jej
wewnętrznych procesów (etapów wykonania, wewnętrznych akcji). Ponadto określa on
protokół
interakcji
oraz
specyfikuje
abstrakcyjne
wiadomości
(ontologiczny
typ
transmitowanej informacji). Ułatwia wywołanie, kompozycję i monitoruje interakcje usług
sieciowych.
Proces może mieć dwa rodzaje celów: pierwszy to generowanie i zwracanie informacji
bazującej na danych informacjach oraz stanie rzeczy, drugi to tworzenie zmian w istniejącej
rzeczywistości procesu.
Proces może mieć dowolną liczbę elementów wejściowych oraz wyjściowych (również zero).
Może mieć dowolną ilość warunków wstępnych, obowiązujących w celu poprawnego
wywołania procesu i może mieć dowolną liczbę efektów.
1) Parametry i wyrażenia
Dane wejściowe i wyjściowe są podklasami ogólnej klasy Parameter. Każdy parametr ma
typ określany przez URI.
<owl:Class rdf:ID="Input">
<rdfs:subClassOf rdf:resource="#Parameter"/>
</owl:Class>
<owl:Class rdf:ID="Output">
<rdfs:subClassOf rdf:resource="#Parameter"/>
</owl:Class>
Modelowanie zmiennych jako globalnych, nazywanych jednostkami, może być nieco
mylące. RDF nie ma zasięgu zmiennych. Dokument RDF jest zbiorem pewnych trójek.
Zmienna jest nazywana za pomocą URI jak każdy inny zasób, zatem ma zasięg globalny,
a dokładniej nie ma żadnego zasięgu. Pomimo tego braku strukturalnego często używa
się RDF do kodowania hierarchicznych jednostek, takich jak formuły czy struktury kontroli.
Proces nie będzie pracował poprawnie dopóki nie są prawdziwe warunki wstępne. W
momencie kiedy już działa może mieć różne efekty. Warunki wstępne i efekty
reprezentowane są przez formuły logiczne. ,Jest kilka różnych podejść otrzymywania
formuł logicznych w RDF w zależności od tego jak blisko RDF/OWL chce się pozostać.
Dokonanie wyboru notacji jest zazwyczaj bardzo istotnym elementem, ale tutaj różnice są
raczej powierzchowne i nie ma problemu z tłumaczeniem między poszczególnymi
opcjami.
Kluczową ideą podpierającą nasze podejście jest traktowanie wyrażeń jak symboli
literowych lub liczbowych (string, XML literals…). Wyrażenia mają przypisane adnotacje o
języku w jakim są wyrażone. Właściwość expressionBody daje właściwe wyrażenie.
<owl:DatatypeProperty rdf:ID="expressionBody">
<rdfs:domain rdf:resource="#Expression"/>
W przypadku gdy wykorzystywane jest kodowanie XML, deklaruje się wyrażenia będące
XML literals.
Trzy rodzaje parametrów są rozłączne.
<rdf:Description rdf:about="#Input">
<owl:disjointWith rdf:resource="#Output"/>
<owl:disjointWith rdf:resource="#Local"/>
</rdf:Description>
<rdf:Description rdf:about="#Output">
<owl:disjointWith rdf:resource="#Local"/>
</rdf:Description>
Flagowanie bitów w RDF jako ”Literals”
oznacza, że kompilator RDF powinien je
ignorować. Trik polega na tym, że kompilator OWL-S wyciąga zignorowane elementy i
interpretuje je odpowiednio do danego przypadku, traktując je w swojej pierwotnej formie
sprzed transformacji.
Są dwa szczególne przypadki dla Expression: Condition i Effect. Ponieważ są one
implementowane jako literals, nie ma sposobu na zadeklarowanie jaka jest różnica,
jednak jest to bardzo użyteczne rozróżnienie dla osoby czytającej ontologię.
<owl:Class rdf:ID="Condition">
<owl:subClassOf rdf:resource="&expr;#Expression"/>
</owl:Class>
<owl:Class rdf:ID="Effect">
<owl:subClassOf rdf:resource="&expr;#Expression"/>
</owl:Class>
2) Parametry procesów i rezultaty
Proces z jego elementami IOPE łączymy za pomocą właściwości opisanych w poniższej
tabeli:
Właściwość
Zasięg
Typ
hasParticipant
Participant
Thing
hasInput
Input
Parameter
hasOutput
Output
Parameter
hasLocal
Local
Parameter
hasPrecondition condition
Expression
hasResult
(zobacz niżej)
Result
Tabela 25 Właściwości procesu
Połączenia od procesów do ich parametrów bezpośrednio określają zasięg. Parametry
participant, input, output i local mają zasięg całego procesu, w którym występują.
Parametr Result ma węższy zasięg.
• Participants
Proces zawiera dwóch lub więcej agentów, jeden to klient (TheClient), z punktu
widzenia którego opisywany jest proces. Drugi to serwer (TheServer), który jest
podstawowym elementem, z którym ma do czynienia klient. Jeżeli istnieją inne
elementy to wymieniane są za pomocą właściwości hasParticipant.
• Input / Output
Dane wejściowe i wyjściowe określają transformację danych dokonywaną przez
proces. Dane wejściowe to elementy wymagane na wstępie procesu, w przypadku
pojedynczego procesu dane wejściowe pochodzą od klienta, w przypadku procesu
złożonego pochodzą od klienta lub z poprzednich kroków procesu. Zostało wyżej
powiedziane, że proces pojedynczy to taki, który koresponduje z usługą jednego
kroku i oczekuje jednej wiadomości, co może wydawać się sprzeczne z wielością
danych wejściowych. Należy jednak rozróżniać wiadomość wysyłaną do procesu a
dane wejściowe. Wiadomość jest istotnie jedna, ale może obejmować tyle danych
wejściowych ile jest wymagane. Podobnie dane wyjściowe są przekazywane
klientowi jako pojedyncza wiadomość.
Poniższy przykład pokazuje definicję hasParameter, i jej podwłaściwości hasInput,
hasOutput, and hasLocal:
<owl:ObjectProperty rdf:ID="hasParameter">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Parameter"/>
<owl:ObjectProperty rdf:ID="hasInput">
<rdfs:subPropertyOf rdf:resource="#hasParameter"/>
<rdfs:range rdf:resource="#Input"/>
<owl:ObjectProperty rdf:ID="hasOutput">
<rdfs:range rdf:resource="#Output"/>
<owl:ObjectProperty rdf:ID="hasLocal">
<rdfs:range rdf:resource="#Local"/>
• Preconditions i Results:
Jeżeli proces ma warunki wstępne to nie może być wykonany pomyślnie jeśli nie są
one prawdziwe. Należy rozróżniać warunki, które są prawdziwe od posiadania
właściwości takich jak wiara, że coś jest prawdziwe, uznawanie, że coś jest
prawdziwe czy reprezentowanie czegoś w bazie danych jako prawdziwe. W OWL-S
jeżeli warunki wstępne są nieprawdziwe, konsekwencje wykonywania i inicjowania
procesu nie są zdefiniowane. Wykonanie procesu może skutkować zmianami stanu
rzeczy oraz zdobywaniem informacji przez agenta klienta (zwracane jako dane
wyjściowe). Jednak procesów nie łączy się bezpośrednio z efektami i danymi
wyjściowymi, ponieważ często jednocześnie modelowane są zależności procesu od
innych kontekstów.
Przykład użycia terminu result oraz sprzężonych danych wyjściowych i efektów:
<owl:Class rdf:ID="Result">
<rdfs:label>Result</rdfs:label>
</owl:Class>
<owl:ObjectProperty rdf:ID="hasResult">
<rdfs:label>hasResult</rdfs:label>
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="#Result"/>
• Warunkowanie danych wyjściowych i efektów
Mając zadeklarowany rezultat model procesu może opisać go w terminach czterech
właściwości:
− inCondition jest właściwością określającą warunek, pod którym dany rezultat (ten
zdeklarowany, nie inny) wystąpi,
<owl:ObjectProperty rdf:ID="inCondition">
<rdfs:label>inCondition</rdfs:label>
<rdfs:domain rdf:resource="#Result"/>
<rdfs:range rdf:resource="&expr;#Condition"/>
− withOutput określa co następuje gdy warunek jest prawdziwy,
<owl:ObjectProperty rdf:ID="withOutput">
<rdfs:label>withOutput</rdfs:label>
<rdfs:range rdf:resource="#OutputBinding"/>
− hasEffect określa co następuje gdy warunek jest prawdziwy,
<owl:ObjectProperty rdf:ID="hasEffect">
<rdfs:label>hasEffect</rdfs:label>
<rdfs:range rdf:resource="&expr;#Expression"/>
− hasResultVar
deklaruje
inCondition.
Zmienne
zmienne,
te
są
które
nazywane
są
ograniczone
ResultVars,
w
są
analogiczne do Locals i służą do podobnych celów.
<owl:ObjectProperty rdf:ID="hasResultVar">
<rdfs:label>hasResultVar</rdfs:label>
<rdfs:range rdf:resource="#ResultVar"/>
Innym deskryptorem danych wyjściowych jest resultForm, który nie jest związany ze
zmiennymi ale z rezultatami.
<owl:DatatypeProperty rdf:ID="resultForm">
<rdfs:label>resultForm</rdfs:label>
<rdfs:range rdf:resource="&rdf;#XMLLiteral"/>
Celem tego elementu jest zapewnienie szablonu XML dla danych wyjściowych
wysyłanych klientowi. Przyczyny, dla których potrzebny jest taki szablon są bardzo
subtelne. Zazwyczaj ugruntowanie wystarcza do wyrażenia tego jak połączyć komponenty
występujące w wiadomości.
3) Pojedyncze i proste procesy
Formalizacja klas procesów jest następująca:
<owl:Class rdf:ID="Process">
<rdfs:comment> The most general class of processes </rdfs:comment>
<owl:Class rdf:about="#AtomicProcess"/>
<owl:Class rdf:about="#SimpleProcess"/>
<owl:Class rdf:about="#CompositeProcess"/>
</owl:unionOf>
</owl:Class>
Istnieją procesy pojedyncze, złożone oraz niewymieniane dotąd procesy proste.
Pojedyncze procesy połączone z akcjami usług mogą być zastosowane do pojedynczej
interakcji. Złożone procesy korespondują z akcjami usług wymagających wielokrokowych
protokołów i różnorodnych działań serwera. Proste procesy zapewniają abstrakcyjny
mechanizm dostarczający różnorodnych widoków tego samego procesu.
• Pojedyncze
procesy
są
bezpośrednio
wywoływalne
(przez
wymienianie
odpowiedniej wiadomości). Nie mają podprocesów i wykonują jeden krok. Oznacza
to, że pobierają wiadomość wejściową, wykonują akcję i zwracają wiadomość
wyjściową. Dla każdego pojedynczego procesu musi być zapewniona konstrukcja
wiadomości. W pojedynczym procesie są zawsze tylko dwaj uczestnicy TheClient i
TheServer.
<owl:Class rdf:ID="AtomicProcess">
<owl:subClassOf rdf:resource="#Process"/>
</owl:Class>
• Proste procesy są niewywoływalne i nieskojarzone z gruntowaniem, ale tak jak
pojedyncze procesy mają jednokrokowe wykonanie. Są używane jako elementy
abstrakcji; taki proces może być wykorzystany albo jako widok (specyficzny sposób
użycia) pewnego pojedynczego procesu albo jako uproszczona reprezentacja
złożonego procesu (głównie dla celów wnioskowania). W pierwszym przypadku
prosty proces jest realizowany przez pojedynczy proces (realizedBy), w drugim
przypadku prosty proces rozszerza się do złożonego procesu (expandsTo).
Przykład:
<owl:Class rdf:ID="SimpleProcess">
<rdfs:subClassOf rdf:resource="#Process"/>
<owl:disjointWith rdf:resource="#AtomicProcess"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="realizedBy">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#AtomicProcess"/>
<owl:inverseOf rdf:resource="#realizes"/>
<owl:ObjectProperty rdf:ID="realizes">
<rdfs:domain rdf:resource="#AtomicProcess"/>
<rdfs:range rdf:resource="#SimpleProcess"/>
<owl:inverseOf rdf:resource="#realizedBy"/>
4) Złożone procesy
Złożone procesy są rozkładalne na inne (niezłożone lub też złożone) procesy. Ich
dekompozycja odbywa się za pomocą konstrukcji sterujących takich jak Sequence czy IfThen-Else. Ponieważ wiele takich konstrukcji ma nazwy przypominające struktury
sterujące w językach programowania, łatwo można zgubić fundamentalną różnicę:
złożony proces nie jest działaniem jakie wykonuje usługa, ale działaniem jakie może
wykonać klient wysyłając i otrzymując z powrotem serię wiadomości. Jeżeli złożony
proces ma kompletny efekt, klient musi również wykonać całkowity proces aby ten efekt
osiągnąć (oznacza to na przykład, że jeżeli proces jest sekwencją pewnych czynności, to
klient musi wysłać serię wiadomości wywołujących poszczególne kroki).
Kluczowym elementem złożonego procesu jest określenie w jaki sposób akceptowane są
dane wejściowe przez poszczególne podprocesy oraz w jaki sposób przekazywane są
przez nie dane wyjściowe. Ponadto istotnym elementem jest fakt, że każdy złożony
proces musi mieć dokładnie jedną właściwość composedOf, poprzez którą wskazywana
jest konstrukcja sterująca procesem dekompozycji (ControlConstruct).
<owl:ObjectProperty rdf:ID="composedOf">
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
Każda konstrukcja sterująca skojarzona jest z dodatkową właściwością components
wskazującą konstrukcje sterujące, z których ta jest zbudowana i w niektórych
przypadkach również ich kolejność.
<owl:ObjectProperty rdf:ID="components">
<rdfs:domain rdf:resource="#ControlConstruct"/>
Na przykład każda instancja konstrukcji sterującej Sequence ma właściwość components
obejmująca zakres listy konstrukcji sterujących ControlConstructList.
Każdy złożony proces może być rozważany jako drzewo, którego węzły są oznaczone
konstrukcjami sterującymi, z których każda ma „dzieci” wyrażone przez components.
Liście drzewa są wywołaniem procesu, oznaczono je jako instancje klasy Perform.
Właściwość process wskazuje proces do wykonania.
<owl:Class rdf:ID="Perform">
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#process"/>
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">
1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Kiedy dany proces jest wykonywany jako krok większego procesu, to wówczas musi
istnieć opis skąd pochodzą dane wejściowe i dokąd wychodzą dane wyjściowe. Proces
może być przeglądany na różnych poziomach rozdrobnienia, albo jako prymitywny,
nierozkładalny proces albo jako proces złożony. Można to porównać odpowiednio do
„czarnego pudełka” i „szklanego pudełka”, każda perspektywa może być użyteczna w
zależności od danego przypadku. Jeżeli złożony proces jest przeglądany jako czarne
pudełko, reprezentujący go prosty proces jest połączony z nim relacją określoną za
pomocą właściwości expandsTo, jej właściwość odwrotna to collapsesTo.
<owl:ObjectProperty rdf:ID="expandsTo">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#CompositeProcess"/>
<owl:inverseOf rdf:resource="#collapsesTo"/>
<owl:ObjectProperty rdf:ID="collapsesTo">
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="#SimpleProcess"/>
<owl:inverseOf rdf:resource="#expandsTo"/>
Zestawienie konstrukcji sterujących OWL-S: Sequence, Split, Split + Join, Choice, AnyOrder, Condition, If-Then-Else, Iterate, Repeat-While, Repeat-Until:
• Sequence jest listą konstrukcji sterujących do wykonania w danym porządku,
• Split jest zbiorem komponentów procesu aktualnie przeznaczonego do wykonania,
kończy działanie kiedy tylko wszystkie komponenty zostaną przeznaczone do
wykonania,
• Split + Join zawiera grupę procesów aktualnie wykonywanych z barierą
synchronizacyjną,
kończy
działanie
kiedy
wszystkie komponenty
zakończą
działanie, definiuje procesy mające częściową synchronizację,
• Choice oznacza wykonanie pojedynczej konstrukcji sterującej z określonego zbioru,
wykonana może zostać dowolna konstrukcja,
• Any-Order pozwala na wykonanie komponentów procesu w nieokreślonej
kolejności, jednak nie jednocześnie, wymagane jest wykonanie i zakończenie
wszystkich elementów, wykonanie procesów nie może się pokrywać w czasie, tzn.
pojedyncze procesy nie mogą być wykonywane jednocześnie a złożone nie mogą
być przerywane innymi,
• If-Then-Else
jest konstrukcją mającą właściwości ifCondition, then, else
oznaczające jej różne aspekty, jej semantyka to „sprawdź ifCondition, jeśli
prawdziwy to wykonaj then, jeśli fałszywy to zrób else ”,
• Iterate jest konstrukcją iteracyjną, nie zakłada ile iteracji jest do wykonania ani kiedy
zainicjować iteracje, skończyć lub wznowić, te warunki określane są za pomocą
whileCondition lub untilCondition,
• Repeat-While sprawdza zadany warunek i wykonuje iterację zataczając pętlę jeśli
jest on prawdziwy, natomiast kończy działanie gdy warunek stanie się fałszywy,
może nie wykonać ani jednej iteracji gdy warunek na samym początku jest fałszywy,
• Repeat-Until wykonuje iterację, sprawdza warunek, kończy działanie jeśli jest on
prawdziwy, w przeciwnym razie wykonuje pętlę, zawsze wykona co najmniej jedną
iterację.
5) Specyfikacja przepływu danych i powiązań parametrów
Definiując procesy w OWL-S jest wiele miejsc, gdzie uzyskiwane są dane wejściowe do
komponentów procesu jako jedna z danych wyjściowych poprzedniego kroku. Jest to
jeden z typów przepływu danych od jednego kroku procesu do kolejnego. Są też inne
wzory: w szczególności dane wyjściowe złożonego procesu mogą pochodzić z danych
wyjściowych niektórych jego komponentów.
Ilustracja przepływu danych:
I1 input of: { Composite Process CP }: with output O1
composed of
Step 1: Perform S1 ⇒
Step 2: Perform S2
where S1 has inputs I11 and I12, and output O11
and S2 has input I21 and output O21
Strzałka w prawo za S1 oznacza, że krok drugi jest wykonywany po kroku pierwszym, ale
niekoniecznie natychmiast. I1 są danymi wejściowymi dla całego procesu i używane są
jako I11 dla kroku S1, dane wejściowe I12 dla S1 są stałe. Dane wyjściowe O11 kroku S1
są danymi wejściowymi dla I21 dla kroku S2. Dane wyjściowe O21 kroku S2 są danymi
wyjściowymi całego procesu. Deklaracja odpowiednich parametrów jest następująca:
I11(Step1) comes from incr(I1(CP))
I12(Step1) = "Academic"
I21(Step2) comes from O11(Step1)
O1(CP) comes from π × max 0, O21(Step2))
Każda z powyższych równości jest reprezentowana w OWL-S jako abstrakcyjny obiekt
Binding z dwoma właściwościami toParam (nazwa parametru) oraz valueSpecifier (opis
wartości parametru). Definiuje się cztery typy zapewniające specyfikację wartości w
sposób tak zwięzły jak to możliwe w zależności od sytuacji: valueType, valueData i
valueFunction.
• valueSource jest najprostszym rodzajem przepływu danych, jego zasięgiem jest
obiekt klasy ValueOf określony całkowicie przez swoje właściwości theVar i
fromProcess.
• valueFunction jest to XML literal używany jako termin funkcjonalny. Oznaczenie
tego wyrażenia nie może być znane dopóki zmienne nie są podłączone.
• valueData jest to XML literal interpretowany jako stała dana.
• valueType jest URI odnoszącym się do definicji klasy C w OWL. Instancja
valueType zapewnia, że wartość danego parametru będzie należeć do klasy C. C
musi być podklasą parametrów wszystkich typów zadeklarowanych przez
parameterType.
Istnieje nowa klasa Produce używana do obejmowania przepływu danych do danych
wyjściowych ParentPerform. Dane wyjściowe nie mogą być zadeklarowane raz na
zawsze, ponieważ w obecności IfThenElse te dane wyjściowe będą zależeć od
warunkowej gałęzi wybranej przez agenta. Na końcu gałęzi, gdzie znane są dane
wymagane do obliczenia danych wyjściowych, wkładamy Produce pseudo-krok do
określenia danych wyjściowych.
<owl:Class rdf:ID="Produce">
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
</owl:Class>
<owl:Property rdf:ID="producedBinding">
<rdfs:domain rdf:resource="#Produce"/>
<rdfs:range rdf:resource="#OutputBinding"/>
</owl:Property>
2.15. Relacje z innymi specyfikacjami
Ugruntowanie („grounding”) jest przygotowaniem najważniejszych elementów do wykonania
konkretnej usługi. Podstawy determinujące realizację usługi to przede wszystkim szczegóły
dotyczące dostępu do usługi, mające głównie do czynienia z formatem protokołu i
wiadomości, publikacją, transportem i adresowaniem. Ugruntowanie może być uważane za
mapowanie z abstrakcyjnej do konkretnej specyfikacji elementów opisów usług, które są
przeznaczone do interakcji z usługą, w szczególności dla naszego celu dane wejściowe i
wyjściowe pojedynczego procesu. W OWL-S zarówno ServiceProfile jak i ServiceModel są
uważane za abstrakcyjną reprezentację, jedynie ServiceGrounding odnosi się do
rzeczywistego poziomu specyfikacji.
Ugruntowanie usługi zapewnia informacje o dostępie do usługi, wraz z modelem usługi
gwarantuje wszystko, co potrzebne do użycia usługi, natomiast wraz z WSDL definiuje
strukturę wiadomości i fizyczne warstwy wiążące. Ponadto określa protokoły i języki
komunikacji oraz mechanizm transportu.
OWL-S nie zawiera abstrakcyjnej konstrukcji do opisywania wiadomości. Abstrakcyjna
zawartość wiadomości jest specyfikowana za pomocą właściwości wejściowych lub
wyjściowych niektórych pojedynczych procesów. W ten sposób pojedyncze procesy oprócz
określania pojedynczych akcji złożonych procesów są również komunikacyjnymi jednostkami
abstrakcyjnej specyfikacji.
Ugruntowanie określa jak dana usługa jest używana, to znaczy wymienia szczegóły w jaki
sposób komputerowy program lub agent może dostać się do usługi. Zazwyczaj określa
dobrze znane komunikacyjne protokoły, szczegóły charakterystyczne dla usługi, takie jak
numer
portu
oraz
jednoznaczne
środki
wymiany
danych
typów
wymaganych
i
produkowanych przez usługę. Podejście domyślnego ugruntowania zapewniane przez OWLS polega na mechanizmach specyfikacji zapewnianych prze WSDL, podczas gdy w tym
samym czasie wykorzystanie bogatszych opisów jest możliwe dzięki użyciu języka OWL.
Konkretne wiadomości są bezpośrednio specyfikowane w ugruntowywaniu usługi. Centralna
funkcja ugruntowywania w OWL-S pokazuje jak abstrakcyjne są dane wejściowe i wyjściowe
pojedynczych procesów przeznaczonych do realizacji jako wiadomości, które przenoszą te
dane w odpowiednim do transportu formacie. W skutek istnienia znaczącej części pracy w
obszarze specyfikacji konkretnych wiadomości zdecydowano się na wykorzystanie WSDL
(Web
Services
Description
Language)
w
tworzeniu
wstępnego
mechanizmu
ugruntowującego dla OWL-S.
WSDL jest formatem XML do opisu siatek usług jako zbiorów punktów końcowych,
działających na wiadomościach zawierających informację zorientowaną albo na dokumenty
albo na procedury. Operacje i wiadomości są opisywane abstrakcyjnie i potem łączone w
konkretne siatki protokołów i wiadomości do zdefiniowania punktu końcowego. Pojęcie
ugruntowania w OWL-S jest zgodne z pojęciem łączenia WSDL. Używając zapewnianych
przez WSDL elementów razem z nowym elementem zaproponowanym przez OWL-S
uzyskujemy prosty sposób na ugruntowanie pojedynczego procesu.
1) Relacje między OWL-S a WSDL
Podejście tutaj opisane pozwala dostarczającemu usługę na czerpanie korzyści z
wzajemnie
uzupełniających
się
sił
obu
języków
specyfikacji.
Z
jednej
strony
(abstrakcyjnej) wykorzystywane jest modelowanie procesów OWL-S wraz z wyrazistością
klas OWL związanych z tym, co dostarczają definicje XML Schema. Z drugiej strony
(konkretnej) korzysta się z możliwości ponownego wykorzystania rozległej pracy zrobionej
w WSDL (i powiązanymi językami takimi jak SOAP) oraz z wsparcia oprogramowania dla
wymiany wiadomości bazujących na tych deklaracjach.
Rysunek 3 Relacje OWL-S i WSDL
Ugruntowywanie OWL-S/WSDL zawiera wzajemnie uzupełniające się wykorzystanie
dwóch języków w sposób zgodny z intencjami autorów. Do pełnej specyfikacji wymagane
są oba języki, ponieważ odpowiadają różnym pojęciowym przestrzeniom. Oba języki
pokrywają się w zapewnieniu specyfikacji tego, co WSDL nazywa „abstrakcyjnymi
typami”, które są używane do charakteryzowania danych wejściowych i wyjściowych
usługi. WSDL definiuje abstrakcyjne typy używając XML Schema podczas gdy OWL-S
pozwala na ich definicję jako klas OWL. Jednak WSDL/XSD nie jest zdolny do wyrażenia
semantyki klas OWL. Podobnie OWL-S nie jest w stanie łączyć informacji w sposób jaki
robi to WSDL. Zatem naturalnym jest, że OWL-S/WSDL używa klas OWL jako
abstrakcyjnych typów części wiadomości zadeklarowanych w WSDL, a potem stosuje
konstrukcje łączenia WSDL do określenia formatu wiadomości.
Ugruntowywanie OWL-S/WSDL bazuje na następujących trzech korespondujących ze
sobą aspektach:
• Pojedynczy proces OWL-S koresponduje z operacjami WSDL. Różne typy operacji
są związane z procesami w następujący sposób:
pojedynczy proces z danymi wejściowymi i wyjściowymi odpowiada operacji
request-response,
pojedynczy proces z danymi wejściowymi ale bez danych wyjściowych
odpowiada operacji one-way,
pojedynczy proces z danymi wyjściowymi ale bez danych wejściowych
odpowiada operacji notification,
złożony proces z danymi wejściowymi i wyjściowymi z przesyłaniem danych
wejściowych
określanych
jako
przychodzące
przed
odebraniem
danych
wyjściowych odpowiada operacji solicit-response.
OWL-S pozwala na korespondencję jeden do wielu między pojedynczymi
procesami a złożonymi operacjami. Można również wyrażać sytuacje jeden do
jeden przez wykorzystanie różnie nazwanych pojedynczych procesów.
•
Każdy zbiór danych wejściowych i zbiór danych wyjściowych pojedynczych
procesów koresponduje z pojęciem wiadomości WSDL.
•
Typy (klasy OWL) danych wejściowych i wyjściowych pojedynczych procesów
korespondują z pojęciami abstrakcyjnych typów WSDL
2) Ugruntowywanie usług OWL-S z WSDL i SOAP
Ponieważ OWL-S jest językiem bazującym na XML a jego deklaracje pojedynczych
procesów, dane wejściowe i wyjściowe znakomicie pasują do WSDL łatwo jest rozszerzyć
istniejące połączenia WSDL dla użycia z OWL-S, takie jak oprawa SOAP.
a) Specyfikacja WSDL
Ugruntowywanie OWL-S z WSDL i SOAP zawiera konstrukcje opisów usług z jej
wszystkimi normalnymi częściami (types, message, operation, port type, binding, service
constructs).
Biorąc pod uwagę typy wiadomości WSDL należy rozróżnić dwa przypadki: taki, w którym
mamy do czynienia z typem OWL i pozostałe. W pierwszym z nich klasa OWL może być
zdefiniowana w sekcji typów WSDL lub w osobnym dokumencie, do którego istnieje
referencja.
Rozszerzenia OWL-S:
• W części definicji wiadomości WSDL atrybut owl-s-parameter może być użyty do
wskazania w pełni kwalifikowanej nazwy obiektu danych wejściowych lub
wyjściowych
(instancje
klasy
Parameter),
z
którą
ta
część
wiadomości
koresponduje. Atrybut ten jest użyteczny przypadkach, w których typ części
wiadomości jest typem OWL (i nie był zdefiniowany w sekcji type WSDL) Wówczas
definicja typu OWL może być otrzymywana ze specyfikacji procesu OWL-S przez
kontrolowanie właściwości parameterType obiektów wejściowych i wyjściowych, do
których jest odniesienie.
• W tych przypadkach, w których część wiadomości używa typu OWL, atrybut
encodingStyle wewnątrz łączenia elementów WSDL może mieć daną wartość taką
jak ``http://www.w3.org/2002/07/owl'' do wskazania, że część wiadomości będzie
podzielona w normalny sposób na instancje klas danych typów.
• W każdym elemencie operacji WSDL atrybut owl-s-process może być użyty do
wskazania nazwy pojedynczego procesu, z którym operacja koresponduje.
Warto zauważyć, że WSDL pozwala na użycie dowolnych nowych atrybutów w
elementach części widomości oraz na użycie dowolnych wartości atrybutu encodingStyle.
b) Klasa Grounding OWL-S
Definicje WSDL mogą odnosić się do korespondujących deklaracji OWL-S. Powstaje
mechanizm, który w OWL-S wskazuje odpowiednie konstrukcje WSDL. Klasa OWL-S
WsdlGrounding podklasa klasy Grounding służy do tego celu. Każda jej instancja zawiera
listę instancji WsdlAtomicProcessGrounding, które odnoszą się do określonych
elementów wewnątrz specyfikacji WSDL za pomocą następujących właściwości:
• wsdlVersion URI wskazujący używaną wersję WSDL,
• wsdlDocument – URI dokumentu WSDL, którego dotyczy ugruntowywanie,
• wsdlOperation – URI operacji WSDL korespondującej z danym pojedynczym
procesem,
• wsdlService, wsdlPort (opcjonalnie) – URI usługi lub portu WSDL oferującego dane
operacje,
• wsdlInputMessage – obiekt zawierający URI definicji wiadomości WSDL trzymającej
dane wejściowe pojedynczego procesu,
• wsdlInput – obiekt zawierający pary mapowania dla części wiadomości danych
wejściowych; każda taka para jest reprezentowana przy użyciu instancji klasy
WsdlInputMessageMap, mapowanie par dla danych wejściowych pojedynczego
procesu
• wsdlOutputMessage - obiekt zawierający URI definicji wiadomości WSDL
trzymającej dane wyjściowe danego pojedynczego procesu,
• wsdlOutput - obiekt zawierający pary mapowania dla części wiadomości danych
wyjściowych, mapowanie par dla danych wyjściowych pojedynczego procesu, który
jest reprezentowany przez instancje WsdlOutputMessageMap.
Usługa
Wersja
Ugruntowanie
usługi
Dokument
Wiadomość
wyjściowa
Wiadomość
wejściowa
Operacja
Mapowanie wiadomości
wyjściowej
Mapowanie wiadomości
wejściowej
Dane
wyjściowe
Parametr XSLT
Dane
wejściowe
Parametr XSLT
Rysunek 4 Elementy ugruntowania
3) Implementacja i wywołanie usług sieciowych
Aby można było wykorzystać ontologie usług sieciowych niezbędne są relacje OWL-S ze
standardami interoperacyjności technicznej oraz konwerterami poszczególnych języków.
Możliwe są interakcje OWL-S z następującymi narzędziami:
• Mapowanie WSDL do OWL-S: wykorzystanie relacji między WSDL a OWL-S w celu
stworzenia specyfikacji OWL-S. Zapewnione są następujące elementy:
o automatyczne generowanie ugruntowania,
o częściowe generowanie modelu procesu i profilu.
• UDDI jest formalnym rejestrem dla usług sieciowych, z którym współpracuje OWL-S,
dzięki czemu zapewnione jest
o wyszukiwanie słów kluczowych usług sieciowych.
Nie ma jednak wyszukiwania możliwości (jest niemożliwe znalezieni usługi sieciowej,
która robi…).
• OWL-S bazuje na BPEL4WS15 (wiodących ramach choreografii) w celu objęcia
reprezentacji i wnioskowania z sieci semantycznej przez usługi sieciowe oraz
15
Por. szerzej Dokument D1.2.1 WKUP
rozpoznawania wpływu standardów przemysłowych i maszynerii na semantyczne
usługi sieciowe. Funkcje i właściwości BPEL4WS (Business Process Execution
Language for Web Services):
o deklaratywna
specyfikacja
przepływu
pracy
lub
procesów
biznesowych
z
wykorzystaniem graficznego edytora,
o procesy łączone są z technicznymi instalacjami,
o powyższe elementy mogą być wykorzystywane przez różne logiki procesów,
o główna część BPEL4WS to język definicji procesów,
o brak semantyki i przede wszystkim bogatych semantycznych adnotacji.
• OWL-S Broker zajmuje się wykrywaniem i mediacją dla klienta, publikuje wstępny
model procesu, podczas interakcji komunikuje nowy model procesu.
• OWL-S Virtual Machine16 jest procesorem dla modelu procesów OWL-S, zapewnia
automatyczną inwokację usług sieciowych.
o Wchodzi w interakcję z dowolną usługą sieciową OWL-S.
o Bazuje na formalnej semantyce modelu procesu.
o Wykorzystuje technologię usług sieciowych, taką jak Axis, WSIF.
o Może być wykorzystywany do automatycznej inwokacji usług sieciowych:
dostosowuje się do semantyk OWL-S,
bazuje na narzędziach wnioskujących OWL.
o Zapewnia komunikację z innymi usługami sieciowymi.
• WSDL2OWL-S17 jest konwerterem zapewniającym translację między WSDL a OWL-S.
Efektem translacji jest kompletna specyfikacja ugruntowania oraz częściowa
specyfikacja modelu procesu i profilu. Niekompletność specyfikacji jest wynikiem różnic
informacji zawartych w WSDL i OWL-S. W szczególności WSDL nie zapewnia
informacji i kompozycji procesu, zatem wynik translacji również nie będzie zawierać tej
informacji. Ponadto WSDL nie zapewnia opisu możliwości, tak więc profil OWL-S
wygenerowany z WSDL jest jedynie zarysem i musi zostać manualnie uzupełniony.
Mimo to dane wyjściowe WSDL2OWL-S zapewniają bazową strukturę opisu OWL-S
usługi sieciowej i zaoszczędzają dużą ilość pracy.
• Java2OWL-S18 jest konwerterem zapewniającym częściową translację między plikami
napisanymi w kodzie języka Java a specyfikacją OWL-S 1.1. Rezultaty tej translacji
stanowią kompletną specyfikację ugruntowania, częściową specyfikację modelu
procesu i profilu, oraz plik klas OWL, kiedy przynajmniej jeden z argumentów metody
16
Por. szerzej http://www.w3.org/2004/08/ws-cc/dmowls-20040904#search=%22%E2%80%A2%20OWL-
S%20Virtual%20Machine%22
17
18
Por. http://projects.semwebcentral.org/projects/wsdl2owl-s/; http://java2owl-s.projects.semwebcentral.org/
Por. http://java2owl-s.projects.semwebcentral.org/
klas Java jest klasą zdefiniowaną przez użytkownika. To narzędzie rozszerza
konwerter WSDL2OWL-S. Zamiast pobierania pliku WSDL jako danych wejściowych
pobiera plik Java i konwertuje na WSDL, a następnie taki plik dostaje się do
konwertera WSDL2OWL-S.
• OWL-S 2 UDDI19 konwertuje opis profilu OWL-S do korespondujących ogłoszeń UDDI,
które mogą być publikowane w rejestrze UDDI. Ten konwerter jest częścią rejestru
OWL-S/UDDI, który usprawnia rejestr UDDI o funkcjonalność łączenia OWL-S.
• Matchmaker Client jest wykorzystywany do interakcji z OWL-S/UDDI Matchmaker.
• OWL-S API20 konwertuje opis OWL-S na obiekty Java.
• OWL-S IDE21 jest środowiskiem rozwoju wspierającym semantyczne usługi sieciowe
poprzez pełne procedury z Javy do kompilacji opisów OWL-S oraz rozmieszczenia i
rejestracji z UDDI. Proces rozwoju sieci semantycznej pochłania czas i wiąże się z
powstawaniem błędów i obecnie jest dostępnych tylko kilka narzędzi wspierających
konstruktorów, które nie tworzą stałego zestawu. Stąd konstruktorzy muszą zmieniać
narzędzia w czasie procesu rozwoju. Dlatego ważne jest zapewnienie integracji między
różnymi środowiskami rozwoju.
• WSDF22 (Web Service Description Framework) to ramy pozwalające na dokładny opis
usług sieciowych, pozwalających na:
o adnotacje semantyczne usług sieciowych,
o wywoływanie usługi „ad-hoc” bez wcześniejszej wiedzy o API,
o formalną specyfikację semantyki usług integrującą się z używanymi strukturami
danych,
o powyższa funkcja umożliwia z kolei wiele zadań, np.:
podejmowanie decyzji o przywoływaniu usługi,
aktualne wytwarzanie wymaganych parametrów,
automatyczne dostarczanie rezultatów do modelu danych klienta,
o WSDF jest umieszczony warstwowo na szczycie dobrze rozwiniętego standardu
WSDL i rozszerzany tak, aby pasował do oprogramowania klienta w językach
obiektowych.
19
20
21
22
Por. http://www.cs.cmu.edu/~softagents/papers/swswpc-04.pdf#search=%22OWL-S%202%20UDDI%22
Por. http://www.mindswap.org/2004/owl-s/api/
Por. http://projects.semwebcentral.org/projects/owl-s-ide/
Por. http://www.aifb.uni-karlsruhe.de/WBS/aeb/wsdf/
Rysunek 5 Przykład architektury systemowej opartej na WSDF w połączeniu z WSDL i RDF
Java2WSDL
konwerter
Kod Java
WSDL2OWL-S
konwerter
Plik WSDL
Pliki OWL-S
Uzupełnianie
brakujących
informacji
OWL-S/UDDI
Matchmaker client
OWL-S Editor
Rejestr
OWL-S/UDDI
AXIS
implementacja
Wykonanie
usługi
OWL-S Verifier
OWL-S Editor
Rysunek 6 Ogólny schemat działania OWL-S [1]
Matchmaker
Client
Narzędzie
OWL-S Matching
J-UDDI
UDDI
Konwerter
OWL-S2UDDI
Edytor OWL-S
Kod Java
OWL-S Broker
eclipse
Ontologie OWL
Konwerter
Java2WSDL
WSDL
Profil
Konwerter
WSDL2OWL-S
proces
Ugruntowanie
Pliki OWL-S
Narzędzia CMU
Pliki danych
Narzędzia trzeciej części
Rysunek 7 Ogólny schemat działania OWL-S [2]
OWL-S VM
OWL-S API
Usługa sieciowa
SOAP
OWL-S VM
OWL-S opis
Wywołanie usługi
usługi
Usługa sieciowa Axisa
Inwokacja usług OWL-S
WSDL
WSDL
OWL-S
grounding
OWL-S procesor
Ugruntowanie
Model procesu
Narzędzia
wnioskujące OWL
OWL-S
model
procesu
OWLS Jess KB
System
wnioskowania
Reguły interakcji
Agent KB
Rozwiązywanie
problemów
Jess
Jena
Rysunek 8 Model wirtualnej maszyny OWL-S
Wirtualna maszyna implementuje ogólny cel klienta usługi sieciowej, który polega na
modelowaniu procesu OWL-S i ugruntowaniu do automatyzacji interakcji między usługami
sieciowymi przy minimalizacji interwencji człowieka. Architektura wirtualnej maszyny
składa się z trzech elementów:
• dane wejściowe (model procesu, ugruntowanie, opis WSDL),
• właściwa maszyna,
• system wnioskowania.
Sposób działania
Po otrzymaniu modelu procesu i ugruntowaniu usługi maszyna wirtualna aktywizuje
procesor OWL-S, który implementuje semantyki OWL-S i OWL do kontroli interakcji usługi
poprzez wykonanie modelu procesu. Ponadto opis WSDL usługi jest wykorzystywany do
parametryzacji modułu inwokacji, który przekazuje informacje między wirtualną maszyną
a usługą. W każdym momencie kiedy model procesu wymaga wymiany informacji między
klientem a usługą, procesor OWL-S prosi system wnioskujący o zawartość wiadomości do
wysłania oraz moduł wywołania usługi o wysłanie wiadomości.
Maszyna wirtualna OWL-S została zaimplementowana i przetestowana. Aktualnie jest
rozszerzana
o
elementy
autoryzacji
i
ochrony
prywatności. Wykorzystuje
ona
semantyczne adnotacje w korespondujących modelach procesów do wymuszenia
ograniczeń
prywatności
i
autoryzacji,
które
mogą
być
zaimplementowane.
Wykorzystywane są adnotacje bezpieczeństwa SOAP do implementacji właściwego
szyfrowania wiadomości. Zatem usługi sieciowe OWL-S gwarantują zachowanie
bezpiecznej komunikacji ze swoimi partnerami.
Informacja zapewniana przez OWL-S jest zapisana w sposób interpretowalny przez
komputery i zawiera ontologiczny opis wymaganych przez usługę danych wejściowych,
gwarantowanych danych wyjściowych oraz warunki wstępne i końcowe każdego
wywołania.
OWL-S oprócz opisu usług i wirtualnej maszyny zawiera również dodatkowo OWL-S
Matchmaker. OWL-S Matchmaker działa jak katalog usług zdefiniowanych przez OWL-S.
Opisy usług OWL-S są rejestrowane przez matchmakera, który dostarcza opisy zbioru
usług zawierające informacje o wymaganej funkcjonalności (czyli bierze pod uwagę tylko
usługi mogące wykonać żądane zadanie). Aplikacje klienta zadają mu zapytanie wraz z
opisem danych wejściowych i wyjściowych, których żądają. Matchmaker komponuje
odpowiedź w zależności od katalogu usług i zwraca ją w postaci listy najbardziej
pasujących do zapytania klienta usług. Następnie aplikacja klienta wykorzystuje wirtualną
maszynę OWL-S do właściwego wywołania usług. Aplikacja klienta formułuje zapytanie za
pomocą formatu określonego przez ontologie OWL danych wejściowych i wysyła
zapytanie do wirtualnej maszyny. Usługi są mapowane do właściwej usługi sieciowej jaką
reprezentują dzięki ugruntowaniu OWL-S. Używają transformacji XSLT obecnej w
ugruntowaniu, maszyna wirtualna przeformatowuje zapytanie aby było zgodne z formatem
wymaganym przez usługę i wywołuje usługę w imieniu klienta. Kiedy maszyna otrzyma
odpowiedź formułuje kolejną transformację XSLT i przeformatowuje usługę do formatu
zgodnego z ontologią danych wyjściowych i zwraca ją aplikacji klienta. W ten sposób
aplikacja klienta nie potrzebuje wiedzieć jak wchodzić w interakcję z właściwą usługą
sieciową. Zatem wirtualna maszyna działa jako mediator zapytania.
W celu wywołania usługi aplikacja klienta musi mieć dostęp do danych oraz musi umieć je
formatować w odpowiednim formacie OWL przed zapytaniem o usługę. Najlepiej jest gdy
to zadanie wykonywane jest automatycznie, w taki sposób, że aplikacja jest świadoma
danych, do których ma dostęp oraz ich ontologicznego znaczenia. Jeśli jest to wykonane
prawidłowo
aplikacja
będzie
umiała
udostępnić
usługi
niedostępne
przed
przeformatowaniem zapytania. Ponadto dzięki planowaniu bazującemu na celach proste
usługi mogą być w przelocie komponowane w bardziej złożone sekwencje usług.
Ważnym elementem jest architektura zorientowana na usługi (SOA), która zapewnia inne
spojrzenie na rozwój oprogramowania i tradycyjne zorientowanie na aplikacje metody.
Zamiast tworzenia wielu monolitowych, pojedynczych aplikacji, które wykonują konkretne
zadania od początku do końca, SOA buduje dynamiczne środowisko usług zapewniające
wsparcie dla bardziej ziarnistych zadań. W ten sposób dostawcy usług mogą tworzyć
proste aplikacje czerpiące korzyści z usług w nowy sposób. To redukuje dublowanie się
aplikacji i upraszcza modyfikowanie wewnętrznego zachowania usług bez wpływu na
aplikacje.
Jednak w środowisku SOA usługi są ciągle dodawane i usuwane, co może powodować
utratę kontroli nad używanymi aplikacjami spowodowaną zmianami środowiska, w którym
następuje wymiana usług. Istniejące ramy zorientowane na usługi nie chronią aplikacji
przed tymi ewentualnościami.
Dynamiczne odkrywanie usług i ich komponowanie jest jednym z możliwych rozwiązań
tego problemu. Pozwalając aplikacjom na odkrywanie nowych usług w oparciu o
wymaganą funkcjonalność, nie są one dłużej ograniczone do konkretnych usług czy
interfejsów, do pracy z którymi zostały oryginalnie przeznaczone. Kiedy pojawiają się
nowe usługi są one automatycznie wykrywane i przygotowywane do udostępniania, nawet
gdy są zupełnie inne. Dynamiczna kompozycja pozwala aplikacjom na automatyczną
kompozycję różnych usług w oparciu o planowanie do osiągnięcia celów zamiast
zwykłego podążania za zdefiniowanym wcześniej procesem.
2.16. Zastosowania
OWL-S jest specyfikacją bliską zakończenia. Pozostało kilka elementów wymagających
poprawy i udoskonalenia; są to:
• brakujący wciąż mechanizm obsługi wyjątków,
• wykonawcza instrukcja dynamicznego ładowania i wykonywania modeli procesów.
Istnieją też elementy, których OWL-S nie uwzględnia wcale, a pojawienie się ich w
specyfikacji przyniosłoby dodatkowe, cenne rezultaty. Do brakujących elementów należą
bezpośrednie wyrażenie środków ochrony i zabezpieczeń oraz zarządzanie usługami
sieciowymi.
Rodzina specyfikacji WSMO
Na rodzinę specyfikacji WSMO23 służącą do modelowania ontologii usług sieciowych
składają się trzy podstawowe elementy. WSMO, czyli ontologie modelujące usługi sieciowe,
WSML24, czyli język opisujący i specyfikujący te ontologie oraz środowisko modelowania
usług sieciowych WSMX25.
WSMO jest rozszerzeniem i ulepszeniem WSMF (Web Service Modeling Framework)
powstałym w celu rozwoju formalnych ontologii oraz odpowiedniego do ich tworzenia języka.
WSMF26 to obecnie w pełni rozwinięte ramy modelowania usług sieciowych, stworzone w
celu zapewnienia odpowiednich środków do ich opisu. WSMF zapewnia model pojęciowy
usług sieciowych do ich rozwoju, opisu oraz kompozycji złożonych usług sieciowych. WSMF
postępuje za ścieżką wytyczoną wcześniej przez języki opisując złożone usługi sieciowe,
takie jak DAML-S czy WSFL27 i jest całkowicie rozwinięty do opisywania różnych aspektów
związanych z usługami sieciowymi.
W pełni dostępne elektroniczne usługi komercyjne, bazujące na realnych i wykonywalnych
usługach sieciowych wymagają ram modelowania skoncentrowanych wokół dwóch
podstawowych zasad:
• Silna rozłączność różnych komponentów realizujących aplikacje usług elektronicznych.
• Mocna mediacja umożliwiająca wszelką komunikację w skalowalny sposób.
Sieć internetowa jest zorganizowana wokół URI, HTML i HTTP. URI zapewniają
identyfikatory do odwoływania się do poszczególnych elementów sieci, HTML zapewnia
sposób zapisu struktury dokumentów, a HTTP definiuje protokoły do pobierania informacji z
sieci. Usługi sieciowe wymagają podobnej infrastruktury wokół UDDI, WSDL i SOAP. UDDI
zapewnia mechanizm znajdowania usług sieciowych dla klientów, WSDL definiuje usługi jako
końcowe punkty siatki (lub porty), a SOAP to specyfikacja rozkładu wiadomości, definiująca
jednolity sposób przekazywania danych zakodowanych w XML.
23
24
25
26
27
Por. http://www.w3.org/Submission/WSMO/; www.wsmo.org
Por. http://www.w3.org/Submission/WSML/; www.wsmo.org/wsml/
Por. http://www.wsmx.org/
Por. http://www1-c703.uibk.ac.at/~c70385/wese/index.html
Por. http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf
Wymaganych jest kilka kroków, które muszą zostać przedsięwzięte aby w pełni zrealizować
usługi. Wymaga to podejścia Peer-to-Peer. Musi istnieć możliwość komunikacji między
poszczególnymi użytkownikami oraz usługami. Jednak takie otwarte i elastyczne
elektroniczne usługi komercyjne muszą radzić sobie z wieloma trudnościami, zanim staną się
rzeczywistością.
• Potrzebne jest zmechanizowane wsparcie wyszukiwania i porównywania dostawców
usług i ich ofert. Obecnie większość tej pracy jest wykonywana manualnie.
Semantyczna technologia może dostarczyć przetwarzalne przez maszyny semantyki
informacji, pozwalając w ten sposób na mechanizację zadania.
• Potrzebne jest zmechanizowane wsparcie w zajmowaniu się licznymi i różnorodnymi
formatami danych. Potrzebne są ontologie do lepszego definiowania standardów opisu
oraz mapowanie między nimi.
• Niezbędne jest również zmechanizowane wsparcie w zajmowaniu się licznymi i
różnorodnymi logikami biznesowymi. Potrzebna jest mediacja między poszczególnymi
standardami pozwalająca partnerom na sprawną współpracę.
WSMF składa się z czterech głównych elementów:
1) Ontologie zapewniające terminologię używaną przez inne elementy.
Ontologie sklejają razem dwa podstawowe aspekty pozwalające zapewnić pełen potencjał
sieci internetowej:
• definiują formalne semantyki informacji pozwalając na przetwarzanie jej przez
komputery,
• definiują semantyki realnego świata umożliwiające łączenie maszynowo przetwarzalnej
zawartości
ze
znaczeniem
dla
człowieka,
bazujące
na
kompromisowych
terminologiach.
Ontologie WSMF definiują terminologię używaną przez inne komponenty specyfikacji,
umożliwiają ponowne jej wykorzystanie oraz interoperacyjność komponentów odnoszących
się do łączonych terminologii.
2) Repozytoria celów definiujące problemy do rozwiązania przez usługi sieciowe.
Opis celu określa wymagania, jakie może mieć klient poszukujący danej usługi. Specyfikacja
celów składa się z dwóch elementów:
• Warunków wstępnych, opisujących czego oczekuje usługa sieciowa aby zapewnić
swoją funkcjonalność. Na przykład pytanie o najbliższą restaurację włoską ma sens
jedynie wtedy, kiedy użytkownik może określić gdzie znajduje się w danym czasie w
sposób zrozumiały dla maszyny. Natomiast zapytanie o najlepszy hotel wymaga
wcześniejszego określenia co dany użytkownik rozumie pod słowem „najlepszy”.
• Warunków końcowych, opisujących co usługa zwraca w odpowiedzi jako dane
wyjściowe. Odwołując się do powyższych przykładów może zwrócić informacje o
najbliższej restauracji włoskiej albo najlepszym hotelu (zgodnie z wymaganiami
określonymi przez użytkownika).
Specyfikacja celów powinna być oddzielona od właściwego opisu usług ponieważ ta sama
usługa może służyć różnym celom lub konkurencyjne usługi mogą służyć tym samym celom.
Zawsze co najmniej jedna ontologia jest importowana przez specyfikację celów do dalszego
definiowania terminów używanych do opisu. Na przykład relacja najbliższy powinna spełniać
następujące kryteria:
− najbliższy(x) implikuje, że nie istnieje żaden y bliższy niż x, np. bliższy(y,x) jest błędne,
x jest optymalny,
− nieprawda, że bliższy(x,x), bliższy nie jest relacją zwrotną,
− bliższy(x,y) i bliższy(y,z) implikuje bliższy(x,z), tzn. bliższy jest relacją przechodnią,
− bliższy(x,y)
implikuje
nieprawda,
że
bliższy(y,x),
tzn.
bliższy
jest
relacją
przeciwsymetryczną.
− bliższy(x,y) lub bliższy(y,x), relacja bliższy jest częściowo uporządkowana.
Istnieje więcej właściwości, które mogą być wymuszane dla takich relacji. Takie właściwości
determinują ile jest rozwiązań spełniających zadane cele. Ontologie zapewniają możliwe do
ponownego wykorzystania słownictwo z precyzyjnie zdefiniowanymi właściwościami.
Oprogramowanie, które zajmuje się rozwiązaniami (lub ich brakiem) może być bezpiecznie
używane poprzez odnoszenie się do ontologii z precyzyjnie zdefiniowanymi właściwościami
pojęć i relacji. Bez takiej dokładności usługa sieciowa, która zakłada przechodniość danej
relacji może wpaść w nieskończoną pętlę (endless loop), jeśli właściwa relacja nie zapewnia
danej właściwości.
3) Opisy usług sieciowych.
Niektóre języki opisujące usługi sieciowe rozróżniają proste i złożone usługi sieciowe, gdzie
proste usługi to proces: dana wejściowa – dana wyjściowa, a złożone rozkładają ogólny
proces na podzadania, które są mniejszymi usługami. Takie rozróżnienie nie jest poprawne i
może prowadzić do nieporozumień pojęciowych w ramach modelujących usługi. To nie
złożoność usługi, ale jej opisu lub interfejsu powoduje różnice. Złożoność usługi, jak np.
narzędzie logicznego wnioskowania czy interfejs sieciowy, mogą być opisane raczej jako
proste. Otrzymują pewne formuły wejściowe i dostarczają pewien zbiór wniosków.
Usługi sieciowe składają się z różnych elementów. Każda usługa ma nazwę (name) i
identyfikator, odnoszące się tylko do niej. Każda usługa spełnia konkretne cele, zatem
powinna mieć referencje tychże celów (goal reference). Opis usługi zawiera warunki
wstępne (pre-conditions) i warunki końcowe (post-conditions). Warunki wstępne to
elementy, które muszą być prawdziwe dla danych wejściowych, aby usługa mogła być
wykonywana. Warunki końcowe to warunki obowiązujące gdy wykonywana jest złożona
usługa, na przykład definiują pewne ograniczenia na dane wyjściowe. Te warunki mogą być
bezpośrednio lub niebezpośrednio połączone z mediatorami. Taka elastyczność architektury
WSMF ma dwie zalety. Po pierwsze, cele i usługa mogą używać różnych terminologii, po
drugie, usługa może wzmacniać warunki wstępne i osłaniać warunki końcowe celów.
Opis usługi sieciowej zawiera informacje o strukturze danych wejściowych (input data) i
danych wyjściowych (output data). Komponenty, przez które dane są przekazywane do
złożonej usługi to porty wejścia. Dane mogą być przekazywane do portów wejścia od
użytkownika jednocześnie z wykonaniem złożonej usługi. To pozwala na przekazywanie
danych kiedy tylko złożona usługa ich potrzebuje. Analogicznie dane wyjściowe zwracane są
przez porty wyjścia. To pozwala usłudze zwracać dane jednocześnie z wykonaniem usługi.
To z kolei umożliwia udostępnianie użytkownikowi rezultatów tak szybko, jak to możliwe, bez
czekania na zakończenie pracy przez złożoną usługę. Błędy danych mogą być zwracane od
złożonej usługi przez porty błędów w dowolnym czasie w celu wskazania stanu błędów
danych.
Elementy bardziej złożonego opisu interfejsu usługi sieciowej.
• Niepowodzenie (failure). Jeśli nastąpi niepowodzenie (błąd) wewnątrz wywoływanych
elementów, to usługa jest w stanie błędu. Jeżeli usługa nie może naprawić go sama,
informuje o tym użytkownika. Użytkownik zostaje poinformowany, które komponenty
zostały wykonane pomyślnie, a których wykonanie nie powiodło się. Jeśli taka
dekompozycja nie jest możliwa, użytkownik nie ma możliwości dowiedzieć się o tym.
• Równoczesne wykonanie (concurrent execution). Jeśli dana usługa wywołuje inne
usługi, czas realizacji może potrwać dłużej. Użytkownik może jednocześnie wykonywać
inne lokalne czynności aby zoptymalizować zasoby lub ogólny czas wykonania. Model
synchronicznej inwokacji nie funkcjonuje zatem w tym przypadku. Ważnym jest aby
użytkownik wiedział, jak długo może potrwać realizacja usługi.
• Jednoczesne dane wejściowe i wyjściowe (concurrent data input and output). Za
każdym razem wywołania usługi dane wejściowe muszą być zapewnione, a wyjściowe
muszą zostać zwrócone. Może się zdarzyć, że dane wejściowe nie są znane w
momencie wywołania usługi. Oznacza to, że musi istnieć możliwość podania usłudze
danych wejściowych, kiedy jest ona wykonywana.
• Dynamiczne łączenie usług (dynamic service binding). Usługa sieciowa wywołuje
inne usługi. Oznacza to, że kiedy usługa sieciowa jest zaimplementowana, musi zostać
wybrana usługa, która ma zostać wywołana. Użytkownik nie ma możliwości zmiany
usługi i zastąpienia jej swoimi preferencjami.
Usługa sieciowa może wywoływać inne usługi sieciowe w celu zapewnienia ich
funkcjonalności. Dla każdej wywoływanej usługi musi być zadeklarowany „pełnomocnik”
(invoked web service proxy), który może składać się z definicji celów albo z nazwy,
warunków wstępnych i końcowych, portów wejścia i wyjścia oraz połączenia do określania
konkretnej usługi sieciowej w czasie pracy.
Usługa sieciowa przedstawia porty wejścia i wyjścia, „pełnomocnik” każdej wywołanej usługi
czyni to samo. Dla każdego portu wejścia usługi trzeba zdecydować, do którego portu
wejścia „pełnomocnika” wywoływanej usługi wartości danych powinny być przekazane.
Każde połączenie między portem wejścia złożonej usługi a portem wejścia pełnomocników
wywoływanych usług jest przepływem danych (data flow). Przepływy danych powinny być
również zdefiniowane dla portów wyjścia. Ponadto porty wyjścia „pełnomocników” mogą być
połączone z portami wejścia innych „pełnomocników”. Jest to sposób na otrzymanie
rezultatów jednej wywołanej usługi otrzymującej dane wejściowe jednego lub kilku kolejnych
wywołanych usług sieciowych. Przepływ danych może być zależny od portów wejścia usług
sieciowych lub pełnomocników.
Przepływ danych determinuje wykonanie sekwencji „pełnomocników” wywoływanych usług
sieciowych oraz kroki wewnątrz implementacji złożonej usługi. Jednak nie wszystkie ważne
sekwencje mogą być kierowane przez przepływ danych. Na przykład kiedy przepływ pozwala
na wywołanie danych przeznaczonych do wykonania równolegle, a one powinny być
wykonywane
sekwencyjnie,
przepływ danych
nie
ma
możliwości
wyrażenia
tego
bezpośrednio. Jedynym sposobem jest stworzenie sztucznego przepływu danych między
dwiema wywoływanymi usługami. Taka sytuacja jest możliwa, jednak niezbyt korzystna.
Zamiast tego powinna być zdefiniowana sekwencja kontrolowanego przepływu (control
flow) pomiędzy dwiema usługami, która definiuje poprawną sekwencję wykonania.
Wszystkie te konstrukcje są dostępne do definiowania odpowiednich sekwencji wykonania
wywołanych usług sieciowych.
Usługi sieciowe mogą wymagać obsługi błędów. W przypadku wystąpienia błędu usługa
zwraca jego kod. W tym przypadku w zależności od kodu musi mieć miejsce obsługa
wyjątków w celu poradzenia sobie z sytuacją.
W przypadku złożonej usługi, kiedy nie powiedzie się realizacja jednego z elementów, usługa
sieciowa informuje o błędzie użytkownika, który może sam przejąć inicjatywę. Na przykład w
przypadku rezerwacji podróży został zarezerwowany lot, ale nie powiodła się rezerwacja
hotelu. Jeśli użytkownik sam zarezerwuje sobie miejsce w hotelu, problem zostaje
rozwiązany, natomiast jeśli mu się nie uda, konieczne jest anulowanie rezerwacji lotu przez
użytkownika. Alternatywnie usługa sieciowa może sama zaimplementować strategię
kompensacji
(compensation)
dla
nieudanej
wywołanej
usługi.
Konstrukcja
takiej
kompensacji pozwala na zdefiniowanie, co dzieje się po wystąpieniu błędu. Zazwyczaj
reprezentuje ona inną usługę sieciową, spełniającą podobne wymagania użytkownika (np.
szukanie wolnych miejsc hotelowych w promieniu 5km od wybranej lokalizacji).
W dowolnej sytuacji komunikacyjnej ludzie wymieniają sygnały na trzech różnych
poziomach:
• potwierdzenie odbioru wiadomości,
• potwierdzenie zrozumienia wiadomości,
• potwierdzenie ogólnej zgody na treść wiadomości.
Można wyróżnić dwa rodzaje potwierdzania wiadomości. Na poziomie usługi wiadomości,
która gwarantuje dostarczenie w znaczeniu, że odbiorca otrzymał wiadomość. Jednak na
poziomie biznesowym nie jest to wystarczające. Przyjęcie odbioru jest wymagane do
zagwarantowania, że wiadomość została zarchiwizowana i przeprowadzono podstawowe
sprawdzanie integralności w celu upewnienia się, że bez względu na okoliczności będzie
możliwość przetwarzania danych. WSMF odzwierciedla te dwa poziomy potwierdzania. W
warstwie biznesowej potwierdzanie odzwierciedla możliwe kroki połączenia tych obszarów
na pewnej zawartości wiadomości. To przypomina o zdefiniowaniu warstwy zrozumienia
wiadomości (message understanding layer) i warstwy wymiany wiadomości (message
exchange layer).
Usługi sieciowe potrzebują opisów związanych z potwierdzaniem zrozumienia wiadomości
(mesage understanding). Potwierdzanie w tej warstwie wskazuje, że odbiornik był zdolny
do przeanalizowania wiadomości i ją odebrał. Wskazuje, że potrafił ją zrozumieć i
przetworzyć, ale nie implikuje, że zgodził się z jej treścią.
Usługi sieciowe potrzebują opisów związanych z protokołem zrozumienia wiadomości
(message exchange protocol). Wiadomości od poszukującego usługi do jej dostawcy są
przesyłane przez sieci takie jak Internet, które nie zawsze są godne zaufania i nie zawsze
gwarantują dostarczenie wiadomości. Usługi sieciowe zakładają, że transmisja wiadomości
ma miejsce tylko raz. W przypadku sieci godnych zaufania pojedyncza transmisja jest
osiągana przez detekcję duplikatów i usunięcie ich w celu osiągnięcia dokładnie jednej
semantyki. W przypadku sieci niegodnej zaufania najpierw musi być zagwarantowane
dostarczenie wiadomości, co następuje przez ponawianie jej i krótkie przerwy pomiędzy. W
momencie nieotrzymania potwierdzenia w założonym czasie przerwy, wiadomość jest
uznawana za niedostarczoną. Jeżeli zostanie osiągnięty maksymalny przyjęty limit czasu
oczekiwania na potwierdzenie, wysłanie wiadomości jest nieudane. Implementacja dokładnie
jednego dostarczenia wiadomości jest nazywana protokołem wymiany wiadomości. Taki
protokół jest oddzielną warstwą i dostarcza dokładnie jedną semantykę dla usługi sieciowej.
Ostatnią ważną cechą są właściwości niefunkcjonalne (non functional properties)
charakteryzujące usługi sieciowe. Przykładem może być geograficzna lokalizacja usług, cena
produktu, czy maksymalny czas produkowania danych wyjściowych.
4) Mediatorzy rozwiązujący problemy interoperacyjności
Architektura oprogramowania opisuje system w terminach komponentów i połączeń, które
tworzą właściwe relacje między elementami. Problem koncentruje się na mediacji między
różnymi stylami interakcji komponentów (które nazywamy biznesową logiką usług
sieciowych). Prace nad różnorodnością systemów rozprzestrzenianej informacji rozwinęły
koncepcje opakowań i mediatorów. Zamiast zakładania globalnego schematu danych, różne
informacje i systemy wiedzy mają mediatorów tłumaczących oczekiwania użytkownika na
zapytania do różnych źródeł informacji i integrujących odpowiedzi.
Mediatorzy muszą radzić sobie z różnymi rodzajami niejednorodności:
• Mediacja struktury danych (data structure) – różne formaty danych wejściowych i
wyjściowych przekazywanych między różnymi usługami.
• Mediacja logiki biznesowej (business logics) – zapewniająca uzupełniającą się
funkcjonalność usługi, które mogłyby zostać połączone, ale nie pasują ich wzory
interakcji.
• Mediacja protokołów wymiany wiadomości (message exchange protocol) – usługi
sieciowe różniące się w sposobie osiągania warstw zaufania.
• Mediacja dynamicznego wywołania usług (service invocation) - wywołanie przez
usługę innych usług sieciowych może być wykonywane w bardziej elastyczny sposób,
przez odnoszenie się konkretnych celów.
Mediacja różnych aspektów jest wykonywana przez różne modele procesu mediacji:
• Podejście klient/serwer (client/server approach): Dostawca zapewnia usługę;
ktokolwiek chce o nią zapytać, musi poradzić sobie ze strukturą danych (formatem
wiadomości), logiką biznesową i protokołami wymiany wiadomości zdefiniowanymi
przez dostawcę. W tym przypadku mediacja ma miejsce wewnątrz procesów odbiorcy
usługi. Dostawca wykonuje swój publiczny proces według swoich reguł, a odbiorca
dostosowuje się do nich poprzez mediację. To podejście wymaga tylko jednej
transformacji na wymienianej wiadomości.
• Podejście peer-to-peer (peer-to-peer approach): w tym przypadku dostawca i
odbiorca zgadzają się co do dwóch pasujących publicznych procesów i obydwoje
dokonują mediacji swoich oryginalnych procesów. To podejście może wymagać dwóch
transformacji, jednej po stronie dostawcy, drugiej po stronie odbiorcy.
Głównymi elementami WSMF są ontologie, opisy celów, proste i złożone usługi oraz
mediatorzy. Celem standardu jest umożliwienie pełnej elastyczności i skalowalnej e-komercji
bazującej na usługach sieciowych.
2.17. WSMO
Specyfikacja WSMO (Web Service Modeling Ontology) to ontologie modelujące usługi
sieciowe, opisujące różne aspekty związane z semantycznymi usługami sieciowymi.
WSMO zapewnia specyfikację dla podstawowych elementów semantycznych usług
sieciowych. Odpowiednie ramy dla tych usług muszą łączyć podstawowe zasady projektu
sieci, zarówno te zdefiniowane dla sieci semantycznej jak i zasady zorientowane na usługi w
sieci. WSMO opiera się na następujących zasadach:
1) Przystosowanie do sieci
- WSMO dziedziczy koncepcję identyfikatorów URI dla
identyfikacji zasobu jako naczelną zasadę sieci www. Wykorzystuje również koncepcję
przestrzeni nazw dla oznaczania zawartości informacji, wspiera XML oraz inne
technologie rekomendowane przez W3C.
2) Bazowanie na ontologiach – ontologie są używane jako model danych w WSMO, co
oznacza, że wszystkie opisy zasobów oraz wymiana danych podczas użycia usługi
bazują na ontologiach. Ontologie są szeroko akceptowaną reprezentacją stanu wiedzy
i są identyfikowane jako centralne technologie dla sieci semantycznej. Intensywne
wykorzystanie ontologii pozwala na semantyczne przetwarzanie informacji oraz
wsparcie interoperacyjności. WSMO wspiera również języki zdefiniowane dla sieci
semantycznej.
3) Ścisła rozłączność – rozłączność oznacza tutaj, że zasoby WSMO są zdefiniowane
osobno i niezależnie, bez odniesienia do możliwego użycia lub interakcji z innymi
zasobami. Ta cecha podporządkowuje WSMO otwartej naturze sieci.
4) Centralizacja pośrednictwa – pośrednictwo to obsługiwanie różnorodności naturalnie
pojawiających się w otwartych środowiskach. Różnorodność może występować w
danych określających ontologię, protokół lub proces. WSMO rozpoznaje istotę
pośrednictwa dla pomyślnego rozmieszczania usług sieciowych poprzez mediację
komponentów.
5) Separacja ról ontologicznych – użytkownicy mają do czynienia z różnymi kontekstami
dla dostępnych usług sieciowych (np. chęć zarezerwowania wakacji zgodnie z
preferencjami pogody, kultury i możliwości opieki nad dziećmi, podczas gdy usługa na
pierwszym miejscu stawia komfort podróży i dostępność hoteli). WSMO rozróżnia
życzenia klienta i możliwości usługi.
6) Opis a implementacja – WSMO rozróżnia opis semantycznej usługi od wymaganych
technologii
(implementacja).
Jest
zainteresowany
wsparciem
istniejących
i
wyłaniających się wykonywalnych technologii dla sieci semantycznej i usług
sieciowych. WSMO ma na celu zapewnienie odpowiedniego modelu ontologicznego
opisu oraz kompatybilność z istniejącymi i pojawiającymi się technologiami.
7) Usługi a usługi sieciowe – usługa sieciowa jest komputerową jednostką zdolną (przez
wywołanie) do osiągania celów użytkowników, natomiast usługa jest aktualną
wartością zapewnianą przez to wywołanie. WSMO zapewnia środki do opisu usług
sieciowych, które zapewniają dostęp (wyszukiwanie, kupowanie itp.) do usług. WSMO
jest zaprojektowane jako środek opisu poprzednich wzorów a nie do zastępowania ich
funkcjonalności.
Terminy usługa i usługa sieciowa będą używane zamiennie jako środek reprezentacji
systemów wspierających interoperacyjność interakcji maszyn w Internecie.
2.17.1.1.
Struktura języka opisującego WSMO
Język WSMO to warstwy meta-modelu, identyfikatory, typy danych i ich wartości.
1) Warstwy meta-modelu opisujące WSMO
WSMO jest meta-modelem dla aspektów związanych z semantycznymi usługami
sieciowymi. MOF (Meta-Object Facility) definiuje architekturę metadanych składającą się
z czterech warstw:
• warstwa informacyjna obejmująca dane do opisu,
• warstwa modelu obejmująca metadane opisujące dane w warstwie informacyjnej,
• warstwa meta-modelu obejmująca opisy, definiująca strukturę i semantykę
metadanych,
• warstwa meta-meta-modelu obejmująca opis struktury i semantyki meta-modelu.
Pod względem wymienionych warstw:
• język opisujący WSMO koresponduje z warstwą meta-meta-modelu,
• WSMO stanowi warstwę meta-modelu,
• właściwe ontologie, usługi sieciowe, cele i specyfikacje pośredników stanowią
warstwę modelu,
• właściwe dane opisywane przez ontologie i wymieniane pomiędzy usługami
stanowią warstwę informacyjną.
Najczęściej używane w WSMO konstrukcje MOF to klasa, podklasa, właściwości, typy
właściwości i ich różnorodne specyfikacje. Podczas definiowania WSMO robione są dwa
ważne założenia:
• właściwości są zbiorami różnowartościowymi, gdy dana właściwość wymaga aby jej
różnorodność stała się jednowartościowa; jest to wyraźnie umieszczane na listach
poniżej,
• dla niektórych elementów istnieje konieczność definiowania właściwości biorących
wartości z sumy różnych typów, cechy, która nie jest bezpośrednio wspierana przez
konstrukcje MOF; ten efekt można osiągnąć poprzez zdefiniowanie nowej klasy jako
super-klasy wszystkich typów wymaganych w definicji właściwości (reprezentacja
sumy pojedynczych typów) z ograniczeniem, że każda instancja nowej klasy jest
instancją przynajmniej jednego typu wykorzystanego w sumie. Taka nowa klasa w
WSMO jest definiowana za pomocą nawiasów klamrowych wymieniając klasy
reprezentujące wymagane typy właściwości.
2) Identyfikatory
a) Identyfikator URI
WSMO bazuje na podstawowych identyfikatorach używanych przez sieć www,
wszystkie elementy są oznaczane za pomocą URI z wyjątkiem liczb, zmiennych i
anonimowych identyfikatorów. URI mogą być definiowane jako pełny URI (adres
www) lub nazwy warunkowe (qNames) za pomocą deklaracji przestrzeni nazw.
b) Identyfikator anonimowy (Anonymous ID)
Anonimowe identyfikatory mogą być numerowane (_#1, _#2, ...) lub nienumerowane
(_#) i reprezentują identyfikatory. Te same anonimowe ID reprezentują ten sam
identyfikator w tym samym kontekście; w przeciwnym wypadku reprezentują różne
identyfikatory. Są podobnym elementem do pustych węzłów RDF. Anonimowe
identyfikatory są stałymi.
3) Wartości i typy danych
Leksykalną reprezentacją wartości takich jak liczby są litery. Mogą być ustalane za
pomocą typów danych XML, np. xsd:integer. Ponadto typy danych mogą przedstawiać
aspekt ich przestrzeni wartości, takich jak porządkowanie i definiowanie aksjomatów
dla relacji oraz symbole takie jak +, -. Takie relacje i funkcje są nazywane orzeczeniami
typów danych.
2.17.1.2.
Elementy wyższego poziomu
WSMO definiuje cztery elementy wyższego poziomu jako główne koncepty, które muszą być
zdefiniowane w celu opisania semantycznych usług sieciowych:
• Ontologie - zapewniają formalną terminologię używaną przez pozostałe komponenty
WSMO do opisu aspektów rozważanej dziedziny.
• Usługi sieciowe – opisują jednostki obliczeniowe udostępniając usługi zapewniające
niektóre wartości z danej dziedziny. Te opisy obejmują możliwości, interfejsy i
wewnętrzną pracę usług. Wszystkie aspekty usług są opisywane za pomocą
terminologii zdefiniowanej przez ontologie.
• Cele - reprezentują życzenia użytkowników; dla każdej ich realizacji mogą być
wyszukiwane odpowiednie usługi realizujące. Cele modelują spojrzenie użytkownika w
proces realizacji usług sieciowych.
• Mediatorzy - opisują elementy przezwyciężające problemy interoperacyjności między
różnymi elementami WSMO, rozwiązują niekompatybilność danych i procesów.
Rozwiązują niedopasowanie między różnie używanymi terminologiami (poziom
danych), komunikacją między usługami (poziom porozumienia) oraz łączeniem usług
(poziom przetwarzania).
1) Ontologie
Ontologia jest formalną i bezpośrednią specyfikacją dzielenia pojęć. Ontologie definiują
ogólnie przyjętą, popularną terminologię poprzez zapewnienie pojęć i relacji między nimi.
Zapewniają również zbiór aksjomatów wyrażonych w języku logicznym w celu objęcia
semantycznych relacji właściwości oraz pojęć.
Definicje i opisy elementów ontologii WSMO:
a) „Niefunkcyjna” właściwość
hasAccuracy – reprezentuje błąd generowany przez usługę sieciową, może być mierzony
przez liczbę błędów generowanych w konkretnym przedziale czasowym,
hasContributor – odpowiedzialne za tworzenie wsparcia dla zawartości jednostek,
hasCoverage – rozszerzenie lub zakres zawartości elementu, może zawierać lokalizację
(nazwę miejsca), tymczasowy okres czasu lub kompetencje,
hasCreator – jednostka pierwotnie odpowiedzialna za tworzenie zawartości elementu;
dc:creator zawiera osobę, organizację lub usługę, jednak zgodnie z rekomendacją ta
nazwa powinna być używana do wskazywania jednostek,
hasDate – wskazuje datę danego wydarzenia w czasie istnienia elementu. dc:date jest
zazwyczaj kojarzone z tworzeniem lub dostępnością elementu. Używane w notacji czasu i
daty,
hasDescription – “raport” zawartości elementu, może zawierać streszczenie, spis treści,
odnośniki do graficznej reprezentacji treści itp., ale nie ogranicza się jedynie do tych
elementów,
hasFinancial – reprezentuje właściwości usługi związane z kosztami i pieniędzmi oraz
zawiera elementy związane z tym tematem, np. jednostki miary, ceny, opłaty itp.,
hasFormat – określa fizyczne lub cyfrowe właściwości elementu, może zawierać wymiary
elementu (rozmiar, czas trwania), używane do identyfikowania narzędzi, oprogramowania
lub wyposażenia potrzebnego do przedstawiania i działania elementem,
hasIdentifier – jednoznaczna referencja do elementu w danym kontekście, zalecana
identyfikacja za pomocą stringa lub liczby adekwatnej do formalnej identyfikacji systemu,
hasLanguage – język intelektualnego kontekstu elementu,
hasNetworkRelatedQoS – reprezentacja mechanizmów QoS niezależnych od usługi i
działających w transporcie siatek; może być mierzona przez opóźnienia siatek, wahania
opóźnień lub stratę wiadomości,
hasOwner – osoba lub organizacja, do której należy dany element WSMO,
hasPerformance – reprezentuje szybkość, z jaką dana usługa może być zrealizowana,
może mierzyć przepustowość, zwłokę, czas działania, reakcji i transakcji; usługa sieciowa
wysokiej jakości powinna zapewniać dużą przepustowość, małą zwłokę, dłuższy czas
działania oraz krótki czas reakcji i transakcji.
hasPublisher – jednostka odpowiedzialna za udostępnianie elementów,
hasRelation – referencja do powiązanego elementu, zalecana identyfikacja za pomocą
stringa lub liczby adekwatnej do formalnej identyfikacji systemu,
hasReliability – reprezentuje zdolność usługi do wykonywania swoich funkcji (utrzymanie
jakości usługi), może być mierzone poprzez ilość błędów w danym przedziale czasowym,
hasRights – informacje o prawach do zatrzymywania lub usuwania elementu, zawiera
prawa zarządzania elementem lub odnośnik do usługi posiadającej te informacje, w
przypadku braku tego elementu żadne przypuszczenia o prawach nie mogą być
dokonane,
hasRobustness – reprezentuje zdolność prawidłowego funkcjonowania w przypadku
niekompletnych lub wadliwych danych wejściowych, może być mierzone za pomocą ilości
złych danych wejściowych, pomimo których usługa funkcjonuje prawidłowo,
hasScalability – reprezentuje zdolność usługi do przetwarzania większej ilości zapytań w
określonym czasie, może być mierzone przez ilość rozwiązanych pytań w danym czasie,
hasSecurity – reprezentuje zdolność usługi do zapewnienia uwierzytelniania osób lub
innych usług mających do niej dostęp, autoryzacji oraz zachowania prywatności (tylko
osoba mająca autoryzację ma dostęp i możliwość zamiany danych), możliwość śledzenia
historii usługi, szyfrowanie danych oraz brak możliwości usunięcia zapytania czy usługi po
realizacji,
hasSource – odnośnik do elementu źródłowego, dany element może całkowicie wywodzić
się z elementu źródłowego lub z jego części,
hasSubject – temat zawartości elementu, wyrażany jako słowa kluczowe, frazy kluczowe
lub kody klasyfikacyjne opisujące temat elementu,
hasTitle – nazwa elementu, zazwyczaj taka, pod którą element jest formalnie
rozpoznawany,
hasTransactional – reprezentuje transakcyjne właściwości usługi,
hasTrust – reprezentuje wartość zaufania usługi lub ontologii,
hasType – natura lub gatunek zawartości elementu, zawiera pojęcia opisujące ogólne
kategorie, funkcje, gatunki lub poziom skupienia,
hasTypeOfMatch – wymaga konkretnych celów; mogą być właściwe dopasowania - gdzie
opis celów jest podzbiorem opisu usługi lub gdzie opis usługi jest podzbiorem opisu
dopasowania,
hasVersion – właściwości elementu mogą zmieniać w czasie identyfikator w zależności od
tego, jaki jest w dany momencie potrzebny.
b) Importowanie ontologii
Budowanie ontologii dla dziedziny konkretnego problemu może być niewygodnym i
skomplikowanym zadaniem. Standardową drogą postępowania jest modularyzacja.
Importowanie ontologii pozawala na modułowe podejście do tworzenia ontologii.
Importowanie ontologii może być używane, gdy nie ma konfliktów między nimi, w
przeciwnym razie trzeba posłużyć się mediatorem.
c) Wykorzystanie mediatorów
W trakcie importowania ontologii muszą być podjęte kroki w celu regulowania,
wyrównywania, łączenia i transformowania importowanych ontologii. Z tego powodu
używa się mediatorów.
Cztery typy mediatorów:
• ggMediators – łączą dwa cele; to połączenie przedstawia udoskonalenie celów
źródła do stanu równoważności,
• ooMediators – importują ontologie i rozwiązują ewentualne nieścisłości reprezentacji
między nimi,
• wgMediators – łączą usługi z celami w znaczeniu spełniania przez usługę celu, z
którym jest połączona, mogą wskazywać różnice między jednostkami i mapować
różne słownictwo (poprzez wykorzystanie ooMediators),
• wwMediators – łączą dwie usługi.
Definicje mediatorów:
Class mediator
hasNonFunctionalProperties type nonFunctionalProperties
importsOntology type ontology
hasSource type {ontology, goal, webService, mediator}
hasTarget type {ontology, goal, webService, mediator}
hasMediationService type {goal, webService, wwMediator}
Class ooMediator sub-Class mediator
hasSource type {ontology, ooMediator}
Class ggMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {goal, ggMediator}
hasTarget type {goal, ggMediator}
Class wgMediator sub-Class mediator
hasSource type {webService, goal, wgMediator, ggMediator}
hasTarget type {webService, goal, ggMediator, wgMediator}
Class wwMediator sub-Class mediator
hasSource type {webService, wwMediator}
hasTarget type {webService, wwMediator}
Source – komponenty źródłowe; definiują jednostki, które są źródłowe dla mediatora.
Target – komponenty definiujące jednostki będące celem mediatora.
Mediation Service – wskazują cele, które w sposób oznajmujący opisują mapowanie,
wskazują usługi, które w sposób właściwy implementują mapowanie lub wwMediators
łączące usługi z właściwą implementacją mapowania.
Dalszy komentarz wgMediators dotyczy miejsca: mogą one w zależności od miejsca i celu
mieć dwie różne funkcje:
• cel jest połączony z usługą za pomocą interfejsu choreograficznego, co oznacza, że
usługa wypełnia cel, z którym jest połączona,
• usługa jest połączona celem poprzez interfejs orkiestracyjny, co oznacza, że usługa
potrzebuje
rozwiązany
cel
aby
spełnić
funkcjonalność
pisaną
w
swoich
możliwościach.
Są dwa sposoby łączenia mediatorów z innymi jednostkami:
• jednostka określa relacje z mediatorem poprzez atrybut has usesMediator,
• jednostki mogą być połączone z mediatorami przez atrybuty źródła i celu mediatora.
d) Pojęcia
Pojęcia stanowią podstawowe elementy dla niektórych domen. Pojęcie pisane przez
swoją definicję zapewnia atrybuty wraz z nazwami i typami.
Definicje pojęć:
Class concept
hasSuperConcept type concept
hasAttribute type attribute
hasDefinition type logicalExpression multiplicity = single-valued
SuperConcept (super pojęcie) – jeżeli dane pojęcie ma swoje super pojęcie, to dziedziczy
jego cechy i odpowiednie ograniczenia, wszystkie instancje pojęcia są również
instancjami super pojęcia. Jest skończona liczba super pojęć danego pojęcia.
Attribute (atrybut) – każde pojęcie zapewnia zbiór atrybutów (również pusty)
reprezentujących nazwane „otwory”, na przykład dla wartości danych. Mogą być
wypełniane na poziomie instancji. Atrybut określa „otwór” pojęcia przez ustalenie nazwy
oraz logicznych ograniczeń na możliwe wartości wypełniające otwór.
Definition (definicja) – jest logicznym wyrażeniem formalnie definiującym semantykę
pojęcia. Dokładniej definiuje rozszerzenie pojęcia. Jeżeli C jest identyfikatorem
wskazujący pojęcie to definicja przyjmuje jedną z form:
• forAll ?x ( ?x memberOf C implies l-expr(?x) ) – oznacza warunek konieczny dla
elementu rozszerzenia pojęcia,
• forAll ?x ( ?x memberOf C impliedBy l-expr(?x) ) – oznacza istnienie warunku
wystarczającego,
• forAll ?x ( ?x memberOf C equivalent l-expr(?x) ) – warunek konieczny i
wystarczający dla obiektu będącego elementem rozszerzenia pojęcia.
l-expr(?x) jest logicznym wyrażeniem z dokładnością do wolnej zmiennej ?x.
e) Relacje
Relacje są używane do modelowania wzajemnych zależności między różnymi pojęciami
(dokładniej instancjami pojęć).
Definicje relacji:
Class relation
hasSuperRelation type relation
hasParameter type parameter
hasDefinition type logicalExpression multiplicity = single-valued
Superrelation (super relacja) – relacja dziedziczy cechy i ograniczenia super relacji.
Istnieje skończony zbiór super relacji dla danej relacji, zbiór elementów należących do
rozszerzenia relacji jest podzbiorem każdego rozszerzenia super relacji.
Parametry – istnieje lista parametrów danej relacji, definicje parametrów:
Class parameter
hasDomain type concept multiplicity = single-valued
Definition (definicja) – logiczne wyrażenie definiujące zbiór instancji relacji (nargumentowe
obiekty).
Jeśli
parametry
są
wymienione
wówczas
relacja
jest
reprezentowana przez n-argumentowe symbole z nazwanymi argumentami (n jest ilością
parametrów relacji) i identyfikator relacji jest używany jako nazwa symbolu. Jeżeli R jest
identyfikatorem wskazującym relację i parametry są wymienione to definicja przyjmuje
jedną z form:
• forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn]
implies l-expr(?v1,...,?vn) ),
impliedBy l-expr(?v1,...,?vn) ),
equivalent l-expr(?v1,...,?vn) ).
Gdy parametry nie są wymienione to relacja jest reprezentowana przez symbol gdzie
identyfikator relacji jest używany jako nazwa symbolu. Jeżeli R jest identyfikatorem
wskazującym relację a parametry nie są wymienione to definicja przyjmuje jedną z form:
• forAll ?v1,...,?vn ( R(?v1,...,?vn)
implies l-expr(?v1,...,?vn) ),
• forAll ?v1,...,?vn ( R(?v1,...,?vn)
impliedBy l-expr(?v1,...,?vn) ),
• forAll ?v1,...,?vn ( R(?v1,...,?vn)
equivalent l-expr(?v1,...,?vn) ).
l-expr(?v1,...,?vn) jest logicznym wyrażeniem z dokładnością ?v1,...,?vn jako wolnymi zmiennymi
oraz p1,…,pn są nazwami parametrów relacji.
f) Funkcje
Funkcja jest specyficzną relacją mającą n-argumentową dziedzinę i jednoargumentowy
zasięg, gdzie wartość zasięgu funkcjonalnie zależy od wartości dziedziny. Pojęcie funkcji
jest nie tylko syntaktyczną jednostką, ale ma również semantyki pozwalające na właściwą
ewaluację funkcji gdy dane są konkretne wartości parametrów. Semantyki funkcji mogą
być ujmowane zewnętrznie lub formalizowane przez wyznaczanie logicznych wyrażeń do
właściwości hasDefinition dziedziczonej z relacji.
Definicja funkcji:
Class function sub-Class relation
hasRange type concept multiplicity = single-valued
Range (zasięg) – pojecie ograniczające ilość wartości zwracanych przez funkcję.
Logiczna reprezentacja funkcji jest prawie taka sama jak reprezentacja relacji, gdzie
wartość rezultatu funkcji jest formalnie reprezentowana. W funkcji jest reprezentowana
przez n+1 argumentowy symbol z nazwanymi argumentami (n jest liczbą argumentów
funkcji) i identyfikator funkcji jest używana jako nazwa predykatu funkcji. W
szczególności,nazwy parametrów korespondujących z relacją są nazwami parametrów
funkcji tak samo jak jeden dodatkowy parametr zasięgu wskazujący wartość funkcji z
daną wartością parametru. Jeżeli F jest identyfikatorem wskazującym funkcję a p1,…,pn
zbiorem parametrów funkcji, to definicja semantyki funkcji (dziedziczona z relacji) wyraża
się następująco:
forAll ?v1,...,?vn,?range ( F[p1 hasValue ?v1,...,pn hasValue ?vn, range hasValue ?range]
equivalent l-expr(?v1,...,?vn,?range) )
Aby zapobiec wieloznaczności zasięg nie może być używany jako nazwa dla parametru
lub funkcji.
g) Instancje
Bezpośrednia definicja instancji pojęcia:
Class instance
hasType type concept
hasAttributeValues type attributeValue
Typ – pojęcie, którego instancją jest dana instancja.
AttributeValues (wartość atrybutu) – wartości pojedynczego atrybutu definiowane są w
samym pojęciu. Dla każdego atrybutu danego pojęcia.może być więcej korespondujących
ze sobą wartości atrybutu. Te wartości muszą być kompatybilne z typem deklaracji w
definicji pojęcia.
Definicja wartości atrybutu:
Class attributeValue
hasAttribute type attribute multiplicity = single-valued
hasValue type {instance, literal, anonymousId}
Instancje
n-argumentowych
komponenty instancji pojęć.
relacji
mogą
być
traktowane
jako
n-argumentowe
Definicja instancji relacji:
Class relationInstance
hasType type relation
hasParameterValue type parameterValue
Parametrvalue (wartość parametru) – zbiór wartości parametru pojedynczych instancji,
które są związane odpowiednio z instancją relacji.
Aksjomaty
Aksjomat jest logicznym wyrażeniem razem z niefunkcyjną właściwością.
Definicja aksjomatów:
Class axiom
hasDefinition type logicalExpression
2) Opisy usług sieciowych
Usługi sieciowe WSMO składają się z funkcjonalnych, niefunkcjonalnych oraz
behawioralnych aspektów usługi. Usługa sieciowa jest komputerową jednostką zdolną do
osiągania celów użytkownika. Usługa sieciowa może zapewniać różne usługi.
Definicja opisu usługi sieciowej:
Class webService
usesMediator type {ooMediator, wwMediator}
hasCapability type capability multiplicity = single-valued
hasInterface type interface
a) Capability – możliwość
Możliwość definiuje usługę sieciową w znaczeniu jej funkcjonalności:
Class capability
usesMediator type {ooMediator, wgMediator}
hasSharedVariables type sharedVariables
hasPrecondition type axiom
hasAssumption type axiom
hasPostcondition type axiom
hasEffect type axiom
SharedVariables (dzielone zmienne) - reprezentują zmienne dzielone między warunkami
wstępnymi, końcowymi, założeniami i efektami. Wszystkie są ilościowymi zmiennymi w
formule, która zawiera założenia, warunki wstępne, warunki końcowe i efekty.
Precondition (warunek wstępny) – specyfikuje przestrzeń informacji usługi sieciowej przed
wykonaniem.
Assumption (założenie) – opisuje stan rzeczy przed wykonaniem usługi sieciowej.
Effect (efekt) – opisuje stan rzeczy po wykonaniu usługi sieciowej.
b) Interface – interfejs
Interfejs opisuje jak może być osiągnięta funkcjonalność usługi sieciowej (np. jak wypełnić
możliwości usługi) poprzez zapewnienie podwójnego widoku na operacyjne kompetencje
usługi:
• choreografia dekomponuje możliwość pod względem interakcji z usługą,
• orkiestracja dekomponuje możliwość pod względem funkcjonalności wymaganej od
usługi.
To rozróżnienie odzwierciedla różnicę między komunikacją a współpracą. Choreografia
opisuje jak komunikować się z usługą w celu wykorzystania jej funkcjonalności.
Orkiestracja definiuje jak osiągana jest całkowita funkcjonalność przez współpracę
podstawowych dostawców usług sieciowych.
Interfejs definiuje się za pomocą następujących właściwości:
Class interface
hasChoreography type choreography
hasOrchestration type orchestration
Choreography
(choreografia)
–
zapewnia
niezbędną
informację
umożliwiającą
komunikację z usługą sieciową z punktu widzenia użytkownika.
Orchetration (orkiestracja) – opisuje jak usługa wykorzystuje inne usługi w celu
osiągnięcia swoich możliwości.
3) Cele
Realizacja (wypełnienie) celów jest elementem poszukiwanym poprzez wykonywanie
usługi sieciowej. Cele mogą być opisami usług, które potencjalnie spełniałyby wymagania
użytkownika.
Definicje celów:
Class goal
usesMediator type {ooMediator, ggMediator}
requestsCapability type capability multiplicity = single-valued
requestsInterface type interface
2.17.1.3.
Logiczny język do definiowania formalnych semantyk WSMO
Jako główny składnik aksjomatów wyrażenia logiczne są używane prawie wszędzie w
modelu WSMO do ujmowania specyficznych niuansów elementów modelujących lub ich
składowych części w formalny i jednoznaczny sposób. W następujący sposób powstaje
definicja składni formalnego języka używana do specyfikacji wyrażeń logicznych. Semantyka
tego języka jest formalnie zdefiniowana w specyfikacji WSML.
1) Identyfikatory zmiennych
Oprócz identyfikatorów URI oraz identyfikatorów anonimowych zmienne mogą być
również identyfikowane przez logiczne wyrażenia. Nazwy zmiennych są stringami
rozpoczynającymi się znakiem zapytania, po którym następują symbole liczbowe,
literowe, spacja lub myślnik.
2) Podstawowe słownictwo i wyrażenia
Niech URI będzie zbiorem wszystkich obowiązujących jednolitych identyfikatorów. Zbiór
ten będzie używany do identyfikowania różnych jednostek w WSMO.
Słownictwo logicznego języka zawiera następujące symbole (słownictwo V języka L(V)):
• nieskończony zbiór identyfikatorów URI,
• nieskończony zbiór anonimowych identyfikatorów AnID,
• nieskończony zbiór symboli liczbowych Lit,
• nieskończony zbiór zmiennych Var,
• symbole funkcji (konstruktory obiektów) FSym, które są podzbiorem URI,
• symbole predykatów PSym, które są podzbiorem URI,
• symbole predykatów nazywające argumenty PsymNamed będące podzbiorem URI.
• skończony zbiór pomocniczych symboli AuxSym zawierający (, ), ofType,
ofTypeSet, memberOf, subConceptOf, hasValue, hasValues, false, true,
• skończony zbiór logicznych powiązań i kwantyfikatorów zawierający standardowe
operatory logiczne or, and, not, implies, impliedBy, equivalent , forAll, exists,
• wszystkie te zbiory są wzajemnie rozłączne,
• dla każdego symbolu z FSym, PSym lub PSymNamed zakłada się, że istnieje
dodatnia liczba arity(S) określająca liczbę argumentów oczekiwanych przez
korespondujący symbol podczas tworzenia wyrażenia w naszym języku,
• dla każdego symbolu w PsymNamed zakłada się, że istnieje zdefiniowany
korespondujący zbiór nazw parametrów parNames(S), który dostarcza nazwy
parametrów
symbolu
używanego
podczas
tworzenia
wyrażenia
w
języku
używającym tego symbolu.
Bezargumentowe symbole funkcji są nazywane stałymi; bezargumentowe symbole
predykatów odpowiadają zmiennym w klasycznej logice.
Dane jest słownictwo V, możemy zdefiniować zbiór terminów Term(V):
• dowolny identyfikator URI jest terminem w Term(V),
• dowolny anonimowy identyfikator w AnID jest terminem w Term(V),
• dowolny element w Lit jest terminem w Term(V),
• dowolna zmienna w Var jest terminem w Term(V),
• jeżeli f jest symbolem n-wymiarowej funkcji w Fsym a t1,…,tn są terminami wtedy
f(t1,…tn) jest terminem w Term(V),
• nic więcej nie jest terminem.
3) Wyrażenia logiczne
Rozszerzamy poprzednią definicję do zbioru wyrażeń logicznych:
• Jeżeli p jest symbolem predykatu w Psym o wymiarze n, t1,…,tn są terminami wtedy
p(t1,…tn) jest prostym logicznym wyrażeniem w L(V).
• Jeżeli p jest symbolem predykatu w PsymNamed o wymiarze n, parNames(r) = {p1,
...,pn} i t1, ...,tn to wtedy R[p1 hasValue t1, ..., pn hasValue tn] jest prostym
logicznym wyrażeniem w L(V).
• Jeżeli P, ATT, T są terminami w Term(V) wtedy P[ATT ofType T] jest prostym
• Jeżeli P, ATT, T1,...,Tn (gdzie n >= 1) są wyrażeniami w Term(V), wtedy P[ATT
ofTypeSet (T1,...,Tn)] jest prostym logicznym wyrażeniem w L(V).
• Jeżeli O, T są terminami w Term(V), wtedy O memberOf T jest prostym logicznym
wyrażeniem w L(V).
• Jeżeli C1, C2 są terminami w Term(V), wtedy C1 subConceptOf C2 jest prostym
• Jeżeli R1, R2 są symbolami predykatów w PSym lub PSymNamed z taką samą
sygnaturą, wtedy R1 subRelationOf R2 jest prostym logicznym wyrażeniem w L(V).
• Jeżeli O, V, ATT są terminami w Term(V), wtedy O[ATT hasValue V] jest prostym
• Jeżeli O, V1,...,Vn, ATT (gdzie n >= 1) są terminami w Term(V), wtedy O[ATT
hasValues {V1,...,Vn}] jest prostym logicznym wyrażeniem w L(V).
• Jeżeli T1 i T2 są terminami w Term(V), wtedy T1 = T2 jest prostym logicznym
wyrażeniem w L(V).
• Nic więcej nie jest logicznym wyrażeniem.
Intuicyjne semantyki dla prostych wyrażeń logicznych są następujące:
• Semantyka predykatów w PSym jest wspólna dla predykatów w logice
matematycznej,
np.
dostarcza
podstawowe
zdania
o
elementach
pewnej
przestrzeni, która jest reprezentowana przez argumenty symboli.
• Predykaty z nazwanymi argumentami mają taki sam semantyczny cel, jednak
zamiast identyfikowania argumentów w znaczeniu ustalonego porządku, pojedyncze
argumenty są identyfikowane przez nazwy parametrów. Porządek argumentów nie
ma znaczenia dla semantyki predykatu. Argumenty są zdefiniowane przez nazwy
skojarzonych parametrów. Oczywiście ma to konsekwencje dla ujednolicania
algorytmów.
• C[ATT ofType T] definiuje ograniczenie na możliwych wartościach, instancje klasy C
mogą przyjmować wartości typu T dla właściwości ATT.
• Ten sam cel ma proste logiczne wyrażenie C[ATT ofTypeSet (T1,...Tn)]. Definiuje
ono ograniczenie na możliwych wartościach, dla których instancje klasy c mogą
przyjmować wartości typu T1, .., Tn na właściwości ATT. Oznacza to, że wszystkie
wartości wszystkich określonych typów mogą być wartościami dla właściwości ATT.
• O memberOf T jest prawdziwe, jeżeli element O jest instancją typu T, co oznacza,
że element oznaczony przez O jest elementem rozszerzenia typu T.
• C1 subConceptOf C2 jest prawdziwe, jeżeli pojęcie C1 jest podpojęciem C2, co
oznacza, że rozszerzenie pojęcia C1 jest podzbiorem rozszerzenia pojęcia C2.
• O[ATT hasValue V] jest prawdziwe, jeżeli element wskazany przez O przyjmuje
wartość V pod wartością ATT.
• Podobnie dla prostego logicznego wyrażenia O[ATT hasValues {V1,...,Vn}]:
wyrażenie obowiązuje jeżeli zbiór wartości przyjmowanych przez element O dla
właściwości ATT zawiera wszystkie wartości V1,...Vn.
• T1 = T2 jest prawdziwe jeżeli obydwa terminy wskazują ten sam element.
Powyższa definicja jest rozszerzona o złożone logiczne wyrażenia w L(V) w sposób
następujący:
• Każde proste wyrażenie logiczne w L(V) jest wyrażeniem logicznym w L(V).
• Zaprzeczenie logicznego wyrażenia w L(V) jest logicznym wyrażeniem w L(V).
• Jeżeli L1 i L2 są logicznymi wyrażeniami w L(V) i op jest jednym z logicznych
operatorów {or and implies impliedBy equivalent} wtedy L1 op L2 jest logicznym
wyrażeniem w L(V).
• Jeżeli L jest logicznym wyrażeniem w L(V), x zmienną z Var a Q kwantyfikatorem
{forAll, exists} wtedy Qx(L) jest logicznym wyrażeniem w L(V).
• Nic więcej nie jest logicznym wyrażeniem (formułą) w L(V).
Intuicyjne semantyki dla złożonych wyrażeń logicznych są następujące:
• not L jest prawdziwe gdy logiczne wyrażenie L nie obowiązuje.
• or, and, implies, equivalent, impliedBy są logicznymi operatorami odpowiednio
alternatywy, koniunkcji, implikacji, równoważności i implikacji wstecz.
• forAll x (L) jest prawdziwe gdy L zachodzi dla wszystkich możliwych elementów x.
• exists x (L) jest prawdziwe gdy istnieje przynajmniej jeden element x, dla którego
zachodzi L.
Ważne elementy notacji
Istnieje zdefiniowany porządek obowiązywania i łączenia operatorów logicznych.
op1 < op2 oznacza, że op2 łączy silniej niż op1 (pierwszeństwo operatora op2):
implies, equivalent, impliedBy < or, and < not. W przypadku niejednoznacznej kolejności
operatorów używa się nawiasów okrągłych.
Można syntaktycznie łączyć pojedyncze formuły jako syntaktyczne skróty odrębnych
formuł, np. C1 subConceptOf C2 i C1[ATT op V] może być połączone jako C1[ATT op V]
subConceptOf C2. Ponadto p.q oznacza element możliwy do osiągnięcia przez
poruszanie się od p poprzez właściwość q, gdzie q jest jednowartościową właściwością.
W przypadku wielowartościowych właściwości posługujemy się notacją p..q.
Semantycznie różne
modelujące elementy ontologii mogą być
reprezentowane
następująco: pojęcia jako terminy, relacje jako predykaty z nazwanymi argumentami,
funkcje jako predykaty z nazwanymi argumentami, instancje jako terminy i aksjomaty jako
logiczne wyrażenia.
2.17.1.4.
Zastosowania
Najogólniej mówiąc, WSMO jest przeznaczone do zajmowania się tym, co jest związane z
usługami sieciowymi, w taki sposób aby ułatwić użytkownikowi korzystanie z usług
dostępnych przez Internet. Zatem specyfikacja ma za zadanie modelowanie ontologii, które z
wykorzystaniem semantycznych zależności ułatwiają wyszukiwanie odpowiednich dla
użytkownika usług oraz umożliwiają ich sprawną realizację.
Integracja aplikacji i usług jest tradycyjnie osiągana dzięki dostosowywaniu rozwiązań dla
każdej pary aplikacji czy usług osobno. To z kolei wymaga inwestowania w sprzęt
komputerowy i oprogramowanie po stronie każdego nowego klienta lub partnera
biznesowego oraz wkładu człowieka w uzgadnianie formatu danych oraz protokołów
interakcji. Z tych powodów możliwość ponownego wykorzystania obecnych integracyjnych
rozwiązań jest stosunkowo niska. Ponadto usługi sieciowe zapewniają pewien zbiór
standardów funkcjonalności w sieci; specyfikację Simple Object Access Protocol (SOAP)
jako standardu transmitowania wiadomości oraz WSDL jako standardu opisującego interfejsy
zapewniające niezależny od platformy dostęp do końcowej funkcjonalności.
Ponadto opisy usług sieciowych w WSDL są jedynie syntaktyczne, odbiorca usługi musi
polegać na opisie usług sieciowych w języku naturalnym, aby zdecydować czy oferują one
oczekiwaną funkcjonalność. Ciężko jest również współpracować jeśli partnerzy biznesowi
mają różne sposoby interakcji lub używają innych terminów do opisu formatu danych lub
funkcjonalności.
Wyższy poziom automatyzacji w lokalizacji i wykorzystywaniu usług sieciowych można
osiągnąć poprzez dodawanie semantyk do opisu usług sieciowych. Takie semantyczne opisy
zazwyczaj odnoszą się do semantycznych usług sieciowych i powinny umożliwić dynamiczną
lokalizację partnerów zapewniających konkretną usługę oraz usprawnić (pół)automatyczną
współpracę i interakcje między nimi.
Specyfikacja WSMO została stworzona w celu realizacji zadań opisanych powyżej i definiuje
formalny pojęciowy model dla semantycznych usług sieciowych bazujący na WSMF.
Głównym celem WSMO jest zapewnienie odpowiedniej technologii do osiągnięcia
elastycznej i efektywnej integracji wewnątrz i pomiędzy biznesowymi granicami.
Jest wiele różnic między aplikacjami, które utrudniają komunikację. Są to między innymi:
• Różnice w słownictwie – różnice w terminach używanych do opisywania oczekiwanej i
oferowanej funkcjonalności usług. Często nie powstają one w sposób jawny, więc są
trudne do usuwania.
• Różnice w protokołach – różne style interakcji między aplikacjami i partnerami.
• Różnice w procesach biznesowych – na przykład różne procesy wdrażane i działające
wewnątrz różnych organizacji.
Jedną z głównych przeszkód w automatycznej integracji usług jest różnorodność słownictwa,
protokołów i procesów. WSMO powstało między innymi po to, aby te niezgodności
wyrównywać i pokonywać. Do tego celu wykorzystuje mediatory.
Współpraca biznesowa może być zakładana bez wcześniejszego uzgadniania różnic w
danych, procesach i protokołach, jakie mogą być oczekiwane. Mediatory WSMO zapewniają
bezpośrednią analizę różnorodności partnerów biznesowych i przezwyciężają ją w celu
umożliwienia płynnej integracji.
Opis WSMO
Opisanie
celu
Opisanie
usługi
Opisanie
celu
Opisanie
celu
Opisanie
celu
Opisanie
celu
Opisanie
celu
użytkownik
dostawca
Wykonanie WSMO
Rysunek 9 Wykorzystanie WSMO przez partnerów biznesowych
Powyższy rysunek przedstawia, w jaki sposób partnerzy biznesowi mogą wykorzystać
WSMO do interakcji w elastyczny i dynamiczny sposób. Lewa strona wskazuje proces
znajdowania dostawcy oczekiwanej usługi, prawa strona przedstawia proces opisywania i
oferowania konkretnej usługi.
Opis możliwych do wielokrotnego wykorzystania mediatorów pozwala zakładać dynamiczne,
biznesowe relacje, jako że nie jest wymagana żadna specjalnie dostosowana infrastruktura
dla partnerów korzystających z usług sieciowych. Infrastruktura mediatorów WSMO może
być wykorzystana do efektywnej i dynamicznej integracji. Mediatory łączą słownictwo oraz
style interakcji użytkowników, zapewniając w ten sposób możliwe do ponownego użycia
rozwiązania różnorodnych procesów biznesowych. Zatem WSMO zapewnia „bezszwowe”
działania wewnętrzne z różnymi usługami sieciowymi, eliminując kosztowną zależność
danych usług od nowych partnerów biznesowych. Ponieważ koszt lokalizacji nowych
użytkowników i wewnętrznych interakcji z nimi jest znacznie zredukowany, możliwa staje się
integracja wielu różnych usług i optymalizacja kosztów efektywności (zaufania i
bezpieczeństwa również) wymaganych usług. Podnosi się jakość procesów biznesowych,
ponieważ każda realizowana usługa może być automatycznie zastąpiona w razie błędu.
Proces działania WSMO z perspektywy odbiorcy usługi:
• Opisywanie celów. Użytkownik formalnie opisuje żądaną funkcjonalność używając
terminów z ontologii.
• Odkrywanie usług. Opisany przez użytkownika cel jest łączony z opisami różnych
usług. Mediatory pomagają w procesie odkrywania poprzez łączenie różnego
słownictwa używanego do opisu celów i usług.
• Selekcjonowanie usług. Kiedy zostanie znaleziona pewna liczba usług oferujących
poszukiwaną funkcjonalność, musi zostać wybrana właściwa usługa i określony pewien
poziom zgodności. Ten proces często wymaga interakcji z dostawcą usługi. Wynikiem
tego kroku jest wyselekcjonowanie właściwej usługi lub usług.
• Działania wewnętrzne. Wykonanie usługi, mediatory pomagają tłumaczyć dane
między różnymi reprezentacjami i przezwyciężać te różnice.
Proces działania WSMO z perspektywy dostawcy usługi:
• Opis
usługi
sieciowej.
Opisywane
są
możliwości
usługi
w
funkcjonalności oraz w terminach interfejsu (orkiestracja i choreografia).
terminach
jej
Możliwości – są formalnym opisem funkcjonalności usługi z uwzględnieniem
założeń, warunków wstępnych, efektów i warunków końcowych.
Choreografia – opisuje sposób interakcji usługi. Formalnie określa jakie rodzaje
wiadomości są oczekiwane jako dane wejściowe a jakie jako dane wyjściowe.
Choreografia jest interfejsem usługi przedstawianym użytkownikowi.
Orkiestracja – opisuje sposób, w jaki dana usługa wykorzystuje inne do uzyskania
wymaganej funkcjonalności. Może być traktowana jako interfejs usługi dla innych
dostawców usług.
Zarówno choreografia jak i orkiestracja stanowią dekompozycję funkcjonalności
opisanej w możliwościach, opisują sposoby osiągania funkcjonalności. Poniższy
rysunek przedstawia relacje między możliwościami, choreografią a orkiestracją.
• Ogłaszanie usług. W celu ułatwienia odkrywania usług są one ogłaszane w
specjalnych repozytoriach usług.
• Działania wewnętrzne. Ten krok jest taki sam jak z punktu widzenia odbiorcy usługi.
Opis usługi sieciowej
Możliwości
przed ⇒ po
Zewnętrzna
usługa sieciowa
Możliwości
przed ⇒ po
choreografia
orkiestracja
choreografia
Rysunek 10 Wewnętrzne działanie WSMO
Podsumowując, WSMO zapewnia ramy do opisu semantycznych usług sieciowych, które
umożliwiają integrację procesów korzystania z usług sieciowych przez formalne opisy,
maksymalne rozdzielenie poszczególnych komponentów i silne wsparcie mediatorów.
2.18. WSML
WSML (Web Service Modeling Language) jest językiem do opisywania i specyfikacji ontologii
oraz różnych aspektów usług sieciowych. Zapewnia składnię i semantykę dla WSMO. WSML
wykorzystuje formuły logiczne w celu ułatwienia opisu różnorodnych aspektów związanych z
semantycznymi usługami sieciowymi.
WSML składa się z kilku wariantów języka: WSML-Core, WSML-DL, WSML-Flight, WSMLRule oraz WSML-Full.
WSML ma na celu zapewnienie środków do formalnego opisu wszystkich elementów
zdefiniowanych w WSMO. Różne warianty języka odpowiadają różnym poziomom
logicznego zaawansowania takim jak: logice deskrypcyjnej (Description Logics), logice
pierwszego rzędu (First-Order Logic) i programowaniu logicznym (Logic Programming) oraz
wykorzystaniu różnych standardów językowych.
WSML-Core – koresponduje z przecięciem logiki deskrypcyjnej oraz Horn Logic (bez
symboli funkcji i równości), rozszerzony przez wsparcie typów danych w celu przydatności w
aplikacjach praktycznych. Jest w pełni zgodny z podzbiorami OWL. WSML-Core ma
najmniejszą moc wyrazistości, ale najbardziej pożądane własności obliczeniowe. Głównymi
cechami języka są: wsparcie modelowania klas, atrybutów, relacji binarnych oraz instancji.
Wspiera hierarchię klas oraz relacji, zapewnia wsparcie typów danych oraz ich predykatów.
Ontologie i semantyczne usługi sieciowe potrzebują formalnych języków dla ich specyfikacji
w celu umożliwienia automatycznego przetwarzania. Rekomendowany przez W3C język
OWL do opisu ontologii ma pewne ograniczenia na poziomie pojęciowym oraz pod
względem niektórych formalnych właściwości. Dlatego propozycją do opisu semantycznych
usług sieciowych jest OWL-S. Jednak okazuje się, że OWL-S ma poważne ograniczenia na
poziomie pojęciowym i również formalne właściwości języka nie są całkowicie jasne. Na
przykład OWL-S oferuje wybór pomiędzy różnymi językami do specyfikacji warunków
wstępnych i rezultatów. Jednak nie jest całkiem jasne jak te języki oddziałują z OWL, który
jest używany do specyfikowania danych wejściowych i wyjściowych. Te nierozwiązane
problemy były głównym motywem do zapewnienia alternatywnego, ujednoliconego języka
dla WSMO jakim jest WSML.
2.18.1.1.
Struktura
1) Podstawy składni WSML
Oznaczenia używane do opisu składni WSML:
| - oddziela alternatywne elementy,
? - dodawany na końcu elementów opcjonalnych,
* - dodawana na końcu elementów mogących występować zero lub więcej razy,
+ - dodawany na końcu elementów mogących występować jeden lub więcej razy,
Składnia WSML składa się z dwóch podstawowych części: składni pojęciowej (modelowanie
ontologii, celów, usług sieciowych i mediatorów – elementów pojęciowego modelu WSMO) i
składni wyrażeń logicznych (udoskonalanie poprzednich definicji za pomocą języka
logicznego).
Struktura dokumentu WSML
WSML
=
Definicja =
WSML wariant?
przestrzeń nazw?
definicja*
cel
| ontologia
| usługa sieciowa
| mediator
Składnia pojęciowa WSML ma styl ramowy. Informacja o klasach i ich atrybutach, relacjach i
parametrach, instancjach i wartościach ich atrybutów jest przedstawiana w jednej dużej
syntaktycznej konstrukcji, zamiast dzielenia na pojedyncze kawałki. Możliwe jest
rozprzestrzenianie informacji o danym elemencie na różne konstrukcje (jednak niepolecane).
Ważnym elementem odróżniającym od OWL jest to, że atrybuty są definiowane lokalnie dla
klasy i w zasadzie nie powinny być używane poza kontekstem klasy i jej podklas.
Mimo to nazwy atrybutów są globalne i istnieje możliwość specyfikowania globalnego
zachowania atrybutów poprzez logiczne wyrażenia. W przypadku potrzeby modelowania
właściwości niezależnej od definicji pojęcia, ta właściwość jest raczej relacją niż atrybutem i
powinna być modelowana jak relacja.
Możliwe jest określenie listy argumentów, np. dla atrybutów. Takie listy w WSML są
oddzielane przecinkami i otoczone nawiasami klamrowymi. Zdanie w WSML zaczyna się
słowem kluczowym i może zajmować kilka linijek.
Specyfikacja WSML podzielona jest na dwie części. Pierwsza zapewnia meta-informacje o
specyfikacji i składa się z takich elementów jak identyfikacja wariantu języka, odniesienia do
przestrzeni nazw, niefunkcjonalne właściwości (adnotacje), importowanie ontologii oraz
odniesienia do mediatorów. Ta część jest ściśle uporządkowana. Druga część złożona z
takich elementów jak pojęcia, atrybuty, relacje (w przypadku specyfikacji ontologii),
możliwości
interfejsu
(w
przypadku
nieuporządkowana.
a) Przestrzenie nazw w WSML
specyfikacji
celów
usługi
sieciowej)
jest
Nazwy w innych specyfikacjach:
W XML każda nazwa kwalifikowana jest krotką <przestrzeń nazw, nazwa lokalna>. W
RDF zaadaptowany jest mechanizm nazw XML z tym, że nazwy kwalifikowane nie są
traktowane jak krotki, ale raczej jak skróty dla pełnych identyfikatorów URI.
WSML wykorzystuje mechanizm RDF. Przestrzeń nazw może być widziana jako część IRI
(Internationalized Resource Identifiers), słowa kluczowe należą do przestrzeni nazw
http://www.wsmo.org/wsml/wsml-syntax# (potocznie skracanej jako ‘wsml’).
Przestrzenie nazw mogą być używane do syntaktycznego rozróżniania elementów w
różnych specyfikacjach WSML, a bardziej ogólnie zasobów sieci www. Przestrzeń nazw
wskazuje syntaktyczną domenę dla zasobu nazwy.
Jeżeli WSML ma identyfikator korespondujący z adresem www to dobrze jest mieć
odpowiedni dokument zlokalizowany w miejscu wskazanym przez identyfikator. Może to
być dokument WSML lub dokument w naturalnym języku związany z dokumentem WSML.
Należy zwrócić uwagę, że identyfikator ontologii nie musi pokrywać się z lokalizacją
ontologii. Dobrze jest jednak dołączać powiązane dokumenty wskazujące specyfikację
WSML w lokalizacji wskazanej przez identyfikator.
b) Identyfikatory
Identyfikator w WSML jest raczej wartością danych IRI niż anonimowym identyfikatorem
ID.
WSML ma bezpośrednie wsparcie typów danych, mianowicie stringi, liczby całkowite i
ułamki dziesiętne, które odpowiadają typom danych z XML Schema: string, integer,
decimal. Te mogą być używane do tworzenia bardziej złożonych typów danych przy
użyciu odpowiednich funkcji będących konstruktorami typów danych.
WSML używa specjalnych opakowań do konstruowania typów danych co zapewnia
lepszą kontrolę struktury wartości danych niż leksykalna reprezentacja XML. Na przykład
data 3 lutego 2006 zapisywana w XML jako '2006-02-03', w WSML jest zapisywana jako
_date(2006,2,3). Argumenty takiego terminu mogą być stringami, liczbami całkowitymi,
ułamkami dziesiętnymi lub zmiennymi, żadne inne argumenty nie są dozwolone. Każda
implementacja WSML powinna wspierać przynajmniej typy danych string, integer,
decimal.
Identyfikatory typów danych w WSML można przedstawiać na dwa sposoby: jako
identyfikatory pojęć i opakowania typów danych. Opakowanie jest używane jako struktura
danych obejmująca różne komponenty wartości danych. Identyfikatory typów danych
mogą być również używane bezpośrednio jako identyfikatory pojęć. Należy zwrócić
uwagę, że domena interpretacji jakiegoś typu danych jest skończona i element danego
typu danych dla wartości, która faktycznie nie należy do tego typu prowadzi do
niezgodności w bazie wiedzy.
Przykłady wartości danych:
_date(2005,3,12)
_sqname(http://www.wsml.org/wsml/wsml-syntax#,”goal”)
_boolean(“true”)
Przykłady definicji atrybutów ograniczających zasięg atrybutu do konkretnego typu
danych:
age ofType _integer
location ofType _iri
hasChildren ofType _boolean
WSML pozwala na następujące syntaktyczne skróty dla poszczególnych typów danych:
• string może być zapisywany w podwójnym cudzysłowu ””””, kolejny cudzysłów
wewnątrz stringa powinien być poprzedzony ukośnikiem \,
• liczby całkowite mogą być zapisywane po prostu jako liczby; np. 4 jest skrótem od
_integer("4"),
• ułamki dziesiętne mogą być zapisywane w swej naturalnej postaci przy użyciu
kropki, np. 4.2 jest skrótem od _decimal("4.2").
integer
= ‘-‘? digit+
decimal
= ‘-‘? digit+ ‘.’ digit+
string
= “” tring_content* “”
string_content = escaped char | not escape char not dquote
Mechanizm IRI zapewnia sposób identyfikacji zasobu. Może wskazywać zasób na stronie
www (‘http://...’), jednak nie tylko. Standard IRI powstał na bazie URI, każdy identyfikator
URI jest IRI.
IRI może być skrótem od sQName ('serialized QName'). sQName składa się z dwóch
części: prefiksu przestrzeni nazw oraz części lokalnej. sQName może być widziane jako
typ danych i wtedy ma odpowiednie opakowanie z dwoma argumentami (przestrzeń
nazw, nazwa lokalna). sQName może być zapisywana w prosty sposób jako prefiks
przestrzeni nazw i nazwa lokalna oddzielone znakiem #: namespace_prefix#localname.
IRI jest typem danych w WSML i ma odpowiednio skojarzone opakowanie typu nazw. Dla
wygody WSML pozwala na krótkie formy z separatorami ' _" ' oraz ' " '.
full_iri
=
‘_”’ iri_reference ””
sQName
=
(name ‘#’)? name
iri
=
full_iri
| sqname
Przykłady sQName w WSML wraz z pełnymi IRI:
• dc#title (http://purl.org/dc/elements/1.1#title),
• foaf#name (http://xmlns.com/foaf/0.1/name),
• hasChild (http://example.org/#hasChild).
WSML definiuje dwa pełne URI, które oznaczają uniwersalną prawdę i uniwersalny fałsz:
http://www.wsmo.org/wsml/wsml-syntax#true,
http://www.wsmo.org/wsml/wsml-syntax#false
Ale znacznie częściej używa się ich skróconych form wsml#true, wsml#false.
Anonimowe identyfikatory reprezentują IRI, które powinny być globalnie jednoznaczne.
Globalna jednoznaczność jest zapewniana przez system interpretujący opis WSML. Może
być używana kiedy konkretny identyfikator używany do wskazywania obiektu jest
nieodpowiedni, ale wymagane jest aby identyfikator był nowy. Nienumerowane
anonimowe identyfikatory są wskazywane przez ‘_#’. Różne wystąpienia ‘_#’ nie są
powiązane, każdy wskazuje inny identyfikator anonimowy. Numerowane identyfikatory są
wskazywane przez ‘_#n’, gdzie n oznacza liczbę identyfikatorów (integer). Numerowane
identyfikatory nie mogą być używane do wskazywania jednostek w składni pojęciowej.
Wielokrotne pojawianie się tego samego numerowanego identyfikatora wewnątrz tego
samego logicznego wyrażenia jest interpretowane jako wskazanie tego samego obiektu.
anonymous
=
nb_anonymous =
‘_#’
‘_#’ digit+
Przykłady wykorzystania w logicznych wyrażeniach:
_#[a hasValue _#1] and _#1 memberOf b,
_#1[a hasValue _#] and _# memberOf _#
W powyższym przykładzie są trzy wystąpienia nienumerowanego anonimowego
identyfikatora. Wszystkie są niepowiązane. Drugie wyrażenie wskazuje, że pewien
anonimowy obiekt jest elementem innego anonimowego obiektu. Dwa wystąpienia _#1 w
pierwszym wyrażeniu wskazują ten sam obiekt. W ten sposób wartość atrybutu a jest
elementem b. Wystąpienie _#1 w drugim wyrażeniu nie jest powiązane z poprzednimi.
Użycie identyfikatorów przy wymienianiu elementów WSML jest opcjonalne. Gdy nie
pojawia się żaden identyfikator obowiązują następujące zasady:
• w przypadku braku identyfikatora ontologii, usługi sieciowej, celu lub mediatora
przyjmuje się, że identyfikator jest taki sam jak lokalizator specyfikacji, np.
lokalizacja znalezienia specyfikacji,
• w przypadku braku identyfikatora elementu WSML (pojęcie, relacja itp.) do
identyfikacji jest używany anonimowy nienumerowany identyfikator.
id
=
iri
| anonumous
| ‘true’
| ‘false’
id_list
=
id
| ‘{‘ id ( ‘.’ Id )* ’}’
Ten sam identyfikator jest używany dla różnych definicji i jest różnie interpretowany w
zależności od kontekstu. W definicji pojęcia identyfikator jest interpretowany jako pojęcie,
w definicji relacji jako relacja. Natomiast jeżeli ten sam identyfikator jest używany w
różnych definicjach, ale w tym samym kontekście, to interpretacja musi przystosować się
do obu definicji i są one interpretowane koniunktywnie. Na przykład jeśli są dwie definicje
pojęcia, których dotyczy ten sam identyfikator to wynikowa definicja pojęcia będzie
zawierać wszystkie atrybuty oryginalnych definicji i jeżeli ten sam atrybut jest
zdefiniowany w obu definicjach, zasięg wynikowego atrybutu będzie równoważny
iloczynowi zasięgów oryginalnych atrybutów.
Zbiory identyfikatorów elementów wyższego poziomu (ontologie, cele, usługi sieciowe,
mediatory) są parami rozłączne i rozłączne z innymi identyfikatorami.
c) Komentarze
Plik WSML może w dowolnym miejscu zawierać komentarz. Pojedyncza linia komentarza
zaczyna się od comment lub // i kończy się przerwą jednej linii. Komentarze występujące
w wielu linijkach wymagają na początku i na końcu znaków /* i */.
comment
= short_comment | long_comment
short_comment
= (‘//’ | ‘comment ’) not cr If* eol
long_comment
= ‘/*’ long comment content* ‘*/’
Zaleca się używać niefunkcjonalnych właściwości dla informacji związanych z aktualnym
opisem WSML, komentarze powinny być używane tylko dla meta-danych o pliku WSML.
Komentarze są omijane podczas analizowania dokumentu WSML.
d) Typy mimiczne (MIME type)
Podczas dostępu do zasobu sieci www typ MIME wskazuje typ zasobu. Np. zwykły
dokument tekstowy ma mimiczny typ text/plain a dokument XML na typ application/xml.
Podczas wymiany dokumentów WSML napisanych w normatywnej składni konieczne jest
używanie odpowiednich typów mimicznych tak, aby automatyczni agenci mogli wykryć typ
zawartości dokumentu. Typ dokumentów WSML to application/x-wsml.
Dokumenty WSML/XML mają typ mimiczny application/x-wsml+xml.
2) Elementy WSML
Ta sekcja opisuje elementy wspólne dla wszystkich typów specyfikacji WSML oraz
wariantów języka. Elementy tu opisane są używane w ontologiach, celach, mediatorach i w
specyfikacji usług sieciowych. Wszystkie elementy tu opisane mają coś wspólnego z metainformacją o specyfikacji i w ten sposób nie zależą od logicznego formalizmu języka, są one
dzielone między wszystkie warianty WSML.
a) Warianty WSML
Każdy dokument WSML może zaczynać się słowem kluczowym wsmlVariant, po nim
następuje identyfikator wariantu używanego w dokumencie.
WSML Variant
IRI
WSML-Core
http://www.wsmo.org/wsml/wsml-syntax/wsml-core
WSML-Flight
http://www.wsmo.org/wsml/wsml-syntax/wsml-flight
WSML Variant
IRI
WSML-Rule
http://www.wsmo.org/wsml/wsml-syntax/wsml-rule
WSML-DL
http://www.wsmo.org/wsml/wsml-syntax/wsml-dl
WSML-Full
http://www.wsmo.org/wsml/wsml-syntax/wsml-full
Tabela 26 Warianty WSML i odpowiadające im identyfikatory
Określenie wariantu języka nie jest obowiązkowe; jeśli wariant nie jest określony
najprawdopodobniej zostanie przyjęte, że jest to WSML-Full.
Poniższy przykład ilustruje referencję wariantu WSML dla specyfikacji WSML-Flight:
wsmlVariant _http://www.wsmo.org/wsml/wsml-syntax/wsml-flight
Jeżeli wariant WSML jest określony to narzędzia mogą natychmiast rozpoznać intencje
autora i zwrócić informację, jeżeli specyfikacja nie pasuje do syntaktycznych ograniczeń
wymaganych przez dany wariant.
b) Referencje do przestrzeni nazw
W dokumencie WSML istnieje opcjonalny blok referencji do przestrzeni nazw
poprzedzony przez słowo kluczowe namespace. Po nim następują referencje. Każda
referencja składa się z wybranego prefiksu oraz IRI identyfikującego przestrzeń. Lista
referencji jest ograniczona nawiasami klamrowymi.
namespace
=
prefixdefinitionlist =
‘namespace’ prefixdefinitionlist
full iri
| ‘{‘ prefixdefinition ( ‘,’ prefixdefinition )* ‘}’
prefixdefinition
=
name full iri
| full iri
Przykład definicji przestrzeni nazw:
namespace {_"http://www.example.org/ontologies/example#",
dc _"http://purl.org/dc/elements/1.1#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/wsml-syntax#",
loc _"http://www.wsmo.org/ontologies/location#",
oo _"http://example.org/ooMediator#"}
c) Nagłówki
Każda specyfikacja WSML ma niefunkcjonalne właściwości, może importować ontologie i
używać mediatorów.
header
=
nfp
| importsontology
| usesmediator
Niefunkcjonalne właściwości mogą być używane w całym dokumencie lub osobno dla
każdego elementu specyfikacji. Bloki tych właściwości są ograniczone słowami
kluczowymi nonFunctionalProperties i endNonFunctionalProperties lub skrótami nfp i
endnfp. Takie słowo kluczowe jest listą wartości atrybutów, która składa się z
identyfikatora atrybutu, słowa kluczowego hasValue, wartości dla danego atrybutu,
wartości danych i anonimowego identyfikatora. Rekomendowane właściwości są w Dublin
Core, przykłady innych niewystępujących w Dublin Core: wsml#version, wsml#accuracy,
wsml#financial,
wsml#networkRelatedQoS,
wsml#performance,
wsml#reliability,
wsml#robustness, wsml#scalability, wsml#security, wsml#transactional, wsml#trust.
nfp
=
‘nfp’ attributevalue* ‘endnfp’
| ‘nonFunctionalProperties’ attributevalue* ‘endnonFunctionalProperties’
Przykład:
nonFunctionalProperties
dc#title hasValue "WSML example ontology"
dc#subject hasValue "family"
dc#description hasValue "fragments of a family ontology to
provide WSML examples"
dc#contributor
hasValue
{
_"http://homepage.uibk.ac.at/~c703240/foaf.rdf",
_"http://homepage.uibk.ac.at/~csaa5569/",
_"http://homepage.uibk.ac.at/~c703239/foaf.rdf",
_"http://homepage.uibk.ac.at/homepage/~c703319/foaf.rdf" }
dc#date hasValue _date("2004-11-22")
dc#format hasValue "text/html"
dc#language hasValue "en-US"
dc#rights hasValue _"http://www.deri.org/privacy.html"
wsml#version hasValue "$Revision: 1.191 $"
endNonFunctionalProperties
Właściwości niefunkcjonalne nie są częścią języka logicznego.
Ontologie mogą być importowane w dowolnej specyfikacji WSML przez blok importu
ontologii identyfikowany słowem kluczowym importsOntology. Stanowi on listę
identyfikatorów IRI wskazujących ontologie importowane. Definicja służy do łączenia
ontologii w sposób podobny do importowania ontologii w OWL za pomocą owl:import.
Oznacza to, że wynikowa ontologia jest sumą aksjomatów i definicji ontologii importującej
i importowanej. Wspierane jest również rekurencyjne importowanie ontologii. Oznacza to
importowanie wszystkich ontologii zaimportowanych przez importowaną ontologię.
importsontology
=
‘importsOntology’ idlist
Przykład:
importsOntology {_"http://www.wsmo.org/ontologies/location",
_"http://xmlns.com/foaf/0.1"}
Jeżeli importowana ontologia jest innego wariantu niż importująca, wynikowa ontologia
będzie miała wariant bardziej ekspresyjny.
Mediatory używane są do łączenia różnych elementów WSML (ontologii, celów, usług) i
rozwiązywania problemu niespójności między nimi. Opcjonalny blok mediatorów
rozpoczyna się słowem kluczowym usesMediator, po którym następują jeden lub więcej
identyfikatorów mediatorów. Ontologia pozwala na wykorzystanie innych mediatorów niż
cele czy usługi. Typ mediatora jest odzwierciedlony w samej specyfikacji mediatora a nie
w referencji do mediatora.
usesmediator
=
‘usesMediator’ idlist
Przykład:
usesMediator _"http://example.org/ooMediator"
3) Specyfikacja ontologii w WSML
Specyfikacja ontologii w WSML jest identyfikowana słowem kluczowym ontology z
opcjonalnym IRI, który dostarcza identyfikatora ontologii.
Dokument specyfikujący ontologię w WSML składa się z następujących elementów:
ontology
=
‘ontology’ id? Header* ontology element*
ontology_element
=
concept
| relation
| instance
| relationinstance
| axiom
Elementy tworzące ontologię w WSML bazują na pojęciowym modelu.
a) Pojęcia
Definicja pojęcia rozpoczyna się słowem kluczowym concept, po którym opcjonalnie
następuje
identyfikator
pojęcia
oraz
podpojęcie
określone
słowem
kluczowym
subConceptOf, po którym wymieniane są identyfikatory innych pojęć.
WSML pozwala na dziedzicznie atrybutów definicji (pojęcie dziedziczy wszystkie atrybuty
definicji swojego nadrzędnego pojęcia). Jeżeli dwa pojęcia nadrzędne do danego mają
definicję tego samego atrybutu, jednak o innym zasięgu, to są one interpretowane
koniunktywnie. Oznacza to, że zasięg wynikowego atrybutu podpojęcia jest przecięciem
zasięgów definicji tego atrybutu dla pojęć nadrzędnych.
concept
=
‘concept’ id superconcept? nfp? attribute*
superconcept
=
‘subConceptOf’ idlist
Przykład:
concept Human subConceptOf {Primate, LegalAgent}
dc#description hasValue "concept of a human being"
dc#relation hasValue humanDefinition
hasName ofType foaf#name
hasParent impliesType Human
hasChild impliesType Human
hasAncestor impliesType Human
hasWeight ofType _float
hasWeightInKG ofType _float
hasBirthdate ofType _date
hasObit ofType _date
hasBirthplace ofType loc#location
isMarriedTo impliesType Human
hasCitizenship ofType oo#country
WSML posiada możliwość tworzenia aksjomatów usprawniających definicje istniejące w
składni pojęciowej języka. Zaleca się zamieszczanie relacji między pojęciami a
związanymi z nimi aksjomatami w niefunkcjonalnych właściwościach poprzez właściwość
dc#relation. W powyższym przykładzie istnieje odwołanie do aksjomatu z identyfikatorem
humanDefinition.
Różne języki reprezentacji wiedzy, takie jak logika deskrypcyjna, pozwalają na
specyfikację „definiowanych pojęć” (nazywanych kompletnymi klasami w OWL).
Definiowanie takiego pojęcia nie jest konieczne, ale użyteczne. Definicja pojęcia musi
wymieniać konsekwencje członkostwa pojęcia dla wszystkich instancji. Definicja pojęcia
Human mówi, że jest ono instancją Primate i LegalAgent. Ponadto wszystkie wartości
atrybutów hasName, hasParent, hasWeight, muszą być określonych typów. Jeżeli dana
właściwość domaga się instancji to wnioskuje się, że instancja musi być elementem tego
pojęcia. Logiczne wyrażenia zawarte w aksjomacie powinny przedstawiać równoważność
relacji między wyrażeniem członkostwa w klasie z jednej strony a koniunkcją wyrażeń
członkostwa w klasie z drugiej strony, każde z takimi samymi zmiennymi. Powinna być
zatem następująca definicja formy:
?x memberOf A equivalent ?x memberOf B1 and ... and ?x memberOf Bn
gdzie A, B1,...,Bn są identyfikatorami pojęć.
Na przykład w celu zdefiniowania klasy Human jako przecięcia klas Primate i LegalAgent
używa się następującej definicji:
axiom humanDefinition
definedBy
?x memberOf Human equivalent ?x memberOf Primate and ?x memberOf
LegalAgent.
Dwa istotne elementy modelowania atrybutów odróżniające WSML od OWL to
ograniczenia ilości oraz zasięgu atrybutu. OWL zapewnia te ograniczenia na atrybutach,
które służą do tworzenia dodatkowych wniosków, takich jak istnienie czy równość
obiektów lub elementów w danej klasie. Dla wielu użytkowników te ograniczenia pokazują
nieintuicyjne zachowanie z punktu widzenia klasycznych zasad języków i baz danych. W
OWL brakuje środków do właściwego sprawdzania danych w bazie wiedzy pod względem
integralności ograniczeń. WSML pozwala na specyfikację tych ograniczeń, które są
zdefiniowane jako integralne ograniczenia w bazie danych. Np. w przypadku zakłóceń w
ograniczeniach dana ontologia jest niespójna. Te dodatkowe elementy pozwalają na
sprawdzanie integralności zamkniętego zbioru danych.
WSML pozwala na dwa rodzaje definiowania atrybutów:
ofType - A ofType D, gdzie A
jest identyfikatorem atrybutu a D pojęcia, jest
ograniczeniem wartości dla atrybutu. Ograniczenie jest naruszone a wartość atrybutu jest
niespójna w związku z ontologią. Ten zapis koresponduje ze zwykłym bazodanowym
stylem ograniczeń.
impliesType – używane do wnioskowania konkretnego typu wartości atrybutu. A
impliesType D, gdzie A jest identyfikatorem atrybutu a D pojęcia, mówi, że wszystkie
wartości atrybutu A są elementami pojęcia D.
WSML-Core i WSML-DL nie pozwalają na ograniczanie definicji atrybutów. W celu
ulepszenia modelowania w tych wariantach języka dozwolone jest użycie impliesType.
Jeżeli zasięg atrybutu jest typem danych to semantyki obu powyższych definicji pokrywają
się, ponieważ typy danych mają znaną dziedzinę i w ten sposób wartości nie mogą być
uważane za będące określonego typu.
Atrybuty mające typ danych jako zasięg mogą być rozróżniane od regularnych atrybutów
przez meta-concept _datatype. Każdy typ danych użyty w WSML jest elementem metapojęcia.
Atrybuty niemające zasięgu będącego typem danych mogą być wymieniane jako zwrotne,
symetryczne, przechodnie lub odwrotne do innego atrybutu przy pomocy słów kluczowych
reflexive, transitive, symmetric i inverseOf. Te słowa kluczowe nie wymuszają
ograniczenia na atrybutach, ale służą do określania dodatkowej informacji o atrybucie
(lepsze wnioskowanie). inverseOf musi zawierać identyfikator atrybutu, którego jest
odwrotnością.
Ograniczenie ilości (cardinality) wartości dla pojedynczego atrybutu wymienia się po
ofType, impliesType za pomocą dwóch liczb w nawiasach okrągłych oznaczających
minimalną
i
maksymalną
moc
(w
tej
właśnie
kolejności),
gwiazdka
oznacza
nieograniczoną maksymalną moc (niedozwolona dla minimalnej), jedna liczba jest
interpretowana jako minimalna i maksymalna moc jednocześnie, gdy nie ma ograniczeń
na moc narzędzia przyjmują, że jest ona (0,*). Maksymalna moc 1 powoduje, że atrybut
staje się funkcyjny.
attribute
=
[attr]: id attributefaeture* att type cardinality?
[type]: idlist nfp?
att_type
=
‘ofType’ | ‘impliesType’
cardinality
=
‘(’ [min_cardinality]: digit+ [max_cardinality]:
cardinality number? ‘)’
cardinality_number
=
{finite_cardinality}: digit+ | {infinite_cardinality}: ‘*’
attributefeature
=
‘transitive’ | ‘symmetric’ | ‘reflexive’
| ‘inverseOf’ ‘(‘ id ‘)’
Przykład definicji pojęcia z definicjami atrybutów:
concept Human
hasParent inverseOf(hasChild) impliesType Human
hasChild impliesType Human
hasAncestor transitive impliesType Human
hasWeight ofType (1) _float
hasWeightInKG ofType (1) _float
hasBirthdate ofType (1) _date
hasObit ofType (0 1) _date
hasBirthplace ofType (1) loc#location
isMarriedTo symmetric impliesType (0 1) Human
hasCitizenship ofType oo#country
b) Relacje
Definicja relacji zaczyna się słowem kluczowym relation, po którym opcjonalnie następuje
identyfikator relacji. WSML pozwala na definiowanie relacji o dowolnej liczbie
argumentów. Dziedzina parametrów może być określana za pomocą impliesType, ofType.
Parametry relacji są ściśle uporządkowane, istnieje możliwość definiowania podrelacji. Na
końcu określa się opcjonalnie blok nonFunctionalProperties.
Relacje w WSML mogą mieć dowolną ilość argumentów i wartości dla parametrów i mogą
być ograniczane za pomocą ofType (nazwa typu) i impliesType (nazwa typu). Definicja
relacji wymaga albo wskazania ilości argumentów, albo definicji parametrów. typeOf
ogranicza dozwoloną liczbę parametrów, impliesType określa elementy pojęcia wartości
parametru.
Relation
=
‘relation’ id arity? paramtyping? superrelation? nfp?
arity
=
‘/’ pos_integer
paramtyping
=
‘(‘ paramtype moreparamtype* ‘)’
paramtype
=
att_type idlist
moreparamtype =
‘,’ paramtype
superrelation
‘subRelationOf’ idlist
=
Przykłady, pierwszy z definicją parametru, drugi z definicją liczby argumentów:
relation distance (ofType City, ofType City, impliesType _decimal)
subRelationOf measurement,
relation distance/3
Dokładne znaczenie relacji definiuje się za pomocą aksjomatów.
c) Instancje
Definicja instancji rozpoczyna się słowem kluczowym instancje, po którym opcjonalnie
występuje identyfikator instancji, słowo kluczowe memberOf i nazwa pojęcia, do którego
instancja należy. Pojawiają się również wartości atrybutów związanych z instancją. Każda
właściwość musi posiadać identyfikator, słowo kluczowe hasValue i wartości atrybutów.
Instancje
=
‘instance’ id? memberof? nfp? attributevalue*
Memberof
=
‘memberOf’ idlist
attributevalue
=
id ‘hasValue’ valuelist
Przykład:
instance Mary memberOf {Parent, Woman}
nfp
dc#description hasValue "Mary is parent of the twins Paul and
Susan"
endnfp
hasName hasValue "Maria Smith"
hasBirthdate hasValue _date(1949,9,12)
hasChild hasValue {Paul, Susan}
Istnieją instancje bezpośrednio zdefiniowane w ontologii oraz instancje danych istniejące
poza ontologią w prywatnych zbiorach danych. Dostęp do tych instancji jest zapewniany
dzięki linkom do ich zbiorów. Nie ma żadnych ograniczeń co do sposobu połączenia
zbiorów pojęć z ontologią. Jest on definiowany na zewnątrz ontologii, aby umożliwić
dostęp do różnych zbiorów pojęć.
Można wymieniać instancje pojęć, ale również instancje relacji. Definicja takiej instancji
rozpoczyna się słowem kluczowym relationInstance, po którym może występować
identyfikator, słowo kluczowe memberOf wraz z nazwą relacji, do której instancja należy.
relationinstance
=
‘relationInstance’ [name]: id? [relation]: id
‘(‘ value (‘,’ value)* ‘)’ nfp?
4) Aksjomaty
Definicja aksjomatu składa się ze słowa kluczowego axiom, identyfikatora aksjomatu,
opcjonalnie bloku niefunkcjonalnej właściwości oraz logicznego wyrażenia poprzedzonego
słowem kluczowym definedBy. Po logicznym wyrażeniu następuje pusta lub nowa linia.
axiom
=
‘axiom’ axiomdefinition
axiomdefinition
=
id
| id? nfp? log definition
log_definition
=
‘definedBy’ log expr+
Przykład definicji aksjomatu:
axiom humanDefinition
definedBy
?x memberOf Human equivalent
?x memberOf Animal and
?x memberOf LegalAgent
WSML pozwala na specyfikacje bazodanowego stylu ograniczeń, na przykład:
axiom humanBMIConstraint
definedBy
!- naf bodyMassIndex(bmi hasValue ?b, length hasValue ?l, weight hasValue ?w)
and ?x memberOf Human and
?x[length hasValue ?l,
weight hasValue ?w,
bmi hasValue ?b].
5) Możliwości i specyfikacja interfejsu
Funkcjonalność WSML jest opisywana w formie możliwości. Oczekiwane możliwości są
częścią celów a zapewniane częścią usług sieciowych. Sposób połączenia wymagań i
rezultatów jest opisany w interfejsach jako część zarówno celów jak i usług.
a) Możliwości
Możliwości opisują funkcjonalność usługi sieciowej. Warunki wstępne opisują dane
wejściowe, warunki końcowe opisują relacje między danymi wejściowymi a efektami
końcowymi usługi, założenia opisują co musi mieć miejsce aby usługa działała sprawnie
natomiast efekty opisują realne wyniki działania usługi. Specyfikacja możliwości jest
opcjonalna.
Na początku definicji występuje słowo kluczowe capability, po nim identyfikator, blok
niefunkcjonalnych właściwości oraz bloki importowania ontologii i wykorzystania
mediatorów. Blok sharedVariables jest wykorzystywany do wskazywania zmiennych
dzielonych między warunki wstępne, warunki końcowe, założenia i efekty, które są
zdefiniowane odpowiednio za pomocą precondition, postcondition, assumption,
effect. Ilość takich definicji nie jest ograniczona.
capability
=
‘capability’ id? Header* sharedvardef? Pre post ass
or eff*
sharedvardef
=
‘sharedVariables’ variablelist
pre_post_ass_or_eff
=
‘precondition’ axiomdefinition
| ‘postcondition’ axiomdefinition
| ‘assumption’ axiomdefinition
| ‘effect’ axiomdefinition
Przykład:
capability
sharedVariables ?child
precondition
dc#description hasValue "The input has to be boy or
a girl
with birthdate in the past and be born in
Germany."
definedBy
?child memberOf Child
and ?child[hasBirthdate hasValue ?birthdate]
and ?child[hasBirthplace hasValue ?location]
and ?location[locatedIn hasValue oo#de]
or (?child[hasParent hasValue ?parent] and
?parent[hasCitizenship
hasValue
oo#de] ) .
effect
dc#description hasValue "After the registration the
child
is a German citizen"
definedBy
?child memberOf Child
and ?child[hasCitizenship hasValue oo#de].
b) Interfejs
Cele WSML mogą wymagać wielu interfejsów podobnie jak usługi mogą oferować wiele
interfejsów.
Definicja interfejsu zaczyna się słowem kluczowym interface, po którym występuje
identyfikator,
blok
niefunkcjonalnych właściwości,
bloki importowania ontologii i
wykorzystania mediatorów oraz blok choreografii zapoczątkowany słowem kluczowym
choreography lub blok orkiestracji ze słowem kluczowym orchestration. Interfejs może
mieć maksymalnie jedną choreografię i orkiestrację.
interfaces
=
interface | minterface
minterfaces
=
‘interface’ ‘{‘ id moreids* ‘}’
interface
=
‘interface’ id? header* choreography? orchestration?
choreography
=
‘choreography’ id
orchestration
=
‘orchestration’ id
Przykład:
interface
choreography _"http://example.org/mychoreography"
orchestration _http://example.org/myorchestration
6) Specyfikacja celów
Specyfikacja celów jest zdefiniowana słowem kluczowym goal, po którym opcjonalnie
występuje IRI służący jako identyfikator celu.
Przykład:
goal _"http://example.org/Germany/GetCitizenShip"
goal
=
‘goal’ id? header* capability? interfaces*
Elementy celów są możliwościami i interfejsami.
7) Specyfikacja mediatorów
WSML pozwala na używanie czterech rodzajów mediatorów, mediatorów ontologii,
mediatorów między usługami sieciowymi, mediatorów między celami i mediatorów między
celami a usługami. Odwołanie się do nich odbywa się za pomocą słów kluczowych
ooMediator, wwMediator, ggMediator i wgMediator. Po właściwym dla rodzaju mediatora
słowie kluczowym opcjonalnie następuje IRI identyfikujący mediator.
mediator
=
oomediator | wwmediator | ggmediator | wgmeditor
Przykład:
ooMediator _"http://example.org/ooMediator"
Wszystkie typy mediatorów mają taką samą składnię:
use_service
=
‘usesService’ id
source
=
‘source’ id
msource
=
‘source’ ‘{‘ id ( ‘,’ id )* ‘}’
sources
=
source | msources
target
=
‘target’ id
a) ooMediator
Wykorzystywane do łączenia ontologii z innymi ontologiami, usługami sieciowymi, celami i
innymi mediatorami. ooMediatory rozwiązują pojawiające się niejednorodności. Źródło
takiego mediatora może zawierać jedynie identyfikatory ontologii i innych ooMediatorów.
Za pomocą usesService identyfikowany jest cel, który opisuje usługę mediacji, usługa
sieciowa,
która
implementuje
mediację,
lub
wwMediator
łączący
takie
usługi.
Wskazywana jednostka jest dana za pomocą identyfikatora.
oomediator
=
‘ooMediator’ id? nfp? importedontology? sources target?
use service?
ooMediator jest używany do importowania ontologii lub jej części i rozwiązywania
niejednorodności. Pojęcie mediacji między ontologiami jest bardziej elastyczne niż
importowanie ontologii, które importuje ontologię WSML do innej specyfikacji WSML.
Mechanizm importowania dołącza definicje importowanej ontologii do specyfikacji
importującej.
Ontologie importujące mogą być
widziane
jako prosta forma mediacji, gdzie
różnorodności są usuwane, jednak zazwyczaj pozostają niedopasowania i zachodzenie
na siebie ontologii wymagających dodatkowej mediacji. Ponadto, jeżeli importowana
ontologia jest napisana w wariancie WSML o nieodpowiedniej wyrazistości, mediator
może być wykorzystany do uaktywnienia definicji w celu osiągnięcia żądanej
ekspresywności.
b) wwMediator
Łączą usługi sieciowe rozwiązując niejednorodności między danymi a procesami. Mogą
mieć tylko jedno źródło składające się z identyfikatora usługi albo innego wwMediatora.
wwmediator
=
‘wwMediator’ id? header* source? target? use service?
c) ggMediator
Łączą różne cele, umożliwiają ulepszanie bardziej ogólnych celów i w ten sposób
umożliwiają ponowne użycie definicji celów. Mogą mieć tylko jedno źródło składające się z
identyfikatora usługi albo innego ggMediatora.
ggmediator
=
‘ggMediator’ id? header* source? target? use service?
d) wgMediator
Łączą cele i usługi sieciowe rozwiązując niejednorodności między danymi a procesami.
Mogą mieć tylko jedno źródło składające się z identyfikatora usługi albo innego
wgMediatora.
wgmediator
=
‘wgMediator’ id? header* source? target? use service?
Poprzez uzewnętrznianie usług mediacji WSML pozwala na stratę elementów. Mediator jest
odpowiedzialny za wiązanie różnych elementów między sobą oraz rozwiązywanie
niejednorodności między nimi.
8) Specyfakcja usług sieciowych
Usługi sieciowe identyfikowane są słowem kluczowym webService, po którym opcjonalnie
występuje identyfikator usługi.
webservice
=
‘webService’ id? header* capability? interface*
Przykład:
webService _http://example.org/Germany/BirthRegistration
9) Logiczne wyrażenia w WSML
Wyrażenia logiczne występują wewnątrz aksjomatów i możliwości wymienianych w opisach
celów i semantycznych usług sieciowych. Ogólnie składnia wyrażeń logicznych w WSML
odpowiada składni wyrażeń logicznych WSML-Full.
Identyfikator Variables
Nazwy zmiennych poprzedzone są znakiem zapytania; zmienne mogą wystąpić w miejscu
pojęć, atrybutów, instancji, argumentów relacji lub wartości atrybutów. Zmienna nie może
jednak zastąpić słowa kluczowego i musi być używana wewnątrz wyrażenia logicznego.
Zakres zmiennych jest zawsze zdefiniowany przez ich kwantyfikację. Jeżeli ilość zmiennych
nie jest określona w formule, zmienna jest domyślnie kwantyfikowana na zewnątrz formuły o
ile nie jest częścią opisu możliwości i nie jest wymieniona w bloku sharedVariables.
variable
=
‘?’ alphanum+
Przykłady zmiennych:
?x, ?y1, ?myVariable
Definicje podstawowego słownictwa wyrażeń logicznych.
Definicja 9.1
Słownictwo V języka L(V) składa się z następujących elementów:
• Zbiór identyfikatorów V ID
• Zbiór konstruktorów obiektów VO ⊆ VID
• Zbiór symboli funkcji VF ⊆ VO
• Zbiór opakowań typów danych VD ⊆ VO
• Zbiór wartości danych VDV ⊆ VO , który obejmuje wszystkie stringi, liczby całkowite i
ułamki dziesiętne
• Zbiór anonimowych identyfikatorów V A ⊆ VO postaci _#, _#1, _#2 itd.
• Zbiór identyfikatorów relacji VR ⊆ VID
• Zbiór identyfikatorów zmiennych VV ⊆ VID
WSML pozwala na następujące operacje logiczne: koniunkcja (i), alternatywa (lub),
implikacja (wynika), implikacja wstecz, równoważność (wtedy i tylko wtedy), negacja
(nieprawda, że), negacja (jako błąd), kwantyfikator ogólny (dla każdego), kwantyfikator
szczegółowy (istnieje) oraz na następujące symbole pomocnicze: '(', ')', '[', ']', ',', '='
(równość), '!=' (nierówności), operator równości ':=:', memberOf, hasValue, subConceptOf,
ofType,
oraz
impliesType.
Ponadto
można
używać
symbolu
implikacji
‘:-’
dla
programowania logicznego oraz symbolu negacji ‘!-’ bazodanowego stylu zawartości.
Definicja 9.2
Zbiór terminów Term(V) w słownictwie V jest zdefiniowany następująco:
• dowolny konstruktor f ∈ VO jest terminem,
• dowolna zmienna v ∈ VV jest terminem,
• jeżeli f ∈ VV i t1 , ... , t n są terminami, to f (t1 , ... , t n ) jest terminem,
• jeżeli f ∈ V D i dv1 , ... , dvn ∈ VDV ∪ VV , to f (dv1 , ... , dvn ) jest terminem.
Zbiór podstawowych terminów GroundTerm(V) jest maksymalnym podzbiorem Term(V)
niezawierającym zmiennych.
W WSML występują formuły, zarówno pojedyncze jak i złożone.
Definicja 9.3
Zbiór pojedynczych formuł w L(V) jest zdefiniowany za pomocą następujących warunków:
• Jeżeli
α , β ∈ Term(V )
i
γ ∈ Term(V )
lub
γ
jest
formą
{γ 1 , ... , γ n } , gdzie
γ 1 , ... , γ n ∈ term(V ) , wtedy
o α subConceptOf γ jest pojedynczą formułą w L(V), α, γ oznaczają pojęcia,
o α memberOf γ jest pojedynczą formułą w L(V), α oznacza instancję, γ identyfikuje
pojęcie,
o α[β ofType γ] jest pojedynczą formułą w L(V), α oznacza instancję, β identyfikuje
atrybut a γ identyfikuje pojęcie,
o α[β hasValue γ] jest pojedynczą formułą w L(V), α oznacza instancję, β identyfikuje
atrybut a γ identyfikuje instancje.
Te pojedyncze formuły są nazywane również molekułami. Identyfikatory mogą
odgrywać różne role w zależności od wykorzystania molekuły.
• Jeżeli r ∈ V R i t1 , ... , t n są terminami to wtedy r (t1 , ... , t n ) jest pojedynczą formułą w
L(V).
• Jeżeli α , β ∈ Term(V ) wtedy α = β , α :=: β , α != β są pojedynczymi formułami w
L(V).
Definicja 9.4
Zbiór formuł w L(V) definiujemy następująco:
• Każda pojedyncza formuła w L(V) jest formułą w L(V).
• Niech α, β będą formułami niezawierającymi symboli ':-' i '!-' i niech ? x1 , ... , ? xn będą
zmiennymi, wtedy
o α and β jest formułą w L(V),
o α or β jest formułą w L(V),
o neg α jest formułą w L(V),
o naf α jest formułą w L(V),
o forall ? x1 , ... , ? xn (α) jest formułą w L(V),
o exists ? x1 , ... , ? xn (α) jest formułą w L(V),
o α implies β jest formułą w L(V),
o α impliedBy β jest formułą w L(V),
o α equivalent β jest formułą w L(V),
o α :- β jest formułą w L(V). Ta formuła jest nazywana regułą programowania
logicznego, α jest założeniem a β tezą reguły,
o !- α jest formułą w L(V). Tą formułę nazywamy ograniczeniem. α jest ograniczeniem
bazy wiedzy.
WSML pozwala na używanie symboli ->, <-, <-> zamiast odpowiednio implies, impliedBy, i
equivalent. Priorytet operatorów jest następujący: implies, equivalent, impliedBy < or,
and < neg, naf, co oznacza, że najsilniej wiążą negacje.
W celu polepszenia czytelności wyrażeń logicznych można używać skrótów koniunkcji
różnych molekuł z tym samym podmiotem, na przykład:
Human subConceptOf Mammal
and Human[hasName ofType foaf#name] and Human[hasChild impliesType Human].
może być zapisane jako
Human[hasName ofType foaf#name, hasChild impliesType Human] subConceptOf
Mammal.
Inne przykłady wyrażeń logicznych w WSML:
Żaden człowiek nie może być jednocześnie kobietą i mężczyzną
!- ?x[gender hasValue {?y, ?z}] memberOf Human and ?y = Male and ?z = Female.
Człowiek, który nie jest mężczyzną jest kobietą.
?x[gender hasValue Woman] impliedBy neg ?x[gender hasValue Man].
Brat rodzica jest wujkiem.
?x[uncle hasValue ?z] impliedBy ?x[parent hasValue ?y] and ?y[brother hasValue ?z].
Nie ufaj nieznajomym.
?x[distrust hasValue ?y] :- naf ?x[knows hasValue ?y].
2.18.1.2.
Warianty języka
WSML ma pięć wariantów językowych na różnych poziomach abstrakcji i złożoności.
WSML Core – koresponduje z przecięciem logiki deskrypcyjnej i Horn Logic (oprócz symboli
funkcji i relacji równości) rozszerzony o wsparcie typów danych. Może być w pełni
podporządkowany podzbiorom OWL.
WSML-DL – jest rozszerzeniem WSML-Core o brakujące pojęcia logiki deskrypcyjnej, w ten
sposób obejmuje tą część OWL, która jest efektywnie możliwa do implementacji. Obejmuje
główną cześć OWL DL.
WSML-Flight – rozszerza WSML-Core w kierunku programowania logicznego, ma bogaty
zbiór pierwotnych elementów modelujących dla modelowania różnych aspektów atrybutów,
takich jak wartość i integralność ograniczeń. Ponadto zawiera w pełni rozwinięty język reguł
jednocześnie pozwalając na efektywne, w pełni rozstrzygalne wnioskowanie. Zawiera takie
elementy
jak
meta-modelowanie,
ograniczenia
i
niemonotoniczna
negacja.
Jest
semantycznym odpowiednikiem Datalog z nierównością oraz (lokalnie) złożoną z warstw
negacją.
WSML-Rule rozszerza WSML-Flight do w pełni rozwiniętego języka programowania
logicznego, zawierającego symbole funkcji, nie ogranicza wykorzystania zmiennych w
logicznych wyrażeniach.
WSML-Full – jako ostateczna wersje języka WSML ujednolica paradygmaty logiki
deskryptywnej oraz programowania logicznego. Ujednolica wszystkie warianty WSML pod
płaszczem logiki pierwszego poziomu z niemonotonicznymi rozszerzeniami pozwalającymi
zebrać niemonotoniczne negacje WSML-Rule.
Rysunek 11 Warstwowość WSML
WSML-DL
Logika pierwszego rzędu
(z niemonotonicznymi rozszerzeniami)
WSML
WSML-Full
Logika deskrypcyjna
Logika pierwszego rzędu
(z niemonotonicznymi
rozszerzeniami)
WSML-Core
WSML-Flight
WSML
WSML-Rule
Programowanie logiczne
(z niemonotoniczną negacją)
Rysunek 12 Relacje między różnymi wariantami WSML
WSML ma dwie alternatywne warstwy: WSML-Core
WSML
-> WSML-DL ->
> WSML-Full
WSML
oraz WSMLCore -> WSML-Flight ->
> WSML-Rule
WSML
-> WSML-Full. W obu przypadkach WSML-Core jest
najmniej, WSML-Full
Full najbardziej wyrazistym językiem.
j zykiem. Interoperacyjność między dwoma
rozłącznymi
cznymi warstwami, logika deskrypcyjna (WSML-DL)
(WSML DL) z jednej strony i programowanie
logiczne (WSML-Flight
Flight i WSML-Rule)
WSML
z drugiej strony jest możliwa
liwa tylko dzięki wspólnemu
rdzeniowi WSML-Core.
Core. Pojawiły się
si jednak propozycje umożliwiające
ące interoperacyjność
interoperacyjno
między
dzy nimi z zachowaniem rozstrzygalności
rozstrzygalno
problemu spełnialności (satisfiability problem)
albo przez redukcję wyrazistości
wyrazistoś jednego z paradygmatów albo przez
ez redukcję
redukcj interfejsu
między
dzy paradygmatami i niezależne
niezależ wnioskowanie z nich.
1) WSML Core
WSML-Core bazuje na programowaniu logicznym jako podzbiorze logiki deskrypcyjnej.
Inaczej mówiąc WSML-Core bazuje na prostym (funkcjonalnym i niefunkcjonalnym) Katalog,
dzięki czemu rozstrzygalność i złożoność rezultatów Datalog stosuje się również w WSMLCore. Wiele syntaktycznych ograniczeń narzucanych przez WSML-Core jest konsekwencją
ograniczenia go do programów logiki deskrypcyjnej.
WSML-Core dziedziczy podstawową składnię WSML, mechanizm przestrzeni nazw ale
ogranicza użycie identyfikatorów.
Definicja 10.1
Słownictwo V WSML-Core ma następujące ograniczenia:
• VC , VD , VR , VI , V NFP są odpowiednio zbiorami pojęć, typów danych, relacji, instancji i
identyfikatorów niefunkcjonalnych właściwości, są podzbiorami zbioru identyfikatorów
IRI i są parami rozłączne.
• Zbiór nazw atrybutów jest równoważny V R .
• Zbiór identyfikatorów relacji V R jest rozdzielony na dwa rozłączne zbiory VRA , VRC ,które
odpowiadają odpowiednio relacjom o abstrakcyjnym i konkretnym zasięgu.
Ograniczenia na elementy modelowania ontologii nakładane przez WSML-Core (rozważamy
jedynie te elementy, które różnią się od ogólnej składni WSML):
a) Pojęcia
WSML-Core nie pozwala na specyfikację cech atrybutów: reflexive, transitive,
symmetric i inverseOf. To ograniczenie spowodowane jest faktem, że zwrotność,
przechodniość, symetryczność i odwrotność są zdefiniowane lokalnie dla pojęć WSML w
przeciwieństwie do programowania logicznego czy OWL. Można jednak zdefiniować te
atrybuty lokalnie definiując poszczególne aksjomaty. Nie jest dozwolone ograniczenie
ilości wartości, dlatego nie da się definiować funkcjonalnych właściwości. Nie są również
dozwolone definicje atrybutów A ofType D jeśli D nie jest identyfikatorem typu danych.
attribute
=
[attr]: id att type [type]: id nfp?
b) Relacje
Ilość argumentów relacji jest ograniczona do dwóch. Dziedzina dwóch parametrów może
być dana za pomocą słów kluczowych impliesType lub ofType, jednak ofType jest
dozwolone jedynie w kombinacji z typem danych i tylko drugi parametr może mieć typ
danych jako swój zasięg.
ralation
=
‘relation’ id ‘/2’? paramtyping? superrelation? nfp?
paramtyping
=
‘(‘ ‘impliesType’ idlist ‘,’ att_type idlist ‘)’
superrelation
=
‘subRelationOf’ idlist
Binarne relacje w ontologicznym sensie są niczym innym jak definicjami atrybutów, jednak
zaleca się definiowanie atrybutów na pojęciach zamiast używania relacji binarnych.
c) Instancje
WSM-Core nie nakłada ograniczeń na instancje pojęć. Instancje relacji są możliwe jedynie
dla relacji binarnych. Pierwsza wartość nie może być wartością danych.
d) Aksjomaty
WSM-Core nie nakłada ograniczeń na definicje aksjomatów z wyjątkiem faktu, że pozwala
jedynie na użycie ograniczonych form składni logicznych wyrażeń.
e) Cele
Nie odstępują od składni WSML. Wyrażenia logiczne w podwarunkach i efektach są
ograniczone do logicznych wyrażeń WSML-Core.
f) Mediatory
Mediatory w WSML-Core wynikają ze składni WSML.
g) Usługi sieciowe
Usługi sieciowe w WSML-Core wynikają ze składni WSML.
h) Składnia wyrażeń logicznych
WSML-Core pozwala tyko na ograniczoną formę wyrażeń logicznych. Nie jest dozwolone
użycie symboli funkcji i ograniczanie ilości argumentów predykatów do unitarnych i
binarnych i łączenie zmiennych nad predykatami. Nie można używać symboli
równoważności, alternatywy oraz szczegółowego kwantyfikatora na początku reguł.
Niech V będzie słownictwem WSML-Core, niech γ ∈ VC , Γ - identyfikator lub lista
identyfikatorów w VC , ∆ - identyfikator w V D , ϕ ∈ VI , Ψ - identyfikator lub lista
identyfikatorów w V I , p, v ∈ V RA , s, t ∈ VRC i niech Val będzie wartością lub listą wartości
danych.
Definicja 10.2
Zbiór pojedynczych formuł w L(V) definiuje się następująco:
• γ subConceptOf Γ jest pojedynczą formułą w L(V),
• φ memberOf Γ jest pojedynczą formułą w L(V),
• φ[ p ofType ∆ ] jest pojedynczą formułą w L(V),
• φ[ s impliesType ∆ ] jest pojedynczą formułą w L(V),
• φ[ s impliesType Γ ] jest pojedynczą formułą w L(V),
• φ[ p hasValue ψ ] jest pojedynczą formułą w L(V),
• φ[ s hasValue Val ] jest pojedynczą formułą w L(V),
Niech Var1, Var2, ... będą zmiennymi. Molekuły postaci Vari memberOf Γ nazywamy amolekułami, a molekuły postaci Vari[ p hasValue Vark ] and Vari[ p hasValue {Vark1,
Varkl}] b-molekułami.
Niech F będzie lhs- formułą (formułą dozwoloną w poprzedniku, z lewej strony lub w
implikacji) ze zbiorem lhs-formuł zdefiniowanym następująco:
• dowolna b-molekuła jest lhs-formułą,
• jeżeli F1 i F2 są lhs-formułami wtedy F1 and F2 jest lhs-formułą,
• jeżeli F1 i F2 są lhs-formułami wtedy F1 or F2 jest lhs-formułą.
Niech R, H będą rhs-formułami (dozwolonymi w konsekwencjach, z prawej strony lub w
implikacji) ze zbiorem rhs-formuł zdefiniowanym następująco:
• dowolna a-molekuła jest rhs-formułą,
• jeżeli R i H są rhs-formułami wtedy R and H jest rhs-formułą.
Definicja 10.3
Zbiór formuł w WSML-Core jest zdefiniowany następująco:
• Dowolna pojedyncza formuła jest formułą w L(V).
• Var1[ p hasValue Var2 ] impliedBy Var1[ p hasValue Var3 ] and Var3[ p hasValue
Var2 ] (globalnie przechodni atrybut/relacja) jest formułą w L(V).
• Var1[ p hasValue Var2 ] impliedBy Var2[ p hasValue Var1 ] (globalnie symetryczny
atrybut/relacja) jest formułą w L(V).
• Var1[ p hasValue Var2 ] impliedBy Var1[ q hasValue Var2 ] (globalny
podatrybut/podrelacja) jest formułą w L(V).
• Var1[ p hasValue Var2 ] impliedBy Var2[ q hasValue Var1 ] (globalnie odwrotny
• G equivalent H jest formułą w L(V) tylko wtedy gdy zawiera jedynie zmienne
WSML.
• H impliedBy F (i F implies H) jest formułą w L(V) jeżeli wszystkie zmienne
występujące w H występują w F i graf F jest związany i cykliczny.
• Każde wystąpienie molekuły formy Var1[ p hasValue Var2 ] w WSML-Core może
być zastąpione formą p(Var1,Var2).
Przykłady logicznych wyrażeń w WSML-Core:
Atrybut ‘hasAncestror’ jest przechodni.
?x[hasAncestor
hasValue
?z]
impliedBy
?x[hasAncestor
hasValue
?y]
and
?y[hasAncestor hasValue ?z].
Osoba płci żeńskiej jest kobietą.
?x memberOf Woman impliedBy ?x memberOf
Person and ?x memberOf Female.
Student jest osobą.
Student subConceptOf Person.
2) WSML DL
WSML-DL jest rozszerzeniem WSML-Core do pełnego opisu logiki podobnego do OWL DL.
WSML-DL jest syntaktycznie i semantyczne kompletną warstwą na wierzchu WSML-Core.
Oznacza to, że wszystko co obowiązuje w WSML-Core obowiązuje również w WSML-DL.
Wszystkie wymienione wcześniej ograniczenia WSML-Core obowiązują również w WSMLDL, różnica między tymi wariantami języka pojawia się w składni wyrażeń logicznych, która
jest mniej ograniczona w WSML-DL.
Składnia wyrażeń logicznych w WSML-DL
WSML-DL pozwala jedynie na pewną ograniczoną formę logicznych wyrażeń będącą
rozszerzeniem WSML-Core, ponieważ język jest ograniczony do pewnego podzbioru logiki
pierwszego rzędu SHIQ(D). Nie pozwala na użycie symboli funkcji, ogranicza ilość
argumentów predykatów do pojedynczych i binarnych oraz uniemożliwia łączenie zmiennych
nad predykatami.
Stosujemy oznaczenia z rozdziału o WSML-Core.
Definicja 11.1
Każde słownictwo WSML-Core jest słownictwem w WSML-DL.
Definicja 11.2 (jest rozszerzeniem definicji 10.2 o jeden podpunkt)
• γ subConceptOf Γ jest pojedynczą formułą w L(V).
Definicja 11.3
• Każda a-molekuła i b-molekuła są opisami w L(V).
• jeżeli F1 i F2 są opisami w L(V) a G jest b-molekułą, to:
o F1 and F2 jest opisem w L(V),
o F1 or F2 jest opisem w L(V),
o neg F1 jest opisem w L(V),
o forall Vari G implies jest opisem w L(V),
o exists Vari G and F1 jest opisem w L(V).
• exists Var1, ..., Varn G1 and ... and Gn and F1 and neg (Var1 :=: Var2) and ... and neg
(Var1 :=: Varn) and ... and neg (Varn-1 :=: Varn) jest opisem w L(V).
• forall Var1, ..., Varn+1 G1 and ... and Gn+1 and F1 implies neg (Var1 :=: Var2) or ... or
neg (Var1 :=: Varn+1) or ... or neg (Varn :=: Varn+1) jest opisem w L(V).
Niech F1, F2
będą opisami WSML-DL ze związanymi cyklicznymi grafami zmiennych.
Ponadto grafy te mogą być widziane jako drzewa o tym samym węźle korzenia.
Definicja 11.4
Zbiór WSML-DL formuł jest zdefiniowany następująco:
• Każda pojedyncza formuła jest formułą w L(V).
• F1 implies F2 F1 jest formułą w L(V).
• F1 impliedBy F2 jest formułą w L(V).
• F1 equivalent F2 jest formułą w L(V).
• Var1[ p hasValue Var2 ] impliedBy Var1[ p hasValue Var3 ] and Var3[ p hasValue Var2
] (globalnie przechodni atrybut/relacja) jest formułą w L(V).
• Var1[ p hasValue Var2 ] impliedBy Var2[ p hasValue Var1 ] (globalnie symetryczny
• Var1[
p
hasValue
Var2
]
impliedBy
Var1[
q
hasValue
Var2
]
(globalny
podatrybut/podrelcja) jest formułą w L(V).
• Var1[ p hasValue Var2 ] impliedBy Var2[ q hasValue Var1 ] (globalnie odwrotny
Jeżeli a-molekuła lub b-molekuła jest dozwolona w zapisie WSML-DL to wtedy złożone
molekuły będące skrótami koniunkcji molekuł są również dozwolone.
Przykłady wyrażeń logicznych w WSML-DL:
Pojęcie Human zdefiniowane jako alternatywa pojęć Woman i Man.
?x memberOf Human
equivalent
?x memberOf Woman or ?x memberOf Man.
Pojęcia Man i Woman są rozłączne.
?x memberOf Man
implies
neg ?x memberOf Woman.
Każdy człowiek ma ojca, który też jest człowiekiem.
?x memberOf Human
implies
exists ?y (
?x[father hasValue ?y]
and ?y memberOf Human )
and
forall ?y (
?x[father hasValue ?y]
implies ?y memberOf Human ).
3) WSML Flight
WSML-Flight jest syntaktycznie i semantycznie pełną warstwą na szczycie WSML-Core.
WSML-Flight dodaje do WSML-Core następujące elementy:
• n-argumentowe relacje z dowolnymi parametrami,
• ograniczające definicje atrybutów dla domeny,
• ograniczenia ilości elementów,
• lokalnie warstwową „domyślną” negację w logicznych wyrażeniach – oznacza to, że
negacja jest prawdziwa nawet gdy fakt uważany jest za prawdziwy, lokalna
warstwowość oznacza, że definicja danego predykatu negatywnie nie zależy od samej
siebie,
• pełny podzbiór Datalog rozszerzony o nierówność i lokalnie warstwową negację,
• meta-modelowanie, WSML-Flight nie wymaga rozdzielania słownictwa (pojęć, instancji,
relacji).
a) Podstawy składni
Składnia WSML-Flight odpowiada ogólnej składni WSML, ograniczenia WSML-Core nie
obowiązują w tej wersji.
b) Ontologie
Porównując z WSML-Core WSML-Flight pozwala na dodatkową funkcjonalność definicji
atrybutów, relacji, funkcji i instancji relacji. Składnia pojęciowa dla modelowania ontologii
w pełni koresponduje z dotychczas przedstawionym modelowaniem ontologii. Dla
aksjomatów pozwala się jedynie na ograniczoną formę wyrażeń logicznych, w sposób
zdefiniowany poniżej w podpunkcie 6).
c) Cele
Realizują ogólną składnię WSML. Logiczne wyrażenia w efektach i warunkach końcowych
są ograniczone do logicznych wyrażeń WSML-Flight.
d) Mediatory
Realizują ogólną składnię WSML.
e) Usługi sieciowe
Realizują ogólną składnię WSML. Logiczne wyrażenia w założeniach, warunkach
wstępnych, efektach i warunkach końcowych są ograniczone do logicznych wyrażeń
WSML-Flight.
f) Składnia logicznych wyrażeń
WSML-Flight jest językiem reguł bazującym na Datalog. WSML-Flight pozwala na
klasyczną implikację i koniunkcję w założeniach reguły oraz alternatywę w tezie.
Założenia i teza są rozdzielone symbolem implikacji programowania logicznego ‘:-‘ Ten
dodatkowy symbol jest wymagany ponieważ negacja jako błąd (naf) nie jest zdefiniowana
dla implikacji.
Składnia wyrażeń logicznych jest taka sama jak ogólna składnia WSML (opisana w
punkcie 9 sekcji o WSML) z następującymi ograniczeniami.
Definicja 12.1
Zbiór terminów TermFlight (V ) w WSML-Flight definiuje się następująco:
• każdy konstruktor f ∈ VO jest terminem,
• każdy identyfikator zmiennej v ∈ VV jest terminem,
• jeżeli d ∈ V D oraz dv1 , ... , dv n ∈ VDV ∪ VV , wtedy d (dv1 , .. , dv n ) jest terminem.
Zbiór podstawowych terminów WSML-Flight to maksymalny podzbiór TermFlight (V )
niezawierający zmiennych.
WSML-Flight nie pozwala na używanie operatora równości ‘:=:’ Ponadto zbiór
dopuszczalnych pojedynczych formuł nie zawiera α :=: β dla terminów α, β.
Definicja 12.2
Pojedyncza formuła w L(V) zdefiniowana jest następująco:
• Jeżeli r ∈ V R i t1 , ... , t n są terminami, wtedy r (t1 , ... , t n ) jest pojedynczą formułą w
L(V).
• Jeżeli α , β ∈ Term Flight (V ) , wtedy α = β i α != β są pojedynczymi formułami w
L(V).
• Jeżeli α , β ∈ Term Flight (V ) i γ ∈ Term(V ) lub jest formą {γ 1 , ... , γ n } o elementach
γ 1 , ... , γ n ∈ TermFlight (V ) , wtedy:
o α subConceptOf γ jest pojedynczą formułą w L(V),
o α memberOf γ jest pojedynczą formułą w L(V),
o α [ β ofType γ ] jest pojedynczą formułą w L(V),
o α [ β impliesType γ ] jest pojedynczą formułą w L(V),
o α [ β hasValue γ ] jest pojedynczą formułą w L(V).
Definicja 12.3
Dla danego słownictwa V w WSML-DL, zbiór formuł L(V) jest rekurencyjnie zdefiniowany
w następujący sposób:
• Definiujemy zbiór dopuszczalnych założeń formuł Head(V):
o każda pojedyncza formuła niezawierająca symboli ‘!=’, ‘=’ jest w założeniach,
o niech α , β ∈ Head (V ) , wtedy α and β jest w założeniach,
o dla
α , β ∈ Head (V )
niezawierających
{implies,
impliedBy,
equivalent}
następujące formuły są w założeniach:
α implies β,
α impliedBy β,
α equivalent β.
• Każda wolna od zmiennych formuła założeń jest formułą w L(V).
• Definiujemy zbiór dopuszczalnych elementów tezy formuł Body(V):
o każda pojedyncza formuła jest w Body(V),
o dla każdej pojedynczej formuły jej zaprzeczenie jako błąd jest w Body(V),
o dla α , β ∈ Body(V ) α and β jest w Body(V),
o dla α , β ∈ Body(V ) α or β jest w Body(V).
• Dla danych formuły założeń β ∈ Head (V ) oraz formuły tezy α ∈ Body(V ) , formułą
jest β := α . Tutaj α nazywamy tezą a β założeniem. Taka formuła jest
dopuszczalna jeżeli (1) α jest dopuszczalną formułą tezy, (2) β jest dopuszczalną
formułą założeń, (3) spełnione są warunki bezpieczeństwa.
• Dla α ∈ Body(V ) każda formuła postaci !- α jest dopuszczalną formułą.
Dopuszczalne formuły w WSML-Flight wraz z kropką ‘.’ są logicznymi wyrażeniami w
WSML-Flight. Istnieje możliwość używania symboli ->, <-, <->.
W celu sprawdzenia warunków bezpieczeństwa dla reguł WSML-Flight następujące
transformacje powinny być zastosowane zanim wprowadzimy reguły transformacji:
• Reguły postaci A1 and … and An :- B są rozdzielane na n osobnych reguł:
o A1 :- B
o …
o An :- B
• Reguły postaci A1 equivalent A2 :- B są rozdzielane na 2 osobne reguły:
o A1 implies A2 :- B
o A1 impliedBy A2 :- B
• Reguły postaci A1 impliedBy A2 :- B są przekształcane na
o A1 :- A2 and B
• Reguły postaci A1 implies A2 :- B są przekształcane na
o A2 :- A1 and B
• Reguły postaci A :- B1 and (F or G) and B2 są rozdzielane na dwie różne formuły:
o A :- B1 and F and B2
o A :- B1 and G and B2
• Reguły postaci A :- B1 and naf (F and G) and B2 są rozdzielane na dwie różne
formuły:
o A :- B1 and naf F and B2
o A :- B1 and naf G and B2
• Reguły postaci A :- B1 and naf (F or G) and B2 są przekształcane do:
o A :- B1 and naf F and naf G and B2
• Reguły postaci A :- B1 and naf naf F and B2 są przekształcane do:
o A :- B1 and F and B2
Aplikacja tych reguł transformacji dostarcza zbioru reguł z jedną pojedynczą formułą w
założeniach oraz koniunkcją elementów w ciele.
Warunki bezpieczeństwa obowiązują dla reguły WSML-Flight, jeżeli każda zmienna
występująca w regule jest dodatnia i nie koresponduje z wbudowanym predykatem. Na
przykład następujące reguły nie są bezpieczne w WSML-Flight:
p(?x) :- q(?y)
a[b hasValue ?x] :- ?x > 25
?x[gender hasValue male] :- naf ?x[gender hasValue female]
Przykłady logicznych wyrażeń w WSML-Flight (należy zwrócić uwagę, że zmienne są
wyliczane globalnie):
Żaden człowiek nie może być jednocześnie kobietą i mężczyzną.
!- ?x[gender hasValue {?y, ?z}] memberOf Human and ?y = Male and ?z = Female.
Brat rodzica jest wujkiem.
?x[uncle hasValue ?z] impliedBy ?x[parent hasValue ?y] and ?y[brother hasValue ?z].
Nie ufaj nieznajomym.
?x[distrust hasValue ?y] :- naf ?x[knows hasValue ?y].
4) WSML Rule
Jest rozszerzenie WSML-Flight w kierunku programowania logicznego, nie wymaga
bezpieczeństwa reguł oraz pozwala na używanie symboli funkcji. WSML-Rule jest
semantycznie i syntaktycznie poprawną warstwą na wierzchu WSML-Flight, gdzie jedyne
różnice między tymi wersjami występują w składni wyrażeń logicznych.
1) Wyrażenia logiczne
WSML-Rule pozwala na nieograniczone użycie symboli funkcji oraz nie wymaga
spełniania warunków bezpieczeństwa, np. zmienne występujące w założeniach nie muszą
występować w tezie reguły.
Definicja 13.1
Dany jest zbiór terminów WSML-Rule TermRule (V ) , pojedyncza formuła w L(V)
zdefiniowana jest następująco:
• Jeżeli r ∈ V R i t1 , ... , t n są terminami, wtedy r (t1 , ... , t n ) jest pojedynczą formułą w
L(V).
• Jeżeli α , β ∈ TermRule (V ) , wtedy α = β i α != β są pojedynczymi formułami w
L(V).
• Jeżeli α , β ∈ TermRule (V ) i γ ∈ Term(V ) lub jest formą {γ 1 , ... , γ n } o elementach
γ 1 , ... , γ n ∈ TermRule (V ) , wtedy:
o α subConceptOf γ jest pojedynczą formułą w L(V),
o α memberOf γ jest pojedynczą formułą w L(V),
o α [ β ofType γ ] jest pojedynczą formułą w L(V),
o α [ β impliesType γ ] jest pojedynczą formułą w L(V),
o α [ β hasValue γ ] jest pojedynczą formułą w L(V).
Definicja 13.2
Dla danego słownictwa V w WSML-Rule, zbiór formuł L(V) jest rekurencyjnie zdefiniowany
w następujący sposób:
• Definiujemy zbiór dopuszczalnych założeń formuł Head(V):
o każda pojedyncza formuła niezawierająca symboli ‘!=’, ‘=’ jest w założeniach,
o niech α , β ∈ Head (V ) , wtedy α and β jest w założeniach,
o dla
α , β ∈ Head (V )
niezawierających
{implies,
impliedBy,
equivalent}
następujące formuły są w założeniach:
α implies β,
α impliedBy β,
α equivalent β.
• Każda dopuszczalna formuła założeń w Head(V) jest formułą w L(V).
• Definiujemy zbiór dopuszczalnych tez formuł Body(V):
o każda pojedyncza formuła jest w Body(V),
o dla α ∈ Body(V ) naf α jest w Body(V),
o dla α , β ∈ Body(V ) α and β jest w Body(V),
o dla α , β ∈ Body(V ) α or β jest w Body(V),
o dla α , β ∈ Body(V ) α implies β jest w Body(V),
o dla α , β ∈ Body(V ) α impliedBy β jest w Body(V),
o dla α , β ∈ Body(V ) α equivalent β jest w Body(V),
o dla zmiennych ? x1 , ... , ? xn i α ∈ Body(V ) , forall ? x1 , ... , ? xn (α ) jest w Body(V),
o dla zmiennych ? x1 , ... , ? xn i α ∈ Body(V ) , exists ? x1 , ... , ? xn (α ) jest w Body(V).
• Dane są β ∈ Head (V ) i α ∈ Body(V ) , β := α jest formułą. Tutaj α nazywamy
tezą a
β założeniem. Taka formuła jest dopuszczalna jeżeli (1) α jest
dopuszczalną formułą tezy, (2) β jest dopuszczalną formułą założeń.
• Dla α ∈ Body(V ) każda formuła postaci !- α jest dopuszczalną formułą.
Dopuszczalna formuła WSML-Rule zakończona kropką ‘.’ Jest wyrażeniem logicznym.
Wymaga się aby każda baza wiedzy WSML-Rule była lokalnie warstwowa.
Przykłady wyrażeń logicznych WSML-Rule:
Obydwoje ojciec i matka są rodzicami.
?x[parent hasValue ?y] :- ?x[father hasValue ?y] or ?x[mother hasValue ?y].
Każda osoba ma ojca.
?x[father hasValue f(?x)] :- ?x memberOf Person.
Odległość istnieje między dwoma miejscami. Odległość między A i B jest równa odległości
między B i A.
!- distance(?location1,?location2,?distance1) and
distance(?location1,?location2,?distance2) and ?distance1 != distance2.
distance(?B,?A,?distance) :distance(?A,?B,?distance).
5) WSML Full
WSML-Full łączy logikę pierwszego rzędu z niemonotoniczną negacją w celu zapewnienia
ekspresywnego języka zdolnego do objęcia wszystkich aspektów ontologii i modelowania
usług sieciowych. Ponadto WSML-Full łączy logikę deskrypcyjną i język programowania
logicznego z „domyślną” negacją w ramach semantycznych. Wyzwaniem WSML-Full jest
znalezienie rozszerzenia logiki pierwszego rzędu, które może objąć taką negację. Jednym z
możliwych rozszerzeń jest Reiter's default logic. Na chwilę obecną semantyka WSML-Full
jest nadal otwartym przedmiotem badań. Należy
zauważyć,
że niemonotoniczne
rozszerzenie logiki pierwszego rzędu jest bardzo trudne do zajmowania się nim. W praktyce
wiele, jeśli nie wszystkie, rozszerzenia nie są nawet pół-rozstrzygalne (np. nawet jeśli
formuła jest logicznie zgodna algorytm może się nie zakończyć).
Zarówno składnia pojęciowa jak i składnia logicznych wyrażeń WSML-Full w pełni
korespondują z ogólną składnią WSML zaprezentowaną w sekcji WSML.
1) Różnice między WSML-DL a WSML-Full
WSML-Full dodaje modelowanie pierwszego rzędu: n-argumentowe predykaty, symbole
funkcji i łączenie zmiennych nad predykatami. Umożliwia niemonotoniczną negację.
2) Różnice między WSML-Rule a WSML-Full
WSML-Full dodaje alternatywę, klasyczną negację, różnorodne semantyczne modele i
operator równości.
2.18.1.3.
Semantyki
W tym rozdziale opisujemy semantyki WSML-Core, WSML-Flight, WSML-DL i WSML-Rule.
Semantyki WSML-Full będą stanowić przyszłe prace. Semantyki opisu możliwości nie są
całkiem jasne. Dlatego definiujemy tylko semantyki opisu ontologii.
Po pierwsze zapewniamy mapowanie między składnią pojęciową dla ontologii i składnią
logicznych wyrażeń dla części składni pojęciowej, która ma znaczenie w logicznym języku.
W takim razie zapewniamy semantykę poprzez mapowanie do logicznego formalizmu.
1) Mapowanie składni pojęciowej do składni logicznych wyrażeń
W celu zapewnienia specyfikacji semantyki WSML w zwięzły i zrozumiały sposób na
początku należy przetłumaczyć język pojęciowy na język wyrażeń logicznych.
Kroki niezbędne do zapewnienia przed tłumaczeniem składni:
• Wprowadzenie
nienumerowanych
anonimowych
identyfikatorów
w
miejsce
brakujących identyfikatorów.
• Usunięcie wszystkich niefunkcjonalnych elementów z modelu pojęciowego.
• Zastąpienie list id (idlist) pojedynczymi id dla subRelationOf, na przykład "P
subRelationOf {Q, R}" jest zastępowana przez "P subRelationOf Q" i "P
subRelationOf R".
• Rozszerzenie wszystkich sQNames do pełnych IRI przy wykorzystaniu przestrzeni
nazw.
• Zastąpienie wystąpień nienumerowanych anonimowych identyfikatorów nowymi
jednoznacznymi IRI (nieużywanymi w ontologii).
Tabela zawierająca mapowanie między pojęciową składnią WSML dla ontologii a składnią
logicznych wyrażeń poprzez funkcję mapującą τ (X i Y są meta-zmiennymi i są
zastępowane konkretnymi identyfikatorami lub zmiennymi podczas translacji; p new jest
nowo
wprowadzonym
predykatem)
jest
dostępna
na
stronie
http://www.wsmo.org/TR/d16/d16.1/v0.21/20051005/#wsml-dl (tabela 8.1). W tabeli słowa
kluczowe pisane kursywą odnoszą się do gramatyki WSML a pogrubione odnoszą się do
słów kluczowych języka WSML.
Przykład tłumaczenia następującej ontologii
namespace {_"http://www.example.org/ontologies/example#",
dc
_"http://purl.org/dc/elements/1.1#",
foaf _"http://xmlns.com/foaf/0.1/",
xsd
_"http://www.w3.org/2001/XMLSchema#",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
loc
_"http://www.wsmo.org/ontologies/location#",
oo
_"http://example.org/ooMediator#"}
ontology Family
nfp
dc#title hasValue "WSML example ontology"
endnfp
concept Human subConceptOf { Primate, LegalAgent }
relation ageOfHuman/2 (ofType Human, ofType _integer)
nfp
dc#relation hasValue FunctionalDependencyAge
endnfp
axiom FunctionalDependencyAge
definedBy
!- ageOfHuman(?x,?y1) and
ageOfHuman(?x,?y2) and
wsml#numericInequal(?y1,?y2).
do następującego logicznego wyrażenia
_"http://www.example.org/ontologies/example#Human"[_"http://www.exam
ple.org/ontologies/example#hasName" ofType
_"http://xmlns.com/foaf/0.1/name"].
_"http://www.example.org/ontologies/example#Human" subConceptOf
{ _"http://www.example.org/ontologies/example#Primate",
_"http://www.example.org/ontologies/example#LegalAgent" }.
!- naf ?x memberOf
_"http://www.example.org/ontologies/example#Human" and
_"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y).
!- naf ?y memberOf _integer and
_"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y).
!- _"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y1)
and
_"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y2) and
_"http://www.wsmo.org/wsml/wsml-syntax#numericInequal"(?y1,?y2).
2) Kroki podejmowane przed rozpoczęciem procesu
W celu uczynienia definicji semantyki WSML bardziej czytelną definiujemy pewne kroki
niezbędne do podjęcia przed rozpoczęciem procesu, które powinny być zastosowane w
logicznych
wyrażeniach.
Identyfikujemy
następujące
kroki
w
celu
uzyskania
odpowiedniego zbioru logicznych wyrażeń, który może być bez problemu mapowany do
logicznego formalizmu.
Zastępowanie anonimowych identyfikatorów nowymi jednoznacznymi
identyfikatorami
Każde wystąpienie nienumerowanego anonimowego identyfikatora jest zastępowane
nowym jednoznacznym IRI (nieużywanym w ontologii). Wszystkie wystąpienia tego
samego numerowanego identyfikatora wewnątrz jednego logicznego wyrażenia są
zastępowane tym samym jednoznacznym IRI (nieużywany gdzie indziej w ontologii).
Zastępowanie list id różnorodnymi zdaniami
Zdania zawierające listy argumentów postaci A op {v1 , ... , v n } , gdzie op ∈ {hasValue,
ofType,
impliesType}
są
zastępowane
zdaniami
w
następujący
sposób:
A op v1 , ... , A op vn . Zdania zawierające listy argumentów postaci A is − a {c1 , ... , c n } ,
gdzie is − a ∈ {memberOf, subConceptOf } są zastępowane koniunkcją zdań w
następujący sposób: A op c1 and … and A op c n .
Redukowanie złożonych molekuł do pojedynczych molekuł
Złożone molekuły są rozkładane na pojedyncze w dwóch sytuacjach:
• molekuły postaci
a is − a b[c1 op1 d1 , ... , cn op n d n ] , gdzie is − a ∈ {memberOf,
subConceptOf} i opi ∈ {hasValue, ofType, impliesType} są przekształcane na
a is − a b and a [c1 op1 d1 , ... , c n opn d n ] ,
• wtedy atrybuty postaci a [c1 op1 d1 , ... , c n opn d n ] , gdzie opi ∈ {hasValue, ofType,
impliesType} są przekształcane na a[c1 op1 d1 ] and … and a[c n op n d n ]
Zastępowanie równoważności dwoma implikacjami
lexpr equivalent rexpr. := lexpr implies rexpr. lexpr impliedBy rexpr.
Zastępowanie prawej implikacji lewą implikacją
lexpr implies rexpr. := rexpr impliedBy lexpr.
Przerabianie skrótów terminów
Skróty dla stringów, liczb całkowitych i ułamków dziesiętnych są przerabiane na ich pełną
formę:
"string" := _string("string") (o ile ”string” już nie występuje w opakowaniu the_string),
integer := _integer("integer"),
decimal := _decimal("decimal").
Przerabianie terminów danych na predykaty
Terminy danych pojawiają się w WSML jako funkcje. Jednak Datalog nie pozwala na
używanie symboli funkcji. Zatem przekształcamy opakowania typów danych na
wbudowane predykaty w następujący sposób:
Każde opakowanie n-argumentowego typu danych ma korespondujący ze sobą
wbudowany predykat z taką samą nazwą jak opakowanie. Taki wbudowany predykat ma
zawsze n+1 argumentów. Każde wystąpienie opakowania δ
w zdaniu ϕ
jest
zastępowane nowa zmienną ?x i predykat korespondujący z δ jest łączony z wynikowym
zdaniem ϕ ' : ( ϕ ' and δ ( X 1 , ... , X n , ? x) ).
Przerabianie wbudowanych funkcji na predykaty
Wbudowane funkcje są zastępowane predykatami podobnymi do opakowań typów
danych. Każdy z wbudowanych predykatów korespondujących z wbudowanymi funkcjami
zawiera jeden argument, który jest rezultatem. Wystąpienie funkcji jest zastępowane
zmienną a zdanie jest zastępowane koniunkcją tych zdań i wbudowanym predykatem.
Rozwijanie sQNames do pełnych IRI
Na koniec wszystkie sQNames są zastępowane pełnymi IRI zgodnie z zasadami
zdefiniowanymi w punkcie 2. Elementy WSML.
W
taki
sposób
otrzymane
zbiory
logicznych
wyrażeń
nie
zawierają
żadnych
syntaktycznych skrótów i mogą być wykorzystane bezpośrednio dla definicji semantyki
poszczególnych wariantów WSML.
2.19. WSMX
WSMX (Web Service Modelling eXecution) jest środowiskiem modelowania usług
sieciowych. Jest rekomendowaną implementacją WSMO i środowiskiem wykonawczym dla
integracji biznesowych aplikacji, gdzie usługi sieciowe są integrowane dla różnych aplikacji.
Celem tego jest zwiększenie automatyzacji procesów biznesowych, w jak najbardziej
elastyczny sposób zapewniając jak najlepsze rozwiązania integracyjne.
Wewnętrznym językiem WSMX jest WSML. WSMO i WSML wraz ze środowiskiem WSMX
stanowią jedną całość i są rozwijane przez DERI International.
WSMX jest rozwijany w środowisku „open source” w celu dopuszczenia szerokiego,
komunikatywnego stylu rozwoju dla zapewnienia każdemu dostępu do rozwoju i osobistego
wykorzystania środowiska dla usług sieciowych.
Istnieją różne projekty Unii Europejskiej, które używają i rozwijają WSMX, np. DIP, SEKT,
Knowledge Web, Cocoon oraz takie, które zamierzają wykorzystać WSMX jako swoją
rdzeniową aplikację, np. NIWA., KMI i SyberNet.
W dzisiejszych czasach w różnego rodzaju działalności coraz częściej (zawsze) pojawia się
problem ilości i różnorodności danych. Problem ten jest intensywnie badany w celu
znalezienia rozwiązań integrujących bazy danych, wymieniających dokumenty biznesowe,
zarządzających katalogami. Niestety żadne kompletne i ogólne rozwiązania nie zostały
znalezione, zatem mediacja i przetwarzanie danych wymaga ciągłej ingerencji człowieka. Ta
część dokumentu przedstawia mediację danych jako część wyłaniającej się technologii
semantycznej dla sieci semantycznej i semantycznych usług sieciowych. Chcemy zobaczyć
jak w tym procesie mogą być wykorzystane ontologie i wsparcie jakich narzędzi jest
wymagane w celu zwiększenia stopnia automatyzacji i zredukowania konieczności ingerencji
człowieka. Zatem opisujemy mechanizmy dla fazy projektowania procesu mediacji, który
prowadzi do półautomatycznego wyrównania między ontologiami oraz dla fazy wykonywania,
która w sposób automatyczny stosuje powstałe wcześniej wyrównania.
Środowisko WSMX pozwala na dynamiczną mediację, selekcję i inwokację usług sieciowych.
Ma zasięg domeny zdefiniowanej w WSMO.
Jest wiele modeli ontologii opisujących te same lub podobne domeny, ich zakres mógłby być
tworzony przez różne jednostki na świecie. Coraz więcej systemów i aplikacji wymaga
mediacji w celu integracji i wykorzystania różnorodnych źródeł danych. Niestety zwykle
pojawia się rozdźwięk
między dokładnością mapowania a poziomem oferowanej
automatyzacji.
Rozwiązanie mediacji danych zaprezentowane w tej części dokumentu polega na
uwzględnieniu interwencji człowieka na początku, zaproponowaniu interaktywnego procesu
mapowania gdzie sugestie narzędzi i ingerencja użytkownika (akceptacja tych sugestii) są
łączone aż nie zostanie osiągnięty efekt końcowy. W dokumencie proponowane są dobrze
zdefiniowane strategie i metodologie dla procesu mapowania w celu zagwarantowania
możliwie poprawnego i kompletnego mapowania oraz zbioru algorytmów i strategii
ułatwiających mapowanie (redukowanie mapowania do prostych akceptacji i wyborów).
2.19.1.1.
Definicje i zasięg mediacji ontologii
Ten podpunkt przedstawia spojrzenie na problem domeny i zasięgu mediacji. Prezentuje
problem definicji i opis ontologii używanych w procesie mediacji.
1) Problem definicji
W ostatnich latach rozwiązaniem pozwalającym ogarnąć różnorodności w sieci
internetowej jest dodawanie semantycznej informacji do danych. To podejście doprowadzi
w niedalekiej przyszłości do rozwoju dużej liczby ontologii modelujących poszczególne
aspekty realnego świata. Ale pojawił się kolejny problem: jak integrować aplikacje
wykorzystujące różne pojęciowe ujęcie tej samej domeny. Ponadto usługi sieciowe
wzbogacone semantyką z ontologii zapewniają dynamiczną komunikację i kooperację
między poszczególnymi jednostkami.
Rysunek 13 Scenariusz mediacji danych
Bardzo łatwo wyobrazić sobie powyższy scenariusz: dwa przedsiębiorstwa decydują się
zostać partnerami w procesie biznesowym. Jedno chce kupić coś, co jest oferowane
przez drugie. Aby to osiągnąć muszą wymieniać widomości (np. zlecenia kupna,
sprzedaży, zapłaty). Każdy z partnerów rozumie jednak tylko wiadomości zgodne
pojęciowo z własną ontologią. Jedną z ról środowiska wykonawczego jest transformacja,
gdy to konieczne, otrzymanej wiadomości zgodnej z ontologią jednostki wysyłającej na
pojęcia zgodne z ontologią jednostki otrzymującej wiadomość przed wysłaniem jej dalej. Z
punktu widzenia ontologii, każda wiadomość zawiera instancje zgodne ze źródłową
ontologią, które muszą zostać przetransformowane na instancje ontologii docelowej.
2) Adresowane ontologie
WSMO jest meta-ontologią opisującą różne aspekty związane z usługami sieciowymi.
Celem WSMO jest ulepszenie wykorzystania usług sieciowych oraz zapewnienie środków
do półautomatycznej inwokacji,
wokacji, kompozycji, realizacji, monitorowania, kompensacji i
mediacji.
Celem tej części
ci dokumentu jest przedstawienie możliwego
mo liwego podejś
podejścia do konstrukcji
systemu mediacji danych zdolnego do mediacji między
mi
danymi wyrażonymi
żonymi w terminologii
ontologii WSMO. Mediator
ediator danych wykorzystuje fakt, że
e ontologie wejś
wejściowe mają ten
sam meta-poziom,
poziom, mianowicie pojęciowy
poj ciowy model WSMO dla ontologii. Wykorzystywany
język
zyk to WSML ale nie wyklucza się
si transformacji z lub do innego języka
ję
ontologii, np.
OWL (transformacje międz
ędzy WSML a OWL DL są już zdefiniowane).
3) Zakres mediacji ontologii w WSMX
Ogólny zasięg
g mediacji w WSMX identyfikuje si
się z zasięgiem
ęgiem innych elementów
architektury WSMX. Intencją
Intencj
jest zapewnienie wsparcia integracji zewn
zewnętrznych
elementów zapewniając
ąc tę sam
samą funkcjonalność, ale lepszą realizację. Zatem pierwszym
krokiem jest zapewnienie dobrze zdefiniowanych interfejsów, które muszą
musz implementować
przez zewnętrzne
trzne komponenty, które dodadz
dodadzą swoją funkcjonalność do architektury
WSMX.
Rysunek 14 Schemat procesu mediacji danych w WSMX
Odpowiednie komponenty mediacyjne pobierają
pobieraj instancje źródłowe,
ródłowe, wykonuj
wykonują mediację i
jako dane wyjściowe
ciowe dostarczaj
dostarczają instancję wynikową lub wiadomość
ść o niepowodzeniu
mediacji.
Transformacje zastosowane do źródłowej ontologii wpływają a ich struktur
strukturę i wartości –
reguły prowadzące
ce transformację
transformacj są połączeniem
czeniem zasad integracyjnych i kontekstowych.
Zasady są budowane w oparciu o podobne jednostki z dwóch ontologii, identyfikowane
przed
rzed startem i przechowywane. Podobne jednostki są
s definiowane i przedstawiane w
WSMX za pomocą
ą graficznego interfejsu u
użytkownika, który umożliwia
żliwia mu wprowadzanie
danych wejściowych
ciowych i prowadzi go przez kompletne procesy. Zatem podobne jednostki ssą
identyfikowane na bazie danych użytkownika, reszta procesu (generacja reguł i
transformacja instancji) jest wykonywana automatycznie bez ingerencji człowieka.
2.19.1.2.
Mapowanie
Celem mapowania jest połączenie źródłowych i celowych ontologii. Mapowanie reprezentuje
również powiązania między fazami projektowania i wykonywania procesu mediacji. W
konsekwencji możemy stwierdzić, że mapowanie reprezentuje krytyczny punkt mediacji,
bezpośrednio wpływając na jakość, skuteczność i wydajność procesu mediacji.
1) Abstrakcyjna składnia mapowania
Mapowanie jest punktem krytycznym procesu mediacji, ale też może być punktem
łączącym różne systemy mediatorów, które mogą dzielić mapowanie ontologii między
sobą w celu współpracy w rozwiązywaniu trudniejszych zadań. W konsekwencji
mapowanie powinno być wyrażone w sposób zapewniający możliwość maksymalnego
ponownego wykorzystania oraz przystosowania się do różnych scenariuszy mediacji.
W celu wyrażenia mapowania należy wybrać odpowiedni do tego celu język. Tutaj został
wybrany język rozwinięty w projekcje SEKT. Język ten pożycza elementy WSML-Flight
oraz OWL, nie jest jednak przypisany do konkretnego formalizmu ontologii. Zapewnia
jedynie abstrakcyjną składnię i w zależności od wykorzystania formalna semantyka musi
być skojarzona z tą składnią.
Wyrażenia składni języka:
• expression
o classMapping
o classAttributeMapping
• attributeMapping
• classAttributeMapping
• classExpr
o classID
URIReference
• attributeExpr
o attributeID
URIReference
• classCondition
o attributeValueCondition
o 'attributeTypeCondition
o 'attributeOccurenceCondition
• attributeCondition
o valueCondition
o typeCondition
• dataLiteral
o typedLiteral
lexicalForm
URIReference
o Plainliteral
lexicalForm['@'languageTag]
Dodatkowe informacje dostępne na stronie http://www.wsmo.org/TR/d13/d13.3/v0.2/
Takie podejście dodaje dodatkowy poziom abstrakcji aby zagwarantować możliwość
ponownego wykorzystania. Ten dodatkowy poziom abstrakcji zawiera przełamywanie
reguł mapowania na pojedyncze jednostki, które powinny być gromadzone w czasie fazy
projektowania oraz odzyskiwane i komponowane w czasie fazy wykonywania. Te
pojedyncze jednostki są klasyfikowane w poszczególnych kategoriach:
• mapowanie pojęć i atrybutów – są najprostszymi przypadkami classMapping,
attributeMapping i classAttributeMapping,
• warunki pojęć i atrybutów – korespondują z classCondition i attributeCondition,
• funkcje konwersji – opisują jak wartości atrybutów instancji przeznaczonych do
mediacji są właściwie transformowane.
2) Tworzenie mapowania
Proces kreacji mapowania reprezentuje najważniejszą fazę w systemie mediacji. W celu
uzyskania dużej dokładności użytkownik musi być obecny w tej fazie.
W naszym podejściu proces mapowana wymaga trzech typów akcji ze strony eksperta
domeny:
• Przeglądanie ontologii – ekspert domeny musi odkryć elementy ontologii zgodne
z wykonywanym zadaniem. Ten krok zawiera różne perspektywy na pracę
z ontologiami oraz strategie redukowania ilości informacji do przetworzenia. Czynności
te wykonuje użytkownik.
• Identyfikowanie
podobieństw
–
identyfikacja
semantycznych
relacji
między
jednostkami dwóch ontologii. W tym celu użytkownik może wykorzystać sugestie
oferowane przez strukturalne algorytmy do wykrywania relacji semantycznych.
• Tworzenie mapowania – ostatni krok zawiera gromadzenie tych podobieństw przez
mapowanie. Oznacza to, że ekspert domeny musi podjąć prawidłowe działanie w
celu
prawidłowego
uchwycenia
semantycznych
relacji
w
zdaniach
języka
mapowania lub wykorzystać wcześniej zdefiniowane wzory.
3) Ogólne strategie
Przedstawiamy zbiór strategii możliwych do wykorzystania bez względu na metody
przeglądania ontologii. Wcześniej wprowadzamy kilka pojęć, które będą od tej pory
używane:
• Widok – zawiera podzbiór jednostek ontologii (np. pojęć, atrybutów, relacji, instancji)
i związki istniejące między nimi.
• Role – w każdym widoku jest zdefiniowana pewna liczba ról odgrywanych przez
jednostki ontologii. Poszczególne role są wypełniane przez różne jednostki w
różnych widokach i w każdej strategii i algorytmie odnosimy się raczej do ról a nie
do jednostek ontologii.
• Złożone elementy – mają przynajmniej jeden opis związany ze sobą (np. pojęcie
mające co najmniej jeden atrybut).
• Prymitywne elementy – nie mają żadnego skojarzonego ze sobą opisu (np. typ
danych).
• Elementy opisu – oferują więcej informacji o elementach złożonych, opisują i
zazwyczaj łączą je z innymi elementami złożonymi lub prymitywnymi.
Algorytm dekompozycji jest jednym z kluczowych elementów naszego podejścia i jest
używany do kierowania ekspertem domeny w procesie mapowania. Przez dekompozycję
eksponowane są opisy złożonych elementów i udostępniane dla procesu mapowania.
Konteksty reprezentują podzbiory widoków i prezentują tylko odpowiednią informację dla
aktualnego kroku mapowania, ponieważ nie wszystkie informacje dostępne w ontologii są
istotne dla danej fazy mapowania. Pojęcie kontekstu idzie w parze z algorytmem
dekompozycji, ponieważ kontekst jest aktualizowany przez zastosowanie tego algorytmu
do zbioru złożonych pojęć. Stosując algorytm rekurencyjnie i cały czas aktualizując
kontekst ekspert jest prowadzony przez proces dopóki wszystkie elementy nie zostaną
zmapowane.
Algorytm sugestii jest używany w celu pomagania ekspertowi w podejmowaniu decyzji z
uwzględnieniem możliwych semantycznych relacji między źródłowymi a docelowymi
elementami w aktualnym kontekście. Są dwa typy tego algorytmu, jeden to algorytm
bazujący na składni a drugi to strukturalny algorytm. Proponujemy połączenie metody
leksykalnej i strategii bazującej na opisie elementów do mapowania.
Podejście Bottom-Up i Top-Down
Rozważając algorytmy i metody opisane powyżej rozróżniamy dwa odrębne podejścia
odnoszące się do mapowania ontologii: podejście Bottom-Up i Top-Down. Pierwsze
oznacza, że proces zaczyna się od mapowania prymitywnych elementów i stopniowo
przechodzi do coraz bardziej złożonych elementów. Rozpoczynając od pogodzenia
najpierw prymitywnych elementów dwóch ontologii bardziej złożone relacje będą
stopniowo odkrywane.
Drugie podejście rozpoczyna proces mapowania bezpośrednio od elementów złożonych i
jest zazwyczaj adaptowane kiedy konkretne problemy niejednorodności zostają
rozwiązane.
Oznacza
to,
że
ekspert
domeny
interesuje
się
rozwiązywaniem
poszczególnych niezgodności elementów a nie pełnym wyrównywaniem ontologii
wejściowej. Algorytm dekompozycji oraz kontekst pomogą w identyfikacji wszystkich
relacji, które mogą być uwzględnione przy realizacji tego punktu widzenia i są adekwatne
do rozwiązywanego problemu.
4) PartOf View
Jest najbardziej popularnym widokiem na ontologię. Rola prymitywnych elementów jest
przejmowana przez prymitywne pojęcia a rola złożonych elementów jest przejmowana
przez pojęcia opisane przez co najmniej jeden atrybut. Opisy są reprezentowane przez
atrybuty i w naturalny sposób sukcesorem opisu jest zasięg atrybutu.
5) InstanceOf View
Podczas modelowania zbiór instancji może być wykorzystany do dokładnego zebrania
cech domeny (podobnie do stałych w językach programowania). Jest to przypadek
wyliczania zbiorów zawierających na przykład położenie geograficzne, kategorie lub
dozwolone wartości pewnych typów danych. W tym podejściu rola prymitywnych
elementów jest przejmowana przez takie instancje (nazywamy je prymitywnymi
instancjami). Używając ich mogą być kreowane bardziej złożone instancje, to znaczy
instancje złożonych pojęć, których atrybuty mają zasięgi dla prymitywnych lub złożonych
już istniejących instancji. Złożone instancje grają rolę złożonych elementów. Opisy
złożonych
instancji
są
reprezentowane
przez
atrybuty
i
wartości
atrybutów
korespondujące z nimi. Wartości atrybutów są sukcesorami opisów złożonych elementów.
6) RelatedBy View
Innym interesującym widokiem jest taki, gdzie atrybuty grają rolę elementów. Każdy
element ma dwa zarezerwowane opisy, hasDomain i hasRange mające domenę i zasięg
atrybutu jako sukcesorów. Wszystkie elementy są złożone (bo mają dwa opisy). Ponadto
stosowanie algorytmu dekompozycji do opisów spowoduje zamianę typu widoku. Jako
sukcesor pojęcia, przez zastosowanie dekompozycji widok RelatedBy przejdzie w PartOf.
7) Przykłady
Rozważmy następujący fragment ontologii:
concept person
name ofType xsd:string
age ofType xsd:integer
hasGender ofType gender
hasChild ofType person
marriedTo ofType person
concept gender
value ofType xsd:string
instance male memberOf gender
value hasValue ″male″
instance female memberOf gender
value hasValue ″female″
oraz korespondujące z nim poszczególne widoki na ontologię:
Rysunek 15 Widoki ontologii
8) Generowanie reguł mapowania
Po dokonaniu mapowania na poziomie schematów, takie mapowania są wykorzystywane
do tworzenia reguł mapowania, które określają sposób w jaki wartości pierwszej instancji
są wydobywane i wykorzystywane do tworzenia instancji celowych. Ten etap w procesie
mapowania jest niezbędny w celu zapewnienia silnych zależności między formą
reprezentowania mapowania a językiem reprezentacji konkretnej ontologii. To podejście
ma wiele zalet: upraszcza obsługę i zarządzanie mapowaniem, zapewnia elastyczność w
wyborze odpowiedniego języka zgodnie z wymaganiami konkretnej specyfikacji i robi z
tego języka mapowania istotny punkt zgodności między różnymi systemami mediacji.
Język, w którym generowane są reguły mapowania jest zazwyczaj determinowany przez
język ontologii wejściowych i instancji źródłowych. Nowe docelowe instancje będą
wyrażone w tym samym języku. Niektóre metody tłumaczenia pozwalają na użycie innego
języka.
Kiedy reguły mapowania są już stworzone, mogą być zachowane w celu ponownego
wykorzystania lub mogą być tworzone od nowa za każdym razem gdy to konieczne. Gdy
używane ontologie są odporne na zamiany, bardziej efektywnym może okazać się
przechowywanie reguł mapowania w trwałym schowku i ponowne wykorzystywanie. Gdy
ontologie ciągle ewoluują i są często zmieniane, bardziej adekwatne jest drugie podejście,
musi być tylko zachowana zgodność między mapowaniami w celu zapewnienia zgodnych
reguł mapowania.
9) Wykonanie
Ten krok ma do czynienia z wykonaniem istniejących reguł mapowania przy
wykorzystaniu środowiska rozumiejącego język źródłowych instancji oraz reguł.
Rezultatem wykonania może być więcej instancji pojęć z docelowej ontologii. Ten krok
może zawierać sprawdzanie potencjalnych ograniczeń zdefiniowanych w źródle
docelowej ontologii, które może mieć wpływ na mapowane elementy. Oznacza to, że przy
wykorzystaniu środowiska wykonawczego można sprawdzić poprawność i zgodność reguł
mapowania.
SWSF
SWSI28
(Semantic Web Services Initiative) jest inicjatywą badaczy naukowych i
przemysłowych mającą trzy główne cele:
1) Tworzenie infrastruktury łączącej sieć semantyczną i technologie usług sieciowych
umożliwiającej maksymalną automatyzację wszystkich aspektów wykorzystania usług
sieciowych,
przy
uwzględnieniu
odkrywania,
selekcji,
kompozycji,
negocjacji,
wywołania, monitorowania i odzyskiwania usług.
2) Koordynacja prowadzonych badań w zakresie semantycznych usług sieciowych.
3) Promowanie rezultatów swoich prac.
W celu realizacji wyżej wymienionych punktów podejmowane są następujące działania:
1) Tworzenie języka i infrastruktury ontologicznej do wspierania inkorporacji semantyk
usług sieciowych zrozumiałych przez maszyny.
2) Rozwój odpowiedniej architektury usług sieciowych i aplikacji.
Główne cele SWSI to zapewnianie pełnego potencjału aktualnym usługom sieciowym
poprzez łączenie i ulepszanie aktualnych trendów związanych z siecią.
1) Technologia sieci semantycznej
Dzięki technologii sieci semantycznej zautomatyzowane usługi będą ulepszane w swojej
wydajności tak, aby asystować użytkownikom w osiąganiu ich celów. Semantyczne usługi
sieciowe charakteryzują się „zrozumieniem” zawartości sieci i dzięki temu zapewniają
bardziej dokładne filtrowanie, kategoryzację i wyszukiwanie źródeł informacji. Taki system
będzie
ostatecznie
specjalistycznymi
prowadził
wnioskującymi
do
systemów
usługami.
Takie
wiedzy
usługi
charakteryzujących
będą
mogły
użytkownika w codziennym życiu, zapewniając dostęp do wszelkiej informacji.
28
Por. szerzej http://www.swsi.org/
się
wspierać
2) Technologia usług sieciowych
Aktualnie sieć nie wspiera przetwarzania informacji. Obecne działania wokół UDDI, WSDL
i SOAP próbują zapewnić sieci nowy poziom usług. Aplikacje oprogramowania mogą być
dostępne i wykonywane przez sieć bazując na koncepcji usług sieciowych. Takie usługi
sieciowe mogą znacząco podnieść potencjał architektury sieciowej, zapewniając
automatyczną komunikację programów, odkrywanie usług itp. Usługi sieciowe łączą
komputery i urządzenia za pomocą Internetu i wymieniają dane pomiędzy nimi.
Kluczowym elementem usług sieciowych jest kompozycja w locie dzięki wykorzystaniu
luźno połączonych, ponownie wykorzystywanych komponentów.
3) Inteligentne usługi sieciowe
Nadal nie ukończone są prace nad wizją semantycznych usług sieciowych. Obecna
technologia z zakresu UDDI, WSDL i SOAP zapewnia ograniczone wsparcie mechanizmu
rozpoznawania usług, ich konfiguracji i kombinacji (na przykład realizacja złożonych
przepływów pracy i logiki biznesowej z usługami sieciowymi), porównywania usług i
automatycznych
negocjacji.
W
środowisku
biznesowym
wizja
elastycznych
i
autonomicznych usług sieciowych przekłada się na autonomiczną kooperację między
usługami przedsiębiorstw. Może być zastosowana niezbędna mediacja bazująca na
ontologiach
danych
i
procesów,
automatycznym
tłumaczeniu
i
semantycznej
interoperacyjności. Przykładem może być dostarczenie łańcuchowych relacji, gdzie firma
wytwarzająca krótkotrwałe produkty musi często szukać dostawców oraz klientów w
sposób dynamiczny. Zamiast ciągłego wykonywania tych zadań przez pracowników usługi
sieciowe wykonają to automatycznie, zgodnie ze zdefiniowanymi warunkami.
SWSF (Semantic Web Services Framework), czyli ramy dla semantycznych usług
sieciowych, jest specyfikacją stworzoną przez Semantic Web Services Language Cometee.
SWSF obejmuje język semantycznych usług sieciowych Semantic Web Services Language29
(SWSL) oraz ontologię semantycznych usług sieciowych Semantic Web Services Ontology30
(SWSO).
Rozpoznawana
jest
coraz
większa
potrzeba
szeroko
akceptowanych
standardów
umożliwiających korzystanie z usług sieciowych, co powoduje powstawanie i rozwijanie
odpowiednich specyfikacji przeznaczonych do komercyjnego użytku. W chwili obecnej
dobrze rokującym standardem z zakresu technologii usług sieciowych jest WSDL i staje się
on standardem organizacji W3C. WSDL pozwala na określanie składni wiadomości
29
30
Por. szerzej http://www.w3.org/Submission/SWSF-SWSL/
Por. szerzej http://www.daml.org/services/swsf/1.0/swso/
wchodzących i wychodzących dla podstawowych usług oraz innych szczegółów niezbędnych
do wywoływania usług. WSDL nie wspiera jednak
specyfikacji przepływu pracy
skomponowanego z podstawowych usług. W tej dziedzinie wspomagany jest przez
BPEL4WS, rozwijany przez OASIS oraz język opisu choreografii rozwijany przez W3C,
umożliwiający różnorodne definiowanie (z różnych punktów widzenia) wymiany informacji
oraz reguł sterowania, które muszą być spełnione w celu realizacji transakcji bazujących na
usługach sieciowych. Usługi sieciowe są rejestrowane, ogłaszane i odkrywane w rejestrze
UDDI. Wszystkie te standardy są rozwijane zgodnie z takimi aspektami usług sieciowych jak
bezpieczeństwo, wiarygodność informacji i zarządzanie zasobami.
Jednocześnie z rozwojem wyżej wymienionych specyfikacji rośnie zapotrzebowanie na
dokładniejsze semantyczne opisywanie usług sieciowych, bazujące na ściśle określonych
ramach obejmujących pełen zakres pojęć związanych z usługami sieciowymi. Takie ramy
umożliwią pełniejszą i bardziej elastyczną automatyzację realizacji usług sieciowych,
wzmocnią konstrukcję silniejszych narzędzi i metodologii i wypromują wykorzystanie
semantycznego wnioskowania o usługach. Ponieważ takie ramy pozwolą na specyfikację
różnych aspektów usług, zapewnią również podstawy dla szerokiego zakresu czynności w
realizacji danej usługi sieciowej. Poniżej opisane narzędzia są przeznaczone do realizowania
wizji semantycznych usług sieciowych.
Dwa podstawowe elementy:
• SWSL – jest językiem używanym do określania formalnej charakterystyki pojęć usług
sieciowych oraz opisów poszczególnych usług. Posiada dwa podjęzyki: SWSL-FOL
bazujący na logice pierwszego rzędu i używany głównie do specyfikowania ontologii
usług sieciowych oraz SWSL-Rules bazujący na logicznym programowaniu (inaczej
„rules”) i wykorzystywany do wspierania użycia ontologii we wnioskowaniu i w
środowiskach
wykonawczych,
bazujących
na
paradygmacie
programowania
logicznego. SWSL jest ogólnym językiem, jego elementy nie są specyficzne dla
konkretnych usług, ale został on zaprojektowany tak, aby odpowiadał potrzebom
semantycznych usług sieciowych.
• SWSO – przedstawia pojęciowy model opisujący usługi sieciowe oraz aksjomaty i
formalną charakterystykę modelu. Kompletne aksjomaty zapisywane są w logice
pierwszego rzędu (używając SWSL-FOL) z teoretycznymi semantykami dokładnie
określającymi znaczenie pojęć. Nazywane jest to formą „FOL” ontologii FLOWS (FirstOrder
Logic
Ontology
for
Web
Services).
Ponadto
aksjomaty
FLOWS są
systematycznie tłumaczone na język SWSL-Rules (jednak przy nieuniknionym
osłabianiu niektórych aksjomatów). Wynikowa ontologia bazująca na semantykach
programowania logicznego jest nazywana ROWS (Rules Ontology for Web Services).
SWSL jest logicznym językiem posiadającym konkretne cechy umożliwiające wykorzystanie
go z innymi podstawowymi językami i infrastrukturą sieci. Te cechy obejmują URI, integrację
wbudowanych typów danych XML, kompatybilne z nimi przestrzenie nazw i mechanizmy
importu. Prawie wszystkie elementy składni są wspólne dla obu podjezyków SWSL tak, aby
umożliwić użytkownikom i programistom łatwą pracę z obydwoma warstwami oraz ułatwić
różne rodzaje interakcji i interoperacyjność między nimi. Zapis składni przedstawiany jest w
sposób czytelny i posiada pewne wygodne cechy, takie jak obiektowo zorientowany styl
prezentacji.
FLOWS jest ontologią pojęć związanych z usługami, zawierającą aksjomaty i zapewniającą
pojęciowe ramy opisu i wnioskowania o usługach. FLOWS wykorzystuje pewne
doświadczenia z OWL-S. Kluczowym elementem FLOWS jest rozwój i zachowanie modelu
procesu bazujące na ISO PSL31 (Process Specification Language). PSL oryginalnie
zaprojektowany do wspierania interoperacyjności języków modelujących procesy, zapewnia
podstawy interoperacyjności pojawiającymi się modelami procesów usług sieciowych
podczas wspierania automatycznej realizacji zadań z wizją semantycznych usług sieciowych.
FLOWS jest zaprojektowany modularnie. Składa się z ontologii dla deskryptorów, czegoś
podobnego do niezależnych od domeny yellow-pages lub profilu usług OWL-S, rozległej
ontologii modelu procesu i ugruntowania łączącego wiadomości modelu procesu z
wiadomościami WSDL. Ontologia procesu obejmuje rdzeniową ontologię i pewną liczbę jej
rozszerzeń.
Powiązane specyfikacje:
• OWL-S – ontologia usług wyrażona w OWL-DL, rozstrzygalny język logiki
deskrypcyjnej. O ile w przypadku OWL-S zdarza się, że semantyki pewnych aspektów
ontologii modelu procesu nie mogą być wyrażane w OWL-DL, to w ontologii FLOWS
nie ma takich problemów. FLOWS zapewnia bardziej kompletne ontologie bazujące na
pojęciowym modelu korzystającym z doświadczeń OWL-S. Obejmuje wszystkie pojęcia
OWL-S, natomiast różni się aksjomatami wiadomości, których nie ma w OWL-S.
Kolejną ważną różnicą jest rola obydwu specyfikacji. Obydwa języki dążą do
zapewnienia dobrej jakości ontologii usług sieciowych, ale FLOWS miał dodatkowy cel
31
Por szerzej http://eil.stanford.edu/psl/
bycia centralnym punktem dla interoperacyjności, umożliwiającym wyrażanie innych
języków modelowania procesów biznesowych lub przynajmniej ścisłe ich powiązanie.
• PSL i powiązane specyfikacje – ontologia procesu SWSL bazuje na ontologii PSL
specyfikacji procesów. Z perspektywy PSL FLOWS może być widziany jako zbiór
rozszerzeń,
które
umieszczają
opis
procesu
wewnątrz
większego
kontekstu
komunikacji bazującej na wiadomościach.
• BPEL4WS – jest językiem modelowania wykonywalnych procesów biznesowych.
Najprawdopodobniej
FLOWS
umożliwi
w
przyszłości
kodowanie
zarówno
wykonywalnych jak i abstrakcyjnych modelów procesów BPEL. Podczas gdy BPEL
koncentruje się na widoku usług stawiającym w centrum wiadomości, FLOWS
zapewnia widok stawiający w centrum procesy, gdzie wymiana wiadomości jest
dodatkowym
procesem
wnioskowanym
automatycznie.
Ważną
różnicą
tych
specyfikacji jest to, że FLOWS wspiera kodowanie „ubocznych efektów” usług.
W rzeczywistości BPEL jest zaprojektowany do orkiestracji usług sieciowych, natomiast
FLOWS może być również używany do ich choreografii.
• WSMO – jest równoległą specyfikacją definiującą ontologię i językiem dla
semantycznych usług sieciowych. Posiada język reguł WSML (podobnie jak SWSLRules), który bazuje na F-logic i ma wiele wspólnych wyrażeń z SWSL. WSMO silnie
koncentruje się na efektach i kwestiach końcowego użytkownika, ponadto WSMO
zwraca uwagę na kompatybilność z OWL. W przeciwieństwie do tego SWSL
koncentruje się na rozszerzaniu funkcjonalności języków reguł, w szczególności
wspiera meta-wnioskowanie i reifikację. Główną różnicą jest to, że WSMO skupia się
na opisywaniu choreografii usług sieciowych poprzez ostrożne reguły przejścia,
natomiast FLOWS umożliwia opis orkiestracji oraz wymianę wiadomości między
procesami. Zapewnia również podstawy automatycznej symulacji, weryfikacji i
kompozycji usług sieciowych, które nie są możliwe do wykonania przy ostrożnych
regułach przejścia bez wcześniejszego zdefiniowania semantyk.
2.20. SWSL
SWSL jest logicznym językiem mającym dwie warstwy, każda służy do odrębnych celów.
SWSL-Rules zawiera kombinację cech, które do tej pory nie występowały w jednym
systemie, chociaż prawie wszystkie elementy SWSL-Rules zostały zaimplementowane w
narzędziu FLORA-232, SweetRules czy komercyjnym Ontobrokerze. Przy tworzeniu
elementów SWSL-Rules została wzięta pod uwagę informacja zwrotna od użytkowników tych
systemów. SWSL-FOL jest z kolei językiem specyfikacji dla SWSO. Ponadto SWSL-FOL
32
Więcej informacji w dokumencie D1.2.5 WKUP
będzie służyć jako popularna platforma wspierająca semantyczną interoperacyjność
pomiędzy różnymi ontologiami bazującymi na logice pierwszego rzędu, takimi jak OWL-S.
SWSL-Rules jest językiem bazujących na logicznych regułach z niemonotonicznymi
semantykami. Takie języki lepiej dopasowują się do zadań mających cechy programowania i
w naturalny sposób polegających na stałej informacji oraz dziedziczeniu. Te zadania
zawierają odkrywanie, uzgadnianie itp. W przeciwieństwie do tego logika pierwszego rzędu
jest lepsza do specyfikacji ontologii procesów. Jednym z ważniejszych przykładów, który
wykorzystuje takie podejście jest PSL. SWSL-FOL rozwinął się do spełnienia takiej potrzeby.
Niestety logika pierwszego rzędu i niemonotoniczne semantyki nie mogą być używane
razem w tym samym języku, więc SWSL-FOL zapewnia „most” między dwoma podjęzykami.
Podstawowa idea SWSL jest następująca. Obydwa podjęzyki współdzielą jeden rdzeń i
współpracują jednocześnie syntaktycznie i semantycznie. Język posiada metodologię
tłumaczenia SWSL-FOL na reguły SWSL-Rules przy minimalnej stracie. Oznacza to, że
wnioski wyprowadzone z przetłumaczonej specyfikacji są kompletne w odniesieniu do
oryginalnej specyfikacji SWSL-FOL, natomiast ilość „zagubionych” wniosków (np. formuł
implikowanych z oryginalnej, nie z tłumaczonej wersji) jest minimalizowana. Takie podejście
zostało wykorzystane w tłumaczeniu aksjomatów PSL Core i PSL Outer Core na SWSLRules.
Zarówno SWSL-Rules jak i SWSL-FOL są prezentowane jako języki warstwowe. W
przeciwieństwie do OWL warstwy nie są zorganizowane w oparciu o moc ekspresyjności czy
złożoność obliczeniową. Zamiast tego każda warstwa zawiera pewną liczbę nowych pojęć,
które poprawiają jakość mocy modelowania języka. Jest to wykonywane w ten sposób, by
ułatwić naukę języka i lepszego zrozumienia relacji między różnymi jego cechami. Ponadto
większość warstw rozszerzających rdzeń języka jest niezależna od siebie nawzajem, to
znaczy mogą być implementowane razem lub w dowolnej częściowej kombinacji.
Wszystkie warstwy mają podobną złożoność i rozstrzygalność z wyjątkiem warstwy jakości,
która jest znacznie bardziej złożona. Dla SWSL-Rules najważniejszym zadaniem
wnioskowania jest odpowiadanie na pytania.
a) SWSL-Rules
Jest językiem zaprojektowanym do wspierania różnorodnych zadań od specyfikacji usług
sieciowych począwszy, na odkrywaniu czy uzgadnianiu usług skończywszy. Jest on
warstwowy i składa się z warstw do poszczególnych zadań, które nie wymagają pełnej
mocy ekspresyjności SWSL-Rules.
Courteous
Nonmon LT
NAF
Reification
HiLog
Mon LT
Equality
Frames
Horn
Rysunek 16 Warstwy SWSL-Rules
Rdzeń języka to logika Horna33. Mon LT to monotoniczne Lloyd-Topor rozszerzenie rdzenia
pozwalające na dysjunkcję w ciele reguły oraz na koniunkcję i implikację w założeniach. NAF
jest rozszerzeniem pozwalającym na negację w ciele reguły. Niemonotoniczne rozszerzenie
Lloyd-Topor (Nonmon LT) pozwala na kwantyfikatory i implikację w ciele reguły. Warstwa
Courteous wprowadza dwie nowe właściwości: ograniczoną klasyczną negację i priorytetowe
reguły. HiLog rozszerza język o wysoki stopień meta-programowania dzięki zezwoleniu na
występowanie zmiennych jako symboli predykatów, funkcji, a nawet formuł. Warstwa Frames
wprowadza cechy obiektowości (składnia, typy, dziedziczenie). Natomiast warstwa
Reification zapewnia mechanizm tworzenia obiektów poza klasą formuł SWSL-Rules, który
umieszcza formuły w dziedzinie zainteresowania i pozwala o nich wnioskować.
SWS-FOL jest używany do określania dynamicznych właściwości usług, ma również
strukturę warstwową przedstawioną na poniższym rysunku.
Rysunek 17 Warstwy SWSL-FOL
Dolne warstwy powyższego rysunku pokazują te warstwy SWSL-Rules, które mają
monotoniczne semantyki i mogą być rozszerzane do pełnej logiki pierwszego rzędu. Powyżej
każdej z nich pokazane jest odpowiednio korespondujące rozszerzenie SWSL-FOL.
33
Por. szerzej http://www.cs.cmu.edu/~fp/courses/atp/lectures/14-horn.html
Najbardziej podstawowym rozszerzeniem jest sam SWSL-FOL, pozostałe trzy warstwy
rozszerzają język syntaktycznie i semantycznie. Niektóre z nich mogą być później łączone w
jeszcze silniejsze języki logiki pierwszego rzędu.
2.21. SWSO
Semantic Web Services Ontology (SWSO) jest ontologią usług sieciowych wyrażoną w
dwóch formach: FLOWS (logika pierwszego rzędu dla usług sieciowych) oraz ROWS
(ontologia reguł dla usług sieciowych).
SWSO obejmuje opis pojęciowego modelu danej ontologii oraz opis aksjomatyzacji logiki
pierwszego rzędu, która definiuje teoretyczne semantyki ontologii. Aksjomatyzacja nazywana
jest „SWSO-FOL” lub inaczej FLOWS.
Celem FLOWS jest umożliwienie wnioskowania o semantykach usług sieciowych, ich
wzajemnych interakcjach oraz interakcjach z realnym światem. FLOWS nie dąży do
kompletnej reprezentacji usług sieciowych, ale raczej do abstrakcyjnego modelu, co jest
wierne semantycznym aspektom zachowania usług. FLOWS jest przeznaczony do
wnioskowania o podstawowych aspektach zachowania usług sieciowych dla różnych celów i
w różnym kontekście. Niektóre wspierane cele to:
• Opis usług sieciowych umożliwiający
automatyczne odkrywanie, komponowanie i
weryfikowanie usług.
• Tworzenie deklaratywnych opisów usług sieciowych, które mogą być mapowane do
wykonywalnych specyfikacji.
Różne konteksty mogą być wspierane przez:
• Modelowanie usług jako niezbędne czarne skrzynki, gdzie zaobserwować można tylko
wiadomości.
• Modelowanie wewnętrznych pojedynczych procesów, wykonywanych przez usługę razem
z wpływem, jaki mają te procesy na rzeczywisty świat.
• Modelowanie wielu właściwości danej usługi, zawierające wszystkie wiadomości API,
wszystkie lub niektóre wewnętrzne procesy oraz niektóre lub wszystkie przepływy danych.
Specyfikacja ontologii FLOWS w logice pierwszego rzędu nie zakłada z góry, że
zautomatyzowane zadania wnioskowania, opisane powyżej, będą realizowane przy użyciu
dowodzenia twierdzeń logiki pierwszego rzędu. Natomiast z pewnością można używać logiki
pierwszego rzędu do określania rozwiązań tych zadań przy użyciu notacji wynikania i
spełnialności.
FLOWS obejmuje najważniejsze funkcjonalne elementy różnych modeli usług sieciowych.
Nacisk kładziony jest na umożliwienie formalnej reprezentacji i badania następujących
formalizmów, między innymi:
• Modele koncentrujące się na specyfikowaniu sieci semantycznej, w tym model OWL-S
pojedynczych procesów, jego dane wejściowe i wyjściowe, warunki wstępne, efekty itp.
oraz ontologię WSMO opisującą zamierzone cele usług sieciowych.
• Różne modele procesów do łączenia pojedynczych usług, w tym model procesu OWL-S.
• Fundamentalne podstawy standardów takie jak WSDL, BPEL, WSCL oraz szersze takie
jak SOA.
• Różne modele interakcji między usługami sieciowymi oraz relacje „globalnych” protokołów
z lokalnym zachowaniem jakie mogą stosować.
Głównym celem FLOWS jest zapewnienie formalnych podstaw dla dokładnego określania
„domen aplikacji” bazujących na paradygmacie usług sieciowych i/lub usług SOA. Ponadto
FLOWS stara się być bardzo elastyczny, pozwalając na różnorodne wariacje usług obecnych
w tych dziedzinach oraz tych przewidzianych do powstania w najbliższym czasie. Innym
celem FLOWS jest tworzenie urozmaiceń formalizmów modelowania procesów wewnątrz
ontologii.
W typowym wykorzystaniu FLOWS, dziedzina aplikacji jest tworzona przez łączenie
aksjomatów FLOWS z dodatkowymi logicznymi zdaniami do formowania teorii. Inaczej
mówiąc każde zdanie w takiej teorii jako ograniczenie modelu (w sensie logiki
matematycznej), które spełnia teorię.
Biorąc pod uwagę wysoki poziom strukturalny OWL-S, FLOWS posiada trzy główne
komponenty:
1) Service Descriptors
Service Descriptors zapewniają podstawowe informacje formalne o usłudze sieciowej. Są to
informacje wykorzystywane głównie do automatycznego odkrywania usług sieciowych i
stanowią wstępny zbiór właściwości niezależnych od dziedziny. Jednak rzeczywistość
pokazuje, że wiele najefektywniejszych odpisów usług dla ich odkrywania zależy jednak od
dziedziny.
Najważniejsze informacje obejmowane przez opis to: nazwa, autor, opis tekstowy, wersja itp.
Może być on rozszerzany przez właściwości zależne od domeny oraz te najczęściej
używane w innych standardach takich jak Dublin Core.
Każda pojedyncza właściwość jest wykazem relacji FLOWS obejmującym pojęcia wewnątrz
ontologii.
• Service Name – odnosi się do nazw usług i może być wykorzystana jako unikalny
identyfikator. Koresponduje bezpośrednio z właściwością OWL-S serviceName.
name(service,service_name.)
• Service Author – informacja o autorze lub autorach usługi
author(service,service_author)
• Service Contact Information – ta właściwość zawiera namiary na osoby lub agentów
posiadających więcej informacji o usłudze, może być to np. adres e-mail
contact(service,contact_info)
• Service Contributor – właściwość opisująca jednostkę odpowiedzialną za aktualizację
usługi
contributor(service,service_contributor)
• Service Description – usługa może mieć opis tekstowy. Zazwyczaj taki opis zawiera
podsumowanie tego, co usługa oferuje oraz czego wymaga. Koresponduje on z
właściwością OWL-S textDescription
description(service,service_description)
• Service URL – właściwość ta zawiera jeden lub więcej URL związanych z usługą i
poprawia interoperacyjność gdy agenci potrzebują bazować na wartościach URL
url(service,service_URL)
• Service Identifier – jednoznaczna referencja do danej usługi
identifier(service,service_identifier)
• Service Version – zawiera identyfikator konkretnej wersji usługi w danym czasie. Staje
się również numerem rewizyjnym w systemie kontroli kodu źródłowego.
version(service,service_version)
• Service Release Date – ta właściwość zawiera datę publikacji usługi, co pozwala na
wyszukiwanie usług według daty publikacji, np. nie starsze niż dwa lata
releaseDate(service,service_release_date)
• Service Language – identyfikator logicznego języka programowania usługi, może
również zawierać etykietę językową ISO
language(service,service_language)
• Service Trust – zawiera jednostkę opisującą solidność usługi
trust(service,service_trust)
• Service Subject – wskazuje temat usługi
subject(service,service_subject)
• Service Reliability – wskazuje zależność usługi. Różne miary mogą być pożyteczne w
określaniu filtrów takich jak liczba błędów w danym okresie czasu
reliability(service,service_reliability)
• Service Cost – wskazuje cenę usługi, może być tylko monetarną jednostką, jak również
złożonym opisem kosztów
cost(service,service_cost)
2) Process Model – model procesu
Ponieważ PSL (Process Specification Language) jest ogólną ontologią dla procesów, należy
określić rozszerzenia zapewniające pojęcia użyteczne w kontekście usług sieciowych. W
szczególności model procesu FLOWS dodaje do PSL dwa podstawowe elementy:
• Strukturalną notację pojedynczych procesów (jak w OWL-S),
• Infrastrukturę do określania różnych form przepływu danych (model procesu FLOWS
polega na konstrukcjach już istniejących w PSL dla reprezentowania podstawowych
aspektów przepływu procesu oraz zapewnia również kilka rozszerzeń dla nich).
Model procesu FLOWS jest warstwowy i podzielony na naturalne grupy. Określając
dziedzinę aplikacji, łatwo jest inkorporować te ontologiczne bloki budujące, które są
potrzebne.
Ontologia modelu procesu składa się z rdzeniowego zbioru aksjomatów oraz zbioru ontologii
rozszerzeń. FLOWS aktualnie składa się z sześciu modułów ontologii, które określają
przypuszczenia o czynnościach skojarzonych z usługami i klasami skomponowanymi z
czynności wyrażających różne ograniczenia wystąpień usług.
3) Grounding – ugruntowanie.
Pojęcia SWSO opisu usługi oraz instancje tych pojęć opisujące poszczególne usługi są
abstrakcyjnymi specyfikacjami w takim sensie, że nie określają detali poszczególnych
formatów wiadomości, protokołów transportu oraz adresów, przez które usługi sieciowe są
udostępniane. Rolą ugruntowania jest zapewnienie tych konkretnych szczegółów.
W formalnej ontologii trzy powyższe elementy są skojarzone z usługami przez
reprezentowanie formalnych usług jako pojęciowych obiektów i przy wykorzystaniu relacji
między nimi, na przykład service-author (usług-autor) jest binarną relacją łączącą usługę z jej
autorem.
Większość twórców ontologii domenowych zapewnia logiczne opisy swoich usług sieciowych
wraz z wglądem w niektóre specyficzne automatyczne zadania, w tym np. odkrywanie usług,
wywoływanie ich, kompozycję itp. Każde takie zadanie wymaga podglądu wewnętrznej
ontologii FLOWS.

Widok/Otwórz

Transkrypt

Podobne dokumenty