apohllo.pl

Instalacja Rubiego 1.9.3 w Ubuntu

2012-02-16T01:27:36Z

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

2011-06-09T06:21:02Z

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

2011-04-05T09:21:50Z

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.

Możemy je załadować do własnej instancji Virtuoso wykonując następujące kroki:

w pliku konfiguracyjnym zezwalamy na ładowanie plików z katalogu, w którym przechowujemy ściągnięte pliki
ściągamy i uruchamiamy skrypt pozwalający na masowe ładowanie danych
w konsoli Virtuoso wykonujemy polecenie/a ld_dir
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ć.

Kolejny krok polega na wskazaniu katalogu, z którego chcemy załadować dane. Polecenie ld_dir przyjmuje trzy argumenty:

ś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

2010-11-28T09:01:02Z

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

2010-11-19T11:45:13Z

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

2010-11-19T08:58:07Z

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.

Autorzy wymieniają następujące problemy, który pojawiają się, kiedy używamy różnych schematów konceptualnych, a nawet tych samych schematów konceptualnych w różnych źródłach danych:

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

Zasadniczy problem poruszany w artykule dotyczy efektywnego wykonywania zapytań w języku SPARQL obejmujących wiele zbiorów danych. Autorzy zwracają uwagę na dwa aspekty zagadnienia:

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

Dotychczasowe podejście do problemu przedstawione jest na przykładzie dwóch wcześniejszych rozwiązań:

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.

Zajęcia nr 3/2010 WDI

2010-10-21T04:41:35Z

Na zajęciach zapoznamy się z systemem ewidencyjnym PESEL i postaramy się skonstruować kilka algorytmów wydobywających różne informacje zakodowane w numerach PESEL.

Zajęcia nr 2/2010 WDI

2010-10-14T04:46:19Z

Na zajęciach przyjrzymy się kilku prostym algorytmom zapisanym w postaci schematów blokowych:

“Hello world” w postaci blokowej
Jw. wypisane kilkukrotnie
Jw. wypisane kilkukrotnie z użyciem zmiennej
obliczanie silni
obliczanie rozwiązań równania kwadratowego
obliczanie NWD

Zastanowimy się również jak można obliczyć ilość wykonań algorytmu iteracyjnego, zawierającego bloki decyzyjne wewnątrz pętli.

Zajęcia nr 1/2010 WDI

2010-10-07T04:21:54Z

Na zajęciach zostaną przedstawione zagadnienia omawiane w trakcie semestru oraz zostanie wprowadzony pierwszy formalizm służący do zapisu algorytmów – schematy blokowe.

Zestawienie poleceń: Git i SVN

2010-06-05T14:59:44Z

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

Operacja	git	svn
Klonowanie repozytorium	`git clone git://github.com/rails/rails.git`	`svn checkout http://dev.rubyonrails.org/svn/rails/trunk`
Przygotowywanie zmian	`git add, git commit`	brak lub ręczne przygotowanie diff-a
Ściąganie zmian z repozytorium	`git pull --rebase`	`svn up`
Rozstrzyganie konfliktów	`git add, git rebase --continue`	`svn resolve`
Rozstrzyganie konfliktów (bez—rebase)	`git add, git commit`	brak
Wycofywanie zmian (przygotowanych do wysłania)	`git reset --hard`	`svn up -rOLD` potem zaaplikowanie diff-a (jeśli pamiętałeś żeby go zrobić)
Publikowanie do repozytorium	`git push`	`svn commit`