blogへの書き込みは楽しいものです。weblogは、ホーム・ページと個人的な日記を混ぜたようなものですが、人々がWeb上で自分を表現するための手段として最も普及したものとなりました。それに伴って現れてきたのがRSS(何の頭文字かは諸説ありますが・・・。RDF Site Summary か Really Simple Syndication のどちらかでしょう)です。その使い方として最も普及したのがweblogアイテムの配信です(直接デスクトップのRSSリーダーに配信する場合もあれば、BlogdexやMeerkat、Bloglinesなどの集約Webサイトに配信する場合もあります)。
RSSは、Web上の多くの場所に書かれています。不幸にしてRSSに馴染みがないようでしたら、参考文献にあるリンクを見てください。実際このコラムではRedland RDF toolkit の使い方について書いていますが、サンプル・コードはRSS 1.0フィードの基本的なアグリゲータです。
前述したように、RSSフィードの最も一般的な使い方は、パーソナル・アグリゲータとしての使い方です。図1は、この用途で典型的な Straw (参考文献参照)の画面です。どのRSSフィードを購読するかを選択することができ、自分の好みに合ったおあつらえむきの情報が得られるようになる、という利点があります。そして、自分の好みに合ったおあつらえ向きの情報・・・と言うことは、結局のところ選択したもの以外の情報が見えなくなってしまうという欠点もはらんでいるのです!
図1. Strawの画面(GNOMEデスクトップ・プラットフォーム用のパーソナルRSSアグリゲータ)
最近ではオープン・ソースのプロジェクトに取り組んでいる開発者が、ますます自分自身のweblogを持つようになっています。内省的なWeb記事よりも、本来的にコード作成に興味を持っているこうした開発者は、pybloxsomやMovable Typeなどの迅速なblogツールの普及によってblogに引きつけられています。また、しばらくの間多くのフリー・ソフトウェアの開発者が日記システムを持つAdvogato(参考文献参照)を使っていましたが、コンテンツやその表現方法をより細かく制御できるようなシステムが好まれる傾向にあるようです。
あなた自身の活動と関連したプロジェクトに取り組んでいる開発者のジャーナル(日誌)を読むことは、進行状況や設計における判断、時宜などに絶えず注意するための方法として有効です。継続的な会話が確立され、ごく緩やかに結びつけられているにすぎない開発者同士がコミュニティを形成し、お互いに触発し合うようになります。中規模から大規模な組織において、その効果は容易に想像できるでしょう。
ただし、こうしたジャーナルをパーソナル・アグリゲータで追いかけるのは少し行き当たりばったりだと言えるでしょう。RSSアグリゲータに、ある一定の人達しか設定していない場合には、コミュニティへの新規参加者を置いてきぼりにしてしまうかも知れませんし、追従を必要とする他の新しいニュース源を見失ってしまうかも知れません。ですから、それぞれが個別のフィードを探し回るよりも、グループとしてジャーナルにアクセスできた方がずっと良いと言えます。
この結果として、またオープン・ソース・プロジェクトにまつわるコミュニティ意識向上の取り組みの中から、参加している開発者のweblogを集約するWebサイトが現れてきています。その最も初期の例として、Planet GNOMEがあります。この参加者には、Red HatやNovell/Ximian等の企業および、数多くの独立した開発者も含まれていました。これに続くものがMonologueで、これはNovell/XimianのMono実装( .NETランタイムやC#コンパイラ関連・・・参考文献参照)に取り組んでいる開発者のweblogで構成されています。
このような新興のコミュニティ・ジャーナルに触発されて、セマンティックWeb技術を取り扱う、似たようなサイトを作ることを目的に、RDFやセマンティックWeb技術に関する興味を私と共有するような何人かの仲間を連れてきました。読み進める前に、Planet RDF と呼んでいるサイトを確認してみてください。図2はそのWebサイトの画面です。
図2. Planet RDFの画面
驚くにはあたりませんが、Planet RDF は全体を通してXMLとRDF技術を使って作られています。これから先では、アグリゲータのアーキテクチャ、構成ファイルのフォーマット、そして、それらを自分用に設定するための方法について説明します。
こうしたアグリゲータに要求されるものは比較的わずかです。
- 集約したいRSSフィードのリスト
- RSSパーサ
- 参加者のデータ・ベース
- 集約結果を抽出し、フォーマットする手段
驚くべきことに、Web(という環境)とコードを共有しようと言う寛大なる精神のもとで、上に挙げたような構成要素はすでに存在していました。Matt Biddulphは2003年に、別の目的のために早くもRSSアグリゲータを書いていました。既に多くの環境が整っていたので、そのチーム(Matt BiddulphとDave BeckettそれにPhil McCarthy)がサイトを構築して稼働を開始するのに3時間しかかりませんでした。しかもその大部分は、XSLTとCSSをいじることだったのです!ではその構成要素を順に見て行きましょう。
Planet RDFのようなサイトを構築するには、各参加者は次のような情報を提供する必要があります。
- 名前
- weblogのURL
- weblogのRSSフィードのURL
- weblogのタイトル
Dave BeckettによるセマンティックWebのweblog(参考文献参照)のリストをアグリゲータの入力として使い、XSLTを使って変換しようと思います。
weblogのRSSフィードのリスト(一部の間ではblogrollとして知られています)に対するXMLフォーマットは既に存在し、OPML (Outline Processor Markup Language:参考文献参照)と呼ばれています。ただしこのフォーマットで伝えることができるのは、たった一つのタイトルとURLだけなので、ここでの課題にはあまり向いていません。その代わりに、必要とされるメタデータ要素の多くがFOAF (Friend of a Friend)ボキャブラリと共通であることに注目して、リスト1に示すようなフォーマットを作りました。説明を簡単にするために2人の参加者だけを示しています。
リスト1. RSSフィードの情報源リスト
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:rss="http://purl.org/rss/1.0/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<foaf:Group>
<foaf:name>Planet RDF</foaf:name>
<foaf:homepage rdf:resource="http://planetrdf.com/" />
<rdfs:seeAlso rdf:resource="http://planetrdf.com/bloggers.rdf" />
<foaf:member>
<foaf:Person>
<foaf:name>Joe Bloggs</foaf:name>
<foaf:weblog>
<foaf:Document rdf:about="http://foo.com/blog/">
<dc:title>Joe Bloggs' Blog</dc:title>
<rdfs:seeAlso>
<rss:channel rdf:about="http://foo.com/blog/blog.rdf" />
</rdfs:seeAlso>
</foaf:Document>
</foaf:weblog>
</foaf:Person>
</foaf:member>
<foaf:member>
<foaf:Person>
<foaf:name>Frederique Smith</foaf:name>
<foaf:weblog>
<foaf:Document rdf:about="http://bar.com/blog/">
<dc:title>Freddie's Blog</dc:title>
<rdfs:seeAlso>
<rss:channel rdf:about="http://bar.com/blog/blog.rss" />
</rdfs:seeAlso>
</foaf:Document>
</foaf:weblog>
</foaf:Person>
</foaf:member>
</foaf:Group>
</rdf:RDF>
|
XMLで表現されているため、リスト1のRDFも特徴的な冗長性を持っていますが、同時にXPath/XSLTのような通常のXMLツールで容易に処理することもできるのです。グループのメンバーに関する意味のある情報が文書に明示されている事に注意してください。単に昔ながらのURLの寄せ集めではないのです!
今回のシナリオでRDFを使う利点は、他のRDFプロセッサとの下位互換性を失うことなく機能追加による拡張ができるということです(なぜ私がこれを素晴らしいと思うかについては、参考文献にある私のエッセイ「Sticking with it -- RDF」を見てください)。リスト2は、将来の拡張例として考えられるものです。どれも、これまでのバージョン用に書かれたRDF対応ソフトウェアとの互換性を失うことはありません。
リスト2. 情報源リストの拡張方法の例
<foaf:member>
<foaf:Person>
<foaf:name>Joe Bloggs</foaf:name>
<!-- Joe's homepage -->
<foaf:homepage rdf:resource="http://foo.com/~joe/" />
<!-- a picture of Joe, to put by each of his entries -->
<foaf:img rdf:resource="http://foo.com/~joe/me.jpg" />
<foaf:weblog>
<foaf:Document rdf:about="http://foo.com/blog/">
<dc:title>Joe Bloggs' Blog</dc:title>
<rdfs:seeAlso>
<rss:channel rdf:about="http://foo.com/blog/blog.rdf" />
</rdfs:seeAlso>
</foaf:Document>
</foaf:weblog>
<!-- a second weblog, detailing exclusively work activity -->
<foaf:weblog>
<foaf:Document rdf:about="http://foo.com/worklog/">
<dc:title>Joe Bloggs' Work Journal</dc:title>
<rdfs:seeAlso>
<rss:channel rdf:about="http://foo.com/workblog/blog.rdf" />
</rdfs:seeAlso>
</foaf:Document>
</foaf:weblog>
</foaf:Person>
</foaf:member>
|
リスト2では、拡張された機能を太字で表記しています。実際、リスト1に示すフォーマットを処理するように設計されたソフトウェアでは、2番目のweblog項目があることを意識せずに扱うはずです。リスト1のフォーマット用に書かれたRDF対応のソフトウェアは、規定外の homepage や image プロパティを単純に無視します。さらに、要素の順序や重要性に関して何も想定していなければ、まったくRDFを認識しないソフトウェアであっても適切で寛容な方法で書くことができるのです。一般的にこれは、対象とするデータの検索にXPath式が使えるということを意味します。
このblogリストの処理は、Redland RDFツールキット(参考文献参照)を使って簡単に行うことができます。リスト3は、bloginfo.py (参考文献にこのコードへのリンクがあります)にあるFOAFクラスの2つのメソッドを示しています。
リスト3. bloginfo.py のFOAF blogリスト処理コードからの抜粋
from __future__ import generators
from RDF import *
class FOAF:
def __init__(self,url):
self.model = Model()
Parser().parse_into_model(self.model,url)
self.NAME = Node(uri_string="http://xmlns.com/foaf/0.1/name")
self.NICK = Node(uri_string="http://xmlns.com/foaf/0.1/nick")
self.TITLE = Node(uri_string="http://purl.org/dc/elements/1.1/title")
def blogs(self):
statement = Statement(subject=None,
predicate=Node(uri_string="http://xmlns.com/foaf/0.1/weblog"),
object=None)
for i in self.model.find_statements(statement):
yield i.object
|
コンストラクタ__init__ は、blogリストのURLを引数として受け取り、RDFモデルとして構文解析します。リスト中に現れるすべてのweblogを見つけるには、単純にblogs() メソッドを呼ぶだけであり、そしてこれはpredicate(述語)プロパティがfoaf:weblog であるステートメントのすべてのobjectに対して検索を実行します。
Web上では,幅広い種類のRSSパーサが入手可能です。私の記事「RDFデータの起源の追跡」で使ったような・・・非常に厳格なものから、もっと寛容(liberal)なもの(様々なユーザ環境におけるRSSの構文解析に関して言えば、良かれ悪しかれ「寛容」は「実用的」ということです)まで様々なものがあります。目標とするプログラミング言語がPythonだったので、こうした寛容なパーサの中から、ここではMark PilgrimによるFeed Parserを選びました(他にも多数利用可能です。参考文献にその一部を挙げてあります)。リスト4を見ても分かるように使い方は、とても簡単です。
リスト4. Mark PilgrimのRSSパーサでRSSフィードを構文解析する
import rssparser
# etag and modified are set to the values we found when
# we last polled this RSS feed
data = rssparser.parse (rss, etag=etag, modified=modified,
agent='Planet RDF Aggregator 0.1; http://planet.rdfhack.com/')
for item in data['items']:
print item['title']
|
リスト4のparse() 呼出しの結果は、Pythonの辞書形式です。各RSSアイテムは、文字列「items」をキーとした配列に保存されます。リスト4の最後の2行は、各登録内容に対してそのタイトルを出力しながら繰り返されます。
Planet RDFコードの集約(Aggregation)に関する部分は比較的単純です。リストにある各RSSフィードを定期的にポーリングし、RSSアイテムに対する一意なキーを引き出し、それぞれのアイテムに対する変更を保存します。各RSSアイテムに対して一意のキーを引き出すのは少しばかり面倒かも知れませんが、たいていの場合には、RSSファイルのURLおよび、そのアイテムのURLで十分です。こうしておくことによって、フィードの提供者がタイトルやアイテムの記述を編集した場合には、その変更が反映されるのです。残念ながらURLに間違いがある場合には、アグリゲータが新しいアイテムであると判断し、誤ったアイテムを同じように保存するでしょう。これを防ぐための方策として、RSSアイテムに不変の識別子を割り当てる仕組みが必要ですが、特に広範囲にわたって引き受けてくれるところは何処にもありません。
コードを見れば集約がどのように行われているかを理解することができるでしょう(参考文献参照)。XMLのファンにとってより興味があるのは、最終的なWebページがどのように作られるかという点でしょう。アグリゲータの出力は、実のところ(Mark Nottinghamによって書かれた)RSS.pyが作るRSSファイルそのものです。このRSSファイルには、参加者のweblogから時系列の逆順で最も新しいアイテムを含んでいます。HTML出力を得るには、XSLTでスタイル化します。既製のRSSファイルを生成できるという利点があるので、ユーザのパーソナルRSSリーダーに集約されたweblogを追加できるのです。
さらに調査してみたいのであれば、参考文献にあるリンクからソフトウェアをダウンロードして試してみてください。そのためには、Python 2.2(あるいはそれ以降)が必要で、さらにRedland RDFフレームワークがインストールされている必要があります(参考文献参照)。ソースファイルをダウンロードし、リスト1のような bloggers.rdf ファイルを作ります。このファイルをテストするには、bloginfo.py の__main__ 部分を自分のRDFファイルを指すように修正してからpython bloginfo.py を実行します。
次にアグリゲータ(chumpologica.py)の main を修正して、手書きで先頭にある出力とデータのディレクトリを、自分が使おうとするものに設定する必要があります。それが終われば、単にpython chumpologica.py bloggers.rdf を実行するだけです。そうするとアグリゲータが実行され、RDFファイルを指定したディレクトリにきちんと格納してくれます(これはRSS 1.0のファイルとなります)。XSLTを使って、もっときれいな表示形式にすることもできます。
Planet GNOMEアグリゲータからもよく分かるように、weblog項目全体を含むことで出力はもっと魅力的なものになります。慣習的にこれには、本体をdescriptionフィールド内に含む(HTMLにおける実体の別扱いを伴うような)RSSの不正利用が行われています。これがなぜ不都合なのかは、Norm Walshが指摘しています(参考文献参照)。RSS 1.0には、これに対処するためにcontent:encoded (参考文献参照)と呼ばれる機構があって、多少改善されています。Planet RDFコードは、content:encoded が出てくるとそれを解釈し、別扱いのHTMLを取り除くことで不正利用されたrss:description プロパティをきれいに整えます。このHTMLはその代わりにRSS 1.0集約ファイルのcontent:encoded プロパティに移動されます。素晴らしいHTML Tidy ツール(参考文献参照)を使うことで、HTMLは可能な限り補修され、最終的なXHTML 1.0出力が生成されます。
ただし、一人の作業で直接にではなく、提供されているweblogをどう処理するかに関しては問題も残っています。例えば・・・。
- 組織または暫定的なグループが生成したフィード
- バグ追跡システムのように、人を介さない手段で生成されたフィード
Planet方式のアグリゲータが増えるに従って(これを書いている間にもPlanets ApacheとSuSEの開発が活発に行われています)、集約サイトを作るためのソフトウェアの種類も増えています。そうしたサイトの構築用に現在のところ、MonologueとPlanet GNOMEそれにPlanet RDFを起源とした、少なくとも3つのコードベースがあります。こうしたコードベースのそれぞれが、少なくともリスト1のRDF blogリストのような構成ファイルを基にして相互運用できるようになっていれば好都合でしょう。さらに、各planet(惑星)を記述する方法として、より高度なものが望まれます・・・おそらくスーパー・アグリゲータ(プラネタリウムとでも呼びましょうか)ができると良いかもしれません。(実際Planet GNOMEを作ったJeff Waughが最近「planetplanet.org」を登録していますので、注目してみてください)。
皆さんのためにコードをリスト5 に置いておきます。これは複数のplanetを記述する方法の提案です。プロセッサは。seeAlso リンクをたどって各planetの提供者リストを検索します。RDF/XMLを使うように選択されている場合には、スーパー構成ファイルを作るのもRDF blogリストを集計するのと同じくらい簡単です。
- Harvard Law Schoolのweblogページを読んでみてください。ここには Donna Wentworth's definition of weblogs があります。この定義によると、weblogは「リンク、コメント、その他に関して頻繁に更新され、新しい項目が上に、古いものは順に下になる」Webサイトです。
- weblogを読む手段として人気のパーソナル・アグリゲータについてさらに調べてみてください。一例としてMac OS X用のNetNewsWire、Windows .NET用のSharpReader、Unix GNOMEデスクトップ用のStrawなどがあります。
- オープン・ソースの開発活動を集約したサイトにはMonologueや、Planet GNOMEそれにPlanet Debianなどがあります。
-
OPML (Outline Processor Markup Language)について調べてみてください。OPMLはRSSフィードのリストを扱うのに適した、階層的なアウトライン文書のフォーマットです。
-
Planet RDFサイトを作ったチームに言及しておくべきでしょう。Matt Biddulphはアグリゲータのコードを担当し、Dave BeckettはRDFブロガー(bloggers)のリストを管理してRedland RDFフレームワークを構築し、またPhil McCarthyは設計作業を担当しました。
- Dave Beckettによる「Semantic weblogs」のリストを見てください。これはアグリゲータの情報源として使われており、またXSLTスタイルシートによってXHTMLからRDFに変換されています。
- 多くのソフトウェア開発者が、日記システムを持つAdvogatoblogツールを使っていました。
-
FOAF (Friend-of-a-Friend) をよく見てください。これは人や、人と人との結びつきの記述を作成したり、活用したりできるように機械で読み取り可能なホーム・ページの構築をねらったRDFボキャブラリです。またEdd Dumbilの初期のdeveloperWorksコラム「XMLとRDFによる友達の検索」(2002年6月)と「FOAFによるオンライン・コミュニティーのサポート」(2002年8月)を見てください。
- Mark PilgrimによるFeed Parserは、個々のユーザ環境に見られるような少し変わったRSSの構文を解析するのに使われます。またMark NottinghamによるRSS.py は、RSSフィードを保存するクラスとしてうまく書かれています。
- 「Sticking with it -- RDF」を読んでみてください。これはXMLボキャブラリを表現する上でのRDFの利点を説明したエッセイです。
-
Redland RDF toolkit をダウンロードしてください。このツール・キットには、RDFの処理に簡単に使えるPythonモジュール(Planet RDFの構築に使われました)が入っています。Redlandツール・キットはdeveloperWorksの記事「RDFデータの起源の追跡」(2003年7月)でも使われています。
- Planet RDFのソースコードは「chumpologica」としても知られており、Matt Biddulph's Web site から入手することができます。
-
RSS 1.0 content module では、
content:encodedタグを規定していますが、このタグを使えばRSSでdescriptionタグに負荷をかけすぎるような弊害を回避できます。 - Norm WalshによるXML.comの記事「Escaped Markup Considered Harmful」で、なぜHTMLの別扱いの特殊文字(<![CDATA[~~]]> など・・・)をXMLに含んでやり取りするのが良くないのかについて、情報を得てください。
- あなたが受け取るHTMLマークアップに関しては寛容に、でも出力する(X)HTMLに関しては厳しくありたいのであれば、HTML Tidy がそのためのツールとして最適です。
- James Lewinによる記事「RSS 2.0によるコンテンツ配信」(developerWorks, 2003年12月)で、この重要なフォーマットをより良く理解してください。
- developerWorksのXMLゾーン には、XMLに関するさらに多くの記事があります。
- Edd Dumbill's の、「XML ウォッチ」シリーズの記事 をご覧下さい。
- Safari Books Online には、XML関係の書籍が豊富に取り揃えられていますので、ご覧下さい。
- IBMのDB2データベースでは、リレーショナル・データベース・ストレージだけでなく、XMLとリレーショナル・システム間のブリッジを提供するDB2 XML Extender のようなXMLに関連するツールも提供しています。DB2に関してより深く学習するために、Information Managementを見てください。
- XMLおよび関連技術においてIBM認証開発者になる方法を参照してください。
Edd Dumbill氏はXML.com の編集長であり、XMLデベロッパーのためのニュース・サイトXMLhack の編集者兼発行者でもあります。Programming Web Services with XML-RPC (O'Reilly) の著者の1人であり、生命科学の知的財産を交換するPharmalicensing の共同設立者兼アドバイザーです。EddはXML Europe コンファレンスのプログラム司会者でもあります。