Jeżeli chcemy zdefiniować schemat URI dla zasobów opisywanych w dokumentach RDF niezależnych od treści HTML (czyli nie osadzonych), mamy do wyboru dwa rozwiązania:

• schemat URI oparty na hash tagach,
• schemat URI oparty na przekierowaniach HTTP 303.

Schemat URI oparty na hash tagach

W pierwszym wypadku nasz serwis dostarcza pojedynczy dokument RDF, w którym poszczególne zasoby identyfikowane są za pomocą lokalnych nazw. Pełne URI zasobu składa się z URI dokumentu RDF i lokalnej nazwy zasobu.

Na przykład nasza firma może zebrać wszystkie informacje w jednym dokumencie RDF i opublikować go pod adresem http://www.przyklad.pl/informacje. Zasób RDF opisujący firmę może mieć lokalna nazwę ofirmie, skąd globalne URI będzie postaci http://www.przyklad.pl/informacje#ofirmie.

Korzystając ze schematów URI opartych na hash tagach możemy dostarczać zawartości w formacie rozpoznawalnym przez danego agenta. Poniższy rysunek pokazuje poszczególne etapy procesu. Agent semantyczny pytając o zasób o URI http://www.przyklad.pl/informacje#ofirmie korzystając z protokołu HTTP otrzymuje cały dokument http://www.przyklad.pl/informacje (hash tagi nie są przetwarzane w ramach protokołu HTTP). W przypadku agenta, który poprosi o dokument RDF (application/rdf+xml) nastąpi de facto przekazanie zawartości dokumentu http://www.przyklad.pl/informacje.rdf; zamiast przekazania bezpośrednio zawartości zasobu http://www.przyklad.pl/informacje. Podobnie w przypadku agenta proszącego o dokument HTML.

Schemat URI oparty na przekierowaniach HTTP 303

W przypadku schematu URI opartego na przekierowaniach HTTP, każdy zasób dla którego dostarczony jest dokument RDF posiada globalne URI. W powyższym przykładzie, taki URI byłby następujący: http://www.przyklad.pl/id/ofirmie. W odpowiedzi na zapytanie agenta o zasób o podanym URI, serwer wysyła status odpowiedzi 303, wraz z nagłówkiem Location o docelowym dokumencie. W przypadku agenta semantycznego proszącego o dokument RDF, zostanie on przekierowany do dokumentu http://www.przyklad.pl/doc/ofirmie.rdf

Który schemat wybrać ?

Zaletą schematów opartych na hash tagach jest mniejsza ilość zapytań HTTP, które musi wykonać agent komunikujący się z naszym serwisem. Niewątpliwą jednak wadą jest konieczność pobrania całego dokumentu opisującego wszystkie zasoby; szczególnie w przypadku dużej liczby zasobów może to prowadzić do sporych opóźnień w komunikacji. Dlatego też schematy URI oparte na hash tagach doskonale nadają się do niewielkich zestawów zasobów, o których informacje zmieniają się rzadko; przykładem mogą być lekkie ontologie. Na zakończenie, warto zauważyć, że oba rozwiązania nie wykluczają się wzajemnie; jeżeli nasz system potrafi skorzystać z hybrytowego rozwiązania opartego na obu schematach, tak powinniśmy uczynić.

A teraz, załóżmy, że supermarket to nasz serwis internetowy, a my jesteśmy agentem semantycznym próbującym uzyskać dostęp do poprzednio zidentyfikowanego źródła informacji. W momencie kiedy nasze położenie dokumentów i usług zmienia się na naszym serwisie, nie agent semantyczny (i nie tylko) musi na nowo sporządzić sobie mapę serwisu (czyli zaindeksować go).

Jak możemy ustrzec siebie i nasz serwis przez niestabilnymi URLami, które będą się zmieniały ? Rozwiązaniem promowanym m.in. przez sir Tima Bernersa-Lee są tak zwane "Cool URIs" (czyli "odjazdowe" URI), które nie ulegają zmianie.

Według TBL, kluczową kwestią w projektowaniu schematów URI jest zapewnienie ich niezmienności w czasie. Dzięki temu dany zasób lub usługa będzie zawsze dostępna pod tym samym adresem. Tak na marginesie, to podobne podejście ma środowisko bibliotekarzy; nie ma się co dziwić, w końcu od wieków muszą odnajdywać książki w przepastnych bibliotekach.

Wielu z was zapewne stwierdzi, że niezmienne URI to ciekawa naukowa wizja, ale w rzeczywistości; wymienicie nawet kilka kontr-przykładów:

1. Konieczność przeorganizowanie serwisu - po pewnym czasie doszliście do wniosku, że obecny sposób funkcjonowania waszego systemu i tego jakie URLe są generowane musi zostać poprawiony; tym samym schemat URI waszego serwisu ulegnie zmianie. To prawda, tak się może zdarzyć i niestety zdarza się zbyt często. A powód jest zazwyczaj jeden i ten sam: w czasie projektowania serwisu nie przemyślano dobrze architektury informacji i usług, a jedynie skupiono się (jeśli wogóle) na architekturze samego systemu. To doprowadziło do problemów z reprezentacją identyfikatorów zasobów.Wniosek: projektowanie architektury informacji jest równie ważne (o ile nie ważniejsze) od projektu samego systemu; system zawsze można poprawić, zmienić technologię, ale URI są jego interfejsem dla innych usług, i nie należy tego zaniedbywać.
   
2. Prawa dostępu - może się zdarzyć, że w natłoku dokumentów, którymi zarządza nasz system będziemy zmuszeni do zmiany uprawnień dostępu do nich. Jeżeli nasze URI będą budowane w oparciu o tę informację, np:
   • /archive/documents/123 - dla dokumentów archiwalnych,
   • /secret/documents/234 - dla dokumentów prywatnych,
   • /public/documents/345 - dla dokumentów publicznych,
3. to przenoszenie dokumentów np. do archiwum, powoduje że ich identyfikator się zmienia, i wszystkie referencje w innych dokumentach powinny zostać zaktualizowane.Rozwiązanie: przechowywać informacje o stanie i prawie dostępu na poziomie metadanych i stosować jednolity schemat URI dla wszystkich dokumentów w systemie.
4. Dokument zmienił swoje miejsce na dysku - sytuacja kiedy jeden z pracowników przejmuje obowiązki kolegi w czasie jego urlopu, i w tym czasie część dokumentów jest dostarczana z jego przestrzeni dyskowej zamiast z przestrzeni dyskowej kolegi, mogłaby teoretycznie prowadzić do zmiany adresu URL tych dokumentów, np. z /~pracownikA/documents/123.pdf do /~pracownikB/documents/123.pdf. .Rozwiązanie: wykorzystać mechanizmy mapowania dostarczne przez serwery HTTPD (np. Apache).
5. Zmiana implementacji usługi wystawiającej dokumenty - pierwsza wersja systemu powstała w PHP, a teraz z uwagi na wydajność musimy zaimplementować nasze usługi w JEE; w najlepszym wypadku będziemy musieli zmienić rozszerzenia skryptów z php na jsp. Ale przecież nie musiało do tego dość, tworzone przez nas schematy URI powinny być niezależne od implementacji danej usługi. Podpowiedź: ponownie mogą nam pomóc mechanizmy mapowania i przekierować dostarczane przez serwery HTTPD; część środowisk  umożliwia definiowanie schematów bez "rozszerzeń", np. JEE za pomocą serwletów.
6. URN vs URI - z założenia unikalne i niezmienialne miałybyć URN (ang. Universal Resource Name). To prawda, ale sam schemat HTTP z którego chcemy korzystać w URI, nie uniemożliwia niezmienialności identyfikatorów. Niestety, zazwyczaj jesteśmy sami winni temu, że one się zmieniają.
7. Brak odpowiednich narzędzi - chyba najczęstrza wymówka. Niestety dla wielu prawdziwa. Jedyne co mogę tutaj zaoferować to pomoc z naszej strony w dobraniu lub wyprodukowaniu odpowiednich rozwiązań.

Podsumowując, czego nie umieszczamy w URI?

1. Nazw i nazwisk - np. dokumentów, twórców, włascicieli
2. Tematow, klasyfikacji, opisów
3. Stanu dokumentów
4. Praw dostepu
5. Typów plików i ich rozszrzeń
6. Informacji o implementacji danej usługi dostarczającej dokumenty, np. PHP lub JSP.

Pamiętajmy również, że nazwa domeny jest częścia URI - więc trzeba zapewnić, żeby się nie zmieniała.

O tworzeniu stron bogatych w semantykę pod kątem indeksowania przez Google napiszemy w kolejnych artykułach.  W tym artykule przedstawimy przegląd technik publikowania semantyki na naszych serwisach internetowych.

Kiedy nasza witryna internetowa zasilana jest bazą danych, np. relacyjną, możemy niskim kosztem uczynić ją bardziej semantyczną, publikując nie tylko jej wersję czytelną dla ludzi, ale również wersję czytelną dla maszyn. Jeżeli nasza strona tworzona jest "ręcznie", a narzędzie którego używamy nie wspiera oznaczeń semantycznych, będzie nas to kosztowało trochę więcej pracy.

Aby powiązać wersję czytelną dla maszyn z naszym serwisem stworzonym dla ludzi, mam do wyboru trzy rozwiązania:

1. Wskazujemy na zewnętrzny dokument (lub usługę), który zawiera reprezentację danej strony w formacie zrozumiałym przez maszyny, np.: RDF (najlepiej w wersji Turtle lub N3).
2. Osadzamy (ang. embed) semantykę bezpośrednio w źródle naszej strony HTML.
3. Podajemy reguły translacji źródła naszej strony do dokumentu RDF.
4. Dostarczamy usługę negocjacji zawartości (ang. content negotiation) w ramach naszego serwisu.

Wskazujemy na dokumenty RDF

Wskazanie na zewnętrzny dokument RDF jest zapewne najprostrzym rozwiązaniem. Wystarczy, że w źródle HTML naszej strony internetowej, w sekcji <head> umieścimy poniższy odnośnik wskazujący na inny dokument po podanym adresem URL.

<link rel="media" type="text/turtle" title="wersja semantyczna" href="http://adres.naszego.serwisu/dane/dokument.ttl"/>

Wskazany w ten sposób dokument może opisywać zarówno pojedynczą stronę HTML naszego serwisu, jak i dostarczać zbiorczy opis dla wszystkich stron opisu. Oczywiście idealnie byłoby gdybyśmy dostarczali osobne dokumenty RDF dla każdej strony HTML.

Plugin dla WordPress eksportujący źródło blogu w ontologii SIOC, którego używamy w Szkole Web 3.0, w informuje agenty Web 3.0 o powiązanych danych semantycznych w następujący sposób:

<link rel="meta" type="application/rdf+xml" title="SIOC" href="http://www.semanticschool.com/index.php?sioc_type=post&amp;sioc_id=487" />

Osadzamy semantykę w źródle strony WWW

Innym sposobem, sugerowanym m.in. przez Google, jest osadzenie semantyki bezpośrednio w kodzie strony WWW. Wykorzystujemy do tego celu elementy definiowane przez specyfikację (X)HTML, m.in. wartości atrybutów class, id, title, rev i rel. W chwili obecnej do najbardziej popularnych standardów osadzania danych RDF w stronie HTML należą:

• mikroformaty (ang. microformats) - są chyba najstarszym sposobem osadzania semantyki. Chociaż przez pewien czas społeczność mikroformatów występowała niejako w opozycji do środowiska Semantic Web, w chwili obecnej są one jednym z rekomendowanych sposobów osadzania semantyki, wspierane zarówno przez Yahoo! i Google. Chyba największym minusem mikroformatów jest fakt, że są one nie tylko sposobem osadzania semantyki, ale również  zamkniętym (w dużej mierze) zestawem mini-ontologii.
• eRDF - umożliwia osadzenie semantyki z dowolnej ontologii. W tym celu, najpierw w <head> definiujemy listę wspieranych ontologii, deklarując mapowanie nazwy ontologii na URI jej specyfikacji:

  <link rel="schema.foaf" href="http://xmlns.com/foaf/0.1/" />

  a następnie wykorzystujemy atrybuty class do określania predykatów zdań RDF osadzonych w stronie:

  <span class="foaf-firstName">Sebastian</span>

  Co zostanie zinterpretowane przez agenta semantycznego jako:

  <> foaf:firstName "Sebastian".

  Podmiot zdań RDF deklarujemy za pomocą elementu <link>

  <link href="#sebastian" rev="foaf-made" rel="foaf-maker" />

  gdzie atrybut rel odczytujemy jako predykat pomiędzy daną stroną a określonym przez href zasobem, a atrybut rev odczytujemy jako predykat pomiędzy określonym zasobem a daną stroną.
  Powyższy przykład zostałby odczytany jako:

  <http://www.semanticschool.com/2009/11/publikowanie-semantyki/#sebastian> foaf:made <http://www.semanticschool.com/2009/11/publikowanie-semantyki/>.
  <http://www.semanticschool.com/2009/11/publikowanie-semantyki/> foaf:maker <http://www.semanticschool.com/2009/11/publikowanie-semantyki/#sebastian> .

• RDFa jest oficjalną rekomendacją W3C, wspieraną m.in. przez Yahoo i Google. Jest dużo bardziej zaawansowana pod względem możliwych konstrukcji osadzania semantyki. Rozszerza ona mechanizmy zdefiniowane w eRDF o m.in. na określaniu przestrzeni nazw (ang. namespace) dla danego fragmentu strony za pomocą meta-atrybutów xmlns:*. Predykaty definiowane są za pomocą atrybutu property. RDFa umożliwia również na definiowanie dowolnych podmiotów zdań RDF, za pomocą atrybutu about, oraz na określanie typów (klas) zasobów za pomocą atrybutów typeof. Standard RDFa opiszemy w jednym z przyszłych artykułów.

Określamy reguły translacji do dokumentów RDF

Zanim osadzanie semantyki za pomocą standardów typu RDFa stało się popularne, środowisko Semantic Web promowało standard GRDDL (czyt: grid'l). Idea tego rozwiązania opierała się na deklarowaniu dla danej strony HTML transformaty XSTL za pomocą której dana strona może zostać przekształcona do postaci dokumentu RDF. Oto przykład takiej definicji:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:grddl='http://www.w3.org/2003/g/data-view#'
      grddl:transformation="glean_title.xsl
			    http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl"
 >

Budujemy usługę negocjacji zawartości

Ostatnim, i w chwili obecnej najbardziej popularnym rozwiązaniem dla wszelkiego rodzaju serwisów internetowych, jest dostarczenie usługi negocjacji zawartości. Pomysł opiera się na określeniu (co najmniej) trzech schematów URI dla każdego typu zasobu obsługiwanego przez nasz serwis, np. dla blogu typami takimi byłby: osóby, artykuły, tagi i kategorie.  Tymi podstawowymi trzema schematami są:

1. Identyfikator zasobu, np.: URI autora artykułów.
2. Wersja zasobu zrozumiała dla ludzi, np.: strona HTML z profilem danego autora artykułów.
3. Wersja zasobu zrozumiała dla maszyn, np.: dokument RDF z profile FOAF danego autora artykułów.

Rozwiązanie oparte o usługę negocjacji zawartości jest sposobem rekomendowanym przez inicjatywę publicznych, połączonych danych (ang. linked data) o której pisałem w poprzednim odcinku tego cyklu. Autorzy mini-podręcznika o tym jak publikować połączone dane omawiają różne sposoby deklarowania schematów URI:

1. Różne domeny:
   • http://id.nasz-serwis.pl/autorzy/Sebastian
   • http://www.nasz-serwis.pl/autorzy/Sebastian
   • http://rdf.nasz-serwis.pl/autorzy/Sebastian
2. Różne rozszerzenia (pseudo-) plików udostępnianych przez serwis:
   • http://www.nasz-serwis.pl/autorzy/Sebastian
   • http://www.nasz-serwis.pl/autorzy/Sebastian.html
   • http://www.nasz-serwis.pl/autorzy/Sebastian.rdf
3. Różne człony wewnątrz schematu URI:
   • http://www.nasz-serwis.pl/id/autorzy/Sebastian
   • http://www.nasz-serwis.pl/html/autorzy/Sebastian
   • http://www.nasz-serwis.pl/rdf/autorzy/Sebastian

W następnym odcinku tego cyklu przedstawimy wytyczne budowania tzw. cool URI.

Kiedy określimy już schemat URI dla naszych typów zasobów, konieczne jest takie skonfigurowanie naszego serwisu (np. na poziomie konfiguracji serwera HTTPD), aby w odpowiedzi na zapytanie o stronę z identyfikatorem zasobu, przekierowywał albo na stronę HTML albo do dokument RDF, w zależności od możliwości interpretowania treści określonych przez klienta (przeglądarkę WWW lub agenta semantycznego).

Ideę przekierowań 303 prezentuje poniższy rysunek. Aplikacja kliencka za pomocą nagłówka HTTP określa rozpoznawany typ zasobów, w tym wypadku application/rdf+xml, na co serwer w odpowiedzi wysyła przekierowanie do dokumentu RDF zawierającemu opis danego zasobu.

Należy pamiętać, aby zarówno na stronach HTML jak i dokumentach RDF posługiwać się URI będącym identyfikatorem zasobu, a nie jego wersją w postaci strony HTML lub dokumentu RDF.

Przekierowania 303 (źródło: http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/)

Wiem co masz na myśli

O ile lata sukcesów i porażek badań nad Sztuczną Inteligencją (ang. Artificial Intelligence) przyniosły bardziej złą sławę niż konkretne rezultaty, to należy pamiętać, że ludzie pracujący nad Siecią Semantyczną odcinają się od sztucznej inteligencji, proponując w zamian dość radykalnie różne podejście: przetwarzanie znaczeniowe a nie numeryczne.

Oczywiście wymaga to również odmiennego sposobu reprezentacji informacji: jest nią RDF (Resource Description Framework). Zanim omówimy czym jest RDF, małe ćwiczenie: postarajcie się opisać krzesło (np. z obrazka poniżej) używając do tego jak najprostszych zdań.

Krzesło: jak je opiszesz?

I jak? Udało się? Oto kilka zdań które mi przyszły do głowy:

• To jest krzesło.
• Jest zrobione z drewna i skóry.
• Posiada oparcie i nogi.
• Ma cztery nogi.
• Służy do siedzenia.
• Wykonane jest przez stolarza.

Możemy też dalej rozszerzać nasz opis:

• Stolarz wykonuje krzesła.
• Mężczyzna siedzi na krześle.
• Stolarz i mężczyzna są ludźmi.

I oczywiście moglibyśmy kontynuować nasz opis w nieskończoność. To co powstaje w naszej głowie to mapa myśli (ang. mind map). Jeżeli pominiemy restrykcje i wytyczne narzucone przez technikę tworzenia map myśli, to nasz opis krzesła możemy przedstawić następująco.

Pojęcie "krzesło" opisane jako mapa myśli

Tym samym stworzyliśmy nasz pierwszy opis w RDF.

Jak to możliwe? Otóż RDF jest właśnie językiem reprezentacji informacji zapisanej w grafie (skierowanym). Każde proste zdanie (w języku naturalnym) odpowiada jednej krawędzi w grafie, tj. wyróżniamy 3 elementy każdego zdania RDF (ang. RDF statement):

• podmiot (ang. subject) to wierzchołek, czyli zasób (ang. resource), w którym zaczyna się dana krawędź,
• predykat (ang. predicate) nazywa daną krawędź w grafie,
• obiekt (ang. object) to drugi wierzchołek, zasób lub literał (ang. literal), w którym kończy się dana krawędź.

Na przykład nasze zdania możemy zapisać następująco, wyróżniając poszczególne elementy zdania RDF:

• [Krzesło] [posiada] [oparcie].
• [Krzesło] [służy do] [siedzenia].
• [Krzesło] [wykonane jest przez] [stolarza].
• [Stolarz] [wykonuje] [krzesła].
• [Mężczyzna] [siedzi na] [krześle].

Jest jednak kilka zdań, których zapis nie jest aż tak oczywisty.

• "Jest zrobione z drewna i skóry" - możemy zapisać jako dwa zdania:
  • [Krzesło] [jest zrobione z] [drewna].
  • [Krzesło] [jest zrobione ze] [skóry].
• "Posiada cztery nogi." - tutaj ujawnia się ciekawa właściwość RDF, tzw. reifikacja (ang. reification), czyli wypowiadanie zdania o zdaniu. W tym przypadku będzimy potrzebowali dwóch zdań RDF do zapisania tego przykładu (tak naprawdę będziemy potrzebowali aż 6 zdań, ale o tym w jednym z kolejnych artykułów):
  • [Krzesło] [ma] [nogi].
  • [W powyższym zdaniu] [jest nóg sztuk] "4".
• Zadania z "to jest" wymagają specjalnego predykatu do określenia klasy, tzn. typu, opisywanego zasobu. Ten predykat to "rdf:type" i jest jednym z istotnych elementów opisu RDF (więcej na ten temat niedługo):
  • [Nasze krzesło] [rdf:type] [Krzesło].
  • [Nasz mężczyzna] [rdf:type] [Człowiek].
  • [Nasz stolarz] [rdf:type] [Człowiek].

Chociaż nie potrafimy jeszcze zapisać formalnie opisu RDF (o tym w artykule o sposobach reprezentacji grafu RDF), to na zakończenie warto zapamiętać jeszcze kilka (trochę technicznych informacji, więc nie przejmujcie się jeżeli wrócimy do nich w najbliższych artykułach).

W grafie RDF występują dwa typy wierzchołków: zasoby (ang. resource) i literały (ang. literal). Zasoby są identyfikowane przez URI (patrz artykuł o semantycznym torcie), i mogą być początkiem, jak i końcem krawędzi w grafie; sama krawędź jest również identyfikowana przez URI. Literały są ciągami znaków, liczbami, datami, itp., i tym samym mogą być jedynie końcowym wierzchołkiem krawędzi.

RDF definiuje jeszcze jeden specjalny typ wierzchołka: tzw. nienazwany wierzchołek (ang. blank node). Nienazwane wierzchołki nie mogą być identyfikowane poza systemem, który przechowuje informacje o grafie. Możemy użyć ich do reprezentacji wierzchołków grafu, ale nie do reprezentacji jego krawędzi. Do nienazwanych wierzchołków jeszcze wrócimy, ale zapamiętajcie, że należy ich unikać ze wszystkich sił.

Image via Wikipedia

Jednym ze sposobów na przedstawienie wizji rozwoju Web 3.0, a dokładniej Sieci Semantycznej, jest analiza tzw. semantycznego tortu (ang. Semantic Web Layer Cake), który przedstawia stos technologii i standardów potrzebnych do stworzenia w pełni funkcjonalnej Sieci Semantycznej. Jedna z jego pierwszych wersji (prezentowana w 2002 roku przez TBL) była następująca:

Semantyczny tort (rok 2002) źródło: http://www.w3.org/2002/Talks/04-sweb/slide12-0.html

Podstawą Sieci Semantycznej są dwie technologie, dzięki którym możliwe jest wskazanie dowolnej treści i obiektu (nie tylko w Internecie) oraz opisanie ich w dowolnym języku; są to odpowiednio URI (Uniform Resource Identifier) i Unicode. Adres URI jest podobny do adresu URL (Uniform Resource Locator), z którym mamy codziennie do czynienia w Internecie; różni go jednak to iż umożliwia (przynajmniej teoretycznie) na wskazanie nawet przedmiotów w świecie rzeczywistym, a zatem również ich opisanie i połączenie z dokumentami w Internecie. Unicode umożliwia zapis znaków ze wszystkich znanych obecnie alfabetów.

Kolejna warstwa to bardzo popularny obecnie standard XML i związane z nim przestrzenie nazw (ang. namespaces). W XMLu można zapisać informacje tak, aby maszyna mogła je przetworzyć (ale nie zrozumieć!). W jednym z przyszłych artykułów postaramy się wyjaśnić dlaczego wprowadzenie warstwy XML do "semantycznego tortu" nie było najlepszym pomysłem.

Warstwę wyżej zdefiniowany jest standard nieodłącznie związany z Siecią Semantyczna: RDF (Resource Description Framework). W odróżnieniu od XMLa umożliwia on na zapis grafu (skierowanego) w postaci przetwarzanej przez maszyny; m.in. właśnie na bazie informacji zapisanych w grafie powiązań znaczeniowych (tj. semantycznych) maszyny mogą podjąć próbę zrozumienia prezentowanej treści. Aby wspomóc proces "rozumienia" informacji zapisanej w RDF, kolejne dwie warstwy związane są z definiowaniem znaczenia pojęć wykorzystanych w opisie grafu RDF. Tak zgadliście: chodzi o okryte złą sławą ontologie (o tym w jednym z następnych odcinków serialu). RDF Schema umożliwia na definiowanie prostych ontologii za pomocą hierarchii klas (ang. class) i właściwości (ang. property); nie, tym razem nie ma to nic wspólnego z programowaniem obiektowym poza samą nazwą. Omówimy ten problem w osobnym artykule.

Kolejna warstwa, czyli reguły (ang. rules), pozwala na definiowanie (w językach formalnych, np. RIF) reguł przetwarzania wiedzy zapisanej w RDF i ontologiach. W zestawieniu z budowanymi obecnie mechanizmami struktur logicznych (ang. logic framework) umożliwią maszynom zrozumienie informacji, a nie tylko jej przetwarzanie.

Ostatnie dwie warstwy konieczne są do zapewnienia maszynom (pewnej) autonomiczności w przetwarzaniu informacji i podejmowaniu decyzji w imieniu ich właścicieli. Wymaga to jednak możliwości dostarczenia formalnych dowodów (ang. proof) na poprawność wysuniętych wniosków, oraz ustalenia poziomu zaufania do przeprowadzonego procesu wnioskowania (ang. trust).

Pozostałe dwa elementy, podpisy cyfrowe (ang. signature) i szyfrowanie (ang. encryption), zapewniają bezpieczeństwo operacji w Sieci Semantycznej.

Uff, dużo tego, a co gorsza - same suche specyfikacje, rekomendacje, standardy. Całe szczęście w ciągu ostatnich lat udało się zmienić tę wizję chociaż częściowo w rzeczywistość.

W ciągu ostatnich lat "semantyczny tort" ewoluował wraz z implementacją kolejnych jego warstw. Już dwa lata póżniej, TBL dodał dodatkową warstwę: zapytań (ang. queries) i schematów XML. Pojawiły się też pierwsze narzędzia (Annotea), słowniki (P3P, CC/PP) i standardy (Dublin Core, RSS) implementujące dolne warstwy tortu:

Kolejna wersja semantycznego tortu (rok 2004) http://www.w3.org/2004/Talks/0412-RDF-functions/slide4-0.html

Obecna wersja "semantycznego tortu" zawiera przede wszystkim specyfikacje, które stały się standardami implementującymi poszczególne warstwy: OWL (Web Ontology Language), RIF (Rule Interchange Format), SPARQL (język zapytań dla RDF). Istotne jest, że ontologie, reguły i logika stały się de facto jedną warstwą. Ograniczone też zostało znaczenie formatu XML, bo tak na prawdę w Sieci Semantycznej można radzić sobie bez ograniczeń wprowadzonych przez XML. Pojawiła się też nowa warstwa "docelowa" - interfejs użytkownika (ang. user interface) i aplikacje. Dodatkowo, wskazywanie obiektów możliwe jest teraz za pomocą standardu IRI (Internationalized Resource Identifier) rozszerzającego URI o możliwość używania znaków spoza standardu ASCII do zapisu identyfikatora obiektu.

Do niedawna cały nacisk na prace nad Siecią Semantyczną skierowany był na rozumienie znaczenia treści przez maszyny. To m.in. sukces Web 2.0 spowodował, że zrozumiano potrzebę i ogromne znaczenie interakcji użytkowników z systemami opartymi o rozwiązania semantyczne.

Obecna wersja semantycznego tortu http://www.w3.org/2007/03/layerCake.png

Na zakończenie, wisienka na torcie (ang. cherry on the cake): wersja 3D semantycznego tortu przygotowana przez Benjamina Nowacka. To co w niej istotne to najnowszy element zestawu technologii semantycznych: powiązane dane (ang. linked data). Nie ma co ukrywać, że są one niezmiernie ważne dla sukcesu Web 3.0:  bez semantycznych (czyt. powiązanych) danych, dostępnych w dużej mierze publicznie, żadne mechanizmy wnioskowania nie będą miały znaczenia.

Semantyczny tort w wersji 3D wraz z powiązanymi danymi http://bnode.org/blog/2009/07/08/the-semantic-web-not-a-piece-of-cake