TheTarPit

RDF PIM — odcinek #2: pozyskiwanie kolejnych danych

Prawdopodobnie eksperyment polegający na stworzeniu bazy wszelakich danych osobistych w postaci modelu RDF (aka RDF PIM) jest interesujący wyłącznie dla mnie. Skoro jednak powiedziało się kiedyś „odcinek #1” to wypada przynajmniej zasygnalizować kolejne numerki... A zatem pozyskiwania danych do bazy RDF PIM ciąg dalszy.

kalendarz

Po przerobieniu na RDF danych kontaktowych pora na kolejny zbiór informacji prywatnych, czyli kalendarz. Wykorzystywane przeze mnie kalendarze (KOrganizer, sporadycznie Mozilla Calendar) umożliwiają eksport danych do formatu iCalendar. Jest to szeroko rozpowszechniony standard (Internet Calendaring and Scheduling Core Object Specification, RFC2445) wspierany przez większość programów do obsługi kalendarzy (choć z drugiej strony jest tak rozbudowany, że wiele programów nie obsługuje go w pełni). Nie dziwne więc, że dawno już pomyślano o wyrażeniu tych danych za pomoca RDF-a. Odpowiednią ontologię opracowano w ramach RDF Calendar Workspace.

Konwersję plików .ics do formatu RDF można wykonać programem analogicznym jak to robiłem w przypadku danych kontaktowych. Format iCalendar (w wersji 1.0 znany jeszcze jako vCalendar) jest zupełnie podobny do formatu vCard i przy założeniu, że program taki nie musi koniecznie działać dla wszelkich możliwych danych tylko dla podzbioru faktycznie występujących przypadków, zadanie to nie powinno być szczególnie trudne.

Albo można skorzystać z dostępnych narzędzi, tym bardziej, że ich odnalezienie okazuje się znacznie łatwiejsze niż w przypadku vCard — konwerter formatu iCalendar do RDF został opracowany w ramach wspomnianego wcześniej RDF Calendar Workspace: fromIcal.py. Program ten, jak większość programów do na potrzeby SW powstających w ramach W3C, jest napisany w pythonie (w przeciwieństwie do moich poprzednich wypocin w ruby) i generuje wynik w RDF/XML (w przeciwieństwie do moich „konwerterów” generujących N3) — jedno i drugie nie ma tak naprawdę większego znaczenia i nie stanowi właściwie żadnej różnicy — ważne aby na wyjściu otrzymać graf RDF w jakiejś poprawnej serializacji... Zatem:

python fromIcal.py --x icalout.ics > kalendarz.rdf

i... tyle. Już mamy kalendarz w formacie nadającym się do praktycznie dowolnej obróbki.

łączenie

Uzyskany plik kalendarz.rdf, tak samo jak otrzymany poprzednio plik kontakty.n3, stanowi sam w sobie dosyć interesujący graf RDF. Skoro jednak buduję model RDF PIM to najlepiej je połączyć w jeden graf — przeszukiwanie kilku grafów (np. przez SPARQL) jest oczywiście możliwe, ale wydaje mi się na tym etapie zupełnie zbędną komplikacją. Tym bardziej, że przy pomocy cwm połączenie grafów w jeden jest jak zawsze banalne:

cwm --rdf kalendarz.rdf --n3 kontakty.n3 --think > pim.n3

drobne uzupełnienia

Podczas dodawania zdarzenia do kalendarza można określić jego organizatora. W praktyce najczęściej tego nie robiłem, więc w wyeksportowanych danych jako organizator figuruje domyślnie lokalny użytkownik — w moim przypadku ma on adres e-mail mimas@gomez. Z punktu widzenia tworzonej bazy RDF PIM jest to jeden z moich adresów. Nie wiem w tej chwili czy ta informacja będzie mi do czegoś rzeczywiście potrzebna, ale jest to pewien fakt i nie ma powodu, żeby go przemilczać. Najłatwiej uzupełnić model dodając ten adres do kontaktu, np. doklejając za pomocą cwm do modelu RDF jeszcze taki pliczek:

@prefix vcard: <http://nwalsh.com/rdf/vCard#> .
@prefix pim: <http://mimas.ceti.pl/pim#> .

pim:mimas vcard:email <mailto:mimas@gomez> .

czy to w ogóle działa?

Wydaje się, że skoro mamy już w jednym grafie RDF kontakty i kalendarz to być może da się zadać jakieś w miarę inteligentne pytanie. Na przykład — skąd pochodzą (w sensie: w jakim mieście mają adres) ludzie, z którymi spotykałem się w tym roku. Dane o spotkaniach powinny być zapisane w kalendarzu, jeżeli wskazałem uczestników spotkania to pewnie mam ich adresy e-mail, jeżeli w książce adresowej programu pocztowego lub w telefonie miałem wpisane ich wizytówki to być może była tam informacja o miejscowości... Zapytanie SPARQL mogłoby wyglądać tak:

PREFIX rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX vcard: <http://nwalsh.com/rdf/vCard#>
PREFIX ical:  <http://www.w3.org/2002/12/cal/icaltzd#>
PREFIX xsd:   <http://www.w3.org/2001/XMLSchema#>

SELECT ?date ?email ?name ?city
WHERE {
 ?e rdf:type ical:Vevent .
 ?e ical:attendee [ ical:calAddress ?email ] .
 ?e ical:dtstart ?date .
 FILTER (?date > "2006-01-01T00:00:00Z"^^xsd:dateTime) .
 OPTIONAL {
  ?v rdf:type vcard:VCard .
  ?v vcard:email ?email .
  OPTIONAL { ?v vcard:fn ?name } .
  OPTIONAL { ?v vcard:adr [ vcard:locality ?city ] }
 }
} ORDER BY ?date ?name

Po uruchomieniu tego zapytania na grafie pim.n3 (w dowolny sposób, do szybkich testów wygodna jest commandline'owa odmiana ARQ) otrzymujemy listę dat tegorocznych spotkań z adresami e-mail uczestników i tam gdzie się dało również nazwą kontaktu i miastem. I faktycznie wygląda na to, że odpowiedź jest zgodna z prawdą (może nie z prawdą obiektywną, ale przynajmniej z prawdą wynikającą z danych w moim telefonie, programie pocztowym i kalendarzach). Uwzględniając:

• ilość pracy włożonej w przygotowania (jednorazowe opracowanie konwerterów) i wykonanie modelu RDF (kilka prostych komend),
• różnorodne pochodzenie danych wejściowych (telefon, książka adresowa program pocztowego, kalendarz, może coś „z ręki”),
• łatwość zadawania skomplikowanych pytań na danych zebranych „do kupy” (zapytania SPARQL na jednym grafie RDF),

uważam, że to całkiem niezły wynik. Przynajmniej jak na początek... :-)

Komentarze