取り上げた規格に関連する情報

メータデータをアプリケーションに依存しない形で記述するための枠組みであるRDFは、セマンティック・ウェブの最も重要な基礎技術のひとつです。この基本仕様と解説、テストケースなど6つの文書が、2004年2月10日にW3C勧告となりました。（RDFの概要については、当サイトの「リソース表現のフレームワーク:RDF」を参照）。

• RDF入門:RDF関連の様々な仕様の要点をまとめたのがRDF Primerです。非常に詳しい入門文書で、RDFの理解の基本となります。XML構文が出てくるのは第3章からです。

• RDF/XML構文:RDFのモデルはグラフをはじめさまざまに表現されますが、最もよく使われるXML表現はRDF/XML Syntax Specification (Revised)で定められます。rdf:bagID属性の廃止、parseType="Collection"の導入、rdf:datatypeによるデータ型指定など、大きな変更が施されています。またコンテクストからRDF/XMLの存在が分かる場合はrdf:RDFはオプションであるとされました（7.2.1）。

  When there is only one top-level node element inside rdf:RDF, the rdf:RDF can be omitted although any XML namespaces must still be declared.

  当サイトのRDF/XML構文の簡単な説明 も参照してください。

• RDF-SCHEMA:RDFのプロパティなどの語彙を定義する方法は、RDF Vocabulary Description Language 1.0: RDF Schema（旧RDF Schema）で定められます。基本クラスにrdfs:Datatype、 rdfs:XMLLiteralが導入され、またRDFのコレクションに対応するためコンテナの語彙が拡充されました。（当サイトのリソース表現の語彙定義：RDFスキーマ参照）。

• コンセプトと抽象データモデル:RDFの抽象グラフ構文およびフラグメント識別子の意味などを定義するのがResource Description Framework (RDF): Concepts and Abstract Data Modelです。RDFを厳密に解釈するための定義がいろいろ含まれています。URI参照はIRIと互換にすることも記載されています。

• RDF-SEM: RDF Semantics（以前のRDF Model Theory）は、RDFで用いる語彙に曖昧さのない意味づけを与えるため、形式論理と集合理論の言語をもちいてモデルを表現しようというものです。付録にはエルブラン定理とかスコーレム化といった非常に専門的な内容も含まれます。

• RDF-MIME:RDFのMIMEタイプ（メディアタイプ）をapplication/rdf+xmlと定義するインターネットドラフトapplication/rdf+xml Media Type Registrationが2003年2月12日に第2版となりました（が、9月には期限が切れ、改版されていません）。RDFの解釈でしばしば問題になっていたフラグメント識別子については

  However, in RDF, the thing identified by a URI with fragment identifier does not bear any particular relationship to the thing identified by the URI alone.

  とされています。

• RDF-I18N:新しいRDFのモデルでは、リテラル値にデータ型を与えるrdf:datatypeが導入されるなど、文字列の扱いが高度になっています。これにxml:langによって言語情報をどう与えるか（与えないか）ということについて、W3Cの国際化WGから2003年6月5日付けでSummary of strings, markup, and language tagging in RDFという長いコメントが寄せられ、2003年9月の草案に反映されています。

メタデータ（書誌情報）を表現するための最も普及している語彙であるDublin Coreは、ますますその重要性が高まっており、関連規格もいくつか新しくなっています。

• ISO標準: DCMIの基本要素型（DCMES）は、2003年2月26日付けで国際標準ISO 15836:2003(E)となりました（PDF）。4月8日にDCMIのホームページで発表されています。

• DCの拡張: DCMIの基本要素型や精密化修飾子を拡張する提案が公開され、2002年5月10日まで一般コメントを受け付けています。新しい要素型としては、ネット上には存在しない蔵書などの所在地を示すholdingLocation、修飾子としてはType, Date, Identifier, Description各要素について、精密化の提案が出されています。

• DC名前空間: DCの名前空間に関する定義は草案の改訂に伴って何度か変更されてきましたが、Namespace Policy for DCMIが2001年10月26日に勧告となり、ようやく安定しました。

  Namespace URIs used by the DCMI

  DC Metadata Element Set	http://purl.org/dc/elements/1.1/
  DC other elements and qualifiers	http://purl.org/dc/terms/
  DCMI Type Vocabulary	http://purl.org/dc/dcmitype/

書籍では「コンピュータの力を使ったより効率的な情報共有」という項目で検討し、またこのサイトでは「意味を表現するウェブ」として、W3Cの提唱するSemantic Webの考え方に言及してきました。Scientific American: May 2001は特集記事として、バーナーズ＝リーほかによるThe Semantic Webを掲載しています。認知科学の話などが出てきてやや難解なこの概念について、比較的分かりやすく解説しているおすすめの記事です。なお、この記事は2001年6月25日発売の日経サイエンス2001年8月号にも翻訳掲載されています。

また、この試みはSemantic Web Activityとして2001年2月9日にW3Cの具体的な活動の一つになりました。

The Semantic Web is a vision: the idea of having data on the web defined and linked in a way that it can be used by machines not just for display purposes, but for automation, integration and reuse of data across various applications. Semantic Web Activity Statement

ウェブでの情報を人間が読むために表示するだけでなく、自動処理、再利用を可能にすること。そのために、互いに独立して設計されたプログラムでも、データを共有し処理できるような技術や仕様が必要とされています。Semantic Webでは、RDFをメタデータ共有の基盤とし、情報表現、情報間の関係表現のための言語の開発などが想定されています。

Activityとは、W3C内部でウェブに関する技術の開発・改良に必要な作業を行うための活動組織で、W3Cのホームページの左側に列挙されている40あまりの名前がそれに相当します。

セマンティック・ウェブのための道具として、ある知識分野のコンセプトやその関連をコンピュータで利用できる形で定義する「オントロジー言語」が必要です。2001年11月に発足したWeb-Ontology (WebOnt) Working Groupは、ウェブのためのオントロジー言語を策定するために活動しています。2004年2月10日に関連する仕様が一斉にW3C勧告となりました。

• OWL: WebOnt WGが策定するオントロジー言語はOWLと呼ばれます。言語の概要を説明するのはWeb Ontology Language (OWL): Overview（以前のFeature Synopsis）です。さらに言語レファレンスとしてはReferenceがあります。

• OWL-SEMANTICS: OWLの抽象構文と意味論を定義するのはAbstract Syntax and Semanticsです。EBNFによる言語定義と、集合語論理による意味の定義が含まれます（RDF MTよりは分かりやすいが、やはり専門家向け）。また、OWL/FullとOWL/DLという2つの定義が導入され、それぞれで意味論が一部違う（DLの方が制約が大きく、FOLでも使える）ことになっています。

• OWL-GUIDE: Guide Version 1.0はOWLの定義や使い方を具体的に解説します。ワインを表現するオントロジーを構築しながら言語のさまざまな機能を説明するもので、一連の文書の中では格段にわかりやすくできています。

• WEBONT-REQ: この言語設計のための指針はOWL Use Cases and Requirementsに示されています。言語の目標、要件などとともに、ウェブポータル、マルチメディアコレクション、知識マネジメント、ユビキタスコンピューティングなどの想定利用例が掲載されています。

• OWL-TEST: OWLの実装のテストや解釈方法を示すTest Casesが用意されています。OWLの書き方の参考として読むこともできます。

当サイトの解説ウェブ・オントロジー言語OWLも参照してください。

URIで使える文字レパートリーを拡張して国際化対応させようというInternationalized Resource Identifiers (IRIs)のインターネットドラフトが、2003年6月29日に改訂されました。

リソースをグローバルに識別するURIはウェブの基盤をなすものですが、その識別子に使える文字はASCIIの一部に限定され、それ以外の文字を使う場合は%HHの形にエスケープしなければなりません。一方、RDFでは語彙をURI参照として定義するように、URIは単なる機械的な識別子以上に、人間が理解できることが望ましい表現にも使われています。こうしたときに、たとえばRDFのクラスを日本語で定義するために%HH%HHという形にするのはナンセンスですから、識別子として漢字などASCII以外の文字が使えるようになることは極めて重要です。

IRIは、識別子として使える文字をUnicode全体に拡張し、それをURIにマップする方法を定めます。アプリケーションは、IRIをURIに変換してリソースを検索したりリクエストしたりすることになります。識別子にスペース文字を含められることにしてよいのか、大小文字の区別をどうするかなど、まだ問題も残っていますが、このIRIはW3Cの仕様でも原則として全面採用される方向で検討が進んでいます。

URIの新しいスキームinfo:を提案するインターネットドラフトThe "info" URI Scheme for Information Assets with Identifiers in Public Namespacesが2003年9月末に公開されました。図書の十進分類法であるDDC（Dewey's Decimal Classification）や米議会図書館コードのLCCNなど、公共的に使われている体系（名前空間）で、従来のURIスキームではうまく表現できないものを扱うことを目的としています。

構文としては、info:スキームのあとに、名前空間のIDとスラッシュ（/）が続き、それ以降は名前空間管理責任者の定義による「パス」になります。名前空間IDは登録制です。例えば、DDCの分類コードなら、次のように表現します。

info:ddc/22%2Feng%2F%2F004.678

urn:スキームと同じではないかという気がしますが、説明によると「urn:は“恒久的”なラベル付けを目的としているのに対し、info:はリソースの恒久性を言明せず、名前空間がその管理主体のポリシーに基づいて運営されているものであることを示す」となっています。Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces.なのだそうです。

障碍を持つ人や限定的な環境でも使いやすいページを作成するためのガイドラインであるWeb Content Accessibility Guidelines（WCAG＝ウェブコンテンツのアクセシビリティのための指針）の新しいバージョンWCAG 2.0の公開草案（Public Working Draft）が、2004年3月11日に改訂されました。2003年6月草案から、またいろいろ変更があります。

この草案は、WCAG 1.0に対するフィードバックやその後の技術の変化に対応するとともに、HTMLだけでなく、SMILやSVGなどその他の多彩なコンテンツ記述言語にも適用できるように、概念を広げて書かれていることが特徴です。ガイドラインは4つの基本方針（Principle）に大きくまとめられ、その中に14のガイドラインが具体的にあげられるという構成になりました。基本方針は

1. Perceivable：全ての機能と情報が、（言葉で表現できないものを除き）全ての利用者に認知できるようにすること
2. Operable：コンテンツのインターフェイス要素は、全ての利用者に操作可能であること
3. Understandable：コンテンツや操作・入力手段を可能な限り理解しやすくすること
4. Robust：現在および将来のアクセシビリティ技術、ユーザエージェントにおいてコンテンツの能力を最大に引き出すウェブ技術を用いること

となっています。まだ草案段階とはいえ、考え方はすぐにでも応用できるものといってよいでしょう。当サイトのハンディがあっても利用できるページづくりでもその内容を紹介します。

HTML技術: 2003年12月9日に、WCAG2.0に対応したHTML Techniques for WCAG 2.0の草案が公開されました。WCAG1.0からお馴染みの項目が並んでいますが、table要素のsummary属性などはオプション（caption要素があれば重複するのでsummary属性はあまり必要ない）と明記されたこと、レイアウト用テーブルならsummary=""とすること（alt=""と同様の考え方）、「input要素などに初期値を入れておくというのは不要かも知れない」という注の追加など、従来分かりにくかった点が明確化されています。一方、以前から議論になっていたimg要素のtitle属性は「使わないこと」とされており、新たな疑問も生じそうです。

WAIではコンテンツ作成の指針以外にも、UA、オーサリングツール、言語などの切り口からアクセシビリティのガイドラインを提唱しています。

• UAAG: ブラウザなどのユーザエージェントのアクセシビリティ指針であるUser Agent Accessibility Guidelines 1.0が、2002年12月17日にW3C勧告となりました。技術編であるTechniques for UAAG 1.0は同時にNoteとなっています。

• ATAG: 多くの場合、コンテンツはオーサリングツールを使って作成されますから、これらのソフトがアクセシビリティを考慮したコードを生成してくれることが重要です。2000年2月3日にAuthoring Tool Accessibility Guidelines 1.0が勧告されていますが、バージョン2となるATAG 2.0の草案が、2004年2月24日に改訂されました。

• ATAG-TECH: ATAGの指針を反映させるための具体的な技術を解説したノートTechniques for Authoring Tool Accessibility Guidelines 1.0が、2002年10月29日に改訂されました。2年半前の旧バージョンから、かなり大きく書き換えられています。

• XML-AG: 2002年10月3日に、XMLによるマークアップ言語設計に際してのアクセシビリティ指針であるXML Accessibility Guidelinesの草案が改訂されました。HTML4の言語としてのアクセシビリティ機能を検討した結果などを反映し、(1)作者が複数の代替オブジェクトを指定できるようにする; (2)意味表現手段を豊富に提供する; (3)アクセシブルなユーザインターフェイス機能を用意する; (4)意味機能を文書化し、外部から利用できるようにする; といったガイドラインと、それに基づくチェックポイントが検討されています。

いつでもどこでも、誰でもどんな環境でも利用できるウェブがユニバーサルアクセスの大きな目標です。WAIは主として「誰にでも」という視点から、またi18nは「どこでも」という切り口からアクセシビリティを高めるための方法を提案していますが、「いつでもどんな環境でも」を考えるのが機種に依存しない（Device Independent）情報提供です。

2003年9月1日に、Device Independence PrinciplesとAuthoring Challenges for Device Independenceの2つの文書が、W3C WGノートとなりました。また技術をまとめたAuthoring Techniques文書も登場しています。

• DIP: Device Independence Principlesには、ユーザー、オーサリング、配信（ユーザエージェント）という3つの視点から、機種に依存しない情報のための原則が提案されています。比較的あたりまえのことが抽象的に述べられている段階ですが、ウェブページ識別子（URI）の在り方、環境（コンテクスト）を伝えてそれを生かす方法など、今後重要になる内容も含まれています。

• ACDI: Authoring Challenges for Device Independenceはウェブ制作者が機種に依存しないコンテンツを制作するために必要な条件などについて検討します。"Challenges"と銘打たれているように、具体的な解決策や指針を示すのではなく、考え方の方向性を示すという位置づけですが、頭の中を整理するには役立ちます。

• ATDI: 機種に依存しないコンテンツ制作のためのテクニックや望ましい手法をまとめたAuthoring Techniques for Device Independenceが2004年2月18日にW3C WGノートとなりました。参考になる考え方が体系的にまとめられています。

ブラウザやデバイスの性能・機能とユーザの嗜好をプロファイルとして記述するComposite Capability/Preference Profiles (CC/PP)の、記述構造と語彙を定義するCC/PP: Structure and Vocabulariesが、2004年1月15日にW3C勧告になりました。CC/PPは、HTTP/1.1のコンテント・ネゴシエーションの概念をより一般化してRDFで記述し、柔軟で拡張性があり、分散処理ができるプロファイルの標準を定義しようというものです。

機器に依存しないウェブの実現のために重要な規格で、実際に携帯電話端末ではCC/PPに基づくUAProfが広く利用されています。

実装ガイド:実装のためのガイドラインも公開されています。

• デバイスのプロファイルを記述する語彙としてはすでにWAPフォーラムのUAProfやFIPAの定めたものがあります。これらをCC/PPに取り込んで利用する方法と、プロファイルを受け取って適切なコンテンツを返すための具体的な方法に関するガイドHarmonization with Existing Vocabularies and Content Transformation Heuristicsが、2001年12月20日にW3Cノートとして公開されました。

• デバイスや環境設定などのプロファイルを送ることは、ユーザーのプライバシーにも関係してくる問題になります。これらに関するガイドPrivacy and Protocolsも、2001年12月20日にW3Cノートとして公開されました。

2003年2月20日にVoice Extensible Markup Language (VoiceXML) Version 2.0の勧告候補が改訂されました。1/28版との違いはスキーマの修正のみです。VoiceXMLを用いて、携帯電話などから音声でウェブを利用したり、視覚障碍者が操作する場合などに有益な機能を提供することが期待されています。2001年10月のW3Cのプレスリリースでは、その役割を

音声合成、 デジタルオーディオ処理、音声や DTMF (タッチトーン) 入力の認識、音声入力の録音、電話機能、双方向会話をそれぞれ実現する、 音声対話を作成するために設計されています。 その主な目的は、Web 技術に基づく開発とコンテンツ提供の利点を、 対話型の音声応答アプリケーションに提供することです

と説明しています。このほか、音声ブラウザに関するさまざまな規格の進展は、"Voice Browser" Activityのホームページで知ることができます。

ペン入力などの「デジタルインク」の仕様はこれまでベンダ独自のものが使われてきましたが、多様な情報機器でのデータ交換・共有のためには、標準的なマーク付け言語が必要です。これを実現するInk Markup Languageの草案が2004年2月23日に改訂されました。ペンの動きのトレース、ペンの角度や圧力、そのコンテクストといったものをXMLとしてマーク付けしていきます。

XML 1.0の小改訂版XML 1.1が、2004年2月4日にW3C勧告となりました。Unicodeが（XML1.0当時の）2.0から4.0へと変化したことを受け、名前文字として使える文字の範囲を拡大する；文字にIBMメインフレームの改行文字(#x85)を加える；コントロール文字への文字参照（#x1〜#x1F）を認める；「文字の正規化」チェックを追加；といった内容が改訂されます。

XML文書に複数のマークアップ語彙を共存させるための仕組みであるXML名前空間の改訂仕様Namespaces in XML 1.1が2004年2月4日にW3C勧告となりました。1.0に比べ、xmlns:prefix=""という形でいったん宣言した名前空間を無効化する機能が追加されたこと、さらに名前空間はIRI（URIではなく）で参照することになり、その同一性に関する規定も加えられました。日本語を扱う我々としては、非常に重要な変更です（厳密にはIRIがRFCとなってからという注釈つき）。

名前空間はいったん宣言されるとその子孫要素まで有効になります。しかしXIncludeを使ってXML文書の一部を他の文書（名前空間）に貼り付けたり、XQueryで大きなXMLデータベースを扱う場合などでは、すべての要素にその名前空間の情報アイテムやノードが付与されていると不都合が生じることがあるため、明示的に無効化する機能を用意するというものです。

名前空間については、当サイトのXML名前空間の簡単な説明も参照してください。

XHTMLをはじめ多くのXML文書はスキーマでIDとなる属性を定めていますが、validationを行わないアプリケーションでは、一般のXML文書内でIDを使う方法が定められていません。こうした場合も含めた、XML一般に通用するID（xml:id）の扱いを明確にするため、2003年8月6日にxml:id Requirementsの草案が公開され、検討が始まりました。

プログラミング言語の多くは、複数のファイルに分けたソースを取り込むメカニズム（例えばC言語の#INCLUDE）によって、モジュール化を容易にしています。XMLの場合も、文書をモジュールに分割して「取り込み」を行いたいケースが考えられます。このための規格XML Inclusions (XInclude) Version 1.0は、2002年9月の勧告候補から差し戻され、2003年11月10日に再度最終草案となりました。XPointer、フラグメント識別子の扱いが大きく変更され、コンテント・ネゴシエーションへの対応が追加されています。

XIncludeでは、文書のデータ構造をInfosetで表し、親文書のinclude要素情報アイテムを取り込む文書のdocument情報アイテムで置き換えることで取り込みを抽象的に表します。

XPathの次期バージョンXPath 2.0およびXSLT2.0/XQuery関連規格が2003年11月12日に最終草案となりました。レビュー期間は2004年2月15日までです。

• XSLT 2.0は、XPath 2.0の仕様を反映してノード・シーケンスへの対応、XML Schemaに基づくデータ型の指定などができるようになるほか、ノードのグループ化、ユーザー定義関数の呼び出し、スタイルシート全体に反映される「トンネル・パラメータ」、複数の結果ツリーの生成、正規表現によるマッチなど多彩な機能が盛り込まれています。これらの機能強化は、2001年2月14日のXSLT Requirements Version 2.0にもとづくものです。

• XQuery: XMLで記述されたさまざまな情報から必要なデータを取り出すための問い合わせ言語として開発されてきたのがXQuery 1.0: An XML Query Languageのです。XQueryはXPath 2.0と密接に関連し、共通した式の表記を用います。

• 関連仕様として、出力の形式に関するXSLT 2.0 and XQuery 1.0 Serialization、XQuery 1.0およびXPath 2.0の型や式の詳細を定義するFormal Semantics、およびXQueryに関するXML Query Use Cases、データモデルを定義するData Model、XML Schemaのデータタイプを操作する関数や演算子を定義するFunctions and Operators、XML Query (XQuery) Requirementsなどがあります。

ほかにも、全文検索のためのXQuery and XPath Full-Text Requirements、XPath Requirementsなどがあります。多くはとても長大な文書で、検討中の項目のリストなども含まれています。

文書の一部分を示したり取り出したりする手段はXPointerやXLinkによって機能が大きく拡張されつつありますが、XML文書から取り出した部分（フラグメント）を、元文書の前後の文脈も考慮して処理できるようにするXML Fragment Interchange規格も策定が進められ、2001年2月12日に勧告候補となりました。この規格は、たとえば、ある段落をフラグメントとして取り出したとき、h2+p{text-indent:0}といった文脈セレクタによるスタイルを適用すべきかどうかを、元の文書全体をチェックすることなく判断できるようにしようというものです。

複合文書を実現する上で便利ではあるものの、ユーザビリティや検索、ブックマーク、セキュリティなどの問題が指摘されてきた「フレーム」を改良するXHTMLモジュールXFramesの草案が、2002年8月6日に公開されました。

XFramesは、HTMLの一部としてではなく、HTMLを含む複数の文書による複合文書を実現する「コンテナ」として、frames要素をルートとして構成します。frames要素内にはhead要素を置いてタイトルやスタイルを定義でき、画面を分割するためのrow, column要素および外部文書を参照するframe要素をその中に含みます。画期的なのは、包含される内部文書を含めた指定のためのURI記述方法でしょう。

http://example.org/home.frm#frames(id1=uri1,id2=uri2,...)

上記のようなURIを使って、親フレームだけでなく、それぞれのidを与えられたframe要素で表示する文書のURIも合わせて示します。これで、フレームの特定の「ビュー」をブックマークしたり、検索エンジンから辿ったりすることが可能になるわけです。

XMLによる高度なフォームを実現しようという概念をコラムで紹介したXForms 1.0が、2003年10月14日にW3C勧告となりました。

XFormsでは、送信すべき内容とそれを入力するコントロール（のマーク付け）、および送信データ形式を分離し、フォームの再利用やさまざまな機種での応用を可能にします。データを詳細に型付けしてチェックを容易にする、主要な用途に対応したイベントハンドラを使うことでスクリプトなどの必要性を減じるといった特徴も持ちます。フォームとして送信する内容はmodel要素で定義します。UIはinput、select1などの機能を示す要素で表現し、ref属性などを用いてモデルと結びつけます。さらにbind要素やXMLスキーマを直接埋め込んでデータのタイプや値の範囲などに制約を与えチェックも可能にします。

DOM2のイベントインターフェイスをXML/XHTML文書で利用するためのしくみXML Eventsが、2003年10月14日にW3C勧告となりました。このモジュールで定義する要素タイプはlistenerのみで、event, observer, target, handler, phaseなどの属性を組み合わせて、ツリー構造に沿って伝えられるイベントに対応した動作をさせるようになります。

次の例は、button1というidを持つ要素にclickイベントが起こった時、#doscriptで参照される要素のハンドラを起動するよう結びつけるものです。

（例） <listener event="click" observer="button1" handler="#doscript"/>

これらの属性は、listener要素を用いず、直接XML要素の属性として機能させることもできます。上の例と同じ関係を、直接script要素に記述してみます（ev:はXML Eventsの名前空間http://www.w3.org/2001/xml-eventsに対応します）。

<script type="text/javascript" ev:event="click" ev:observer="button1">
 //some action;
</script>

また、小さな実装のために機能を限定したBasic XML Events Profileも定義されています。