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 }

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.

Pamiętacie zapewne lekką ontologię Dublin Core, którą omawiałem w październiku zeszłego roku. Jest ona jedną z najstarszych i prawdopodobnie najbardziej popularnych ontologii stosowanych nie tylko w Web 3.0, ale i w szeroko rozumianym Internecie. Być może część z Was już wie, że standard Dublin Core wywodzi się tak na prawdę ze środowiska bibliotekarskiego. Inną ontologią ściśle związaną ze środowiskiem bibliotek cyfrowych jest SKOS, o której też pisałem w zeszłym roku.

Te ontologie, jak i inne standardy powstały właśnie w wyniku badań naukowych prowadzonym w ramach projektów bibliotek cyfrowych. Wiele idei, które przyświecały budowaniu Sieci Semantycznej wywodzi się właśnie z tego środowiska; wielu ludzi ściśle związanych z rozwojem Web 3.0 posiadało doświadczenie w pracy nad bibliotekami cyfrowymi. Dziwić więc może, że jeszcze do niedawna oba środowiska nie potrafiły znaleźć wspólnego języka.

Kiedy myślimy o bibliotece na myśl przychodzą nam dwa obrazy: zbiór książek i budynek w którym przechowywany jest ten zbiór. Zdefiniowanie pojęcia biblioteki cyfrowej jest trudniejsze:

• Czy biblioteki cyfrowe to po prostu katalogi do przeszukiwania zasobów bibliotecznych dostępne przez Internet (ang. Online Public Access Catalog - OPAC) ?
• Czy może biblioteka cyfrowa to skanowane dzieła, np. starodruki, opublikowane w Internecie ?
• A może biblioteka cyfrowa to kolekcja zasobów i metadanych dostępna za pomocą przeglądarki Internetowej ?
• Wreszcie, może biblioteka cyfrowa to sam system informatyczny publikujący kolekcję zasobów w Internecie ?

Dodatkowo biblioteki cyfrowe mogą być rozpatrywane zarówno pod kątem historycznym jak i technologicznym. Możemy też brać pod uwagę różne aspekty ich funkcjonowania: katalogowanie, zarządzanie informacją, wyszukiwanie informacji lub interakcja z użytkownikiem. Jak widać odpowiedź na to pytanie nie jest trywialna. Jeden z Europejskich projektów poświęconych bibliotekom cyfrowym, DELOS (obecnie dl.org), opracował raport, który odpowiada na to i inne pytania. W jednym z następnych artykułów postaram się przybliżyć nieznacznie tę tematykę.

Jak wcześniej wspomniałem wyniki badań w nad bibliotekami cyfrowymi dostarczyły wiele standardów, które są obecnie dość powszechnie stosowane w Internecie. Same jednak biblioteki cyfrowe do niedawna nie były tak na prawdę częścią Internetu. Oferowane przez nie usługi były często niekompatybilne pomiędzy samymi nawet bibliotekami, nie mówiąc już o próbie ich wykorzystania w innych usługach internetowych. Z drugiej strony do nie tak dawna biblioteki cyfrowe całkowicie odrzucały nurt mediów społecznych czy jakiegokolwiek innego sposobu na (niekontrolowane) dostarczanie dodatkowych treści. Dodatkowo słowniki (tezaurusy i taksonomie) utrzymywane przez biblioteki cyfrowe często nie są dostatecznie szybko aktualizowane aby odzwierciedlać obecny stan wiedzy. Nie bez znaczenia pozostaje fakt, że interakcja dostarczana przez biblioteki cyfrowe znacząco odbiega od "standardów" spotykanych w popularnych serwisach, jak choćby Facebook czy Twitter; tym samym nie odpowiada potrzebom i oczekiwaniom użytkowników, szczególnie młodszym pokoleniom.

Celem prac nad Semantycznymi Bibliotekami Cyfrowymi jest doprowadzenie do lepszej integracji pomiędzy bibliotekami i innymi usługami w Internecie, oraz poprawienie satysfakcji użytkowników z korzystania z usług dostarczanych przez biblioteki cyfrowe.

Semantyczne biblioteki cyfrowe są wynikiem połączenia wyników prac badawczych z trzech dziedzin:

• bibliotek cyfrowych, z głównym wkładem w postaci systemów organizacji wiedzy, słowników, tezaurusów, klasyfikacji, itp.
• sieci semantycznej zapewniającej znane nam już mechanizmy rozszerzalności opisów i interoperacyjności pomiędzy usługami i opisami,
• technologii Web 2.0 wprowadzających do świata bibliotecznego społeczne opisywanie zasobów (tagowanie) i społeczności powiązanych użytkowników systemów bibliotecznych.

Część z Was słyszała zapewne o inicjatywie Biblioteki 2.0 (ang. Library 2.0). Chociaż część z założeń jest podobna to jednak pojęcie Biblioteki 2.0 opiera się na 5 elementach: open source, single sign-on (czyli współdzielenie uwierzytelniania), otwarte standardy, zintegrowany OPAC, i oczywiście mediach społecznych. Brakuje więc dwóch istotnych elementów: standardów semantycznych zapewniających rozszerzalność i interoperacyjność, oraz powiązania ze standardami i usługami Internetowymi. Nurt Biblioteki 2.0 jest obecnie bardzo popularny, jednak określanie niektórych systemów bibliotek cyfrowych mianem "semantycznymi" tylko dlatego, że pozwalają użytkownikom na tagowanie jest dużym nadużyciem.

Na zakończenie tej części serii artykułów o Semantycznych Bibliotekach Cyfrowych, chciałbym pokrótce wymienić kilka projektów z nimi związanymi. W najbliższych tygodniach postaram się przybliżyć je bardziej.

• DuraSpace jest inicjatywą powstałą w ubiegłym roku z połączenia dwóch grup: popularnej biblioteki cyfrowej DSpace oraz Fedora Commons dostarczającej infrastruktury do budowy wydajnych i bogatych w funkcjonalność semantycznych bibliotek cyfrowych.
• JeromeDL jest projektem prowadzonym przez DERI Galway i Politechnikę Gdańską, z komercyjnym wsparciem ze strony firmy Knowledge Hives; powstał na bazie prototypu semantycznej biblioteki cyfrowej Elvis-DL stworzonego na Politechnice Gdańskiej w 2003 roku. Wokół projektu JeromeDL powstało kilka innych projektów tworzących klaster Corrib.org; w tym m.in., inicjatywa MarcOnt,  które dostarczają usługi, komponenty i ontologie dla semantycznych bibliotek cyfrowych.
• Greenstone jest kolejnym bardzo popularnym systemem biblioteki cyfrowej, umożliwiającym, m.in, efektywne wykorzystanie informacji o geolokalizacji za pomocą technologii semantycznych.
• SIMILE jest projektem prowadzonym przez MIT Libraries, który dostarcza szereg komponentów, które umożliwiają łatwe przekształcenie klasycznej biblioteki cyfrowej (lub innej witryny w Sieci) w interaktywny, bogaty w funkcje serwis oparty o technologie semantyczne.
• BRICKS był projektem prowadzonym w ramach Szóstego Programu Ramowego (FP6) - dostarczył kilka komponentów oraz infrastrukturę umożliwiającą efektywne społeczne i semantyczne opisywanie zasobów bibliotecznych, oraz wymianę pojęć pomiędzy różnymi systemami bibliotecznymi.

Więcej na temat Semantycznych Bibliotek Cyfrowych możecie dowiedzieć się na stronie inicjatywy, gdzie znajdziecie kilkanaście prezentacji (w tym kilkugodzinne tutoriale) oraz opis dwóch książek na ten temat.

Zanim napiszę o planach na najbliższy semestr, podsumujmy krótko pierwsze kilka miesięcy działalności Szkoły. Przez pierwsze cztery miesiące funkcjonowania Szkoły (od września do grudnia 2009):

• odwiedziliście nas ponad 4000 razy, spędzając średnio prawie 5 minut
• większość z was trafiała do nas kierowana z wykopu, Facebooka, GoldenLine i blipa.
• docieraliście do nas z najróżniejszych miast w Polscei z granicą
  

W pierwszym semestrze opublikowaliśmy 39 artykułów, w których:

• prezentowaliśmy ideę i podstawy Web 3.0,
• omawialiśmy podstawowe technologie i specyfikacje, w tym RDF, RDF Schema i OWL,
• wprowadziliśmy pojęcie ontologii i przedstawiliśmy kilka przykładów najbardziej popularnych z nich: SKOS, DublinCore, FOAF i SIOC,
• zwróciliśmy uwagę na wagę słowników w Web 3.0, takich jak WordNet czy OpenVocabulary, w Web 3.0,
• omówiliśmy czym są otwarte dane i jak wykorzystać je "aktualizacji" własnego serwisu do wersji Web 3.0,
• pokazaliśmy jak napisać w Javie prosty program korzystający z semantyki,
• informowaliśmy was na bieżąco o ciekawych wydarzenia związanych z Web 3.0: publikacji otwartych danych przez New York Times, decyzji HP w sprawie biblioteki Jena, czy doktoracie honoris causa dla sir Tima Bernersa-Lee,
• na zakończenie poprzedniego semestru napisaliśmy o tym jak otwarte standardy w stylu RDFa i Good Relations wpierają przedsięwzięcia typu e-commerce.

W tym semestrze planujemy:

• napisać więcej o wykorzystaniu technologii semantycznych w zastosowaniach komercyjnych,
• przybliżyć wam usługi Web 3.0 z których mogą korzystać wasze serwisy: Sindice, OpenCalais, DBPedia
• przedstawić kilka ciekawych projektów wykorzystujących technologie semantyczne, m.in. Twine, Drupal, DuraSpace
• omówić tematykę semantycznych bibliotek cyfrowych,
• opisać popularne języki zapytań i wnioskowania,
• oraz dalej kontynuować rozpoczęte tematy: podstawy, ontologie, programowanie.

Planujemy również wyjście poza cyfrowy świat: chcielibyśmy omówić dokładniej niektóre tematy i odpowiedzieć bezpośrednio na wasze pytania w trakcie warsztatów, które odbyłyby się jeżeli uda się zgromadzić odpowiednią ilość zainteresowanych.

Czekamy na wasze komentarze i opinie: tutaj na blogu, na Facebooku, i zapraszamy do dalszej lektury.

Jak więkość z nas wie rynek e-commerce rośnie w siłe, jego wartość wzrasta zdecydowanie z roku na rok. Kolejne sklepy internetowe wchodzą do gry i coraz ważniejsze staje się pozyskanie nowych klientów. Jedną z kluczowych metod jest pozyskanie ruchu przychodzącego z wyszukiwarek. Działania typu white hat są oczywiste dla wszystkich graczy na tym rynku, bardziej agresywni gracze wykorzystują do pozycjonowania grey hat czy nawet black hat sztucznie napędzające ruch na strony sklepu.

Czy można sprowadzić na strony sklepu więcej ruchu, lepszej jakości grając czysto? Według Jay’a Mayers’a można. Wyniki przeprowadzonego przez nich eksperymentu z wykorzystaniem RDFa i ontologii Good Relations do opisania stron z produktami sklepu spowodowały:

1. Podniesienie page rank Gogola dla stron wykorzystujących opisy semantyczne w stosunku do stron nie wykorzystujących tych opisów. W odpowiedzi na zapytanie o produkt na pierwszej pozycji Google wyświetlało strony wykorzystujące RDFa na pierwszej pozycji, pomimo że były to nowe strony w serwisie. Efekt ten pokazuje silny wpływ RDFa i ontologii Good Relations na mechanizm oceny stron przez Google.
2. 30% wzrost ruchu na stronach poszczególnych sklepów Best Buy.

O jakości wyszukiwania wśród zasobów opisanych min. przy pomocy ontologii Good Relations i RDFa  wypowiadał się także Nick Cox z Yahoo – CTR (Click-through-ratio) na stronie z wynikami wyszukiwania wzrasta o 15%.

Podsumowując - nie ma na co czekać, wdrożenie ontologii Good Relation i RDFa w serwisach e-commerce nie powino stanowić dużego probelmu, ale więcej o tym można przeczytać w naszym artykule o ontologii Good Relations.

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.