3NF 4NF active rdf ai ann apache automaty BCNF bd bsf c colors cyc db dbpedia debian dia dydaktyka eclipse erd filozofia firewall flex gem gemcutter gentoo git google grafy gui guides https ig isa iswc java jquery jruby kolokwium krug linux lisp logika maven musicbrainz mysql mysql workbench nginx Nielsen nlp onp openoffice pascal passenger pesel php pjn poliqarpr prezentacja programowanie prolog rails rcp rdb rdf regex rmbench rod rsa ruby ruby rails rvm semantic web sparql sql ssh subclipse subversion svn sw ubuntu ujs uml usability vim virtuoso wdi web wierzba wsd

Blog

Moje prywatne publiczne notatki.

Virtuoso installation in Debian

Introduction

Following the dbpedia mailing list discussion I am providing a step by step configuration procedure for the Virtuoso server in English. This also covers loading of the DBpedia data (n-triples) into the server. The procedure was tested on Debian, but it should work also for the other popular Linux distros, such as Ubuntu.

Virtuoso OS installation

The installation of Virtuoso OpenSource is easy, since there is a Debian package available in the default package tree. So the only thing to do is to type apt-get install virtuos-server in the console:

$ sudo apt-get install virtuoso-server
...

During the installation, the user will be asked for the password of the administrative account. If it is provided, the server will start automatically, when it is installed. This password will be used in the following steps of the configuration.

Server configuration

The Virtuoso distribution for Debian comes with a predefined configuration file, which can be found at /etc/virtuoso-opensource-6.1/virtuoso.ini The most important configuration options are as follows:

• DatabaseFile – the Virtuoso database file
• TransactionFile – the Virtuoso transaction file
• ErrorLogFile – the Virtuoso error log file (important when something goes wrong)
• DirsAllowed – the directories which are allowed to contain the data, that might be bulk-loaded to the server (important!)
• ServerPort – there are two options of this kind – one in Parameter section and the other in HTTPServer section. The first one is an API endpoint of the server, while the other allows for querying the server via a web-based interface.

The only option that should be adjusted for this tutorial is DirsAllowed. It is good to add /home/username to the end of list of allowed dirs. The username of the path should be replaced with the actual name of the user in the system, e.g. fred.

To make the changes effective, the user has to restart the server by issuing the following command:

$ sudo /etc/init.d/virtuoso-opensource-6.1 restart

Loading the DBpedia data

First of all we have to download some data from the DBpedia download page (or any other providing RDF triples), to make sure we have something to load. For example we could download all the English DBpedia article titles in the form of n-triples.

$ wget http://downloads.dbpedia.org/3.6/en/labels_en.nt.bz2

This will take several minutes, since the file is more than 100 MB. You can download any other dataset to experiment with, but the rest of the tutorial will assume, that the labels_en.nt.bz2 is available.

It’s important to note that the data is available in bzip2 format, so we have to install the bzip2 tools, in order to extract the data:

$ sudo apt-get install bzip2
...
$ bzip2 -d labels_en.nt.bz2
...

The last important thing to download is the rdfloader script Since it is not available as a separate file on the wiki, I’ve put it on my server for convenience (and I hope not to be sued by OpenLink ;-). So downloading it is as simple as:

$ wget http://apohllo.pl/texts/rdfloader.sql
...

When we have all the necessary files, we can start the Virtuoso client. We have to provide the password, that was selected in the installation phase.

$ isql-vt -U dba
Enter password for dba:
Connected to OpenLink Virtuoso
...
SQL>

Virtuoso is a regular SQL database with support for RDF, hance the SQL prefix in the client.

To load the DBpedia data into the server first we have to load the rdfloader script:

SQL> load rdfloader.sql;
...

• directory path
• pattern for loaded files
• the name of the graph the data will be stored in

It is important to note, that the first option of the command have to be provided in the DirsAllowed option of the Virtuoso configuration file. I guess most of the problems with loading the data into the server comes from this option. Although the configuration file defines the current directory (’.’) as valid for loading the data, it doesn’t seem to work, at least if we interpret this directory as the one, the isql-vt command was issued in. So in the case of problems, it seems to be the first option to carefully inspect.

If we wish to load the data downloaded in the previous steps we have to issue the following command:

SQL> ld_dir('/home/username','*.nt','http://dbpedia.org');
Done -- 2 msec.

Surprisingly this command won’t load the data. This is done via call to rdf_loader_run:

SQL> rdf_loader_run;
...

This command can take much time (even several hours!), especially if you wish to load much of the contents of DBpedia. So please be patient.

Using the data

When the data has been loaded it’s time to issue some queries to server, to check if everything works fine. The easiest way is to start the sparql client and issue a simple select, such as:

SQL> sparql select from <http://dbpedia.org> where {?s ?p ?o} limit 5;
s
  p
    o
VARCHAR
  VARCHAR
    VARCHAR
------------------------------------------------------------------------
http://www.dbpedia.org/resource/AccessibleComputing
  http://www.w3.org/2000/01/rdf-schema#label
    AccessibleComputing
...

If the result looks as above the DBpedia data is in the Virtuoso instance! Now you can issue more complex queries (assuming you have loaded more data than the mere labels).

There is also another option for accessing the data – via web interface. If you open the address http://localhost:8890/sparql in you browser you should have access to the web based client of the Virtuoso server.

Instalacja Rails 3.2 pod Ubuntu

Instrukcja instalacji Ruby on Rails w wersji 3.2.2 pod Ubuntu (testowane w wersji 11.04)

1. Instalacja Rubiego w wersji 1.9.3

Postępujemy zgodnie z instrukcją instalacji Rubiego

2. Instalacja Railsów w wersji 3.2.2

W konsoli wpisujemy poleceni instalacji Railsów gem install rails:

$ gem install rails
Fetching: i18n-0.6.0.gem (100%)
Fetching: multi_json-1.0.4.gem (100%)
Fetching: activesupport-3.2.1.gem (100%)
Fetching: builder-3.0.0.gem (100%)
Fetching: activemodel-3.2.1.gem (100%)
Fetching: rack-1.4.1.gem (100%)
Fetching: rack-cache-1.1.gem (100%)
Fetching: rack-test-0.6.1.gem (100%)
Fetching: journey-1.0.1.gem (100%)
Fetching: hike-1.2.1.gem (100%)
Fetching: tilt-1.3.3.gem (100%)
...

Na początku wydaje się, że polecenie zamarło, ale trzeba trochę odczekać. Jeśli wynik jest inny niż powyższy, należy dokładnie przeczytać komunikat błędu.

3. Instalacja biblioteki TheRubyRacer

Wbrew pozorom pomimo instalacji wielu zależności, konfiguracja Railsów nie jest jeszcze skończona. Ze względu na dodanie w wersji 3.1 asset pipline konieczne jest jeszcze doinstalowanie biblioteki pozwalającej na uruchamianie Javascriptu po stronie serwera. Istnieje kilka opcji, ale instalacja gemu therubyracer powinna przebiegać bez problemów:

$ gem install therubyracer

4. Wygenerowanie przykładowej aplikacji

Po instalacji gemu therubyracer możemy wygenerować nową aplikację:

$ rails new library
      create  
      create  README.rdoc
      create  Rakefile
      create  config.ru
      create  .gitignore
      create  Gemfile
      create  app
      create  app/assets/images/rails.png
      create  app/assets/javascripts/application.js
      create  app/assets/stylesheets/application.css
      create  app/controllers/application_controller.rb
      create  app/helpers/application_helper.rb
      create  app/mailers
      create  app/models
...

5. Konfiguracja aplikacji

Pomimo tego, że aplikacja została wygenerowana pomyślnie konieczne jest jeszcze wskazanie biblioteki używanej do obsługi Javascriptu. W tym celu w pliku Gemfile w katalogu głównym aplikacji musimy dodać następującą linijkę

gem "therubyracer"

Następnie wywołujemy komendę bundle w katalogu aplikacji:

$ cd library
$ bundle
Using rake (0.9.2.2) 
Using i18n (0.6.0) 
Using multi_json (1.0.4) 
Using activesupport (3.2.1) 
Using builder (3.0.0) 
Using activemodel (3.2.1) 
Using erubis (2.7.0) 
Using journey (1.0.1) 
Using rack (1.4.1) 
...

5. Dodanie przykładowej funkcjonalności

Na koniec możemy wygenerować przykładowy scaffold, żeby czy wszystko działa jak należy:

$ rails g scaffold author name:string surname:string
      invoke  active_record
      create    db/migrate/20120205195252_create_authors.rb
      create    app/models/author.rb
      invoke    test_unit
      create      test/unit/author_test.rb
      create      test/fixtures/authors.yml
       route  resources :authors
...
$ rake db:migrate
==  CreateAuthors: migrating ==================================================
-- create_table(:authors)
   -> 0.0011s
==  CreateAuthors: migrated (0.0012s) =========================================
$ rails s
=> Booting WEBrick
=> Rails 3.2.1 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2012-02-05 20:54:10] INFO  WEBrick 1.3.1
[2012-02-05 20:54:10] INFO  ruby 1.9.3 (2011-10-30) [i686-linux]
[2012-02-05 20:54:10] INFO  WEBrick::HTTPServer#start: pid=21730 port=3000

Jeśli w przeglądarce wejdziemy po adres http://localhost:3000/authors powinniśmy zobaczyć następującą treść:

Kilka ważnych poleceń

Jest kilka poleceń i ustawień w Linuksie, które wprowadzam raz na rzadki czas, a po tym czasie zapominam i szukam ich wciąż na nowo.

GPG error – Debian/Ubuntu

Pobranie klucza GPG z serwera i dodanie go do apt-get-a:

$ sudo gpg --keyserver subkeys.pgp.net --recv 7D2C7A23BF810CD5
$ sudo gpg --export --armor 7D2C7A23BF810CD5 | sudo apt-key add -

PgUp/PgDown w historii poleceń

W Debianie/Ubuntu wystarczy w pliku /etc/inputrc odkomentować linijki (w Gentoo standardowo włączone):

"\e[A": history-search-backward
"\e[B": history-search-forward

Kolory znak zachęty z gitem

Dzięki poniższym poleceniom, znak zachęty w Linuksie jest kolorowy oraz posiada dodatkowe informacje dla katalogów zawierających repozytorium Git. Należy wrzucić do ~/.bash_profile

parse_git_branch ()
{
        if git rev-parse --git-dir >/dev/null 2>&1
        then
                gitver="[$(git branch 2>/dev/null| sed -n '/^\*/s/^\* //p')]" 
        else
                return 0
        fi
        echo -e $gitver
}
branch_color ()
{
  if git rev-parse --git-dir >/dev/null 2>&1
  then
          color="" 
          if git diff --quiet 2>/dev/null >&2 
          then
                  color='\033[01;32m'
          else
                  color='\033[01;31m'
          fi
  else
          return 0
  fi
  echo -ne $color
}
PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[$(branch_color)\]$(parse_git_branch) \[\033[01;34m\]\$\[\033[00m\] '

Instalacja Rubiego 1.9.3 w Ubuntu

Prosta instrukcja, jak zainstalować najnowszą wersję Rubiego (1.9.3-p0) w systemie Ubuntu (testowane z 11.04).

1. Najpierw instalujemy niezbędne pakiety za pomocą apt-get-a (m.in. Ruby w wersji 1.8):

$ sudo apt-get install zlib1g-dev libssl-dev libreadline5-dev libxml2-dev libsqlite3-dev 
$ sudo apt-get install ruby rubygems curl git-core

2. Następnie ściągamy i instalujemy Ruby Version Manager (w skrócie RVM):

$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

3. Wczytujemy nową konfigurację shella

$ source /home/user/.profile

4. Testujemy działanie RVM:

$ rvm help

[![Build Status](https://secure.travis-ci.org/mpapis/rvm.png)](http://travis-ci.org/mpapis/rvm)
= rvm
* http://github.com/wayneeseguin/rvm
== DESCRIPTION:
...

Jeśli nie widzimy powyższych komunikatów, znaczy to, że instalacja się nie powiodła! Należy przeczytać uważnie komunikat i sprawdzić co jest nie tak.

6. Instalujemy najnowszą stabilną wersję Rubiego:

$ rvm install 1.9.3
Installing Ruby from source...

Instalacja trwa kilka minut, ponieważ w jej trakcie kompilowany jest Ruby.

7. Na koniec ustawiamy Rubiego 1.9.3 jako domyślny interpreter używany w systemie:

$ rvm use 1.9.3 --default
Using /home/user/.rvm/gems/ruby-1.9.3-p0

8. Weryfikujemy powyższe wydając polecenie:

$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]

9. Teraz możemy otworzyć konsolę irb i ostatecznie potwierdzić, że mamy najnowszą wersję Rubiego:

$ irb
ruby-1.9.3-p0 :001 > "abc".encoding
 => #<Encoding:UTF-8>

Rod - Ruby Object Database

Rok temu na EuRuKo miałem superkrótką prezentacje na temat biblioteki Rod mojego autorstwa. Wtedy rozwinąłem ten skrót jako “Read-only database”, co wywołało gromki śmiech, bo po co komu baza danych tylko do odczytu? Obecnie nazwę rozwijam (oczywiście jest w tym przesada) jako Ruby Object Database. W praktyce jej podstawowy charakter się nie zmienił, ale z pewnością nazwa jest bardziej chwytliwa :)

Ale do rzeczy – co to za biblioteka? Otóż została ona zaprojektowana jak baza do przechowywania danych, które rzadko ulegają zmianie. Chodzi mi przede wszystkim o dane lingwistyczne, tzn. takie jakie spotykamy w tradycyjnych słownika i książkach (korpusach tekstów). Język oczywiście jest tworem żywym, co odzwierciedlone jest w ewoluującej zawartości słowników, ale zmiany te następują raczej w ciągu lat, czy dziesięcioleci, niż dni czy godzin. Podobnie z zawartością korpusów tekstów – jeśli coś tam trafi, to już raczej nie podlega zmianie (być może usunięciu, jeśli język zmienił się na tyle, że tekst staje się bardzo mało reprezentatywny).

Dla tego typu danych nie potrzeba baz, które kładą specjalny nacisk na wielodostęp, czy transakcje, bo w praktyce modyfikację bazy lepiej wykonać poprzez jej ponowne wygenerowanie, ewentualnie poprzez dodanie nowych danych i powiązań między danymi, do już istniejącej bazy. Z drugiej strony baza tego rodzaju nie musi być trzymana w pamięci, ponieważ analizując tekst potrzebujemy zawsze jedynie fragmentu słownika. Natomiast w przypadku korpusów tekstu trzymanie w pamięci nie wchodzi w rachubę, ze względu na rozmiar danych. Dlatego tak popularne ostatnio bazy oparte o memcache’a i pokrewne nie są zbyt przydatne dla danych lingwistycznych.

Z kolei relacyjne bazy danych nie mogą być wykorzystane przy analizie tekstów, ponieważ zbiór relacji w jakie wchodzą ze sobą poszczególne elementy czy to słownika, czy też korpusu, jest olbrzymi. Wymagane w tym wypadku wielokrotne złączenia tabel wprowadziłyby nieakceptowalny czas przetwarzania.

Zatem Rod pomyślany jest jako baza danych, w której dane nie ulegają zmianie (choć nie wyklucza się ich dodania i uzupełnienie ich związków), a ich rozmiar wyklucza trzymanie w pamięci operacyjnej. Dodatkowe oczekiwania obejmują szybki czas dostępu dla zindeksowanych danych (np. kilku milionów form wyrazowych), który jednak nie wprowadza narzutu przy uruchomieniu bazy danych (wczytanie pełnego indeksu kilku milionów form zajmuje co najmniej kilka sekund). Co więcej – wczytanie pojedynczej informacji (która zwykle jest elementem dużego grafu zależności) nie powinno z jednej strony powodować wczytania wszystkich elementów powiązanych (szybko okazałoby się, że wczytujemy bardzo dużo niepotrzebnych danych), a z drugiej – dzięki słabemu wiązaniu, umożliwiać GC łatwe usuwanie danych z pamięci, nawet jeśli są one osiągalne z aktualnie dostępnych zmiennych. Ten drugi wymóg dotyczy sytuacji, w której wczytano pewne dane, dokonano analizy i dodatkowe informacje nie są już potrzebne, ale dalej rezydują w pamięci. Luźne wiązanie pozwala łatwo się ich pozbyć.

Biblioteka Rod implementuje większość z tych funkcjonalności (obecnie jedynie uzupełnianie związków między danymi nie jest wspierane). W niedalekiej przyszłości zamierzam wydać słownik języka polskiego oraz narzędzie do tworzenia korpusów, które będzie oparte o tę bibliotekę. Z ciekawych własności słownika: powinien on umożliwiać poprawne generowanie opisów dla błędów w formularzach, np. “W formularzu jest 1 błąd/2 błędy 5 błędów”, “Nazwa nie może być pusta”, “Adres nie może być pusty” oraz np. właściwe generowanie opisów typu: “Ania skomentowała twój status”, “Wojtek skomentował twój status”.

Oczywiście wszystko będzie dostępne jako biblioteka Rubiego.

Virtuoso - podstawy

Dlaczego Virtuoso?

Obecnie jest już sporo narzędzi pozwalających na przechowywanie danych w formacie RDF oraz zadawanie pytań w języku SPARQL. Ponieważ obecnie nie mam czasu żeby przyjrzeć się szczegółowo nawet tym najbardziej popularnym (AllegroGraph, Sesame 2, OWLime, D2R, OntoBroker, Virtuoso), aby przechowywać dane, które są co prawda dostępne jako RDF, ale nie posiadają dedykowanego SPARQL endpointu, oparłem się na wyborze jakiego dokonali twórcy DBpedii, tj. Virtuoso. Narzędzie to występuje w wersji komercyjnej oraz wolnej, więc z jednej strony można mu się swobodnie przyjrzeć, a z drugiej, czas na to poświęcony raczej nie będzie stracony, jeśli w przyszłości zechcemy wykorzystać je w jakimś komercyjnym projekcie, dla którego potrzebna będzie większa wydajność oraz support.

Instalacja

Virtuoso OpenSource można ściągnąć ze strony producenta lub za pośrednictwem dedykowanego dla naszego systemu operacyjnego narzędzia do zarządzania pakietami (odpowiednie paczki istnieją np. dla Gentoo oraz Debiana), dlatego z instalacją nie powinno być problemu.

Konfiguracja

Zainstalowane ze źródeł Virtuosu (przynajmniej pod Gentoo) nie posiada żadnych plików konfiguracyjnych, dlatego musimy przygotować sami minimalną konfigurację. Może ona wyglądać następująco:

[Database]
DatabaseFile=/var/lib/virtuoso/db/virtuoso.db
TransactionFile=/var/lib/virtuoso/db/virtuoso.trx
ErrorLogFile=/var/lib/virtuoso/db/virtuoso.log
[Parameters]
DirsAllowed=/path/to/dir
[HTTPServer]
ServerPort=8080

Konfigurację tę możemy umieścić np. w pliku /etc/virtuoso.ini.

Poszczególne zmienne konfiguracyjne zasadniczo są samoopisujące – z wyjątkiem może DirsAllowed. Ten parametr ustala ścieżki, z których będziemy mogli ładować pliki zewnętrzne. Ustalenie go jest kluczowe dla punktu, w którym będziemy ładować dane zewnętrzne.

Uruchomienie serwera i klienta

Serwer uruchamiany jest za pomocą polecenia virtuoso-t. Polecenie to przyjmuje kilka opcji, w szczególności kluczowe jest określenie pliku konfiguracyjnego. Służy do tego opcja +configfile. Dodatkowo przy pierwszym uruchomieniu możemy zażądać, aby serwer nie działał w tle (opcja +foreground), dzięki czemu w razie problemów będziemy mogli zobaczyć co jest nie tak.

$ virtuoso-t +configfile /etc/virtuoso.ini +foreground
        Tue Apr 05 2011
12:23:07 INFO: OpenLink Virtuoso Universal Server
12:23:07 INFO: Version 06.01.3127-pthreads for Linux as of Mar  8 2011
12:23:07 INFO: uses parts of OpenSSL, PCRE, Html Tidy
12:23:07 INFO: Database version 3126
12:23:07 INFO: SQL Optimizer enabled (max 1000 layouts)
12:23:08 INFO: Compiler unit is timed at 0.000694 msec
12:23:11 INFO: Roll forward started
12:23:11 INFO: Roll forward complete
12:23:12 INFO: Checkpoint started
12:23:13 INFO: Checkpoint finished, log reused
12:23:15 INFO: HTTP server online at 8080
12:23:15 INFO: Server online at 1111 (pid 15156)

Kiedy uruchomimy serwer, możemy sprawdzić go w działaniu wykorzystując polecenie isql-v. Otwiera ono interaktywną sesję pracy z serwerem:

$ isql-v
SQL> sparql select * where {?s ?p ?o} limit 10;

Powłoka klienta pozwala na bezpośrednie przeglądanie bazy danych, na której działa Virtuoso, za pomocą zwykłych poleceń SQL-owych. Dlatego zapytania SPARQL-owe muszą być poprzedzone słowem kluczowym SPARQL. Przykładowe zapytanie przedstawione jest powyżej. Niemniej dla świeżej instalacji Virtuoso nie zwróci ono żadnych rezultatów.

Ładowanie istniejących danych

Żeby poeksperymentować z zapytaniami SPARQL musimy załadować jakieś dane RDF. Są one dostarczane przez wiele organizacji (np. DBpedię, Umbel, itp) w postaci RDF+XML lub innego popularnego formatu, np. n3. Zazwyczaj dane takie dostępne są w postaci jednego dużego pliku lub, w przypadku bardzo dużych zbiorów, w postaci kilku mniejszych plików.

1. w pliku konfiguracyjnym zezwalamy na ładowanie plików z katalogu, w którym przechowujemy ściągnięte pliki
2. ściągamy i uruchamiamy skrypt pozwalający na masowe ładowanie danych
3. w konsoli Virtuoso wykonujemy polecenie/a ld_dir
4. w konsoli Virtuoso wykonujemy polecenie df_loader_run

Pierwszy krok został opisany w punkcie “Konfiguracja”.

Po ściągnięciu pliku, wskazanego w drugim punkcie, zapisujemy go w aktualnym katalogu, np. pod nazwą rdfloader.sql, następnie w tym samym katalogu wywołujemy polecenie isql-v. Następnie w konsoli SQL wywołujemy polecenie load rdfloader.sql:

$ ls
rdfloader.sql
$ isql-v
SQL> load rdfloader.sql;

Jeśli za kilka dni będziemy chcieli załadować kolejną paczkę danych, to procedury tej nie trzeba będzie już powtarzać.

• ścieżkę do katalogu
• szablon nazwy plików
• nazwę grafu, do którego załadowane zostaną dane

Pierwszy argument nie wymaga wyjaśnienia. Drugi argument pozwala określić szablon (tak jak dla polecenia ls), np. ’*.n3’ lub wskazać konkretny plik, np. dbpedia.n3. Trzeci argument jest o tyle istotny, że pozwala przechowywać w jednej instancji semantycznej bazy dane z różnych źródeł i odwoływać się do nich niezależnie za pomocą klauzuli WHERE. Warto wybrać nazwę wskazującą źródło danych w postaci adresu URL, np. http://dbpedia.org.

Przykładowe polecenie może wyglądać następująco:

SQL> ld_dir('/home/user/rdf/dbpedia','*.n3','http://dbpedia.org');

Wbrew oczekiwaniom polecenie to nie załaduje od razu danych do bazy. Dopiero kolejne polecenie df_loader_run, spowoduje załadowanie danych. Przed jego wykonaniem należy uzbroić się w cierpliwość, gdyż może zająć to całkiem sporo czasu.

SQL> rdf_loader_run ();

Przykładowe użycie

Jeśli wszystko przebiegło poprawnie, to powinniśmy mieć możliwość korzystania z załadowanych danych poprzez SPARQL end-point. Możemy go najpierw przetestować w konsoli isql-v:

sparql select * from <http://dbpedia.org> where {?s ?p ?o} limit 5;
http://dbpedia.org/resource/Autism          http://www.w3.org/1999/02/22-rdf-syntax-ns#type  http://www.w3.org/2002/07/owl#Thing
http://dbpedia.org/resource/Alabama         http://www.w3.org/1999/02/22-rdf-syntax-ns#type  http://www.w3.org/2002/07/owl#Thing
http://dbpedia.org/resource/Aristotle       http://www.w3.org/1999/02/22-rdf-syntax-ns#type  http://www.w3.org/2002/07/owl#Thing
http://dbpedia.org/resource/Academy_Award   http://www.w3.org/1999/02/22-rdf-syntax-ns#type  http://www.w3.org/2002/07/owl#Thing
http://dbpedia.org/resource/Actrius         http://www.w3.org/1999/02/22-rdf-syntax-ns#type  http://www.w3.org/2002/07/owl#Thing

Innym sposobem dostępu jest wykorzystanie wbudowanego serwera WWW. Otwieramy stronę pod adresem http://localhost:8080/sparql i od razu możemy zadawać zapytania SPARQL.

Możemy również przetestować działanie end-pointu z poziomu jakiegoś języka programowania, np. Rubiego:

client = SPARQL::Client.new("http://localhost:8080/sparql")
results = client.query("select * where {?subject ?predicate ?object} limit 5")
results.each{|r| puts "#{r.subject} #{r.predicate} #{r.object}"}

Rails 3 and UJS with jQuery

Recently I tried to convert my Rails 2.3 application into Rails 3.0. There are various tutorials covering this problem, so I just concentrate on one issue which is not well described – namely the UJS functionality introduced in Rails 3.

Generally I agree with the idea, that UJS is a good solution – the HTML we had with calls link_to_remote and the like was really ugly, and this ugliness is not just something unimportant IMHO (especially when you have to look at the page source). So I welcome this feature appreciatively.

So it seemed that the switch should to be as easy, as replacing the old:

link_to_remote "tilte", :url => {...}, :update => "some_id"

with

link_to "title", {...}, :remote => true

but… as you might see in this piece of code above, the :update key, which I found very useful, is missing in the new syntax. I thought – “Strange”, but who cares – there must be some rationale for that, just another piece of Rails/jQuery magic. But when I started googling, I “discovered” that there is no good substitution for :update. Especially in Ryan’s recent railscast the solution was really disappointing, I mean this line of code in index.js.erb:

$("#products").html("<%= escape_javascript(render("products")) %>");

What?! Do I have to write this piece of sh… for every remote action? Where is the beauty of Rails’ DRYness?

But just the next day after implementing this in my application, I thought “There must be some solution for that”. And there is!

If you wish to preserve the old behavior of link_to_remote without lousing the benefits of UJS, do the same as you did, namely:

link_to "title", {...}, :remote => true, :"data-update" => "some_id"

(We use :"data-update" instead of :update to be more HTML 5 compliant. You could use :update, but then you would have to adapt the code below appropriately.)

And then add this little piece of code to your application.js:

jQuery(function($) {
$("a[data-update]").live("ajax:success", function(data,status,xhr){
      $("#"+$(this).attr("data-update")).html(status);
    });
});

And that’s it! The :update behavior should work as previously (and don’t ask me why I use “status” variable for something which has semantic of “data” – the names are taken directly from the official rails.js file).

ISWC 2010 dzień 1

mc shraefel – invited talk

Nie wiem dokładnie o co chodzi z imieniem i nazwiskiem Pani “mc shraefel”, ale wszędzie pojawia się ono z małej liter, więc pozostaję przy tej konwencji.

Prezentacja zaczęła się w nieoczekiwany sposób, gdyż uczestnicy musieli wstać, machać rękami i bujać się na biodrach. Wśród niektórych wywołało to małą konsternację, ale niewątpliwie wszyscy się obudzili, a niektórzy przynajmniej na chwilę odłożyli swoje komputery.

W zasadzie cała prezentacja mc, koncentrowała się na zagadnieniach usability technologii semantycznych. Podstawowa jej obserwacja, która chyba wywołała najwięcej niezadowolenia audytorium, dotyczyła faktu, że właściwie każda z prezentowanych jej aplikacji opartych o Semantic web, dla przeciętnego użytkownika Internetu w zasadzie była niezrozumiała. Trudno nie zgodzić się jednak z tą obserwacją, jeśli widzi się, że kolejne aplikacje pokazują dane RDF w coraz to nowych konfiguracjach, z coraz to nowymi ikonkami, ale nic sensownego z tego nie wynika. Oczywiście jest to zgrubna ocena, ale też ważny sygnał dla firm, które chciałyby komercjalizować tego typu technologie. Oczekiwanie, że użytkownik oglądając jakąś dziwną tabelkę z dziwnymi napisami będzie zachwycony jest mało realne.

Oczywiście jako przeciwwaga pokazany został interfejs projektu, nad którym pracuje mc. Zasadniczo w ogóle nie było wiadomo, że jest to aplikacja Semantic Web – interfejs był tekstowy. Użytkownik mógł wprowadzać zapytania w języku zbliżony do naturalnego, no i na tym cała rzecz się opierała (coś podobnego do firefoxowego Ubiquity).

Konkluzją prezentacji było stwierdzenie – niech tematem kolejnej ISWC będą zwykli użytkownicy i ich potrzeby, a nie kolejne dyskusje nad przewagą OWL-a nad RDFS i vise-versa.

Doctoral consortium i NLP

Po prezentacji mc shraefel przeniosłem się do sali, w której prezentacje mieli studenci. Przyznam szczerze, że prezentacje mnie nie powaliły. Generalnie większość z nich miała podobny problem – chcieli poruszyć zbyt wiele tematów w jednej pracy. Co więcej, choć ambicje prezentujących były duże, to prezentacje wycinkowe i zazwyczaj koncentrowały się na zagadnieniach już dość dobrze zbadanych (np. ekstrakcja relacji taksonomicznych z Wikipedii). Dlatego szybko przeniosłem się na prezentację Supporting Natural Language Processing with Background Knowledge: Coreference Resolution Case.

W prezentowanym artykule autorzy pokazują, jak można wykorzystać statystyczne algorytmy w połączeniu z wiedzą dostępną w Semantic Web, aby ulepszyć wyniki uzyskiwane dla różnych zadań z dziedziny ekstrakcji informacji, w tym wypadku w zadaniu rozpoznawaniu koreferencji między dokumentami. Autorzy proponują, aby użyć Wikipedii jako punktu odniesienia dla innych źródeł wiedzy. Niewątpliwie nie jest to zaskakujące rozwiązanie. Duża część artykułu poświęcona jest zagadnieniu wyboru tych relacji, spośród wielu występujących w źródłach Semantic Web, które istotne są z punktu widzenia skuteczności algorytmu. Wiadomo bowiem, że dane dostępne jako Linked Data nie są zbalansowane i nierzadko dla określonych zasobów (np. Obamy) istnieją setki faktów, a dla innych zaledwie kilka. Prezentacja niewątpliwie ciekawa, ale w moim przekonaniu zastanawiające jest użycie statystycznych metod do określenia istotnych cech zasobów, zamiast wykorzystanie jawnej reprezentacji, która jest jedną z podstawowych zalet zasobów udostępnianych w jako Linked Data.

Z pozostałych prezentacji, które obejrzałem tego dnia, chyba żadna nie zapadła mi specjalnie w pamięć. Były to m.in. dyskusja panelowa nad formatem RIF, “I18n of Semantic Web Applications”, “Mapping Master: a Flexible Approach for Mapping Spreadsheets to OWL” oraz “ISReal: An Open Platform for Semantic-Based 3D Simulations in the 3D Internet”.\

Tego dnia pokazywałem również swoje demo, w którym dla danych udostępnianych jako Linked Data, tworzone były polskie opisy. Niestety ze względu na tymczasową niedostępność serwisu MusicBrainz, demo nie działało :( No cóż – taka natura Semantic Web. Ale przynajmniej mogłem sobie porozmawiać z kilkoma osobami, które udawały, że chcą się nauczyć języka polskiego (ponieważ nie miałem plakatu, zamieściłem tylko krótką notkę, że można nauczyć się naszego języka ;) ). Kilka dyskusji było niewątpliwie ciekawych, ale ich konkluzje pozostawiam dla siebie.

ISWC 2010 COLD

Ciekawsze prezentacje z warsztatów COLD w ramach konferencji International Semantic Web Conference 2010

Capturing Emerging Relations between Schema Ontologies on the Web of Data

Autorzy pokazują jak można ustalać relację ekwiwalencji pomiędzy klasami wykorzystywanymi w Linked Data. Zasadnicza idea opiera się na wykorzystaniu relacji “sameas” na poziomie instancji. Okazuje się, że proste drzewo decyzyjne pozwala uzyskać precyzję na poziomie przekraczającym 90%. Problem, który utrudnia wykorzystanie rezultatów tego rodzaju, jest m.in. zmienność schematów konceptualnych używanych w różnych bazach wiedzy. Ponadto operowanie na poziomie instancji dużych zbiorów danych jest bardzo czasochłonne.

The R2R Framework: Publishing and Discovering Mappings on the Web

Autorzy przedstawiają metodykę oraz język, który mają pomóc w rozwiązaniu jednego z podstawowych problemów Semantic Web, tzn. występowania wielu niezależnych taksonomii. Podstawowa idea polega umożliwieniu publikowania oraz odnajdywania mapowań pomiędzy różnymi schematami konceptualnymi.

• odmienne klas używane do wyrażenia tych samych pojęć
• odmienne własności (tutaj istotny problem polega również na dopasowaniu pozycji argumentów)
• używanie odmiennych jednostek w różnych DS korzystających z tej samej ontologii
• modyfikacje typu danych -> int – float
• używanie odmiennych etykiet (A. Einstein vs. Albert Einstein)

Autorzy proponują nowy język R2R zbudowany na podstawie SPARQL, który pozwalałby na opisywanie przekształceń, które muszą być dokonane aby dopasować do siebie różne źródła danych, ponieważ dotychczasowe rozwiązania zdefiniowane w OWL i SKOS są niewystarczające do rozwiązania wszystkich wyżej przedstawionych problemów.

Propozycja polega na dodanie rozbudowanych szablonów mapowania, które uwzględniają wszystkie wyżej wymienione problemy. Ponadto zaproponowane rozwiązanie umożliwia tworzenie łańcuchów przetwarzania (tzn. mapowania poprzez schematy pośrednie) oraz uwzględnia meta dane na temat twórcy mapowania, jego jakości, etc.

Rozwiązanie wydaje się jednak dosyć nietrafione – istnieje wiele formalnych rozwiązań, które adresują powyższe problemy. Zdecydowanie lepiej byłoby objąć w rozwiązaniu tylko te elementy, które nie dają się załatwić na poziomie deklaratywnym. W szczególności odnosi się to do dopasowania klas, własności oraz jednostek (w końcu można wprost opisać jednostki, które używane są w określonym DS, albo wymusić używanie określonych jednostek w samej ontologii). W szczególności rezygnacja z wykorzystania predykatów sameAs, equivalentClass, equivalentProperty wydaje się najgorszym pomysłem.

Wydaje się natomiast, że niektóre aspekty są zupełnie pomijalne – np. etykieta A. Einstein vs Albert Einstein. Jeśli tylko będzie ustalona relacja sameAs pomiędzy odpowiednimi zasobami, takie różnice będą zupełnie nieistotne (jest to jedna z podstawowych idei leżących u podstaw Semantic Web – tzn. reidentyfikacja przez URL a nie te lub inne własności).

PS. Autorzy są twórcami DBpedii. Rozmawiałem z autorem prezentacji i wyjaśnił, że predykaty sameAs, etc. będą wykorzystywane przez prezentowane narzędzie, ale po co zatem dodawać nowe rozwiązanie służące do tego samego?

Consuming multiple linked data sources: Challenges and Experiences

• uwzględnieniu wielu URL-i wskazujących ten sam obiekt w różnych zbiorach danych
• efektywne przetwarzanie zapytań, dla których dane znajdują się w odrębnych zbiorach

• Semantic Web Client Library – w celu wykonania zapytania obejmującego wiele zbiorów danych, dane są wcześniej cache’owane lokalnie i zapytanie realizowane jest na ich kopii. Problemem jest to, że często pobierane są znaczne ilości informacji nie istotne do realizacji zapytania.
• DARQ – prezentuje podejście dokładnie przeciwne dl SWCL, wszystkie zapytania realizowane są w oparciu od zdalne SPAQRL end-pointy (co wyklucza wykorzystanie danych nie posiadających takiego end-pointu). Zasadniczymi wadami tego podejścia są: mała wydajność oraz konieczność dostarczenia danych statystycznych na temat zawartości określonego źródła danych w celu optymalizacji zapytani.

Propozycja przedstawiona przez autorów opiera się na doświadczeniu zdobytym z narzędziem RKBExplorer. Służy ono do dostarczania informacji na temat społeczności praktyków pracujących nad jakimś zagadnieniem naukowym. W szczególności narzędzie to powinno dostarczać informacje na temat osób, ich publikacji, tematów badań itp. Zaproponowane rozwiązanie sprowadza się do dostarczenie specyficznych połączeń zapytań, które mają być wykonywane na wielu zbiorach danych. W szczególności chodzi o to, by fragmenty zapytania mogły być wykonywane wewnątrz jednego zbioru danych, natomiast całość może obejmować wiele zbiorów. Choć rozwiązanie to posiada istotne ograniczenia, dla zadania, w którym było wykorzystywane uzyskana wydajność była zadowalająca. Co więcej zbiory danych różnego typu (surowe dane RDF oraz dane dostępne za pomocą języka SPARQL) są obsługiwane w tym rozwiązaniu.

IBM Jeopardy! Challenge

Zdecydowanie najciekawsza prezentacja z tych warsztatów – przedstawiciel IBM-a – Chris Welty przedstawił projekt o rozmachu podobny do Deep Blue. Duży zespół naukowców z IBM Research pracuje nad systemem odpowiadającym na pytania, który mógłby konkurować z ludźmi w grze podobnej do naszego “Va Banque” (w istocie rzeczy Va Banque był realizowany na licencji Jeopardy). Cały problem polega na tym, że osoby wygrywające ten teleturniej zazwyczaj odpowiadają w ciągu kilku sekund, i w przeważającej liczbie przypadków nie mylą się. Dodatkowym utrudnieniem jest fakt, że pytanie zadawane jest nie wprost.

Zatem system, który mógłby konkurować z ludźmi musiałby poprawnie analizować zdanie, posiadać olbrzymią wiedzę faktograficzną oraz określać właściwą odpowiedź w czasie kilku sekund. Niestety w gruncie rzeczy uczestnicy konferencji nie dowiedzieli się zbyt wiele, poza ogólnikowymi stwierdzeniami, że kluczową własnością systemu, jest zdolność do prawidłowej oceny odpowiedzi. Padło też dosyć enigmatyczne stwierdzenie, że w systemie tego rodzaju niezbyt istotna jest wiedza “zdroworozsądkowa”, której tak wiele uwagi poświęcają twórcy ontologii, ale wiedza faktograficzna. Z pytania, które zadałem Weltyemu wynikało jednak, że chodzi tutaj przede wszystkim o odpowiednie określenie kategorii semantycznej obiektu podlegającego ocenie. Niewątpliwie jest to wiedza faktograficzna, ale z drugiej strony wątpię, by można obyć się bez pewnych inferencji realizowanych na jej podstawie.

Dosyć zabawne było również rozwiązanie problemu ograniczeń czasowych – system generuje bowiem tysiące hipotetycznych odpowiedzi i każda z nich analizowana jest na odrębnej maszynie. Zatem system działa w oparciu o wielotysięczny klaster komputerów. A nad samym systemem pracuje kilkudziesięcioosobowa grupa naukowców z IBMa. Nie dowiedzieliśmy się również, jaka jest jego obecna skuteczność, choć przez przypadek pojawił się taki slajd (którego miało nie być… :] )

W każdym razie system wzbudził duże zainteresowanie i niewątpliwie można się spodziewać, że niedługo zostanie pokazany całemu światu, jako kolejne wielkie dzieło IBMa.

Zestawienie poleceń: Git i SVN

Yehuda Katz opublikował artykuł, w którym pokazuje, jak wygląd jego typowa sesja edycji kodu w kontekście Git-a. Cały artykuł warty jest przeczytania, natomiast tabelka, która pojawia się na końcu zdecydowanie może służyć za ściągę z Gita, dla wcześniejszych użytkowników SVN-a. Pozwalam ją sobie przerysować: