セマンティック Web サイトの計画

構造化データに対応したサイトを作成する

セマンティック Web は、ユーザーにはより有意義な検索結果を得る可能性を、サイト所有者にはユーザーがまさに必要とする内容を見つけられるようにトラフィックを絞り込む可能性をもたらします。しかし、このようなメリットは魔法の如く目の前に現れるわけではありません。この記事では、急激に拡大しつつあるこの可能性を実際に活用するために必要な情報アーキテクチャーと一般的インフラストラクチャーの両面について説明します。

この記事では、Web サイトをセマンティック Web にするために知っておかなければならないことについて説明します。まずはセマンティック Web で解決しようとしている問題、そしてセマンティック Web に関連する RDF (Resource Description Framework)、OWL (Web Ontology Language)、SPARQL (SPARQL Protocol and RDF Query Language) などの技術について説明します。この説明から、セマンティック Web が既存の Web の上にどのように重ねられるかがわかるはずです。次に、新しい Web サイトを計画するときに知っておくべき課題を取り上げるとともに、RDFa やマイクロフォーマットなどの技術を使用して既存の Web サイトをセマンティック Web に仲間入りさせる具体的な例も記載します。

セマンティック Web の概要

World Wide Web は、これまで人類が作った単独の情報リソースとしては最大級です。しかし残念なことに、仮にもコンピューターによる情報操作を頼りにしているにもかかわらず、大部分の情報はコンピューターではなく人間にしか理解できません。コンピューターは HTML 文書の構文を使ってブラウザーに文書を表示することはできても、Web コンピューターはその内容、つまりセマンティクスを理解することができません。

よく使われる頭字語

  • API: application programming interface
  • HTML: Hypertext Markup Language
  • URI: Uniform Resource Identifier
  • W3C: World Wide Web Consortium
  • XML: Extensible Markup Language

セマンティック Web は、Tim Berners-Lee による Web の将来に向けた構想です。この夢はまだ実現していませんが、今では RDF、OWL、SPARQL をはじめとするいくつかのセマンティック Web 技術を Web サイトで活用できるだけのビルディング・ブロックが揃っています。セマンティック Web が目標とするのは、Web の膨大な情報リソースをコンピューターが自動的に解釈できるデータとして公開することです。

Web は当初、文書がすべてでした。ユーザーが Web ブラウザーでリンクをクリックするという単純な行動によって、ブラウザーは Web サーバーに文書を送信するよう要求し、送信されてきた文書を表示します。文書は次の 7 日間を示すカレンダーであったり、友達からの E メールであったりします。しかし Web ブラウザーにとっては文書が何であろうと関係なく、ブラウザー自体の内部ルールに従ってページを表示するに過ぎません。ページ上の情報を理解するのはユーザーの役目だからです。

データを構造化すると、データには付加価値が与えられます。構造に一貫性があれば、データの使い道が広がります。今日、構造化データが必要とされていることは、Web 2.0 トレンドの一環として Web サイトを中心に API が急激に増えていることを見れば明らかにわかります。API は構造化データです。そして各種ソースの構造化されたデータがマッシュアップを構成する源となります。マッシュアップの背景にある概念は、Web 上のさまざまなソースからデータを集め、これらのデータ要素を同じように組み合わせて表示したときに、その要素の組み合わせが、元の情報を単独で使用+した場合以上の価値を与えるというものです。

誰もが懸命に作成している個々の API は、セマンティック Web によって解決しようとしている問題とまったく同じ問題を解決しようとしています。それは、Web のコンテンツをデータとして公開し、それから各種データ・ソースをさまざまに組み合わせて新しい価値を生み出すという課題です。したがって、独自の API を作成して維持する代わりに、すでに用意されたセマンティック Web インフラストラクチャーを最大限に活用する Web サイトを構築すれば問題は解決します。Web サイトが API であれば、開発作業と保守作業全体を削減することができます。同様に、データの収集対象となる Web サイトごとにカスタム・ソリューションを構築するのではなく、セマンティック Web 技術をベースとした 1 つのソリューションを実装すれば、開発を始める前には気付きもしなかった Web サイトを含め、多数の Web サイトで交互にそのソリューションを機能させることができます。


セマンティック Web 技術の概要

セマンティック Web 技術を階層という点から見ると、それぞれの階層がその下にある階層の機能を拡張していると考えることができます。セマンティック Web はあたかも別個のエンティティーとして語られることがよくありますが、そうではありません。セマンティック Web は既存の Web に置き換わるものではなく、その拡張であり、機能強化です。

図 1. セマンティック Web 技術のスタック
セマンティック Web 技術のスタック

図 1 に示されているように、セマンティック Web の基底にある階層は HTTP と URI です。この 2 つは一般に「セマンティック Web」ではなく「Web」と見なされますが、提案されるすべてのセマンティック Web 技術はこの 2 つの Web の基礎をベースにしています。セマンティック Web では、URI が名詞となります。そして動詞となるのは HTTP です。GETPUTPOST だけでなく、認証および暗号化に関して徹底的にテストされた多数のソリューションが動詞として使われます。

セマンティック Web では、RDF (Resource Description Framework) が大きな役割を果たします。RDF は、関係をコードで表すための文法です。RDF トリプルは主語、述語 (または動詞)、目的語の 3 つのコンポーネントからなります。それぞれのコンポーネントは Web 上のリソース、つまり URI として表現することができるため、ランダムな XML 文書のコードにするよりも曖昧さはずっと少なくなります。単純な関係を XML を使ったさまざまな方法で表現しているリスト 1 と、RDF トリプルによって表現しているリスト 2 を見比べてみてください。

リスト 1. XML での曖昧な関係
<author>
    <uri>page</uri>
    <name>Rob</name>
</author>

<person name="Rob">
    <work>page</work>
</person>

<document href="http://www.example.org/test/page" author="Rob" />

リスト 2 は、RDF トリプルによる関係の表現です。

リスト 2. RDF での関係の表現
<page> <author> <Rob> .

リスト 1 に記載したすべての例で共通して表現しているのは、「Rob がこのページ (page) の作成者 (author) である」という関係です。このように、かなり単純な文でも XML では何通りもの表現方法があるため、XML で可能なあらゆる表現方法からこの関係を導き出すソフトウェアを作成するのは至難の業となります。その一方、RDF が関係を表現する方法は 1 つしかないので、汎用パーサーを作成することが可能です。

初期の頃のセマンティック Web では、コンテンツの作成者がすべてのコンテンツを RDF で使用できるようにすれば、すぐに大量のデータが利用可能になると期待されていましたが、残念ながら、RDF でコンテンツを作成するという動きはなかなか活発になりませんでした。おそらく RDF の主要な XML 表現が必要以上に複雑そうに見えることが原因でしょう。今では N3 (Notation3) や Turtle (Terse RDF Triple Language) など、より簡潔になった RDF 表現を使用できるようになってはいますが、それでもこの複雑さの問題は克服されていません (N3 および Turtle についての詳細は「参考文献」を参照してください)。この問題に対しては、マイクロフォーマットの手法に端を発したソリューションがあります。マイクロフォーマットでは、標準 HTML 要素および属性の一貫したパターンを使ってセマンティック値を既存の HTML コンテンツに追加します。マイクロフォーマットが対象とするのは、連絡先情報やカレンダー項目などといった、限られてはいるものの共通するデータ項目です。W3C では、XHTML に組み込まれた RDF データである RDFa がマイクロフォーマットに相当します。RDFa は、マイクロフォーマットの場合より実装は多少複雑ですが、汎用性は遥かに高く、RDF で表現できるものであれば何でも RDFa を使って XHTML 文書に追加することができます。この手法を使用すれば、既存の Web コンテンツをセマンティック Web にすることは可能になります。

すべてのセマンティック Web ツールは RDF を入力として必要とするため、当然のことながら、これらのツールにとって XHTML 文書に RDFa として組み込まれた RDF は役立ちません。そこで必要となるのが、RDFa コンテンツの存在を認識し、そこから RDF を抽出するための自動化方式です。これに対する W3C ソリューションとしては GRDDL (Gleaning Resource Descriptions from Dialects of Languages) があります。GRDDL は、まず XSLT によって既存の XHTML 文書から RDF を生成し、それから参照を直接組み込むことによって、あるいは間接的にプロファイルと名前空間の文書を使うことによって、GRDDL 変換にリンクするというものです。

RDF により明確に表現したセマンティクスは有効で、誰もがこの方法を使ったとしても、他のサイトで使用している RDF との関係がわからなければ役には立ちません。リスト 2 の RDF トリプルでは述語に author という関係を表現しています。これが意味することが人間にとっては明白であるとしても、コンピューターにはまだ助けが必要です。例えば、あなたのサイトでも author という関係を RDF ファイルで表現したとすると、コンピューターはそれをこの 2 つの author という関係を同じものと見なすでしょうか。あなたの RDF トリプルには含まれるのは author という関係ではなく、writer という関係だったとしたらどうなるでしょう。つまり必要なのは共通の語彙を表現する手段です。その手段によって、複数のサイトで使用している author が同じ意味であること、あるいは「author」と「write」は同じ意味として捉えられることを示すことができなければなりません。セマンティック Web では、この問題をオントロジーによって解決します。オントロジー表現に関する W3C 標準は OWL (Web Ontology Language) です。この記事で焦点を当てるのは、OWL そのものではなく、OWL を使ったアプリケーションなので、それ自体が大きな主題となる OWL については「参考文献」で詳細を調べてください。

RDF でのデータ・ソース、そしてデータ・ソース間の関係を判別するためのオントロジーが用意できたら、次はデータ・ソースから有益な情報を取得する方法が必要です。SPARQL (Simple Protocol and RDF Query Language、「スパークル」と発音) は、RDF データに対するクエリーを表現する SQL に似た構文で、クエリー自体の見かけも動作も RDF データと似ています。SPARQL の基本的パラダイムはパターン・マッチングです。これは、Web 全体で各種ソースから組み合わせられたデータで機能するよう柔軟性のある設計となっています。例えば、マッチングはオプションとして記述することが可能なので、不揃いなデータに対してクエリーを実行する際には SQL よりも遥かに優れたマッチングを行うことができます。単一の SQL データベースではなく、Web 上のさまざまなソースからデータが組み合わせられている場合にはデータは不揃いになり、その構造は予測も信頼もできないものになる可能性があります。


セマンティック Web サイトを計画する際に知っておかなければならないこと

これまでの説明からおわかりのように、今度、素晴らしい Web 2.0 サイトを構築しようと思ったら、はじめからセマンティック Web 技術を採用し、Web サイトのために別途 API を作成するのではなく Web サイトを API にしてしまうことを計画すれば時間の節約になります。セマンティック Web の手法は、API に似た自由な機能をもたらします。通常、API は構造化されていない Web サイトから XML または JSON フォーマットで構造化データを取得する手段となることから、手法は二重化されることになります。つまり、人間が利用するための Web ページと、コンピューターが構造化された情報を引き出して自動処理するための API です。しかし、それによって追加の作業も生じます。なぜなら、その API を人々が利用することを期待する場合には、API を文書化し、サポートし、そして Web サイト上の新しい機能と常に同期させなければならないからです。セマンティック Web の手法では Web サイト自体が構造化データです。そのため、個別の実装は必要ありません。皆さんの Web サイトでも、そしてそのユーザーも、他のセマンティック Web ツールを利用して自動処理を行うことができます。

このことが、Web サイトの計画に当たっていくつかの問題を提起するのは確かです。API では、配信したいと思う情報の項目ごとに独自のデータ・フォーマットを自由に定義することができます。セマンティック Web の場合、これに似ているのは、独自のオントロジーを定義することです。しかし、乏しい経験でオントロジーを正しく設計することは困難なので、豊富に揃った既存のオントロジーのなかかで、どれが使用する予定のデータのタイプに適しているかを検討しなければなりません (これについては、次のセクションで説明します)。通常、API を設計する際には、概念構成に対応するオブジェクト・モデルを考慮し、開発者が、いつ項目の集合や単なる項目を受け取り、それらの項目はどの集合に属しているのか、を理解できるようにします。セマンティック Web サイトの場合、こうしたことは、一部はオントロジーの選択によって決まり、また URI スキームにもよっても決まります。その上で、URI を API の一部として使用できるようにするための手法を検討することになります。

最後に知っておくべき点として、皆さんの既存の Web サイトでもコンテンツを更新して GRDDL、RDFa、そしてマイクロフォーマットを活用するようにすることで、皆さん自身もユーザーもセマンティック Web のメリットを享受することが可能になります。


既存のオントロジーに照らし合わせてデータを評価する

セマンティック Web でさらに複雑なのは、データによくマッチしたオントロジーを設計するという部分です。通常は、正しいオントロジーにたどり着くことが、セマンティック Web プロジェクトの実装を成功させる上での重要な要素となりますが、幸いなことに、すでに存在するさまざまなオントロジーを使うことができます。表 1 に、既存のオントロジーをいくつか抜粋します。

表 1. 現在 Web で使用されているオントロジーの抜粋
Dublin Coreドメイン共通情報リソースの記述を対象としたメタデータ要素標準です。オンライン上にあるものを検索しやすいように記述するための、単純かつ標準化された表記セットを規定しています。
SIOCSIOC (Semantically-Interlinked Online Communities) プロジェクトは、ブログやフォーラムのメーリング・リストなど、インターネットでの討論手段に明示的および暗黙的に含まれる情報を表現するオントロジーです。
FOAFFOAF (Friend Of A Friend) オントロジーは、個人とそのアクティビティー、そして他の人々とオブジェクトとのその個人の関係を記述します。FOAF では、分散型のソーシャル・ネットワークを記述することができます。
DOAPDOAP (Description Of A Project) は、オープンソース・プロジェクトを記述するためのオントロジーです。
ResumeRDFこのオントロジーは、職務経験や学歴、あるいはスキルなどの情報を含め、履歴書 (CV) を表現します。

上記の他にも、技術、環境科学、化学、言語学など、それぞれの分野に固有のオントロジーが多数ありますが、これらのオントロジーが適用される Web サイトは、上記に記載したものに比べ数が限られています。お使いのデータの大部分は、表 1 に記載したオントロジーが対象とする分野の少なくとも 1 つには適合する可能性が高いはずです。適合する場合は、そのオントロジーを計画に組み入れてください。


セマンティック URI スキームを選択する

Web サイトが API である場合、プログラマーはデータを取得するために URI にアクセスすることになります。そのため URI の構造として、目的にふさわしい簡潔かつ一貫した構造を前もって考えておくことが非常に重要になります。すべてが動き出してから頻繁に変更を加えるのでは、ターゲットとする使用者の信用を損なうからです。また、RDF トリプルのコンポーネントは通常、URI であることも忘れてはなりません。URI を変更すると、Web サイトを参照する既存の RDF のほとんどが無効になってしまいます。

初期の頃の Web では、URI の構造は一般的に Web サーバー上のファイル編成を反映していました。例えば、一連の製品のなかから特定タイプの製品を販売した場合、その URI は http://www.mysite.com/products/gadgets/widget.html のようになります。

この手法の利点は、URI のセマンティクスが比較的わかりやすいことです。関連製品も販売したとすれば、URI http://www.anothersite.com/products/gadgets/doodad.html にその製品の詳細が記載されていると見なせます。

このように、ある製品とその関連製品との関係はかなり明確ですが、この方法の主な問題点は、柔軟性がなく、カテゴリーの階層が固定されていることです。

Web が進化するにつれ、動的に生成されるサイトが当たり前となってきました。けれどもサイトがより柔軟になった一方、構造がファイルの特定のレイアウトに結び付けられなくなったことから、URI に含まれるセマンティック情報の量が減ったことも事実です。表示されるページは、クエリー・ストリングに含まれる暗号めいた情報によって決まります。例えば、前述の製品の URI は http://www.mysite.com/inventory.cgi?pid=12345 となり、関連製品の URI は http://www.mysite.com/inventory.cgi?pid=67890 となるといった具合です。

そうなると途端に、URI にはほとんどセマンティックな価値がなくなり、この 2 つの製品が同じカテゴリーに含まれているかどうかがわからなくなってしまいます。最近になって、コンテンツ管理システムと Web 開発フレームワークがこの問題に対処し始めるようになりました。それにより、今では URI をセマンティックに構造化すると同時に、動的ページの柔軟性も維持させることが遥かに容易になっています。これを可能にしたのは、サーバー上の物理ファイルを参照するのではなく、異なるロケーションにあるスクリプトあるいはページから配信可能なコンテンツを参照する URI です。流行の立役者である Ruby on Rails フレームワークでは、このような URI をルート (対応する URL を特定のコントローラーとアクションにマッピングするルール) という手段によって実現しています。CMS パッケージでは、この機能は通常 Apache の mod_rewrite (その他の Web サーバーでは、これに相当するもの) に依存し、よく「検索エンジン・フレンドリーな URI」といったような名前で呼ばれます。サイトの CMS または開発フレームワークを選ぶときには、この点に関する機能を必ず調べてください。

最後に注意しておく点として、可能であれば、URI からファイル名の拡張子を取り除くことを検討してください。ファイル名の拡張子 (.html および .cgi) は、ユーザーに関連するセマンティック情報を提供することはなく、実際、長い目で見れば問題の種となります。CGI スクリプトの代わりに PHP を使用するように Web サイトを変更したとすると、異なる URI がまったく同じコンテンツを提供することになってしまいます。これは、URI が持つセマンティックな価値からしても、Google のランキングという点からしても望ましくありません。それよりもセマンティックに洗練された手段となるのは、HTTP ヘッダーを利用してコンテンツ・ネニゴシエーションを行うことです。例えば、http://www.mysite.com/products/gadgets/widget といった URI です。

通常、Web ブラウザーは優先するコンテンツ・タイプを Accept HTTP ヘッダーを使って示します。そのリソースが要求されると、Web サーバーはヘッダーをチェックし、text/html がオプションの 1 つであることを認識して HTML ページを供給します。マッシュアップ・アプリケーションで RDF が必要な場合には、HTTP リクエストの Accept ヘッダーに application/rdf+xml を含めると、Web サーバーは URI が同じであっても、RDF バージョンのページを供給することになります。

現在、既製の CMS ソリューションのほとんどではこのコンテンツ・ネゴシエーション機能を使用できませんが、近い将来、多くの CMS ソリューションでファイル拡張子なしの URI を使用できるようになるはずです。これはつまり、将来的には URI スキームを混乱させることなく、この機能を追加できるようになることを意味します。


既存のセマンティクス追加ツールを利用する

Web サイトのインフラストラクチャーにセマンティック Web を完全に採用するにしても、あるいは既存のコンテンツの有効性を一層高めたいという場合にしても、Web サイトの既存のコンテンツに構造を追加する機会はあるはずです。これは、マイクロフォーマット、RDFa、そして GRDDL の領域です。表 2 に、構造化データとして簡単にマークアップできる一般的な情報のタイプを抜粋して一覧にします。

表 2. 構造化マークアップおよび自動変換が考えられる情報タイプ
情報タイプ構造化マークアップ
人物、組織hCard、RDF vCard
カレンダー、イベントhCalendar、RDF Calendar
意見、採点、評価VoteLinks、hReview
ソーシャル・ネットワークXFN、FOAF
ライセンスrel-license
タグ、キーワード、カテゴリーrel-tag
リスト、概要XOXO

ページに構造化マークアップを追加する方法は至って簡単です。以下のリスト 3リスト 4 の HTML フラグメントには、それぞれマークアップを使用していない連絡先情報、RDF vCard に必要なマークアップが追加された連絡先情報を示しています。

リスト 3. 構造化されていない連絡先情報
<div class="contactinfo">
  Rob Crowther. Web hacker
  at
  <a href="http://example.org">
    Example.org
  </a>.
  You can contact me
  <a href="mailto:robertc@example.org">
    via e-mail
  </a> or on my work phone at 0123 456789.
</div>

リスト 4 に、RDF vCard に必要な追加マークアップを設定した連絡先情報を示します。

リスト 4. vCard を使用した連絡先情報
<div xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#" class="contactinfo"  
                                     about="http://example.org/staff/robertc">
  <span property="contact:fn">Rob Crowther</span>.
  <span property="contact:title">Web hacker</span>
  at
  <a rel="contact:org" href="http://example.org">
    Example.org
  </a>.
  You can contact me
  <a rel="contact:email" href="mailto:robertc@example.org">
    via e-mail
  </a>
  or on my 
  <span property="contact:tel">
    <span property="contact:type">work</span>
    phone at
    <span property="contact:value">0123 456789</span>
  </span>.
</p>

リスト 4 には、重要なセマンティクスを持つテキスト部分を区切るために追加された span 要素、そしてこの要素の意味を示す属性があります。ここで追加されているのは RDF VCard 語彙にリンクする名前空間「contact」で、次にこの要素が URI http://example.org/staff/robertc によって表されるリソースのことを指していることが示されています。リンク・リレーションショップには rel 属性を使ってメタデータを追加し、リンク以外には property 属性を追加しています。多少複雑な唯一の部分は電話番号で、番号だけでなく種類も指定しなければならないからです。そのための手段として、type 要素と value 要素が tel 要素のなかにネストされています。この構造を追加すれば、ユーザーはマウスを 1 回クリックするだけで自分のアドレス帳に連絡先の詳細を追加できるようになります。

これ以外の自動処理も、別の構造化フォームを使って行うことができます。例えば、Technorati では rel-tag マイクロフォーマットを利用して膨大なブログの投稿をカテゴリー分けしています。リスト 5 に記載した rel-tag を見るとわかるように、これは rel 属性を利用する単なるリンクに過ぎません。重要なのは、最後の / に続く URI の最後の部分で、これがタグとなっています (通常の URI エンコード規則を使用して、スペースは + 符号で表されています)。

リスト 5. Technorati で使用する「semantic web」タグの rel-tag
<a href="http://technorati.com/tag/semantic+web" rel="tag">
  Semantic Web
</a>

リスト 5 のコードが含まれるセマンティック Web 関連のブログ投稿を作成し、Technorati に ping を実行して新しい投稿を行ったことを知らせると (多くのブログ・ソフトウェアは、これを自動的に行うように構成することができます)、Technorati のクローラーが投稿にインデックスを付け、投稿者の tag 要素がリンクしているページに投稿の要約と、同じタグが設定されたその他すべての投稿を追加します (図 2 を参照)。

図 2. rel-ta によって生成された Technorati の「semantic web」ページ
rel-ta によって生成された Technorati の「semantic web」ページ

まとめ

この記事では、Web サイトごとに独自の API を定義するという現在よく使われている手法とは対照的に、セマンティック Web 技術では標準的な一貫したやり方で、どのようにして Web 上での構造化データのニーズを満たしているのかを説明しました。セマンティック Web 技術は、既存の Web の HTTP と URI の上に重ねた階層に付加価値を与えます。その方法は、まず RDF によって関係を明白に表現し、オントロジーに基づく OWL で意味を共有し、そして最終的には SPARQL を使用して分散 Web のナレッジに対してクエリーを実行できるようにすることです。この記事ではまた、既存のオントロジーを利用してデータの内容を定義し、セマンティック URI スキームによって Web サイトを API にもできることを説明しました。そして最後に、RDFa とマイクロフォーマットを使用することで既存の Web サイトのコンテンツをアップグレードし、GRDDL サービスがページから自動的に RDF を抽出できるようにする方法も紹介しました。

Tim Berners-Lee のセマンティック Web で約束されたことは、まだ完全には実現されてはいませんが、今日私たちが直面している実際の問題を解決するという点では、これまで何年も積み重ねられてきた思索と研究が今、実を結び始めています。Web 2.0 での強力なコラボレーションの風潮により、セマンティックにエンコードされた構造化データを Web 上で利用可能にする必要性はますます高くなっていくことでしょう。その必要性を満たす手助けをするセマンティック Web ツールを利用するには、周到な計画が必要です。

参考文献

学ぶために

製品や技術を入手するために

  • IBM 試用版ソフトウェア: developerWorks から直接ダウンロードできる試用版ソフトウェアで、次の開発プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=301287
ArticleTitle=セマンティック Web サイトの計画
publish-date=04102008