TheTarPit

Co w RDF-ie powinno być wypisane?

Pewien facet, którego wcale nie znam, i który podpisuje się jako Marcin W. Dąbrowski, napisał w komentarzu do jednego z poprzednich wpisów:

Tylko mnie jedno dręczy - co w RDF-ie powinno być wypisane? Jakie informacje są najważniejsze? Bo chyba bez sensu wrzucać wszystko, co się da - od tego są ontologie i wnioskowanie, żeby agenci sami sobie to wyciągnęli...

Racja, święte słowa — po to są, żeby sobie sami... Jednak problem nie jest taki prosty jak by można z pozoru sądzić...

Szczegółowość grafu RDF z pewnością jest ściśle powiązana z typem opisywanych przez niego zasobów i z celu, w jakim ten opis powstaje. Jednak w przeciwieństwie do baz danych lub klas w modelach obiektowych, zestaw cech zasobu opisywanego w RDF nie jest sztywno określony. Nie można powiedzieć, że RDF stanowiący opis jakiegoś zasobu musi posiadać określone wyrażenia; można co najwyżej wywnioskować, że bez pewnych danych opis jest postrzegany jako niepełny czy wręcz pozbawiony sensu. Oczywiście do takiego wniosku może dojść tylko człowiek i tłumaczenie „bo inaczej jest niedopowiedzenie” zupełnie nie przemówi do agenta Sieci Semantycznej.

w poszukiwaniu przykładów

Chyba najbardziej dzisiaj rozpowszechnione ontologie/słowniki (oprócz RSS (1.0), który jest już tak przemaglowany, że sobie pozwolę odpuścić) to wynik projektów DC, FOAF i DOAP, co widać po wszędobylskich i powszechnie rozpoznawanych przestrzeniach nazw:

@prefix  dc:    http://purl.org/dc/elements/1.1/
@prefix  foaf:  http://xmlns.com/foaf/0.1/
@prefix  doap:  http://usefulinc.com/ns/doap#

Dublin Core Metadata Element Set (aka DC) jest na tyle popularny, że większość użytkowników (wstawiających najróżniejsze <dc:cośtam> we wszelakie feedy lub <meta name="DC.cośtam" ...> w nagłówki stron) w ogóle nie kojarzy przestrzeni nazw http://purl.org/dc/elements/1.1/ z Siecią Semantyczną. A przecież pod tym adresem znajdujemy po prostu kawałek RDF-a. Powszechny brak skojarzenia DC z RDF wynika chyba z tego, że zupełnie nie funkcjonuje tutaj założenie jakiegokolwiek konkretnego kontekstu (DC ma być używane gdziekolwiek, nie tylko w danych dla agentów SW) ani problem kompletności czy wymagalności. Trudno zatem mówić ile należy powiedzieć o dokumencie, który się opisuje za pomocą słownika DC, ponieważ każdy to robi inaczej...

Znacznie porządniej wygląda sytuacja w przypadku ontologii DOAP. Opis projektu jest zazwyczaj podobny — każdy ma nazwę, stronę, daty, wersje, repozytorium kodu itd. Chyba jedyny powód, żeby w opisie projektu nie uwzględniać jakiegoś elementu, to taki, że element ten w danym projekcie faktycznie nie występuje. A wtedy brak tej informacji również jest jakąś charakterystyką.

Natomiast FOAF niejako ze swej natury jest najbardziej zróżnicowanym, niejednorodnym i rozproszonym zbiorem danych RDF jaki jest aktualnie dostępny w Sieci — dane „o mnie i kogo znam” z zasady są mało kompletne, niekoniecznie aktualizowane a równocześnie odwołujące się do mnóstwa innych zasobów (ludzie, strony, blogi, publikacje, ...). I faktycznie przeglądając różne pliki FOAF publikowane w Sieci można znaleźć całą gamę najróżniejszych podejść — od skrótowych, wręcz minimalistycznych („nazywam się i mam stronę”), do rozbudowanych ze wskazaniem wszystkich krewnych i znajomych królika. Idealnie nieidealne środowisko do badań. ;-)

DRY?

Z pewnością nie ma sensu powielać w różnych miejscach tej samej informacji — zasada DRY obowiązuje nie tylko pragmatycznych programistów, ale pragmatycznych autorów RDF również jak najbardziej. Jeżeli wiemy, że gdzieś istnieje plik RDF opisujący ten sam zasób, to (mimo że idea open world nie zabrania nam powielenia tej informacji) lepiej jest użyć rdfs:seeAlso (jeżeli wskazywane źródło traktujemy jako dodatkowy, równorzędny lub uzupełniający opis) lub bardziej specyficznie rdfs:isDefinedBy (jeżeli wskazywane źródło jest autorytatywnym opisem definiującym dany zasób). Zatem we wspomnianym przez Marcina przykładzie opisu widowiska tanecznego umieszczenie odnośników do plików FOAF zaangażowanych osób byłoby jak najbardziej na miejscu; opisywanie ich w tym samym pliku już raczej nie. I to wydaje się intuicyjnie oczywiste.

Niestety również przy tak prostym przykładzie jak FOAF zasada DRY jest nagminnie łamana — bardzo często spotykam się z taką sytuacją, że oprócz wskazania na plik FOAF podaje się jakieś informacje opisujące, np.:

<foaf:knows>
  <foaf:Person>
    <foaf:nick>MiMaS</foaf:nick>
    <foaf:mbox_sha1sum>99c1a86ed2ccf30320ccfc943f89e27f7b0d24d2</foaf:mbox_sha1sum>
    <rdfs:seeAlso rdf:resource="http://mimas.ceti.pl/pub/mimas.rdf"/>
  </foaf:Person>
</foaf:knows>

Podanie pewnych danych identyfikacyjnych osoby, którą wskazujemy w FOAF jako znaną, jest dosyć oczywiste — zamiast mówić „znam kogoś, a więcej o nim dowiesz się pod podanym adresem” mówimy raczej „znam mimasa, a kto to nosi taki kretyński pseudonim dowiesz się pod podanym adresem”. Czyli informacja teoretycznie nadmiarowa jest wręcz konieczna dla zachowania pewnej minimalnej kompletności danych.

Ciekawsze znaczenie ma tutaj wartość foaf:mbox_sha1sum. Służy ona w praktyce (bez żadnych podstaw teoretycznych!) jako klucz, po którym można wykonać w miarę bezpieczne łączenie grafów RDF; po prostu żaden inny atrybut w foaf:Person się do tego nie nadaje...

to w końcu jak ma być?

Moja rada (którą możesz zapamiętać, cytować, powiesić sobie nad łóżkiem czy gdzie tylko chcesz, tam również) brzmi: rób jak uważasz. ;-)

Komentarze

Brak komentarzy do tego wpisu.