Standardy semantyczne

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 Maps 1 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), - pojęcie, którego podmiot jest klasą pojęcia; 1 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 identyfikatora do wskaźnika (w przypadku podmiotu nieelektronicznego).

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 RDF 2 (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 jest identyfikowana przez referencję URI http://www.w3.org/2000/01/rdf-schema# i jest skojarzona z przedrostkiem rdfs. Specyfikacja używa również przedrostka rdf odnoszącego się do przestrzeni nazw http://www.w3.org/1999/02/22-rdf-syntax-ns#. RDFS 3 (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 relacje 4 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 Por. szerzej http://www.w3.org/tr/rdf-concepts/ 3 Por. szerzej http://www.w3.org/tr/rdf-schema/ 4 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 Komentarz rdfs:resource rdfs:literal rdf:xmlliteral rdfs:class rdf:property rdfs:datatype rdf:statement rdf:bag rdf:seq rdf:alt rdfs:container Zasób klas, wszystko. Klasa wartości liczbowo-literowych, np. stringi tekstowe, liczby całkowite. Klasa wartości liczbowo-literowych XML. Klasa wszystkich klas. Klasa właściwości RDF. Klasa typów danych RDF. Klasa zdań RDF. Klasa nieuporządkowanych kontenerów. Klasa uporządkowanych kontenerów. Klasa kontenerów alternatyw. Klasa kontenerów RDF. Klasa właściwości elementów kontenerów, rdf:_1, rdf:_2, rdfs:containermembershipproperty wszystkie, które są podwłaściwościami 'member'. rdf:list 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:class rdfs:subpropertyof Podmiot jest podwłaściwością właściwości. rdf:property rdf:property

Nazwa właściwości Komentarz 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:rest Reszta listy RDF, to, co za pierwszym rdf:list elementem. rdf:list 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 do rdfs:resource rdfs:resource uporządkowanych wartości. 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 używane w RDF są kompatybilne z abstrakcyjnym językiem XML Schema. Typy danych składają się z

przestrzeni leksykalnej (zbiór Unicode 5 ), 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 w XML Schema pod warunkiem, że podporządkowują się one powyższemu schematowi. Istnieją 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 wskazywana w grafach RDF przy pomocy danych liczbowo-literowych, które posiadają specjalny typ danych 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) działają jako pośrednicy między niektórymi odzyskiwanymi dokumentami a zbiorami możliwych 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. Semantyka 7 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.