TheTarPit

(rd)ffreak — dialog — odcinek #2: razem czy osobno?

E-mailowej dyskusji ciąg dalszy.

ms:
A tak na marginesie - co Ci przeszkadza osobny plik RDF?

kt:
Gdybym chciał rozdzielić XHTML i RDF, to musiałbym albo równocześnie aktualizować dwa dokumenty, albo zastosować szereg innych technologii, np. XML, XSLT, XHTML, RDF/XML (czy inny..), ewentualnie za pomocą własnego, zapewne dość złożonego i wymagającego ciągłych poprawek arkusza XSLT generować RDF na podstawie HTML (co w swojej ostatecznej formie dałoby praktycznie kolejny (prywatny) standard zagnieżdżania RDF w HTML..).

ms:
Hmmm... a spójrz na zagadnienie globalnie, od innej (właściwszej IMHO) strony: warstwa danych i warstwa prezentacji. W idealnym świecie SW powinno być tak, że dane są przechowywane w postaci grafu RDF na zasadzie analogicznej jak w dzisiejszych bazach danych. To, jak będą one prezentowane, zależy od ich konsumenta — jeżeli będą przetwarzane przez agenta programowego to powinny być mu zaserwowane w postaci strawnej dla niego, np. po serializacji do RDF/XML czy czegoś takiego. Jeżeli natomiast konsumentem danych będzie człowiek (via strona WWW) to powinny one być przedstawione w formie czytelnej dla człowieka, np. jako śliczny XHTML. Oczywiście forma prezentacji jak i zakres danych będą sie różnić — dla agenta: kilka suchych faktów, dla człowieka: pełna ekspresja.

A zatem — czy nie lepiej byłoby podejść od drugiej strony — podstawowe źródło danych to RDF, a HTML to jedynie wizualizacja...? Wtedy mechanizm byłby zupełnie odwrotny do eRDF. I właśnie w przypadku strony tworzonej w celu przedstawienia pewnych danych, czyli takiej jak Twoja wizytówka, wydaje mi się to podejście znacznie lepsze. Przeciwnie jest np. w przypadku wpisów bloga, które z założenia powstają jako tekst przeznaczony dla człowieka...

Przemyśl to — może warto rozdzielić XHTML i RDF, ale wychodząc od drugiej strony...? :-)

kt:
Kiedy decydowałem się na HTML+RDF byłem hura-optymistą — uważałem, że uda mi się skupić dane w jednym miejscu, że nie będą się one musiały powtarzać, że edycja ich będzie banalna (bo to przecież HTML). Uważałem także, że taki standard uczyni mój kod HTML jeszcze bardziej semantycznym (zmuszając do używania rel, opisowych class itd..).

Okazało się natomiast, że:

• dane mimo wszystko będą musiały się powtarzać, bo:
  • eRDF jest sam w sobie mocno ograniczony,
  • atrybut name elementu meta mieści tylko jedną wartość,
  • w sekcji meta nie ma elementów grupujących,
  • dostępne narzędzia służące do ekstrakcji eRDF są jeszcze mocno niedoskonałe (musiałem haczyć kod, co powodowało, że się rozrastał),
• kod HTML stał się stosunkowo nieczytelny, panuje „classitis”, jest sporo niepotrzebnych z semantycznego punktu widzenia id, jego objętość wyraźnie się zwiększyła (taka specyfika strony gdzie treści jest mało),
• oficjalna specyfikacja standardu eRDF nie opisuje wszystkich jego konstrukcji (jedną, bardzo ważną znalazłem dopiero na blogu autora),
• specyfikacje niektórych ontologii, a w szczególności tej, która aspiruje do miana najpowszechniejszej, czyli FOAF nie nadają się do zwyczajnego czytania — je trzeba studiować i to praktycznie w całości (ale pomijając to są całkiem zrozumiałe),
• dane się praktycznie duplikują, kiedy chcemy przygotować alternatywne wersje językowe (bo trzymanie wszystkich w jednym pliku jest nieefektywne na sto sposobów).

RDFa jest jeszcze w stadium, któremu bardzo daleko od produkcyjnego i jeszcze długo w taki nie wejdzie (jeśli w ogóle), a szkoda.

Mikroformaty myślę, że rozwiązują część przedstawionych wyżej problemów, ale niestety są tylko mikroformatami — jest ich ograniczona ilość i same są mocno ograniczone.

Konkluzja: HTML+RDF w żaden sposób nie nadaje się do trzymania wiedzy/danych ;) Dokładnie tak jak pisałeś, ale chyba musiałem sam się o tym przekonać.

Zrobię teraz tak jak radzisz — warstwa danych wyląduje w grafach RDF i z pomocą XSLT będę je transformował do XHTML, czy RDF/XML. Muszę przyznać, że kiedy o myślę o możliwościach jakie to daje i czystości tego rozwiązania, to jestem pod wrażeniem — jest idealne. Z tym, że wymaga to znajomości kilku dodatkowych technologii, dużo dużo rozważań i dużo więcej pracy/programowania, więc to nie ma szans się przebić jako powszechne rozwiązanie (myślę o innych w tym momencie ;))

ms:
Chyba powinno Cię zaniepokoić zastosowanie XSLT ;-) Można tak robić na jednej stronce (np. zerknij tu) ale na poważniejszą skalę to jest mordęga. Nie polecam... Czy nie lepiej użyć jakiegoś „silnika”, który by zaczytał dane RDF (obojętnie czy z pliku czy z bazy) i wypluł Ci je w zadanej postaci...?

Moim zdaniem problem ze stroną, jaką chcesz zrobić, polega na tym, że będzie na niej za dużo danych jak na zastosowanie jakiegoś ręcznego mechanizmu typu XSLT, a za mało na poważny silnik przetwarzający RDF. Dodatkowo zakładam, że Twoje możliwości programowe raczej wykluczają postawienie tam jakiejś poważniejszej aplikacji np. w jakimś frameworku jawowym (typu Jena czy Sesame)...

Stąd jeden wniosek — powinieneś się chyba zainteresować rozwiązaniami ze średniej półki, czyli np. RAP albo ARC. (O RAP pisałem kiedyś.)

CDN...

Komentarze