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:Resource rdfs:Resource rdfs:isDefinedBy Definicja zasobu podmiotu. rdfs:Resource rdfs:Resource rdf:value Idiomatyczna właściwość używana uporządkowanych wartości. do rdfs:Resource rdfs:Resource rdf:subject Podmiot zdania RDF. rdf:Statement rdfs:Resource rdf:predicate Predykat zdania RDF. rdf:Statement rdfs:Resource rdf:object Obiekt zdania RDF. rdf:Statement rdfs:Resource 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 . gdzie _:nnn identyfikuje pusty węzeł przydzielony do 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 . gdzie _:nnn identyfikuje pusty węzeł przydzielony do wartości liczbowo-literowej lll przez tę regułę. Tabela 6 Proste reguły wnioskowania [2] 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. Tabela 7 Proste reguły wnioskowania [3] 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 gdzie _:nnn identyfikuje pusty węzeł przydzielony do 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 www rdfs:domain vvv . . rdfs:subClassOf rdfs:subPropertyOf www . www rdfs:domain vvv . ext7 rdfs:subPropertyOf rdfs:subPropertyOf www . rdfs:Class rdfs:subClassOf vvv . rdf:Property rdfs:subClassOf vvv . www rdfs:domain vvv . ext8 ext9 rdfs:subClassOf rdfs:subPropertyOf www . www rdfs:range vvv . rdfs:subPropertyOf rdfs:subPropertyOf www . www rdfs:range vvv . 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 . uuu aaa "sss"^^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 . uuu aaa "sss"^^ddd . 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:name "Johnny Lee Outlaw" . _:a foaf:mbox <mailto:[email protected]> . _:b foaf:name "Peter Goodguy" . _:b foaf:mbox <mailto:[email protected]> . Zapytanie: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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:name "Johnny Lee Outlaw" . _: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: @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:b foaf:name "Bob" . Zapytanie: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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:name ?name . ?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/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 . 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:name ?name . ?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: <http://xmlns.com/foaf/0.1/> 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: <http://xmlns.com/foaf/0.1/> . @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 <mailto:[email protected]> . _:b rdf:type foaf:Person . _:b foaf:name "Bob" . Zapytanie: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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” <mailto:[email protected]> ”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/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 . 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: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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: <http://xmlns.com/foaf/0.1/> . @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> . _:a vcard:N _:x . _:x vcard:Family "Hacker" . _:x vcard:Given "Alice" . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> . _:b foaf:N _:z . _:z vcard:Family "Hacker" . _:e foaf:name _:e vcard:N "Ella" . _:y . _:y vcard:Given "Eleanor" . Zapytanie: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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” <mailto:[email protected]> "Alice" "Hacker" “Bob” <mailto:[email protected]> “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/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> 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 PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> 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 ), (< u 2 >, G2 ), ... , (< u n >, Gn )} , gdzie G oraz Gi są grafami, a < u i > różnymi identyfikatorami IRI. G jest grafem domyślnym, a (< u i >, 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 =< u i > dla niektórych i, a S jest rozwiązaniem dla P na zbiorze danych {Gi , (< u1 >, G1 ), ...} • g jest zmienną, S odwzorowuje g do < u j > 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 foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> _:a foaf:knows _:b . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> . _: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 foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:z foaf:mbox <mailto:[email protected]> . _:z rdfs:seeAlso <http://example.org/foaf/bobFoaf> . _:z foaf:nick "Robert" . <http://example.org/foaf/bobFoaf> 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. PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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” <http://example.org/foaf/bobFoaf> „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: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> . Zapytanie: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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: @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@org> . _:z foaf:name "Alice" . _:z foaf:mbox <mailto:smith@work> . Zapytanie: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } ORDER BY ?name PREFIX : <http://example.org/ns#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?name WHERE { ?x foaf:name ?name ; :empId ?emp } ORDER BY DESC(?emp) PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?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: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?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: @prefix foaf: <http://xmlns.com/foaf/0.1/> . _: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: <http://xmlns.com/foaf/0.1/> 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 <http://xmlns.com/foaf/0.1/> . "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> . Zapytanie: PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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 A<B xsd:string op:numeric-equal(fn:compare(STR(A), STR(B)), -1) xsd:bolean A>B 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:onProperty rdf:resource="#hasParent" /> <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:onProperty rdf:resource="#hasParent" /> <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:onProperty rdf:resource="#hasParent" /> <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:onProperty rdf:resource="#hasParent" /> <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:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Tosca" /> <owl:Thing rdf:about="#Salome" /> </owl:oneOf> </owl:Class> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Turandot" /> <owl:Thing rdf:about="#Tosca" /> </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:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Tosca" /> <owl:Thing rdf:about="#Salome" /> </owl:oneOf> </owl:Class> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Turandot" /> <owl:Thing rdf:about="#Tosca" /> </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> <owl:oneOf rdf:parseType="Collection"> <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:unionOf rdf:parseType="Collection"> <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"> <rdfs:subClassOf rdf:resource="#MusicDrama"/> <owl:disjointWith rdf:resource="#Opera"/> </owl:Class> <owl:Class rdf:about="#Musical"> <rdfs:subClassOf rdf:resource="#MusicDrama"/> <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:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Person"/> <owl:Class rdf:about="#Corporation"/> </owl:unionOf> </owl:Class> </rdfs:domain> </owl:ObjectProperty> 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"/> </owl:ObjectProperty> 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" /> </owl:ObjectProperty> Inny zapis syntaktyczny tego samego: <owl:ObjectProperty rdf:ID="husband"> <rdfs:domain rdf:resource="#Woman" /> <rdfs:range rdf:resource="#Man" /> </owl:ObjectProperty> <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"/> </owl:ObjectProperty> 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:datatype="&xsd;integer">30</rdf:first> <rdf:rest> <rdf:List> <rdf:first rdf:datatype="&xsd;integer">40</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> </owl:DatatypeProperty> 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:Ontology rdf:about=""> <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: <owl:Ontology rdf:about=""> <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"/> <!-- note that equivalentClass only means that the classes have the same extension, so this DOES NOT lead to the entailment that Automobile is of type DeprecatedClass too --> </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 { 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(' datavaluedPropertyID 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) 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) } ∩ Abstrakcyjna składnia annotation(p o) dla referencji URI o annotation(p Individual(…)) Interpretacja (wartość EC) {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) [ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] annotation(p1 o1) … annotation(pk S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ ok) descr1 … descrn) EnumeratedClass(c [Deprecated] EC(annotation(pk ok)) EC(c) ⊆ EC(descr1) ∩... ∩ EC(descrn) [ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] annotation(p1 o1) … annotation(pk S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ ok) i1 … in) Datatype(c [Deprecated] EC(annotation(pk ok)) EC(c) = { S(i1), …, S(in) } [ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] annotation(p1 o1) … annotation(pk S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ ok) ) EC(annotation(pk 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) EC(annotation(pk ok)) 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)] S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ ok) super(s1) … super(sn) EC(annotation(pk ok)) 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 S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ o1) … annotation(pk ok)) EC(annotation(pk ok)) OntologyProperty(p annotation(p1 o1) S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ … annotation(pk ok)) EC(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. Abstrakcyjna składnia 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 annotationPropertyID rdf:type URIreference) rdf:Property . [opt] O annotationPropertyID URIreference . annotationPropertyID rdf:type owl:AnnotationProperty . Annotation(annotationPropertyID annotationPropertyID rdf:type dataLiteral) rdf:Property . [opt] O annotationPropertyID T(dataLiteral) . annotationPropertyID rdf:type Annotation(annotationPropertyID individual) owl:AnnotationProperty . annotationPropertyID rdf:type rdf:Property . [opt] O annotationPropertyID T(individual) . rdfs:Literal rdfs:Literal Abstrakcyjna składnia (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 datavaluedPropertyID owl:DatatypeProperty . datavalued- datavaluedPropertyID rdf:type PropertyID rdf:Property . [opt] 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 rdf:Property . [opt] 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 Abstrakcyjna składnia 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 classID rdf:type owl:Class . annotation1 … annotationm classID rdf:type rdfs:Class . [opt] 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] classID rdf:type owl:Class . complete classID rdf:type rdfs:Class . [opt] annotation1 … annotationm [classID rdf:type owl:DeprecatedClass description1 … descriptionn) .] classID T(annotation1) … classID T(annotationm) classID owl:intersectionOf T(SEQ description1…descriptionn) . Główny węzeł M(T(S)) Abstrakcyjna składnia Transformacja T(S) (i sekwencje) S Class(classID [Deprecated] classID rdf:type owl:Class . complete classID rdf:type rdfs:Class . [opt] annotation1 … annotationm [classID rdf:type owl:DeprecatedClass description) .] classID T(annotation1) … classID T(annotationm) classID owl:equivalentClass T(description) . Class(classID [Deprecated] classID rdf:type owl:Class . complete classID rdf:type rdfs:Class . [opt] annotation1 … annotationm [classID rdf:type owl:DeprecatedClass unionOf(description1 … .] descriptionn)) classID T(annotation1) … classID T(annotationm) classID owl:unionOf T(SEQ description1…descriptionn) . Class(classID [Deprecated] classID rdf:type owl:Class . complete classID rdf:type rdfs:Class . [opt] annotation1 … annotationm [classID rdf:type owl:DeprecatedClass complementOf(description)) .] classID T(annotation1) … classID T(annotationm) classID owl:complementOf T(description) . EnumeratedClass(classID classID rdf:type owl:Class . [Deprecated] classID rdf:type rdfs:Class . [opt] annotation1 … annotationm [classID rdf:type owl:DeprecatedClass iID1 … iIDn) .] classID T(annotation1) … classID T(annotationm) . classID owl:oneOf T(SEQ iID1…iIDn) . Główny węzeł M(T(S)) Abstrakcyjna składnia (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 description1…descriptionn) . intersectionOf(description1 … _:x rdf:type owl:Class . descriptionn) _:x rdf:type rdfs:Class . [opt] _:x owl:intersectionOf T(SEQ _:x description1…descriptionn) . complementOf(description) _:x rdf:type owl:Class . _:x rdf:type rdfs:Class . [opt] _:x owl:complementOf T(description) . _:x Abstrakcyjna składnia (i sekwencje) S oneOf(iID1 … iIDn) Transformacja T(S) Główny węzeł M(T(S)) _:x rdf:type owl:Class . _:x rdf:type rdfs:Class . [opt] _:x _:x owl:oneOf T(SEQ iID1…iIDn) . oneOf(v1 … vn) _:x rdf:type owl:DataRange . _:x rdf:type rdfs:Class . [opt] _:x _:x owl:oneOf T(SEQ v1 … vn) . restriction(ID component1 … _:x rdf:type owl:Class . componentn) _:x rdf:type rdfs:Class . [opt] (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 rdf:type rdfs:Class . [opt] _:x _:x owl:onProperty T(ID) . _:x owl:allValuesFrom T(range) . restriction(ID _:x rdf:type owl:Restriction . someValuesFrom(required)) _:x rdf:type owl:Class . [opt] _:x rdf:type rdfs:Class . [opt] _:x _:x owl:onProperty T(ID) . _:x owl:someValuesFrom T(required) . restriction(ID value(value)) _:x rdf:type owl:Restriction . _:x rdf:type owl:Class . [opt] _:x rdf:type rdfs:Class . [opt] _:x _:x owl:onProperty T(ID) . _:x owl:hasValue T(value) . restriction(ID minCardinality(min)) _:x rdf:type owl:Restriction . _:x rdf:type owl:Class . [opt] _:x rdf:type rdfs:Class . [opt] _:x owl:onProperty T(ID) . _:x owl:minCardinality "min"^^xsd:nonNegativeInteger . _:x Abstrakcyjna składnia (i sekwencje) S Transformacja T(S) Główny węzeł M(T(S)) restriction(ID maxCardinality(max)) _:x rdf:type owl:Restriction . _:x rdf:type owl:Class . [opt] _:x rdf:type rdfs:Class . [opt] _:x owl:onProperty T(ID) . _:x _:x owl:maxCardinality "max"^^xsd:nonNegativeInteger . restriction(ID cardinality(card)) _:x rdf:type owl:Restriction . _:x rdf:type owl:Class . [opt] _:x rdf:type rdfs:Class . [opt] _:x owl:onProperty T(ID) . _:x owl:cardinality "card"^^xsd:nonNegativeInteger . DatatypeProperty(ID [Deprecated] ID rdf:type owl:DatatypeProperty . annotation1 … annotationm 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 Abstrakcyjna składnia Transformacja T(S) (i sekwencje) S ObjectProperty(ID [Deprecated] ID rdf:type owl:ObjectProperty . annotation1 … annotationm [opcjonalne jeśli zawarta jest jedna super(super1)… super(supern) z ostatnich trójek] domain(domain1)… ID rdf:type rdf:Property . [opt] domain(domaink) [ID rdf:type owl:DeprecatedProperty .] range(range1)… ID T(annotation1) … ID T(annotationm) 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 . ID rdf:type rdf:Property . [opt] ID T(annotation1) … ID T(annotationm) OntologyProperty(ID annotation1 … annotationm) ID rdf:type owl:OntologyProperty . ID rdf:type rdf:Property . [opt] ID T(annotation1) … ID T(annotationm) 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)) Abstrakcyjna składnia Transformacja T(S) (i sekwencje) S annotation(annotationPropertyID annotationPropertyID URIreference . URIreference) annotationPropertyID rdf:type Główny węzeł M(T(S)) owl:AnnotationProperty . annotationPropertyID rdf:type rdf:Property . [opt] annotation(annotationPropertyID annotationPropertyID T(dataLiteral) . dataLiteral) annotationPropertyID rdf:type owl:AnnotationProperty . annotationPropertyID rdf:type rdf:Property . [opt] annotation(annotationPropertyID annotationPropertyID T(individual) . individual) annotationPropertyID rdf:type owl:AnnotationProperty . annotationPropertyID rdf:type rdf:Property . [opt] 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} Tabela 21 Charakterystyka słownictwa OWL [2] 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 Tabela 22 Charakterystyka słownictwa OWL [3] 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>∈ <x,p> ∈ EXTI(SI(owl:onProperty))) EXTI(p)}) ≥ y } <x,y> ∈ EXTI(SI(owl:maxCardinality))) /\ {u ∈ IOT : card({v ∈ IOT ∪ LV : <u,v>∈ <x,p> ∈ EXTI(SI(owl:onProperty))) EXTI(p)}) ≤ y } <x,y> ∈ EXTI(SI(owl:cardinality))) /\ {u ∈ IOT : card({v ∈ IOT ∪ LV : <u,v>∈ <x,p> ∈ EXTI(SI(owl:onProperty))) 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> ∈ ∈ … EXTI(SI(rdf:first)), <ln,SI(rdf:nil)> ∈ EXTI(SI(rdf:rest)) ∈ <l1,x1> EXTI(SI(rdf:first)), <l1,l2> EXTI(SI(rdf:rest)), x1, …, xn ∈ IOT ∪ LVI <ln,xn> ∈ ∈ … EXTI(SI(rdf:first)), <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> ∈ EXTI(SI(owl:onProperty)) /\ ∈ EXTI(SI(owl:onProperty)) /\ <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)) x ∈ IOOP ∪ IODP /\ w ∈ LVI /\ w jest <y,x> nieujemną liczbą całkowitą EXTI(SI(owl:onProperty)) <y,w> ∈ EXTI(SI(owl:hasValue)) x ∈ IOOP ∪ IODP /\ w ∈ LVI /\ w jest <y,x> nieujemną liczbą całkowitą ∈ ∈ EXTI(SI(owl:onProperty)) /\ <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ę) (rdfs:subClassOf Ssak 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ę) (rdfs:subClassOf Ssak 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 intersectionOf(a:osoba 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 intersectionOf(a:osoba restriction(a:lubi someValuesFrom(a:kot)))) Z powyższych zapisów wynikają następujące wnioski: • 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)) Z powyższych zapisów wynikają następujące wnioski: • 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ę)) Z powyższych zapisów wynikają następujące wnioski: • 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ę) 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ę))))) Z powyższych zapisów wynikają następujące wnioski: • Ż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)))) Z powyższych zapisów wynikają następujące wnioski: • 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ę) 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ę)) 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))) Z powyższych zapisów wynikają następujące wnioski: • 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))) Z powyższych zapisów wynikają następujące wnioski: • 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)) Z powyższych zapisów wynikają następujące wnioski: • 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)))) Z powyższych zapisów wynikają następujące wnioski: • 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ę)))) Z powyższych zapisów wynikają następujące wnioski: • 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) unionOf (restriction (all (p A)) restriction (all p B))) unionOf (restriction (all (p A)) restriction (all p 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"/> </owl:DatatypeProperty> 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> <owl:ObjectProperty rdf:ID="hasInput"> <rdfs:subPropertyOf rdf:resource="#hasParameter"/> <rdfs:range rdf:resource="#Input"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasOutput"> <rdfs:subPropertyOf rdf:resource="#hasParameter"/> <rdfs:range rdf:resource="#Output"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasLocal"> <rdfs:subPropertyOf rdf:resource="#hasParameter"/> <rdfs:range rdf:resource="#Local"/> </owl:ObjectProperty> • 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"/> </owl:ObjectProperty> • 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"/> </owl:ObjectProperty> − withOutput określa co następuje gdy warunek jest prawdziwy, <owl:ObjectProperty rdf:ID="withOutput"> <rdfs:label>withOutput</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="#OutputBinding"/> </owl:ObjectProperty> − hasEffect określa co następuje gdy warunek jest prawdziwy, <owl:ObjectProperty rdf:ID="hasEffect"> <rdfs:label>hasEffect</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&expr;#Expression"/> </owl:ObjectProperty> − 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:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="#ResultVar"/> </owl:ObjectProperty> 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:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&rdf;#XMLLiteral"/> </owl:DatatypeProperty> 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:unionOf rdf:parseType="Collection"> <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> <owl:ObjectProperty rdf:ID="realizes"> <rdfs:domain rdf:resource="#AtomicProcess"/> <rdfs:range rdf:resource="#SimpleProcess"/> <owl:inverseOf rdf:resource="#realizedBy"/> </owl:ObjectProperty> 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"/> </owl:ObjectProperty> 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"/> </owl:ObjectProperty> 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> <owl:ObjectProperty rdf:ID="collapsesTo"> <rdfs:domain rdf:resource="#CompositeProcess"/> <rdfs:range rdf:resource="#SimpleProcess"/> <owl:inverseOf rdf:resource="#expandsTo"/> </owl:ObjectProperty> 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 usesMediator type ooMediator hasSource type {webService, goal, wgMediator, ggMediator} hasTarget type {webService, goal, ggMediator, wgMediator} Class wwMediator sub-Class mediator usesMediator type ooMediator 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 hasNonFunctionalProperties type nonFunctionalProperties 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 hasNonFunctionalProperties type nonFunctionalProperties 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 hasNonFunctionalProperties type nonFunctionalProperties 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) ), • forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] impliedBy l-expr(?v1,...,?vn) ), • forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?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 hasNonFunctionalProperties type nonFunctionalProperties 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 hasNonFunctionalProperties type nonFunctionalProperties 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 hasNonFunctionalProperties type nonFunctionalProperties 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 hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology 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 hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology 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 hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology usesMediator type ooMediator 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 hasNonFunctionalProperties type nonFunctionalProperties importsOntology type ontology 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 logicznym wyrażeniem w L(V). • 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 logicznym wyrażeniem w L(V). • 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 logicznym wyrażeniem w L(V). • 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} nonFunctionalProperties dc#description hasValue "concept of a human being" dc#relation hasValue humanDefinition endNonFunctionalProperties 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 nonFunctionalProperties dc#description hasValue "concept of a human being" endNonFunctionalProperties hasName ofType foaf#name 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 nonFunctionalProperties dc#description hasValue "The input has to be boy or a girl with birthdate in the past and be born in Germany." endNonFunctionalProperties 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 nonFunctionalProperties dc#description hasValue "After the registration the child is a German citizen" endNonFunctionalProperties 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 atrybut/relacja) jest formułą w L(V). • 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 atrybut/relacja) jest formułą w L(V). • 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 atrybut/relacja) jest formułą w L(V). 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 } nonFunctionalProperties dc#description hasValue "concept of a human being" endNonFunctionalProperties hasName ofType foaf#name 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.