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).

Wyobraźmy sobie, że jesteśmy właścicielem sklepu internetowego: nasi klienci mają konkretne pytania, potrzeby. W chwili obecnej jedynym sposobem na odnajdywanie odpowiedzi na ich pytania jest mozolne przeszukiwanie całej Sieci za pomocą Google albo pytanie szeroko rozumianych "znajomych" (np. tag #drogiblipie). Bez odpowiednich metadanych, rozumianych przez maszyny, nasz sklep czy usługa jest prawie tak samo widziana jak inne witryny internetowe, np. opisujące produkty, które my właśnie oferujemy. W ten sposób nasi klienci mają dużo mniejszą szansę na trafienie do naszego sklepu; a tego przecież nie chcemy, prawda? Nawet dedykowane serwisy wyszukiwania usługi i towarów również mają zbyt mało informacji, aby jednoznacznie powiązać naszą ofertę z wymaganiami naszych niedoszłych klientów.

Ontologia Good Relations została stworzona z myślą o rozwiązaniu tego problemu. Pozwala nam ona opisać to co oferuje nasz sklep: produkty, ich cechy, ich ceny. Pojęciami wprowadzonymi w ontologii Good Relations możemy również podać informacje o fizycznych lokalizacjach naszych sklepów i np. godzinach ich otwarcia. Ontologia pozwala na opisanie dostępnych sposobów płatności i przesyłek; możemy również opisywać dodatkowe informacja listy życzeń, specyfikacje gwarancji, itd. Ontologia Good Relations wspiera zarówno rozwiązania typu Business-to-Consumer (B2C) jak i Business-to-Business (B2B). Osobom szukającym rozwiązań oferowanych przez nas będzie łatwiej odnaleźć naszą ofertę na podstawie cechy, na których im zależy; w ten sposób nasi przyszli klienci dużo szybciej i pewniej docierają do zamierzonego celu.

Informacje zgodne z ontologią Good Relations mogą być zapisane w standardzie RDFa wspieranym przez Yahoo i Google; dzięki temu nasz serwis i produkty są lepiej dostrzegalne*, m.in., gwiazdkom z ocenami w wynikach wyszukiwania. Już teraz ontologia Good Relations jest bardzo popularna i wiele firm z niej korzysta, w tym m.in. BestBuy (o którym napiszemy jutro).

Co zrobić aby zacząć wykorzystywać ontologię Good Relations?

• Jeżeli jesteśmy sklepem internetowym: warto zacząć od stworzenia prostego przeglądu naszej oferty zapisanego w tej ontologii.
• Jeżeli jesteśmy firmą produkującą oprogramowanie dla sklepów internetowych: należy stworzyć możliwość importu i eksportu informacji w tym standardzie.
• W pozostałych przypadkach: możemy stworzyć listę produktów i usług opisaną w ontologii Good Relations; oraz opracować nowe modele biznesowe oparte na tych opisach.

Aby stworzyć swój pierwszy opis w ontologii Good Relations możemy skorzystać z narzędzie dostarczonego przez jej twórców pod adresem: http://www.ebusiness-unibw.org/tools/goodrelations-annotator/.

Więcej informacji na temat ontologii Good Relations możemy dowiedzieć się na stronie domowej projektu oraz na wiki, gdzie znajdują się również przykłady wykorzystania ontologii. Specyfikacja ontologii znajduje się pod adresem http://www.heppnetz.de/ontologies/goodrelations/v1.

Aby być stale na bieżąco ze zmianami warto zapisać się na listę dyskusyjną http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations lub śledzić tag #goodrelations na twitterze.

Jedyne ograniczenie w wykorzystywaniu tej ontologii to konieczność podania referencji do jej twórców w naszych produktach i usługach, zgodnie z licencją Creative Commons Attribution 3.0.

Na zakończenie warto zauważyć, że niektóre popularne CMSy i programy do obsługi sklepów elektronicznych już wspierają Good Relations.

A czy firma dostarczająca oprogramowanie do Waszego e-sklepu zaoferowała wam już wsparcie dla Good Relations? czy nadal jesteście jednym z milionów nie wyróżniających się sklepów internetowych? Jeżeli nie, to możemy pomóc Ci wdrożyć Good Relations w Twojej firmie.

*) Google na razie twierdzi, że nie będzie wykorzystywał informacji uzyskanych z metadanych w postaci RDFa i Microformaty, do pozycjonowania treści. Czy tak jest na prawdę, tego na razie nie wiadomo.

Receptę na nasz problem opisał na swoim blogu Richard Cyganiak, z DERI Galway.

Do przetestowania naszego systemu potrzebujemy programu curl. Jeżeli korzystamy z linuxa jest duża szansa, że będzie już zainstalowany. W przypadku Mac OSX możemy go łatwo pobrać i zainstalować. Niestety w przypadku systemu Windows - najlepszym rozwiązaniem będzie zainstalowanie sobie środowiska Cygwin oraz paczki curl.

Po zainstalowaniu komenda curl umożliwia nam pobranie informacji znajdujących się pod podanym adresem URL.

curl http://www.semanticschool.com/

zwróci nam zawartość dokumentu HTML głównej strony Szkoły Web 3.0

curl -I http://www.semanticschool.com/

zwróci nam sam nagłówek protokołu HTTP informujący o głównej stronie Szkoły Web 3.0

  HTTP/1.1 200 OK
  Date: Sun, 13 Dec 2009 21:40:48 GMT
  Server: Apache
  X-Powered-By: PHP/5.2.9
  X-Pingback: http://www.semanticschool.com/xmlrpc.php
  Vary: Accept-Encoding
  Content-Type: text/html; charset=UTF-8

curl -I http://www.openvocabulary.info/thesauri/ot/pl/instances/wordsense-dom-9

zwróci nam podobny nagłówek HTTP do poprzedniego, jednak na uwagę zasługuje wpis o statusie 303 i nowej lokalizacji do której powinno nastąpić przekierowanie.

 HTTP/1.1 303 See Other
  Date: Sun, 13 Dec 2009 21:43:44 GMT
  Server: Apache/2.2.8 (Fedora)
  Set-Cookie: JSESSIONID=A69D4C95449EAF3148EB6980804F9828; Path=/
  Location: http://www.openvocabulary.info/html/thesauri/ot/pl/instances/wordsense-dom-9
  Connection: close
  Content-Type: text/html;charset=UTF-8

Teraz wystarczy tylko przekonać serwis Open Vocabulary, że jesteśmy agentem semantycznym prosząc o treści w formacie RDF. W tym celu razem z zapytaniem HTTP GET do serwisu, wysyłamy również nagłówek informujący o oczekiwanej treści: Accept: application/rdf+xml

curl -I -H "Accept: application/rdf+xml" http://www.openvocabulary.info/thesauri/ot/pl/instances/wordsense-dom-9

tym razem przekierowanie następuje do dokumentu RDF:

  HTTP/1.1 303 See Other
  Date: Sun, 13 Dec 2009 21:46:44 GMT
  Server: Apache/2.2.8 (Fedora)
  Set-Cookie: JSESSIONID=15369544CC3DB2694D104F721CC0AD43; Path=/
  Location: http://www.openvocabulary.info/rdf/thesauri/ot/pl/instances/wordsense-dom-9
  Connection: close
  Content-Type: text/rdf;charset=UTF-8

Jeśli sprawdzamy nasz serwis, to zwracajmy uwagę na nagłówki Location otrzymywane dla różnych nagłówków Accept w zapytaniach HTTP GET. Dla każdego z wspieranych typów dokumentów, np.: HTML, RDF, JSON, przekierowanie powinno następować do istniejącego dokumentu w danym formacie. Zazwyczaj możemy też przyjąć, że domyślne przekierowanie powinno następować do (istniejącej) wersji dokumentu w formacie HTML.

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ć.

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/)

Jena jest biblioteką dostarczającą API w języku Java. Zacznijmy więc od zebrania potrzebnych narzędzi:

• kompilator i maszyna wirtualna Java, najlepiej w wersji JDK 5.0
• środowisko programistyczne, np.: Eclipse
• biblioteka Jena i biblioteki zależne [pobierz najnowszą wersję tutaj]

W Eclipse rozpoczynamy nowy projekt typu Java, i przegrywamy i dodajemy do projektu JARy dostarczone z biblioteką Jena:

Następnie tworzymy nową klasę i zaczynamy nasz pierwszy "semantyczny" program. Polecam specyfikację biblioteki Jena: http://www.openjena.org/javadoc/index.html.

Zdefiniujmy dwie przestrzenie nazw, jedną na elementy ontologii w RDF Schema, a drugą na zasoby:

Następnie tworzymy nowy model, czyli obiekt który będzie reprezentował tworzony przez nas graf RDF; pamiętajmy że RDF Schema jest również zapisana w postaci grafu RDF.

W następnym kroku dodajemy do modelu definicje naszych klas i właściwości.

W tym momencie możemy wypisać nasz graf RDF:

otrzymamy w następujący wynik (z dokładnością do kolejności trójek):

W kolejnym kroku stwórzmy nowy model bazujący na poprzednim. Model ten nie będzie wykorzystywał wnioskowania bazującego na RDF Schema (tzw. inferencing)

A następnie dodajmy do niego dwa zasoby: [Jan] i [Mazda], oraz stwórzmy zdanie [Jan] [kieruje] [Mazdę].

I ponownie jak poprzednio wypiszmy nasz obecny graf:

Jak widać poniżej, w wyniku doszło tylko jedno dodatkowe zdanie RDF:

A teraz czas na wnioskowanie w akcji. Dzięki bibliotece Jena uruchomienie wnioskowania jest bardzo proste.

Musimy najpierw stworzyć nowy model bazujący na poprzednim. Tym razem, nasz model będzie dedykowany dla wnioskowania z RDF Schema.

Podobnie jak poprzednio dodajemy nasze przykładowe zdanie:

Ponieważ cały model infmodel zawiera również trójki związane ze specyfikacją języka ontologii RDF Schema, więc odpytajmy nasz model tylko o typy zasobów [Jan] i [Mazda].

W wyniku otrzymamy:

Co tym samym kończy nasz dowód: maszyna wnioskująca poprawnie określiła typ zasobów [Jan] i [Mazda].

Pełen kod projektu razem z biblioteką Jena, znajdziecie [tutaj]