Zainspirowany innymi prezentacjami na InfoShare (tzn. tymi ciekawymi) postanowiłem przerobić swoje slajdy praktycznie w ostatnim momencie. Patrząc na komentarze na blip, chyba nie był to tak głupi pomysł.

• ivyl: #infoshare ^skruk - mile i lekkie wprowadzenie do ontologii w informatyce.
• ivyl: #infoshare ^skruk
  
• ivyl: #infoshare
  
• hary: #infoshare bardzo bardzo ciekawie o web 3.0, doskonaly wstep do tematu.[semanticschool.com]s do ulubionych
• gregor: #infoshare a potem to już web 4.0 [antyweb.pl]s

Jak widać tematyka wypłynęła nawet na tak popularnym w Polsce blogu jak antyweb.

Zostałem więc z dwoma zestawami slajdów, jednym który pokazałem a drugim z wystarczającą ilością tekstu aby posłużyć jako komentarz do pierwszego.  Oto one:

Krytycy twierdzili, że znaczenie (semantyka) tego co my (ludzie) chcemy zakomunikować nie może być łatwo zinterpretowane (przez maszyny), ponieważ często wyrażamy nasze myśli w sposób nielogiczny, figlarny, fałszywy, nikczemny czy celowo wprowadzając w błąd. Jednak my ludzie też nie zawsze możemy prawidłowo zinterpretować intencje mówiącego.

Postaram się podsumować ten raport zbierając najciekawsze opinie o przyszłości Sieci Semantycznej.

Idea Sieci Semantycznej jest szlachetna, ale zdaje się być zbyt kosztowna, gdy weźmiemy pod uwagę takie czynniki jak zbyt duże zróżnicowanie pomiędzy ludźmi lub rywalizację (gospodarczą).

Część uczestników kwestionowała możliwość pojawienia się Sieci Semantycznej w pełni w językach innych niż angielski. Bibliotekarze (cyfrowi) sugerują, że systemy organizacji wiedzy mogą być bardziej skuteczne niż pełnoprawne technologie semantyczne. Inni przypominają, że dotychczasowe wysiłki wprowadzania większej ilości meta-danych do stron internetowych nie poskutkowały, i tym trudniej jest mówić o wprowadzeniu RDF, OWL i mikroformatów, gdy dobrze zbudowany HTML jest nadal rzadkością.

Istnieją również obawy związane z problemem fałszywych danych i braku zaufania. Niektórzy z was mogą pamiętać, że Google nie ufa(ł) twórcom serwisów internetowych w kwestii dostarczania prawidłowych metadanych w tagach <meta>; stąd też były one indeksowane. Kwestia fałszywych metadanych i zaufania jest jednym z problemów, z którymi spotykam się przez ostatnie 10 lat, odkąd tylko zacząłem "ewangelizować" wykorzystanie technologii semantycznych. Zbyt często spotkaliśmy się bowiem z celowo niepoprawnym wykorzystaniem metadanych, i wiele osób zakłada, że to samo może spotkać opisy semantyczne. Dlatego górną warstwę semantycznego tortu stanowią warstwy odpowiedzialne za dowodzenie poprawności danych i wniosków, oraz zapewniające zaufanie do tych danych. Ale jak narazie jesteśmy gdzieś w połowie drogi do tych górnych warstw zanim Sieć Semantyczna może osiągnąć swój potencjał do roku 2020.

Niektórzy ankietowani twierdzą, że pomimo faktu iż rozwój Sieci Semantycznej jest zadaniem niebagatelnym i kosztownym, które wymaga zbyt wiele energii i koordynacji aby wpłynąć na nasze życie, oczekują oni pozytywnych wyników z tworzenia Sieci Semantycznej, takich jak bardziej znaczące, interoperacyjne treści internetowe i lepsze zrozumienia ekosystemu Sieci.

Wielu ludzi wierzy, że wraz z rozwojem Sieci Semantycznej zostaniemy przeniesieni z ery informacyjnej do ery zarządzania wiedzą, co zaowocuje zarówno nowymi innowacjami jak i nadużyciami.

Niektórzy uważają, że jeśli budowa Sieci Semantycznej się powiedzie to nikt nie będzie jej już tak nazywał, ani też nie zauważy jej istnienia. Mam wrażenie, że może być podobnie jak w przypadku sztucznej inteligencji (AI). Twierdzimy, że AI było porażką, ale w tym samym czasie co dziennie pomaga nam ona w sposób niedostrzegalny. W celu jak najlepszego wykorzystania i zrozumienia Sieci Semantycznej potrzebujemy nowej nauki o Sieci (Web Science). Jeden z ankietowanych stwierdza, że w najgorszym przypadku w 2020 Sieć Semantyczna będzie "zdrowym maluchem".

Mimo że istnieje pewien opór dla rozwoju Semantic Web znajdujemy się również silne zachęty do współpracy. TBL ma wizję, że jest to coś więcej, niż tylko lepsze wyszukiwanie informacji na poszczególnych stronach. TBL i jego wizją będzie nadal odgrywać istotną rolę w rozwoju Sieci w ciągu najbliższych dziesięciu lat.

Takie zmiany jak Sieć Semantyczna są nieuniknione Web, jednak nie powinny one być prowadzone przez arbitralnie narzucone normy, ale raczej "wyhodowane" z wymagań i doświadczeń użytkowników i twórców usług.

Meta-Sieć następnej generacji jest nieuniknione. W 2020 roku w Sieć będzie bardziej semantyczna niż obecnie; jednak będzie ona raczej oparta o nowe rozwiązania i własne standardy niż te zaproponowane przez ortodoksów takich jak TBL. Te standardy muszą brać pod uwagę trudności związane z czynnikiem ludzkim w procesie tworzenia informacji. Rozwiązania zaproponowane przez Google (Rich Snippets) oraz Facebook (Open wykres) pokazują już teraz, że standardy W3C nie zawsze pasują i pewne zmiany/dostosowania są nieodzowne. Coś podobnego stało się kiedy "ciężkie" rozwiązania jak SOAP i XML-RPC zostały zastąpione przez proste interfejsy klasy REST. Sieć nadal ma wiele do zrobienia zanim semantyczne połączenia staną się normą.

Sieć Semantyczna może zaistnieć, ale jeszcze nie teraz, nie przed pojawieniem się killer app, która może nie objawić się w przeciągu najbliższych 10 lat

Semantic Web może wymagać też znaczących zmian w zachowaniu ludzi, które mogą trwać dłużej niż dziesięć lat. Potrzeba aby ktoś wymyślił usługę której wszyscy potrzebujemy. Następny killer app może być oparty o wyszukiwanie konwersacyjne, zwłaszcza gdy mamy (będzie mieć) GGG (ang. Giant Global Graph) powiązanych ze sobą krotek z usług takich jak CIA Fact Book, DBPedia, FOAF, itp.

Potrzebujemy systemów, które mogą przeprocesować mylne i skomplikowane informacje wytworzonych przez człowieka w celu stworzenia Semantic Web.

Bez świadomych maszyn Turing, Sieć Semantyczna zdaje się być bardzo trudnym problemem do rozwiązania. Kiedy jednak zostanie zauważona to jedynie po to aby narzekać na jakość wyników wyszukiwania. W związku z tym oczywiste korzyści z realizacji Semantic Web mogą nie być oczywiste dla przeciętnego użytkownika.

Sieć Semantyczna wymaga elementów sztucznej inteligencji, aby zrozumieć człowieka; jednak oparcie się na AI nie rokuje dużych nadziei.

Wiele osób (w tym również i ja) dość cynicznie podchodzi do tego jak wiele można osiągnąć z automatycznego wydobywania znaczenia z informacji (technologie NLP), zwłaszcza jeśli ograniczymy się do jedynie do korpusu tekstu. To jest jak dziecko stara się zrozumieć rozmowę pomiędzy jego rodzicami tylko przez słuchanie jej części, która czasem nawet jest celowo ukryta w takie zwroty aby dziecko ich nie rozumiało. Najprawdopodobniej w ciągu 10 lat ludzie będą nadal operować na danych niestrukturalnych i pół-strukturalnych. Jakość wdrażania i stosowania technologii semantycznych mogą różnić się w zależności od zastosowania. Semantic Web może okazać się przydatne w niektórych dziedzinach, ale nie będzie raczej rozwijać się w pełnym zakresie jak przewidział to TBL. Oczywiście niektórzy bardziej zaawansowani użytkownicy będą mogą skorzystać z dobrodziejstw Sieci Semantycznej. Być może Semantic Web będzie tak jak sztuczna inteligencja - zawsze za rogiem w teorii i rozczarowaniem w praktyce.

Niektórzy uważają, wraz ze poprawą dostępności baz informacji semantyka będzie coraz bardziej związana z samymi aplikacjami, niż stawać się częścią języka zapisu dokumentów Sieciowych. Nie sądzę. W chwili obecnej mamy bowiem "semantykę" w aplikacjach, a to, co nam naprawdę brakuje, to "połączenia", czyli sieci, pomiędzy elementami informacji z różnych aplikacji.

Jeśli założymy, że ludzie, którzy tworzą strony i bazy danych zrobią to zgodnie z kanonem standardów informacyjnych osiągniemy bardzo dużo w kierunku budowy Sieci Semantycznej. Jednakże dużo czynników (ludzkich) najprawdopodobniej stanie na przeszkodzie. Miara sukcesu zależy w dużej mierze od definicji: niektórzy ludzie widzą Semantic Web, jak zoptymalizowane zasady projektowania dla Sieci. Jeśli pamiętasz nasz artykuł na temat inicjatywy Pedantycznej Sieci, to wychodzi na to, że leczenie Sieci może mieć duże znaczenie dla dalszego rozwoju Semantic Web.

Inni respondenci zwrócili uwagę na rolę, jaką standardy Sieci Semantycznej odgrywają dla przenośności danych i interoperacyjności. Niektórzy twierdzą, że do 2020 roku mechanizmy interoperacyjne pozwolą na łatwą i niewidoczną wymianę danych pomiędzy aplikacjami.

Istotą Sieci Semantycznej, w szerokim tego słowa znaczeniu, jest aby maszyny zrozumiały ludzi, ale szczegóły tej koncepcji zmieniały się (zmieniają się) wraz z upływem czasu i zależą od zmian w technologii i społeczno-ekonomicznych: kiedy mamy więcej mocy obliczeniowej, więcej danych może dawać lepsze rezultaty niż fragmenty wysokiej jakości meta-danych dostarczonych z informacją. Niektórzy respondenci twierdzą, że Semantic Web jest "drogą" a nie rzeczywistą "rzeczą", który mogłaby zostać osiągnięta.

Sieć Semantyczna wpływa już na nowe aplikacje; by wymienić tylko kilka z nich: TripIt, TrueKnowledge, Wolfram | Alpha lub Twine.

Stąd też mówi się o innej metryce sukcesu: rosnącej liczbie aplikacji sieciowych skutecznie wykorzystujących technologie semantyczne (np. poprzez większe wykorzystanie systemów organizacji wiedzy zamiast tagów) i ... liczby nowych startupów, które wymyślają nowe kawałki układanki zwanej Semantic Web. Na zakończenie, przyjrzyjmy się, czy respondenci uważali, że Sieć Semantyczna może zostać osiągnięta do roku 2020. 41% wszystkich uczestników (38% ekspertów) zgodziło się, że do 2020 r. wizja TBL "zostanie osiągnięta w znacznym stopniu". Podczas gdy 47% respondentów (52% ekspertów) argumentowało coś przeciwnego, sugerując, że do 2020 r. "użytkownicy nie zauważą wiekszej różnicy (w funkcjonowaniu Sieci)".

Jedna z uczestniczek, Kate Ray, korzystając z okazji, że tak wielu ekspertów w tej dziedzinie zebrało się w jednym miejscu, nagrała imponujący dokument na temat Web 3.0. Oto krótki przegląd tego, czego może się z niego dowiedzieć.

Web 3.0 from Kate Ray on Vimeo.

Dlaczego?

Jesteśmy zalewani ogromem informacji; daje (da) to nam ogromne możliwości, ale na razie nie mamy jeszcze narzędzi, aby móc sobie z tym ogromem poradzić i wykorzystać go w pełni!

Szacuje się, że w Sieci jest opublikowane 10.000 TB danych; możemy to przeliczyć na mniej więcej prawie 2000 bibliotek. David Weinberger zauważa, że stare rozwiązania, np. system klasyfikacji dziesiętnej Deweya (DDC), znany będący podstawą wielu systemów katalogowania stosowanym w bibliotekach, staje się bezużyteczny wobec ogromu informacji w Sieci. Nova Spivack idzie jeszcze dalej i twierdzi, że Google (a raczej styl interakcji/wyszukiwania używany dzisiaj) przestaje być odpowiedni do zarządzania tymi miliardy miliardów elementów Sieci. W chwili obecnej musimy wszystko robić w naszych głowach: od integracji informacji do "przepisywania"  zapytań  wprowadzanych w Google. Sir Tim Berners-Lee (TBL) zauważa, że ludzie oczekują od procesu wyszukiwania czegoś w rodzaju spadochronu, który umieści nas bezpośrednio w oczekiwanym wyniku.

Chris Dixon wskazuje, że użytkownicy zalewani informacją są mniej skorzy do tego, aby coś kupić. Weinberger zastanawia się czy biorąc pod uwagę ogrom otaczającej nas informacji nie powinniśmy rozpocząć "tagowanie naszych tagów" i "filtrowania naszych filtrów".

W związku z powyższym w celu integracji, utrzymania, aktualizacji i filtrowania tak ogromnej przestrzeni informacyjnej, potrzebujemy struktur i (prawdopodobnie) technologii semantycznych.

Jak?

TBL mówi, że 20 lat temu pokazał nowe sposoby zarządzania informacją (np. przez wynalezienie WWW). Teraz chce zachęcić nas, abyśmy opublikowali w Sieci nasze dane. Spivack sugeruje, że Sieć staje się coraz bardziej globalną bazą danych. Wraz ze wzrostem liczby powiązań pomiędzy elementami informacji tworzony jest kontekst; jest on zaś kluczowym krokiem w kierunku rozumienia znaczenia (semantyki) informacji.

Krytycy

Oczywiście nie wszyscy są tak optymistycznie nastawieni do Web 3.0, nawet wśród ekspertów związanych technologiami sieciowymi. Dla niektórych, Semantic Web tworzona jest i działa we własnym  nierealnym "kokonie"; i jest przeznaczona dla idealistycznego świata, w którym każdy jest ekspertem w bazą danych lub zarządzaniu informacją. Ponieważ nie udało nam się aby maszyny zrozumiały nas, staramy się teraz "myśleć" (wyrażać siebie) jak maszyny. Jednak podstawowe pytanie brzmi "Czy świat ma sens, czy my nadajemy sens światu?". Dodatkow, świat wokół nas jest zbyt niejednoznaczny, i nie ma jednego sposobu wyrażania tego co nas otacza; dlaczego miałby być? Czy wam również w tym miejscu na myśl przychodzi twierdzenia Gödla o niekompletności ?

Schizmy

Tak jak nie ma jednego sposobu wyrażania otaczających nas rzeczy, tak też wygląda na to, że nie ma jednego sposobu myślenia o Semantic Web. David Karger i Abraham Bernstein twierdzą, że możliwe jest uzyskanie Semantic Web bez ontologii: "wiele można osiągnąć z nawet małą strukturą" (ang. a little structure goes a long way); jednak inni uczestnicy konferencji mówią: "Czy Papież jest Katolikiem?"

Przyszłość

Wszyscy zgadzają się, że Sieć jest ogromnym sukcesem technologicznym i społecznym. Spivack twierdzi, że po ewolucji zawsze następuje rewolucja, więc teraz czekamy już tylko na pierwszą poważną aplikację (ang. killer app) korzystającą z technologii Sieci Semantycznej. TBL mówi, że Semantic Web to platforma, podobnie jak sama Sieć; więc nie sposób powiedzieć, co powinniśmy z nią zrobić lub dokąd nas to zaprowadzi. Stwierdza on, że jeśli Semantic Web miałby jedynie zrealizować jego wizję (lub przewidywania) to byłoby w poważnym niebezpieczeństwie.

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.

Z dużą przyjemnością chciałbym więc poinformować was o (darmowym!) podręczniku "Linked Data Patterns - A pattern catalogue for modelling, publishing, and consuming Linked Data" opisującym kwestie związane z modelowaniem i publikowaniem połączonych danych. Autorami tej książki (a właściwie ebooka) są znani w środowisku Semantic Web: Leigh Dodds i Ian Davis.

Ebook został wydany w formie PDF i ePUB. Autorzy na swoim blogu piszą, że nie jest to jeszcze ostateczna wersja podręcznika, stąd zachęcają do zgłaszania wszelkich (konstruktywnych) uwag na jej temat.

Znając osobiście obu autorów i ich dorobek  szczerze zachęcam do lektury.

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.

Ponieważ temat wypłynął niedawno na forum Biblioteka 2.0, postanowiłem zmierzyć się z tym pytaniem.

Niecały miesiąc po wspomnianym tutorialu na konferencji WWW, prezentowaliśmy tematykę Semantycznych Bibliotek Cyfrowych na konferencji ESWC2007. Tym razem postanowiliśmy odpowiedzieć na to pytanie od razu w czasie prezentacji:

Podstawowymi 3 pojęciami, które musimy rozróżniać to: taksonomia (ang. taxonomy), tezaurus (ang. thesaurus) i ontologia (ang. ontology). Wszystkie mają przynajmniej jedną cechę wspólną: są stałą kolekcją pojęć, tzn. że nie można dowolnie i samodzielnie dodawać do nich nowych pojęć tak jak to ma miejsce w przypadku tagów. Nie oznacza to, że są one całkowicie niezmienne, a jedynie to, że ich dynamika zmian jest dużo wolniejsza.

Zacznijmy od taksonomii: najprościej rzecz ujmując jest to kolekcja pojęć pomiędzy, którymi zostały określone relacje tworzące hierarchię tych pojęć. Zazwyczaj mówimy o zawężaniu i poszerzaniu znaczenia pomiędzy pojęciami w hierarchii; tak też nazywają się predykaty wprowadzone w SKOS, odpowiednio skos:narrower i skos:broader.

Tezaurus jest kolekcją pojęć pomiędzy, którymi występują nie tylko relacje tworzące hierarchię tych pojęć, ale również dodatkowe relacje znaczeniowe (semantyczne). W przypadku tezaurusów w stylu WordNet, dodatkowymi relacjami mogą być określenia synonimów, homonimów, itp.

Czym więc jest sama ontologia? Pojęcia które są w niej zdefiniowane za pomocą formalnego języka definicji ontologii (np. OWL), pozwalają na nadanie znaczenia innym pojęciom w konkretnej dziedzinie wiedzy. Czyli zarówno w tezaurusie jak i ontologii używamy zestawu meta-pojęć, które tworzą relacje pomiędzy pojęciami z danej kolekcji; w przypadku tezaurusa pojęcia te definiujemy wraz z danym tezaurusem lub używamy standardów w stylu SKOS, zaś w przypadku ontologii używamy formalnych języków w stylu OWL. Różnica jest o tyle znacząca, że pojęcia wprowadzane w formalnych językach typu OWL mają nie tylko konkretne znaczenie, ale co więcej implikują znaczenie na pojęciach, które opisują. Najważniejsze jest jednak to, że tezaurusy czy taksonomie wykorzystujemy jako słowniki pojęć z relacjami pomiędzy nimi. W przypadku ontologii, pojęcia w niej zdefiniowane służą nam do tego aby nadawać znaczenie pojęciom z jakiegoś obszaru wiedzy.

Jak łatwo poznać, że taksonomia czy tezaurus to nie ontologia ? Bo do tego, żeby stworzyć taksonomię czy tezaurus potrzebujemy metasłownika relacji dostępnych w danej taksonomii czy tezaurusie, takiego jak np. SKOS. Z drugiej zaś strony wiemy, że SKOS jest lekką ontologią. Tym samym ontologie i tezaurusy/taksonomie istnieją na dwóch różnych poziomach "abstrakcji".

Zdaję sobie sprawę, że być może nadal część z was nie do końca rozumie różnicę, ale mam nadzieję, że szczególnie ostatni akapit pozwoli dostrzec znaczące szczegóły pomiędzy ontologią a tezaurusami i taksonomiami.

Tom Gruber (niekwestionowany autorytet w sprawach ontologii), kiedyś stwierdził, że ontologie są często przyrównywane do taksonomicznej hierarchii klas, ich definicji i relacji zawierania; jednak ontologie nie mogą być ograniczone do tych form. Ontologie nie mogą być również ograniczone konserwatywnymi definicjami, które jedynie wprowadzają terminologię ale nie wprowadzają żadnej wiedzy o otaczającym świecie.

O ile więc można przyjąć, że ontologia zawiera elementy taksonomiczne, bo mamy hierarchię klas czy właściwości, to

1. taksonomia dotyczy bardziej konkretnych pojęć z ontologii a nie całej ontologii
2. ontologia będzie nadal ontologią bez hierarchii klas czy właściwości; a czy taksonomia nie pozostanie taksonomią bez hierarchii konceptów ?
3. i jeszcze raz powtórzę: należy patrzeć na to do czego służy ontologia a do czego taksonomia; ta pierwsza pozwala nam modelować świat w sposób formalny, taksonomia - może być użyta do tego aby klasyfikować lub opisać, ale nie modelować

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 }