Oto program mojej prezentacji:

1. O co chodzi z Web 3.0 ?
   • Krótka historia Sieci
   • Od URI do zaufania
2. Podstawy: RDF, ontologie i SPARQL
3. Byc w Sieci a byc czescia Sieci
   • Polaczone Dane: Publikujemy w Web 3.0
   • Cyfrowe a Sieciowe: Semantyczne Biblioteki Cyfrowe
   • eGov: Upublicznianie publicznych danych
4. Poza akademickie rozwazania:
   • Google Rich Snippets, RDFa i BestBuy
   • Facebook Open Graph
5. Podsumowanie: Przyszlosc  Web 3.0

Jeżeli jest coś o czym chcielibyście usłyszeć to proszę o komentarze, a być może uda mi się omówić krótko dany temat w czasie tej 45-minutowej prezentacji.

Kliknij na graf aby pobrać źródło w formacie Turtle

W celu zdefiniowania operacji filtrowania w danym zapytaniu stosujemy operator FILTER. Zacznijmy od czegoś prostego, np.: znajdźmy takie węzły które mają dla predykatu :e wartość literału większą od 5, a dla predykatu :j datę (jako wartość literału) po 1 marca 2010. Ponieważ nasz RDF nie ma jawnie określonych typów literałów zastosowaliśmy rzutowanie na datę (xsd:dateTime) oraz liczbę całkowitą (xsd:integer).

PREFIX    : <http://www.semanticschool.com/>
PREFIX xsd:	<http://www.w3.org/2001/XMLSchema#>
SELECT ?x
WHERE { ?x :j ?date;
           :e ?value.
        FILTER ( xsd:dateTime(?date) > xsd:dateTime("2010-03-01T00:00:00Z") &&
                 xsd:integer(?value) > 5 ) }

W wyniku otrzymamy: ?x = :B. W filtrach możemy również używać wyrażenia regularne. Jeżeli np. interesują nas te węzły, które mówią o tym, że Ala coś ma, to zapiszemy to następująco:

PREFIX :      <http://www.semanticschool.com/>
SELECT ?x
WHERE { ?x :e ?value.
        FILTER regex( ?value, "[Aa]la ma \\S+" ) }

W wyniku otrzymamy ?x = :C oraz ?x = :E. Zauważyliście zapewne, że zapisaliśmy Ala jako "[Aa]la" - to wyrażenie umożliwia nam wybranie tych fraz które zawierają zarówno Ala jak i ala. Jeżeli wielkość liter nie jest dla nas istotna w całej frazie, możemy skorzystać flagi "i", która mówi procesorowi wyrażeń regularnych, że ma ignorować wielkość liter:

PREFIX :      <http://www.semanticschool.com/>
SELECT ?x
WHERE { ?x :e ?value.
        FILTER regex( ?value, "ala ma \\S+", "i" ) }

Kliknij na graf aby pobrać źródło w formacie Turtle

Do dyspozycji mamy zestaw funkcji testujących właściwości podanych węzłów w grafie RDF:

• isIRI oraz isURI - sprawdza czy podany argument jest zasobem identyfikowanym przez URI/IRI (tzn. nie jest literałem albo bnodem).
• isBlank - sprawdza czy podany argument jest bnodem (nienazwany węzeł).
• isLiteral - sprawdza czy podany argument jest literałem.
• sameTerm - sprawdza czy podane dwa argumenty są tym samym zasobem lub literałem (zobacz http://www.w3.org/TR/rdf-concepts/ po dodatkowe informacje)
• langMatches - sprawdza czy znacznik języka literału podanego jako pierwszy argument znajduje się w zakresie języków podanym w drugim argumencie; jako drugi parametr możemy również podać "*" do oznaczenia każdego niepustego znacznika języka. Więcej na temat porównania znaczników jezyka pod adresem http://www.ietf.org/rfc/rfc4647.txt.
• możemy również porównać dwa węzły za pomocą znaku = (zobacz http://www.w3.org/TR/rdf-sparql-query/#func-RDFterm-equal po więcej informacji)

Oraz zestaw funkcji za pomocą, których możemy przekształcać podane węzły w grafie RDF do postaci ciągu znaków

• str - zwraca ciag znaków reprezentujący dany zasób; np. w przypadku literału będzie to część literału bez znacznika języka czy typu
• lang - zwraca znacznik języka podanego literału (jeśli jest określony)
• datatype - zwraca znacznik typu podanego literału (jeśli jest określony)

Dodakowo, poszczególne wyrażenia w ramach jednej frazy FILTER możemy łączyć za pomocą operatorów logicznych AND (wyrażanego jako &&) oraz OR (wyrażanego jako ||).

A teraz czas na kilka przykładów.

Szukamy zasobów "wkazujących" na węzeł :B w naszym grafie, które są identyfikowane przez URI (a nie przez bnode).

PREFIX    : <http://www.semanticschool.com/>
SELECT ?x
WHERE { ?x ?p :E.
        FILTER ( isBlank(?x) ) }

Szukamy tych zasobów które wskazują na :E i są bnodami

PREFIX    : <http://www.semanticschool.com/>
SELECT ?x
WHERE { ?x :g ?y.
        FILTER ( isLiteral(?y) ) }

Szukamy takich zasobów które wskazują na ten sam inny zasób.

PREFIX    : <http://www.semanticschool.com/>
SELECT ?x ?y
WHERE { ?x :g ?px.
        ?y :e ?py.
        FILTER ( sameTerm(?px, ?py) ) }

Pytanie: ile bedzie par wyników dla jeżeli :g, :e zastąpimy przez ?g, ?e ?

Szukamy zasobów wskazujących na literały napisane po Hiszpańsku.

PREFIX    : <http://www.semanticschool.com/>
SELECT ?x
WHERE { ?x :e ?l.
        FILTER ( langMatches( lang(?l), "ES") ) }

Pytanie: ile będzie wyników jeżeli będziemy szukali zasobów w dowolnym języku ?

Szukamy takich zasobów które wskazują na literały nie będące określeniem czasu.

PREFIX xsd:	<http://www.w3.org/2001/XMLSchema#>
SELECT ?x ?l
WHERE { ?x ?p ?l.
        FILTER ( datatype(?l) != xsd:dateTime  ) }

Na zakończenie trochę bardziej skomplikowany przykład: szukamy takich par różnych zasobów, które wskazują na ten sam literał, oraz dla których dla pierwszego zasobu reprezentacja URI w postaci ciągu znaku występuje w sortowaniu alfabetycznym przed reprezentacja URI drugiego zasobu.

SELECT ?x ?y
WHERE { ?x ?p1 ?l1.
        ?y ?p2 ?l2.
        FILTER ( isLiteral(?l1) &&
                      isLiteral(?l2) &&
                      ?l1 = ?l2 &&
                      ?x != ?y &&
                      str(?x) > str(?y) ) }

Składniki:

• ok 100MB wolnej przestrzeni na dysku (co najmniej tyle, więcej będzie potrzebne w zależności od wielkości przechowywanych przez was grafów) [pobierz]
• system operacyjny z zainstalowaną maszyną wirtualną Java'y w wersji deweloperskiej (JDK) 1.5 lub wyższej (osobiście korzystam z JDK5 i JDK6) [pobierz]
• instalator (dla Windows) lub paczka (archiwum) z kontenerem serwletów Apache Tomcat w wersji 6.0 [pobierz]
• paczka z silnikiem bazy danych Sesame 2.0 [pobierz].

Wszystkie z składniki należy zainstalować w podanej kolejności. W przypadku Apache Tomcat i Sesame wystarczy rozpakować sciągnięte paczki (archiwa) w dowolnie wybrane miejsce. Jeżeli instalujecie Apache Tomcat jako usługę (Windows Service Installer) zapamiętajcie gdzie poleciliście instalatorowi zainstalować tę usługę.

Paczkę z Sesame możecie rozpakować w dowolnym miejscu, gdyż potrzebujemy jedynie dwóch plików war dostarczanych w tej paczce. W katalogu który powstał po rozpakowaniu paczki z Sesame odnajdujemy podkatalog o nazwie war i przegrywamy z niego oba znajdujące się tam pliki do podkatalogu webapps w katalogu gdzie zainstalowaliśmy (rozpakowaliśmy) kontener serwletów Apache Tomcat.

Czas aby uruchomić serwer Apache Tomcat. Użytkownicy Windows mogą włączać i wyłączać serwer Tomcat za pomocą usług Windows (patrz zdjęcie poniżej)

lub ikonki, która powinna być widoczna na tacce systemowej:

Dla tych którzy nie zainstalowali (lub nie mogli zainstalować) Tomcata jako usługi Windows uruchamianie jest równie proste. Wystarczy wejść do katalogu w którym został zainstalowany serwer, przejść do podkatalogu bin i tam uruchomić program startup.bat lub startup.sh (w zależności czy korzystamy odpowiednio z Windows czy systemu Unixowego).

Po uruchomieniu w przeglądarce internetowej otwieramy adres http://localhost:8080/openrdf-workbench/ (z dokładnością co do numeru portu o ile go zmieniliście w czasie instalacji).

Na powitanie, świeże Sesame wita nas nasŧępującym ekranem.

Nasze pierwsze zadanie to stworzyć nowe repozytorium do którego będziemy mogli załadować później graf RDF i wykonywać na nim zapytania. W tym celu klikamy na link "New repository". Musimy zdecydować pomiędzy jednym z kilku dostępnych typów repozytoriów: na wstępie proponuje pozostać przy "Native Java Store".

Po zakończeniu procesu tworzenia nasze nowe repozytorium zostaje wybrane jako domyślne i możemy rozpocząć pracę.

Aby dodać graf RDF klikamy na link "Add" w sekcji "Modify". Tam mamy do wyboru albo załadowanie pliku z grafem z dysku, albo wskazanie zasobu w sieci, albo wklejenie fragmentu grafu w jednym z dostępnych języków, w tym w N-triples, Turtle i RDF/XML.

Po dodaniu grafu RDF możemy przystąpić do zadawania zapytań korzystając z opcji "Query" w sekcji "Explore".

Pozostaje mi tylko życzyć dobrej zabawy w zadawaniu pierwszych zapytań w SPARQL.

Specyfikacja SPARQL definiuje 4 typy zapytań:

• SELECT - zwraca wszystkie (lub określoną część) zmiennych zadeklarowanych w szablonie zapytania.
• CREATE - umożliwia zdefiniowanie szablonu grafu RDF wypełnianego wartościami zmiennych zadeklarowanych w szablonie zapytania.
• DESCRIBE - zwraca graf RDF możliwie najpełniej opisujący podany zasób.
• ASK - zwraca wartość prawda lub fałsz w zależności od tego czy podany szablon zapytania został spełniony czy też nie.

Przeanalizujmy każdy typ zapytania na jednym z grafów z poprzedniego odcinka.

Zacznijmy od prostego zapytania typu SELECT; poszukajmy te podgrafy w których istnieją zasoby będące obiektami w zdaniach, gdzie podmiotem jest :B a predykatem jest :e, oraz które znajdują się dokładnie dwa stopnie oddalenia od zasobu :A.

SELECT ?V ?V1 ?e1 ?e2
WHERE
{
:B :e ?V.
:A ?e1 ?V1.
?V1 ?e2 ?V.
}

W wyniku otrzymamy następujące rozwiązania:

Załóżmy teraz, że naszym celem jest stworzenie grafu zawierającego ścieżki prowadzące od zasobu :A i od zasobu :B do zasobów będących wynikami poprzedniego zapytania, przy czym predykaty na ścieżce od zasobu :A do znalezionego zasobu zostaną zastąpione przez predykat :p.

CONSTRUCT
{
:B :e ?V.
:A :p ?V1.
?V1 :p ?V.
}
WHERE
{
:B :e ?V.
:A ?e1 ?V1.
?V1 ?e2 ?V.
}

Zwróci nam następujący wynik w postaci grafu RDF (poniższy wynik zapisany w języku Turtle):

:B :e :F, :E, :G .
:A :p :B .
:B :p :E , :F , :G .
:A :p _:c .
_:c :p :F .
:A :p :D .
:D :p :E .

Przy pomocy zapytań SPARQL możemy również stwierdzić czy :F znajduje się na ścieżce o długości 2 z :A do :E.

ASK
{
:A ?p1 :F.
:F ?p2 :E.
}

W tym wypadku otrzymamy odpowiedź "false".

Na zakończenie czwarty rodzaj zapytania - opis zasobu. Na następujące zapytanie o zmienną ?a

DESCRIBE ?a
WHERE
{
?a :b :B.
}

Otrzymamy opis zasobu który został pod nią dopasowany:

:A :a :D ;
:b :B ,
_:c .

W następnym odcinku opiszę jak łatwo i bezboleśnie zainstalować własne repozytorium RDF na którym można uczyć się zapytań w języku SPARQL.

W poprzednim odcinku nauczyliśmy się jak znaleźć URI zasobu lub jego właściwości korzystając z prostych zapytań.

Weźmy teraz pod uwagę powyższy graf. Załóżmy, że chcemy wskazać zasób :A; możemy go opisać następującymi zdaniami:

:A :b :B.
:A :b :C.
:B :e :E.
:B :e :F.
:B :e :G.

Jeżeli nie znalibyśmy niektórych z informacji w grafie, np.: zasobu :B czy właściwości :e, informacja o zasobie :A wyglądałaby następująco:

:A :b ?x.
:A :b :C.
?x ?y :E.
?x ?y :F.
?x ?y :G.

Tym samym zapisaliśmy podstawowe reguły do zapytania SPARQL, które wyglądałoby następująco:

SELECT ?a
WHERE
{
?a :b ?x.
?a :b :C.
?x ?y :E.
?x ?y :F.
?x ?y :G.
}

To zapytanie wskaże nam wszystkie zasoby ?a, które wraz z zasobami :C, :E, :F i :G będą tworzyć podany podgraf.

Jeżeli pamiętacie Turtle, to zapewne zaczęliście się zastanawiać czy nie udałoby się zapisać krócej informacji o tym podgrafie; podobnie jak w Turtle. Podobnie jak w języku Turtle poszczególne grupy predykat-obiekt (dla tego samego podmiotu) oddzielamy średnikiem, a poszczególne obiekty (dla tej samej pary podmiot-predykat) oddzielamy przecinkiem. Nasze zapytanie wyglądać może więc następująco:

SELECT ?a
WHERE
{
?a :b ?x; :b :C.
?x ?y :E, :F, :G.
}

Wszystko wydaje się proste kiedy mamy do czynienia z zasobami które możemy jednoznacznie zidentyfikować za pomocą URI albo zawartości literału. Co jednak w przypadku nienazwanych węzłów (blank nodes). W tym przypadku jedynym sposobem na zidentyfikowanie węzła jest jego jednoznaczne oznaczenie za pomocą najmniejszego możliwego podgrafu.

W zapytaniach SPARQL poszczególne bnode'y możemy zapisać za pomocą notacji _:label lub nawiasów kwadratowych.
Nieznacznie zmodyfikujmy powyższy graf, zastępując zasób :C bnodem o etykiecie _:c

W tym przypadku nasze zapytanie mogłoby wyglądać następująco:

SELECT ?a
WHERE
{
?a :b ?x; :b _:c.
?x ?y :E, :F, :G.
}

Ale nie możemy pozostawić samego _:c, bo mogłoby oznaczać dowolny bnode, czyli byłoby to mało precyzyjne. Zamiast tego nasze zapytanie mogłoby wyglądać następująco:

SELECT ?a
WHERE
{
?a :b ?x; :b _:c.
_:c :d :F.
?x ?y :E, :F, :G.
}

Ponieważ wartość bnode nie ma znaczenia, możemy zastąpić nasze zapytanie korzystając z nawiasów kwadratowych:

SELECT ?a
WHERE
{
?a :b ?x; :b [ :d :F ].
?x ?y :E, :F, :G.
}

Zapis [ :d :F ] jest jednoznaczny z [] :d :F i zastępuje oznaczenie _:c.

Na zakończenie dzisiejszego wykładu jeszcze jeden sposób na skracanie zapytań SPARQL: za każdym razem kiedy chcemy skorzystać z predykatu rdf:type możemy go zastąpić litera a, na przykład dla poniższego grafu

zapytanie

SELECT ?a WHERE { ?a rdf:type : D }

możemy zastąpić nieznacznie krótszym.

SELECT ?a WHERE { ?a a : D }

Dlaczego warto poznać SPARQL ? Jeszcze kilka lat temu każda baza RDF implementowała swój język zapytań na grafie RDF. Tak zgadliście: próba przeniesienia się z jednego repozytorium do drugiego była koszmarem. Dodatkowo, chociaż nie wiele wówczas serwisów udostępniało publicznie swoje dane, to bez jednego standardu zapytań konieczne było pisanie agentów semantycznych, które potrafiły zadawać zapytania w różnych językach.

Wraz z popularyzacją języka SPARQL przez W3C (SPARQL obchodził niedawno 2 lata od opublikowania jako rekomendacja W2 sytuacja się drastycznie zmieniła: SPARQL jest na tyle popularny, że udostępnianie tzw. SPARQL endpoint jest jednym z de facto standardów funkcjonowania serwisów semantycznych zgodnych z Linked Open Data. Innym ciekawym przykładem wykorzystania języka SPARQL jest projekt sparqlTeX, dzięki któremu możemy automatycznie aktualizować dokumenty PDF w oparciu o dane z serwisów udostępniających SPARQL endpoint.

W chwili obecnej trwają prace nad kolejną wersją języka; napiszemy o proponowanych zmianach pod koniec cyklu.

Być może części z was nazwa SPARQL przywodzi na myśl SQL. Podobieństwo w nazwie jest częściowo zamierzone ... podobnie jak w przypadku formatu zapytań.

Weźmy pod uwagę prosty graf RDF:

<http://www.semanticschool.com/2010/02/sparql-wstep/> <http://purl.org/dc/elements/1.1/title> "SPARQL - cz. 1: Wstęp do odpytywania grafów RDF".
<http://www.semanticschool.com/2010/02/sparql-wstep/> <http://purl.org/dc/elements/1.1/creator> "Sebastian Ryszard Kruk".

Jeżeli chcemy zapytać o tytul artykułu pod adresem http://www.semanticschool.com/2010/02/sparql-wstep/ możemy to zrobić za pomocą zapytania:

SELECT ?tytul
WHERE
{
<http://www.semanticschool.com/2010/02/sparql-wstep/> <http://purl.org/dc/elements/1.1/title> ?tytul.
}

Zapytania SPARQL zaczynamy słowem SELECT, po którym wypisujemy listę zmiennych o które pytamy. Zaś w sekcji WHERE wewnątrz nawiasów sześciennych wpisujemy szablon grafu RDF (w formacie Turtle), gdzie pewne elementy grafu zastępujemy zmiennymi rozpoczynającymi się od znaku zapytania.

Przyznacie jednak, że ciągłe wpisywanie pełnych URI nie jest zbyt wygodne. Podobnie jak w przypadku języka Turtle, możemy skorzystać z prefiksów. Poprzednie zapytanie wyglądałoby następująco:

PREFIX dc: <http://purl.org/dc/elements/1.1/> .
SELECT ?tytul
WHERE
{
<http://www.semanticschool.com/2010/02/sparql-wstep/> dc:title ?tytul.
}

Kilka z prefiksów jest zdefiniowanych domyślnie:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>.
PREFIX fn: <http://www.w3.org/2005/xpath-functions#>.

A co jeśli chcemy zapytać więcej informacji o danym zasobie ? Nic prostszego. Dla następującego grafu

<http://www.semanticschool.com/2010/02/sparql-wstep/> <http://purl.org/dc/elements/1.1/title> "SPARQL - cz. 1: Wstęp do odpytywania grafów RDF".
<http://www.semanticschool.com/2010/02/sparql-wstep/> <http://purl.org/dc/elements/1.1/creator> "Sebastian Ryszard Kruk".
<http://www.semanticschool.com/2009/12/semantyczne-seo-ontologia-good-relations-i-rdfa/> <http://purl.org/dc/elements/1.1/title> Semantyczne SEO, czyli jak zwiększyć widoczność stron w wyszukiwarkach przy pomocy ontologii Good Relations i RDFa".
<http://www.semanticschool.com/2009/12/semantyczne-seo-ontologia-good-relations-i-rdfa/> <http://purl.org/dc/elements/1.1/creator> "Arkadiusz Kwoska".

nieznacznie zmodyfikowane zapytanie SPARQL

PREFIX dc: <http://purl.org/dc/elements/1.1/> .
SELECT ?url, ?tytul, ?autor
WHERE
{
?url dc:title ?tytul.
?url dc:creator ?autor.
}

otrzymamy w wyniku:

W zapytaniu możemy wybierać trójki na podstawie literałów w zdaniu. Na przykład dla grafu:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://www.semanticschool.com/> dc:lang "Polski".
<http://semdl.info/> dc:lang "English".
<http://semdl.info/> dc:type "Site"@en.
<http://www.semanticschool.com/> dc:type "Strona"@pl.
<http://www.semanticschool.com/> <http://example.com/articleCount> 43.
<http://blog.knowledgehives.com/> <http://example.com/articleCount> 9.
<http://semdl.info/> dc:date "02/01/2010"^^xsd:date.
<http://www.semanticschool.com/> dc:date "09/19/2009"^^xsd:date.
<http://semdl.info/> <http://example.com/inPolish> "false"^^xsd:boolean.
<http://www.semanticschool.com/> <http://example.com/inPolish> "true"^^xsd:boolean.


Poniższe zapytanie wypisze stronę napisaną po angielsku

PREFIX dc: <http://purl.org/dc/elements/1.1/> .
SELECT ?url WHERE { ?url dc:lang "English". }

A to stronę typu "Strona", gdzie literał ma ustalony język "pl". W następnych odcinkach napiszę co zrobić jeżeli nie znamy języka literału, lub nie wiemy czy język został w ogóle podany.

PREFIX dc: <http://purl.org/dc/elements/1.1/> .
SELECT ?url WHERE { ?url dc:type "Strona"@pl. }

Możemy też zapytać o ilość:

SELECT ?url WHERE { ?url <http://example.com/articleCount> 43. }

o datę:

PREFIX dc: <http://purl.org/dc/elements/1.1/> .
SELECT ?url WHERE { ?url dc:date "09/19/2009"^^xsd:date. }

lub o wartości typu prawda / fałsz.

SELECT ?url WHERE { ?url <http://example.com/inPolish> true. }

Jak widać SPARQL jest całkiem prosty. W następnym odcinku nauczymy się jak konstruować zapytań dotyczące większych obszarów grafu RDF w tym nienazwanych węzłów (ang. blank nodes).

Jednym z podstawowych celów projektu LarKC jest zgromadzenie powiązanej wiedzy dostępnej w chmurze otwartych danych (ang. Linked Open Data) i dostarczanie usług wydajnego wnioskowania na tych danych.

Czym zajmuje się projekt LarKC najlepiej obrazuje następujący Woordle:

Być może nie wspominałbym o tym projekcie gdyby nie opublikowane ostatnio zbiory danych:

• Baza zainteresowań naukowych pracowników naukowych związanych z informatyką; zawiera semantyczną reprezentację profili ponad 600 tysięcy naukowców; bazuje ona na otwartych danych udostępnionych przez serwis DBLP.
• Semantyczne repozytorium połączonych danych (ang. Linked Data Semantic Repository) zawiera ok 1.7 miliarda trójek zawierające powiązane dane pochodzące z różnych serwisów zarządzających wiedzą ogólną, w tym DBPedia, Freebase, Geonames, MusicBrainz, UMBEL, czy znany nam już Wordnet. Na tych danych zostało dodatkowo przeprowadzone wnioskowanie zgodnie z regułami zawartymi w powiązanych ontologiach.
• Połączone dane nauk przyrodniczych (ang. Linked Life Data) prawdopodobnie najciekawsza baza, zawierająca ok 5 miliarda trójek z informacjami biomedycznymi powiązanymi pomiędzy poszczególnymi zestawami danych, które zostały zintegrowane w tej bazie.

Jeżeli zastanawiacie się dlaczego poświęciłem dzisiejszy artykuł projektowi LarKC, to odpowiedź jest bardzo prosta: w poniedziałek opowiem o języku zapytań SPARQL, a nowo nabytą wiedzę będziecie mogli przetestować na dwóch ostatnich z zaprezentowanych repozytoriów: LDSR i Linked Life Data.

Bo Web 3.0 to nie Web3D, to nie wyszukiwarki odpowiadające na pytania w języku naturalnym (ang. natural language processing - NLP), to wreszcie nie tylko ontologie i maszyny które z nich korzystają. Web 3.0 to Sieć danych, która w odróżnieniu nie jest tylko dla ludzi (Web 1.0) czy stworzona przez/dla społeczności (Web 2.0), ale jest przede wszystkim dostępna i zrozumiała przez maszyny. Tylko w ten sposób będziemy mogli zbudować narzędzia, które usprawnią nasz dostęp do Sieci, jeżeli będą one miały dostęp do połączonych, zrozumiałych danych.

Takie właśnie założenia dotyczące rozwoju Web 3.0 stały się podstawą do powstania inicjatywy Linked Data, promującej udostępnianie danych w Sieci w postaci grafu powiązań zrozumiałego przez maszyny.

W swoim artykule z 2006 roku, sir Tim Berners-Lee, podaje cztery reguły nazywania rzeczy w Sieci:

1. Należy używać URI do nazywania zasobów (dokumentów, ludzi, usług, ...) w Sieci.
2. Preferowanym schematem URI jest HTTP, tak aby ludzie (i maszyny) mogli sprawdzić co kryje się pod daną nazwą.
3. Pod podanym URI należy udostępnić wartościowe informacje o danym zasobie korzystając ze standardów, np.: RDF i SPARQL.
4. W danym opisie udostępnionym pod podanym URI umieszczamy odnośniki do innych URI, tak aby maszyny i ludzie mogli odnaleźć więcej  powiązanych zasobów w Sieci.

Co powinien zawierać taki dokument RDF opisujący dany zasób pod podanym URI? Przede wszystkim tzw. minimalny spójny graf RDF (ang. minimal self-contained graph - MSG), czyli te zdania, które odnoszą się do podanego zasobu, oraz wszystkie zdania powiązane rekurencyjnie z nimi za pośrednictem pustych węzłów (ang. blank nodes) o których pisalismy wprowadzając RDF. TBL wspomina również o możliwości udostępnienia usługi zapytań w języku SPARQL (ang. SPARQL end-point), o którym napiszemy niedługo.

Tak stworzoną Sieć danych, tzn. strony i usługi które publikują swoje dane zgodnie z powyższymi wytycznymi, można przeglądać za pomocą aplikacji Tabulator, stworzonej przez TBL.

W chwili obecnej coraz więcej usług udostępnia swoje dane zgodnie z wytycznymi inicjatywy Linked Data. Jakiś czas temu pisalismy o słowniku WordNet, usłudze OpenVocabulary oraz o usłudze publikowania danych rozpoczętej przez New York Times. Poniższy graf, autorstwa Richarda Cyganiaka z DERI Galway, prezentuje stan chmury połączonych źródeł danych w lipcu 2009.

Usługi publikujące i wykorzystujące połączone dane (Lipiec, 2009; źródło: http://richard.cyganiak.de/2007/10/lod/)

Dr Tom Heath z  Talis podaje pięć kroków do stworzenia aplikacji publikującej dane zgodnie z ideą Linked Data (zobacz również tutorial z ISWC'08 na videolectures.net):

1. Należy zrozumieć powyższe podstawowe zasady publikowania w Web 3.0.
2. Musimy zrozumieć model danych naszej aplikacji sieciowej; szczególnie ważne jest zidentyfikowanie klas rzeczy, których będzie ona dotyczyć, np.: ludzie, miejsca, spotkania, itp.
3. Definiujemy schematy URI (a właściwie URL) dla poszczególnych typów obiektów zidentyfikowanych w poprzednim punkcie. Więcej na ten temat w dwóch najbliższych artykułach.
4. Następnie implementujemy mechanizmy dostarczania danych dla ludzi (np HTML) i maszyn (np RDF), używając wybranej przez nas technologii, np. PHP lub JEE.
5. WAŻNE: o ile to tylko możliwe, do opisu naszych rzeczy wykorzystujemy identyfikatory rzeczy dostarczane przez inne usługi, np. wspomniane wcześniej WordNet, OpenVocabulary, New York Times, i inne; wystarczy tylko rzucić okiem na powyższą chmurę połączonych danych aby odnaleźć dane, które mogą być związane z naszą aplikacją.

W następnych odcinkach cyklu "Publikujemy w Web 3.0" opowiem o tym w jaki sposób poprawnie publikować dane tak aby budować i wykorzystywać Web 3.0.

Na zakończenie prezentacja o publikowaniu i wykorzystywaniu publicznych danych, przygotowana przez dr Michaela Hausenblas z DERI Galway:

Więcej na temat inicjatywy Linked Data oraz samego publikowania danych zgodnego  z duchem Web 3.0 znajdziecie na stronie ze zbiorem szkoleń i prezentacji o Linked Data oraz na wiki grupy W3C Linking Open Data.

Chociaż do tej pory nie opisywaliśmy  jeszcze biblioteki Jena udostępniającej za pomocą API Java dostęp do grafu RDF i mechanizmów wnioskowania, postanowiliśmy poinformować o zmianach jakie zapowiedziała firma HP, w której ośrodku badawczym powstała ta biblioteka.

Zgodnie z opublikowaną niedawno notką prasową, firma HP postanowiła zakończyć działanie ośrodka badawczego "Semantic Web Research". Ciężko w tej chwili dociekać powodów, bo ten ośrodek istniał już bardzo wielu lat; być może, jest to związane ze znaczącym upowszechnieniem się technologii semantycznych, i (co należy zauważyć) brakiem znaczących osiągnięć tego ośrodka w ostatnim czasie. Najważniejszą jednak informacją jest ta, że biblioteka Jena (oraz inne rozwiązania) pozostaną dostępne na licencji open source (BSD), zmieni się jedynie adres strony domowej biblioteki na http://www.openjena.org/. Najprawdopodobniej powstanie również firma, niezależna od HP, która będzie dostarczała komercyjnego wsparcia oraz nadzorowała dalszy rozwój tej biblioteki.

Dla osób które do tej pory nie słyszały o bibliotece Jena: jest ona jedną z najstarszych, i (przynajmniej do niedawna pozostawała) jedną z najbardziej popularnych bibliotek udostępniających za pomocą Java API dostępu do grafu RDF. Jej największą zaletą jest to, że do informacji zapisanych w grafie RDF można uzyskać dostęp za pomocą API podobnego do Java DOM znanego z przetwarzania XMLa. Poza podstawowymi operacjami zapisu i odczytu informacji z grafu, Jena oferuje również:

• możliwość odpytywania grafu RDF za pomocą zapytań w języku SPARQL,
• połączenie z mechanizmami wnioskowania na przechowywanym grafie RDF i ontologiach
• wsparcie dla tzw. quadów, czyli zdań RDF składających się z czterech elementów, gdzie dodatkowym elementem jest wskazanie na kontekst (napiszemy o nich niedługo),
• możliwość wygenerowania hierarchii klas Java odpowiadających zadanej ontologii (w RDF Schema lub OWL); warto jednak pamiętać w tym miejscu, że takie mapowanie nie gwarantuje nam pozbycia się problemów z przejściem pomiędzy programowaniem obiektowym a logiką opisową, o czym pisaliśmy niedawno.

Już niedługo pokażemy na prostych przykładach jak korzystając z biblioteki Jena napisać pierwszą aplikację operującą na grafie RDF.

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