このシリーズの過去3回の記事では、オープン・ソース・プロジェクトや関連リソースを記述するためのXML/RDFボキャブラリ、DOAP（Description of a Project）の開発について解説してきました。DOAPを使うことによって、ソフトウェア維持管理者は、複数のWebサイトにプログラムを登録する必要がなくなります。代わりに、DOAP記述のURLを与えればよいのです。より多くのアプリケーションがDOAP対応になれば、オープン・ソース・プロジェクトへの参加と管理に、新しい可能性が生まれてきます。

こうしたゴールに達するために、単にボキャブラリを作る以上のことをする必要があります。最後となる今回の記事では、DOAPが採用されるために必要となるものを、ドキュメンテーションやツール、コミュニティといった面から見て行きます。

DOAPを見る

思い出して頂くために、単純なDOAPファイルを下記に挙げます。リスト1は、DOAPプロジェクト自体に対する最小限のDOAPファイルを示しています。

                
<Project xmlns="http://usefulinc.com/ns/doap#"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:foaf="http://xmlns.com/foaf/0.1/">
    <name>DOAP</name>
    <homepage rdf:resource="http://usefulinc.com/doap" />
    <created>2004-05-04</created>
    <shortdesc xml:lang="en">
        Tools and vocabulary for describing community-based
        software projects.
    </shortdesc>
    <description xml:lang="en">
        DOAP (Description of a Project) is an RDF vocabulary and
        associated set of tools for describing community-based software
        projects.  It is intended to be an interchange vocabulary for
        software directory sites, and to allow the decentralized
        expression of involvement in a project.
    </description>
    <maintainer>
        <foaf:Person>
            <foaf:name>Edd Dumbill</foaf:name>
            <foaf:homepage rdf:resource="http://usefulinc.com/edd" />
        </foaf:Person>
    </maintainer>
</Project>

DOAPユーザにとって第一の要求事項、そして最も基本的な要求事項は、このデータに対する、ユーザに分かりやすいビューを取得することです。他に何も編集機構が存在しなければ、皆さんは手動でファイルを編集し、ビューアを使ってファイルをチェックします。多くのWebページは、この昔ながらの、そして問題の多い方法によって作られています。ビューアを作るために恐らく一番手っ取り早いのは、XSLTスタイルシートを書き、入力されるRDF/XMLをHTMLに変換してしまうことでしょう。

ところが、DOAPは単なるXMLボキャブラリ以上のものです。つまり、XSLTを使う、と単純に決めるわけには行きません。ビューアの目的は一つではありません。ビューアはDOAPデータのビューを提供するだけではなく、DOAP処理アプリケーションの最初の例でもあるのです。従って、初めてDOAPに来る実装者達は、これを一例として捉えます。ですから、DOAPビューアがRDF対応のアプリケーションであれば便利なのです。

私はビューアを作るために、Redland RDFアプリケーション・ライブラリを使ってDOAPファイルをメモリ内RDFストアに読み込み、ストアからXMLへとデータを抽出し、それを今度はXSLTでフォーマットしています。この中間的XML表現は、サーバ側アプリケーションでのHTMLに変換されるか、あるいはクライアント側のDOAPビューアに対するGUI（graphical user interface）を駆動するために使われます。図1は、ビューアからの、変換されたHTML出力を示しています。

私はビューアを作るために、RedlandのMono/.NETバインディングを使いました（参考文献）。リスト2のコード断片はループを示しています。このループでDOAPファイルの中のプロジェクト（通常は一つだけです）を一つ一つ処理し、<project>要素内にあるデータをXML文書に出力します。rdf ["type"] 変数とdoap ["Project"] 変数は、RDFスキーマとDOAPスキーマでの用語に対応したURIを持つリソース・ノードへのショートカットです。

                
foreach (Node proj in model.GetSources (rdf ["type"], doap ["Project"])) {
    w.WriteStartElement (null, "project", null);
    Node name = model.GetTarget (proj, doap ["name"]);
    w.WriteStartElement ("name");
    w.WriteString (name.Literal);
    w.WriteEndElement ();
    ...
    w.WriteEndElement ();
}

DOAPビューアを書く上で、もう一つ面白い選択肢としては、Mozilla Webブラウザ内部にあるRDFレンダリング・サポートを使って、XULベースのDOAPビューアを作る方法です。これは、Firefoxのようなブラウザを拡張する上で、魅力的なシナリオにつながる可能性があります。

上に戻る

DOAPを妥当性検証する

DOAPファイルを処理する上で、DOAPファイルを妥当性検証できる機能は必須です。妥当性検証は、DOAPを作る上にも、使う上にも有用なものです。作る人にとっては、手動でDOAPを書くにしろ、DOAPを出力するツールを作るにしろ、仕様に合致しているかどうかをバリデータが示してくれます。一方DOAPを使う人にとっては、ソフトウェアがゴミを処理してしまわないためにも、妥当性検証が必要です。

非常に基本的に言えば、妥当性検証というのは、入力ファイルが仕様に適合しているかどうかを、単純に「イエス」「ノー」でレポートすることです。もっと便利なバリデータであれば、エラーや推奨事項をレポートします。そうしたものの中で、最もよく知られているのが、W3C HTML Validator（参考文献）でしょう。これは、WebページのW3C仕様適合性をより改善するための、あらゆる種類の情報を返してくれます。

DOAPはRDF/XMLなので、様々なレベルで妥当性を検証することができます。

• XML: DOAPは整形式のXMLでなければならない
• RDF: DOAPは有効なRDFでなければならない
• 意味体系: 文書は、意味をなすために充分なだけのDOAP用語を含む必要がある。例えば、名前や記述、ホームページ・プロパティ等がなければ、DOAPファイルはほとんど役に立ちません。

伝統的に、純粋なXML妥当性検証手法では、構文的な妥当性検証、つまり要素や属性の有無、その順序に関する検証までしか行いません。これでも多くのエラーを捉えられますが、構文的には有効であっても意味不明な書き方をされたものを判定するためにデータ処理が必要なシナリオでは、役に立ちません。しかし、ある種の意味体系制約は、構文的制約として表現することもできます。例えば、DOAPの要求事項の一つとして「homepage」プロパティが必要なので、これらはXMLスキーマを使って捉えることができます。

RDFの妥当性検証にXMLスキーマを使う上で問題となるのは、RDFが非常に柔軟なXML構文を持っており、同じことを書くのに複数の方法がある、という点です。実際、W3C XML SchemaでRDFを妥当性検証することは不可能です。RDF妥当性をチェックするためには、単純に、例えばRedlandのraptorなどのRDFパーサを通した方が簡単です。入力されるDOAPファイルが有効なRDFであることがいったん分かれば、一連の構文テストを適用して、そのファイルの残り部分の品質を判定することができます。

誰もがRDF処理ツールを利用できる限り、あるいはDOAPを妥当性検証するための無料Webサービスを提供したいのであれば、この戦略は有効です。しかし、妥当性検証プロセスの最初の70%を達成するXMLスキーマを提供し、一定レベルの意味体系整合性を検証できる構文的方法をこのスキーマで使うのであれば、RDFの構文柔軟性は幾らか犠牲にしますが、より普遍的を高めることができます。これにちょっとした常識を加味すれば、大部分の人には十分でしょう。

私はこのあたりを考慮しながら、DOAPに関する、制限付きRDF/XML構文用のRELAX NGスキーマを作りました。このスキーマは全てのDOAPファイルは妥当性検証しませんが、実際に妥当性検証するDOAPファイルは、DOAPとしてアプリケーションで処理できることが保証されていることに注意してください。リスト3は、このスキーマをRELAX NG Compact表記で表したものです。

                
default namespace = "http://usefulinc.com/ns/doap#"
namespace foaf = "http://xmlns.com/foaf/0.1/"
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
namespace rdfs = "http://www.w3.org/2000/01/rdf-schema#"
grammar {
rdf-resource = attribute rdf:resource { text }
xml-lang = attribute xml:lang { text }
literal = xml-lang?, text
Person-element = element foaf:Person {
            element foaf:name { literal }
            & (
                element foaf:homepage { rdf-resource } |
                element foaf:mbox { rdf-resource } |
                element foaf:mbox_sha1sum { text }
            )+&
            element rdfs:seeAlso { rdf-resource}*
        }
cvs-repository = element CVSRepository {
            element anon-root { text },
            element module { text },
            element browse { rdf-resource}?
        }
svn-repository = element SVNRepository {
            element location { rdf-resource },
            element browse { rdf-resource}?
        }
bk-repository = element BKRepository {
            element location { rdf-resource },
            element module { text },
            element browse { rdf-resource}?
            }
arch-repository = element ArchRepository {
            element location { rdf-resource },
            element module { text },
            element browse { rdf-resource}?
            }
start = element Project
{
    element name { literal }&
    element homepage { rdf-resource }&
    element old-homepage { rdf-resource }*&
    element created { text }&
    element shortdesc { literal }+&
    element description { literal }+&
    element mailing-list { rdf-resource }*&
    element maintainer { Person-element }+&
    element developer { Person-element }*&
    element documenter { Person-element }*&
    element translator { Person-element }*&
    element tester { Person-element }*&
    element helper { Person-element }*&
    element category { rdf-resource }*&
    element release {
        element Version {
            element name { text },
            element created { text },
            element revision { text }
        }
    }*&
    element license { rdf-resource }*&
    element download-page { rdf-resource }?&
    element download-mirror { rdf-resource }*&
    element repository { ( cvs-repository | svn-repository
        | bk-repository | arch-repository ) }*&
    element bug-database { rdf-resource }?&
    element screenshots { rdf-resource }*&
    element wiki { rdf-resource }*&
    element programming-language { text }*&
    element os { text }*
}
}

このスキーマを作る中からの派生物として、XML編集ツールが、いまや有効なDOAPファイルを書くために使えるのです。図2は、James ClarkによるEmacsテキスト・エディタ用のnxmlモードが、DOAP自体のDOAP記述を編集するために使われているところを示しています。nxmlモードは、RELAX NG Compactスキーマを使っています。妥当性検証エラーによって下線が引かれていることに注意してください。手動オーサリングのレベルでは、構文の表現力を失うことと引き換えに編集ツールのサポートが得られるのですが、それだけの価値があると言えるでしょう。

スキーマと妥当性検証を併せて使うと、XML整形式性と、一定レベルの意味体系整合性の両方が保証されます。しかし、これでも充分ではなく、妥当性検証の残りのステップを実行するためにはRDF処理に訴える必要があります。そうしたステップには、（DOAPツールがライセンスURIを認識するかどうかを調べるために）与えられるライセンスURIをチェックしたり、必要な部分ではテキストのスペル・チェックをしたりすることなども含まれます。

私はこうしたことを念頭に、ビューア・アプリケーションと同じような形でXMLを出力するバリデータを作り始めました。こうすると、バリデータ・コードを、Web側のGUIアプリケーションとクライアント側のGUIアプリケーションの両方で使えるようになります。このバリデータは4つのレベルのチェックを行います。

• XML整形式性
• RELAX NG Schemaに対する妥当性（オプションで使用不可にできます）
• RDF妥当性
• 一連の、DOAP特有の意味体系チェック

リスト4は、このバリデータを使ってXML整形式性と構文妥当性検証エラーを捉える、2つの実行例を示しています。これから分かるように、<Test>要素からのテスト名が、もっと進んで、より詳細な説明や推奨事項を指すためのインデックスとして使えるのです。

                
<Problems>
<Problem>
<Test>ParseXML</Test>
<Title>Not well-formed XML</Title>
<Description>DOAP files must follow the rules of XML syntax.</Description>
<Detail>unmatched closing element: expected name but found Project Line
27, position 10.</Detail>
</Problem>
</Problems>
<Problems>
<Problem>
<Test>Doap.Tests.Xml.RelaxValidate</Test>
<Title>XML syntax validation</Title>
<Description>This test checks to see that the DOAP file validates against
a restricted XML syntax, which guarantees its validity.</Description>
<Detail>Invalid start tag found. LocalName = Person, NS = 
http://xmlns.com/foaf/0.1/.  line 26, column 3</Detail>
</Problem>
</Problems>

このバリデータのコードは、DOAPのホームページ（参考文献）から入手することができます。このバリデータのパブリック・アクセス・インスタンスが、Webに設定される予定です。DOAPの採用を考えている人達にとって、自分たちの出力を早い段階でチェックできるということは重要です。さらに、DOAPコンテンツの品質として想定できる最低限を設定するために、どのDOAP処理アプリケーションも、その入力を、（少なくともRELAX NGスキーマで）まず妥当性検証するようにお勧めします。RSSフィードに対する、いい加減な構文解析によって引き起こされるWeb上の混乱を少しでも見れば、一定レベルの厳しさがあった方が良いことに納得できるでしょう。その一助とするために、また余計な心配をせず他のプログラムと統合できるようにという配慮から、バリデータとビューアのコードには、寛容なオープン・ソース・ライセンスが与えられます。

上に戻る

DOAPを作る

そもそもDOAPファイルはどのように作るのでしょう。最初にDOAPを採用する人は、テキスト・エディタを使って手で書きます。バリデータとXMLスキーマ・ファイルを組み合わせて使うことによって、そうしたファイルにエラーが含まれないようにすることができます。先に書いた通り、XMLスキーマに準拠するDOAPファイルはRDFの持つ表現力を一部失いますが、ほとんどの人にとっては、この損失は問題にならないはずです。

DOAPファイルを作る人の大部分は、DOAPボキャブラリ自体には興味がないでしょう。その人達が必要とするのは、単に結果としての機能性、つまりソフトウェア・レジストリでプロジェクトを登録できることだけです。恐らく彼らはサンプル・ファイルを少し細工して、自分たちのデータを含めるようにするでしょう。ですから、悪いサンプルが拡散しないように、充分な指導資料、良いサンプル、妥当性検証ツールなどが利用できるようにしておくことが重要です。低品質なカット・アンド・ペーストによるでっち上げが一度解き放たれてしまうと、ほとんど止めようがありません。

DOAPを作るプロセスの中で、カット・アンド・ペーストのフェーズは最小限にとどめるべきです。そのためには、何らかのレベルのツール・サポートを、早めにDOAPファイル作成用に用意しておく必要があります。ほとんどのソフトウェア開発者は、パッケージやコンフィギュレーション用に何らかのシステムを既に使っており、そうしたシステムには、彼らのソフトウェアに対するDOAPファイルを生成するために必要なメタデータが、少しは含まれているものです。そうしたシステムとしては、Cプログラミング用のGNUAutoconfや、Pythonのdistutils、PerlのMakeMakerファイルなどがあります。手軽にDOAPを生成できるソリューションが、開発者が選んだシステムの上で利用できれば、正しいDOAPファイルが作られる可能性が大幅に高くなります。

この他にも、DOAPファイルを作るために様々なガイド手法を利用することができます。

• DOAP-a-matic: Leigh DoddsによるFOAF-a-maticは、JavaScript対応のWebページであり、これを利用すると、FOAF（Friend-of-a-friend）ファイルを簡単に作ることができます。これのDOAP版も便利です。開発者がすべきことは、幾つかの質問に答えることだけです。
• Freshmeat-to-DOAP変換: Freshmeatソフトウェア・レジストリは恐らく、手近にあるものの中で最大のものであり、その内容をXMLエクスポートすることができます。Freshmeatの内容からDOAP記述を生成するプログラムを書くのは、比較的単純なはずです。
• GUIアプリケーション: グラフィカル・アプリケーションは、DOAPに必要なメタデータをプロジェクトのビルド情報と共に保存することによって、EclipseやMonoDevelopなどのIDEの中に統合することができます。そうするとDOAPファイルは、結果として作られるビルドの一部となります。

DOAPをどのように作るにせよ、2つ重要なゴールは、開発者にとって可能な限り使いやすいものであること、そしてDOAPが作る出力が、できるだけ表現力豊富で高品質であることです。手軽に使えること、使用できるデータの品質が高いことは、共にDOAPの今後にとっての鍵と言うことができます。

上に戻る

コミュニティ

ツールが用意できたとしても、DOAPプロジェクトに集まるコミュニティがなければ、長くは続きません。新しい技術を導入する時には、コミュニケーションが何よりも重要です。プロジェクトの目的だけでなく、参加のルールも明確に表現されていることが重要です。コミュニケーションにおける最も基本的なステップは、必要なドキュメンテーションが用意された、プロジェクトに関心を持つ人達が使用できる資料へのリンクを含んだWebサイトを構築することです。

図3は、DOAPホームページのスクリーンショットを示しています。2つの重要要素、明確なナビゲーションとニュースに注意してください。静的なWebサイトはしばしば、技術が停滞しているという印象を与えますが、定期的に更新されるニュースを表示することによって、人々に新しいことを知らせる目的と、プロジェクトが生きていることを知らせるという、2つの目的を果たすことができます。プロジェクト・ニュースに対してRSSフィードを使うことも、最近では必須になっています。

考えられる質問のすべてに対して、最初からすべて答える必要はありませんが、プロジェクトのWebサイトは、できるだけ早くドキュメンテーションやチュートリアルを追加して、応答性の良いものになっている必要があります。新たに採用する人達が最初に見るところは、ほとんどの場合、ハウ・ツーやFAQです。

しかし、コミュニケーションはすべて一方通行なのではありません。DOAPを使ったり採用したりすることに関心を持つ人達が出会い、質問ができるようなフォーラムが必要です。そのための媒体として、オープン・ソース・プロジェクトでは、メーリング・リストが最も成功しています。DOAPにも、もちろんメーリング・リストがあります（参考文献）。コミュニティが成長するにつれ、DOAPを使うサード・パーティが製品や成果をここで発表することができ、それが採用に拍車をかけ、さらなる発展を図ることができます。

最後に、プロジェクトは、関心を持ちそうな人達に宣伝することによって大きくなって行く必要があります。私はXML関係の会議でDOAPを紹介するだけでなく、様々なメーリング・リストに対して、またオープン・ソースの世界で鍵となる人達にも宣伝して行くつもりです。

上に戻る

まとめ

この記事はDOAP作成に関する4回シリーズの最後ですが、私以外の外部の人にとっては、これがプロジェクトの生命の始まりでもあります。セマンティックWeb技術の力を利用することと、幅広いサポートを得るのに充分なだけ「Web的」であり続けること、という2つに対して、DOAPは非常に適切な妥協を図っていると思います。こうした判断が中長期的にどのような結果を生んだかを見るために、何ヶ月か先に再度このコラムで、このプロジェクトについて触れたいと思っています。

参考文献

• このシリーズについて、これまでdeveloperWorksに掲載された記事を読んでください。DOAPボキャブラリ開発について、この記事より前の段階について説明しています。
  • 第1回（2004年2月）
  • 第2回（2004年3月）
  • 第3回（2004年6月）
  
  
  
• DOAP用のビューアとバリデータを書くために使用したRedland RDF Application Frameworkについて学んで下さい。
  
  
• 皆さんのマークアップをW3CのHTML Validatorで妥当性検証してください。これはWeb妥当性検証サービスに関する標準として、最高のものです。
  
  
• RELAX NGを詳しく調べてください。David MertzがdeveloperWorksで、このXMLスキーマ言語に関する3回シリーズの記事を書いています。
  • 第1回（2003年2月）
  • 第2回（2003年3月）
  • 第3回（2003年5月）
  
  
  
• Emacs用の、James ClarkによるnXMLモード機能に関するレポート (US)を読んでください。これは彼の、Thai Open Sourceサイトからダウンロードすることができます。
  
  
• JavaScriptを使ってFOAF (Friend-of-a-Friend)ファイルを作るためのツールとして、Leigh Doddsによる、FOAF-a-Maticを調べてください。
  
  
• DOAPサポートを追加する場所として、Eclipse IDEは理想的です。
  
  
• DOAP home pageを見てください。このプロジェクトに関するニュースや、新たに作られたDOAP mailing listを含めて、参考となる資料へのリンクが用意されています。
  
  
• developerWorksのXMLゾーン には、XML関連の資料が豊富に用意されています。
  
  
• Edd Dumbill's の、「XML ウォッチ」シリーズの記事 をご覧下さい。
  
  
• Technology bookstore には、この記事や他の技術的な話題に関する本が豊富に取り揃えられています。
  
  
• XMLおよび関連技術においてIBM認証開発者になる方法についてはこちらを参照してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• DOAPを見る
• DOAPを妥当性検証する
• DOAPを作る
• コミュニティ
• まとめ
• 参考文献
• 著者について
• コメント