CyberLibrarian

【注意】 このドキュメントは、W3CのGleaning Resource Descriptions from Dialects of Languages (GRDDL) W3C Recommendation 11 September 2007の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2007年11月3日


W3C

言語方言からの資源記述収集(GRDDL)

W3C勧告 2007年9月11日

本バージョン:
http://www.w3.org/TR/2007/REC-grddl-20070911/
最新バージョン:
http://www.w3.org/TR/grddl/
旧バージョン:
http://www.w3.org/TR/2007/PR-grddl-20070716/
編集者:
Dan Connolly
著者:
謝辞を参照してください。

このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。

翻訳版も参照してください。


要約

GRDDLは言語の方言から資源記述を収集する(Gleaning Resource Descriptions from Dialects of Languages)ための仕組みです。このGRDDL仕様では、XMLドキュメントがRDF(Resource Description Framework)に準拠したデータを含んでいると宣言するため、そして、各種アルゴリズム(一般的にXSLTで表現される)にリンクするための既存の規格に基づき、ドキュメントからこのデータを抽出するためのマークアップを紹介しています。

このマークアップには、汎用的なXMLドキュメント用の名前空間限定付き属性と、正当なXHTMLドキュメント用のプロファイル限定付きリンク関係が含まれています。また、GRDDLの仕組みにより、当該名前空間(または、プロファイル)に関連しているあらゆるドキュメントは収集可能なデータを含んでいるとXML名前空間ドキュメント(または、XHTMLプロファイル・ドキュメント)で宣言することや、データを収集するためのアルゴリズムにリンクすることが可能になります。

関連するGRDDLユースケース草案では、動機づけとなるような例を提供しています。GRDDL入門は、マイクロフォーマットとして知られる、広く流布している方言を含むXHTMLドキュメントにおける仕組みの実例を示しています。 GRDDLテスト・ケースドキュメントは、当該設計における特定の問題を例示し、GRDDLを意識したエージェントの試験開発を支援する材料を提供します。

このドキュメントのステイタス

この項は、このドキュメントの公開時のステイタスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。

これは、W3C勧告です。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

このドキュメントに関するコメントは、公開アーカイブ付きのメーリングリスト、public-grddl-comments@w3.orgにお送りください。

このドキュメントは、GRDDLワーキンググループが作成したもので、W3Cセマンティック・ウェブ・アクティビティの一部です。このドキュメントの草案としての最初の公開は2006年10月24日で、ワーキンググループは、それ以後に受け取った多くのコメント課題に取り組んで来ました。規範的な記述は、このようにマークアップされています。

ワーキンググループの実装報告では、このドキュメントの2007年5月の勧告候補草案で設定された相互運用可能な実装の目標が達成されたことを実証しています。

GRDDLは、RDFinXHTML-35namespaceDocument-8xmlFunctions-34などのウェブ・アーキテクチャの課題や、rdfms-validating-embedded-rdffaq-html-complianceなどのRDFコア・ワーキンググループが先送りした課題への対処に貢献することを目的としています。特に、GRDDLワーキンググループは、issue-faithful-infosetを先送りしており、TAG(訳注:Technical Architecture Groupの略)の課題xmlFunctions-34の解決により、さらなる明確化と指針がもたらされることを予期しています。

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

この草案の一部であった課題付録は、ワーキンググループ課題リストに移動しました。具体的には、issue-whichlangsissue-output-formatsissue-base-paramissue-tx-elementissue-html-nsdocissue-faithful-infosetissue-mt-nsissue-conformance-labelsissue-http-header-linksです。

目次

  1. はじめに
  2. 整形式XMLへのGRDDLの付与
  3. XML名前空間用のGRDDL
  4. 正当なXHTMLでのGRDDLの使用
  5. HTMLプロファイル用のGRDDL
  6. GRDDL変換
  7. GRDDLを意識したエージェント
  8. セキュリティに関する考察
  9. GRDDL語彙
  10. 参考文献
リンク・ドキュメント:

1. はじめに: データとドキュメント

ウェブ上の多くのXMLドキュメントで実際に用いられている、領域固有の言語(「方言」)が多く存在しています。詩から散文まで、発注書から請求書まで、集計表からデータベースまで、スキーマからスクリプトまで、リンク・リストからオントロジーまでのすべてを表わすために用いられるXHTML、XML、RDFという方言が存在しています。

この表現の幅が全く自由で、新しい方言による情報表現を促進している一方で、異なる領域や分野を越えた理解にとっては障壁になりえます。例えば、ソフトウェアは、いかにして詩、集計表、オントロジーの作者を発見するでしょうか?そして、それぞれの作者が実際には同じ人物であるか否かをソフトウェアはどのように決定できるでしょうか?

以下は、同じ音楽作品が異なるXML方言でいかに記述されうるかの例です。

iTunes Music Library
<key>Artist</key>
  <string>The Jimi Hendrix Experience</string>
<key>Album</key>
  <string>Are You Experienced?</string>
Audioscrobbler
<album>
    <artist mbid="">The Jimi Hendrix Experience</artist>
    <name>Are You Experienced?</name>
...
</album>
Atom
<entry ... >
<title>Are You Experienced?</title>
<author>
<name>The Jimi Hendrix Experience</name>
</author>
...
</entry>
Open Office
<office:document-meta ... >
<office:meta>
<dc:title>Are You Experienced?</dc:title>
  <meta:initial-creator>
  The Jimi Hendrix Experience
  </meta:initial-creator>
<dc:creator>The Jimi Hendrix Experience</dc:creator>
</office:meta>
</office:document-meta>

上記の例は明らかに同じ情報を符号化したものですが、コンピュータ・ソフトウェアがこの関係性を決定できる明確な仕組みはありません。

資源記述

RDF[RDFC04]は、主語-述語-目的語という表現形式で資源に関するステートメントを出すための標準を提供します。「Are You Experienced?のアーチストはザ・ジミ・ヘンドリックス・エクスペリエンスである」という事実をRDFで表現する一つの方法は、主語がAre You Experienced、その述語が「has artist」(アーチストを持つ)、その目的語がザ・ジミ・ヘンドリックス・エクスペリエンスであるトリプルにすることでしょう。述語「has artist」は、主語(Are You Experienced?)と目的語(ザ・ジミ・ヘンドリックス・エクスペリエンス)との関係を表します。皆がザ・ジミ・ヘンドリックス・エクスペリエンスを知っているわけでも、常に名前を綴れるわけでもないため、URIを用いて、アルバム、アーチスト、および、その関係をも一意に識別することで、ソフトウェア設計が容易になるでしょう。

上記のXMLフラグメントに含まれる情報を、以下に、今回はRDFで表現しています。

<rdf:RDF
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/">

  <rdf:Description rdf:about=
"http://musicbrainz.org/mm-2.1/album/6b050dcf-7ab1-456d-9e1b-c3c41c18eed2">
    <dc:title>Are You Experienced?</dc:title>
    <foaf:maker>
      <foaf:Agent rdf:about=
  "http://musicbrainz.org/mm-2.1/artist/33b3c323-77c2-417c-a5b4-af7e6a111cc9">
        <foaf:name>The Jimi Hendrix Experience</foaf:name>
      </foaf:Agent>
    </foaf:maker>

  </rdf:Description>
</rdf:RDF>

エンティティー(主語と目的語という資源)と関係(述語)の両方が、一意のURIを用いて識別されています。

国際化資源識別子(Internationalized Resource Identifiers)すなわちIRI[RFC3987]の使用において、GRDDLがHTML 4、RDF、およびXMLスキーマに準拠していることに注意してください。非公式に使用する場合には、この仕様では、より知られている用語URIを、最近標準化された用語IRIとほぼ同様の意味で用いますが、公式な規則では関連用語を厳密に使用します。

また、上記のXMLの作者は、RDF/XMLやその他のRDF構文の一つを用いて、RDFで同じデータを提供できるでしょう。GRDDLは、RDFの構築から各方言専用の変換アルゴリズムの作成へ負担を移し、統一化されたXML方言からRDFコンテンツを自力で出力するための比較的安価な手段を提供します。

GRDDLは、参照を直接包含するか、プロファイルと名前空間ドキュメントによって間接的に個々の文献に変換を関連づけることにより機能します。コンテンツの作者は、コンテンツからRDFを生成するための変換を指名し、それを参照するためにGRDDLを用います。

忠実な翻訳

GRDDL変換を指定することにより、ドキュメントの作者は、その変換が、ソース・ドキュメントで使用しているXML方言で表現されている情報(または、情報のある部分)のRDFによる忠実な翻訳を提供していると述べます。

同様に、GRDDL名前空間変換やプロファイル変換を指定することにより、その名前空間やプロファイルの作者は、その変換が、その名前空間やプロファイルに関連づけられているソース・ドキュメントのクラスの忠実なRDF翻訳を提供していると述べます。名前空間ドキュメントやプロファイル・ドキュメントは、その作者が変換の目的や方針宣言を散文で説明する方法も提供します。

序文と付属文書

このGRDDL仕様は、GRDDLの仕組みとそのXML構文に関する簡潔な技術仕様書です。正当なXHTMLおt整形式のXMLドキュメントで用いるGRDDL構文と、GRDDLを名前空間とHTMLプロファイルにコード化する方法を定めています。GRDDL変換に関する議論に関するリンクとセキュリティ問題も取り上げています。付録では、より広範な例と、GRDDLを採用している既存のソフトウェアとサービスへのリンクを提供しています。

GRDDL入門

GRDDL入門[primer]は、GRDDLの仕組みを段階的に解説しています。GRDDLユースケース・ドキュメントに基づく多くの例を作成し、ドキュメントとRDFを抽出するための変換とを関連づけるためのGRDDLの手法を例示しています。

GRDDLユースケース

ユースケース・ドキュメント[usecases]は、GRDDLに対する目標と要件を有する多くのユースケースを集めています。これらのユースケースは、 マイクロフォーマット、埋め込みRDF、またはRDFaステートメントを、どのようにXMLおよびXHTMLドキュメントに付加して、様々なタスクを自動化するために後で使用できる有益なデータの抽出を担うGRDDL変換をサポートできるかを示しています。

GRDDLテスト・ケース

GRDDLテスト・ケース[GRDDL-TESTS]は、この仕様を例証するテスト集を提供します。一部のテストによって、規範的なテキストが意図する解釈を明確化できるようになるかもしれません。

2. 整形式XMLへのGRDDLの付加

GRDDL変換リンクと整形式のXMLドキュメントを関連づける一般的な形式は、ソース・ドキュメントをRDFに変換することが予期される実行可能なスクリプトやプログラムを参照するIRI参照またはIRI参照リストである値を持つgrddl名前空間宣言とgrddl:transformation属性をルート要素に付加したものです。この方法は、ルート要素に付加的な名前空間修飾(namespace-qualified)属性を収容できるあらゆるXML方言の用途に適しています。

例えば、http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.htmlにあるこのXMLドキュメントは、次の2つのGRDDL変換にリンクされています。

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:grddl='http://www.w3.org/2003/g/data-view#'
      grddl:transformation="glean_title.xsl
			http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl"
 >
<head>
<title>Are You Experienced?</title>
[...]
</html>
  1. これは、http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xslで識別される変換にリンクされています。
  2. 相対URI参照glean_title.xslを解決して絶対形式にするためには、このXML要素http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.htmlの基底URIを使用します。そして、このドキュメントは、絶対形式http://www.w3.org/2001/sw/grddl-wg/td/glean_title.xslで識別されるGRDDL変換にもリンクされています。
図: 複数の変換へのリンク

タイトルと作者情報の抽出

(svg)

後の項で示すように、GRDDLをHTMLドキュメントに追加する方法が他にあり、HTMLの既存の機能を活用するように特別に設計されており、従って、XML DTDがHTMLのいくつかの方言に課している制約を克服します。正当なXHTMLでGRDDLの使用およびHTMLプロファイルのためのGRDDLを参照してください。

以下に、このマークアップの形式的な仕様を示します。参考情報である機械的バージョンの各規則は、SPARQLグラフパターン[SPARQL]として記述された前提と結論と共に提示しています。名前空間接頭辞の結合、および、より詳細な説明に関しては、機械的な規則の付録を参照してください。これは、これが有益であると考える読者のために含まれています。他の読者は、これを無視してください。

規範的ステートメント機械的な規則
(参考情報)
ルート要素Eを持つXPath[XPATH]ルート・ノードNとすると、
/*/@*[local-name()="transformation"
  and namespace-uri()=
    "http://www.w3.org/2003/g/data-view#"]
という表現が要素Eの属性と一致する場合、その属性の値のスペースで区切られたトークンREFごとに、REFの絶対形([RFC3986]の5.2項 相対解決を参照)によって識別される資源[WEBARCH]は、Eの基底IRI[RFC3987],[XMLBASE]に対するNGRDDL変換です。

スペースで区切られたトークンは、空白文字#x9、xA、#xD、#x20を含まない最大の空でない部分列です。

(?N "/*") gspec:xpath ?E.
(?N """/*/@*[local-name()="transformation" and
    namespace-uri()=
    "http://www.w3.org/2003/g/data-view#"]""")
   gspec:xpath [ fn:string ?V].
?V fn:normalize-space ?Vnorm.
(?Vnorm "[ \t\r\n]+") fn:tokenize [
  list:member ?REF ].
?E fn:base-uri ?BASE.
(?REF ?BASE) fn:resolve-uri ?TXURI.
?TX log:uri ?TXURI.

?N grddl:transformation ?TX.

上記のXMLドキュメントを入力すると、glean_title.xsl変換は、以下のRDF/XMLドキュメントを算出します。

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rdf:Description rdf:about="">
    <dc:title>Are You Experienced?</dc:title>
  </rdf:Description>
</rdf:RDF>

このドキュメントによってシリアル化されたグラフは、http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.htmlで識別される資源のGRDDL結果です。グラフのこのシリアル化が相対URI参照を含むことに注意してください(rdf:about属性の値において)。GRDDL変換によって作り出されたグラフのシリアル化における相対IRI参照を解釈するための基底IRIは、ソース・ドキュメントの基底IRIです。

glean_title.xslという情報資源は、XPathドキュメント・ノードからRDF/XMLドキュメントまで、従って、RDFグラフまでの機能を定義します。この機能は、XSLTドキュメントの変換プロパティーと呼ばれます。詳細は、GRDDL変換の項を参照してください。

整形式のXMLでGRDDLを用いるための一般的な規則は、次の通りです。

情報資源([WEBARCH]、2.2項)IRが、XMLドキュメントによってXPathルート・ノードRで表現され、R変換プロパティーTPを持つGRDDL変換を持ち、Rに適用されたTPがRDFグラフ[RDFC04]Gを作成する場合、GIRGRDDL結果です。
?IR log:uri [ fn:doc ?R ].
?R grddl:transformation [ grddl:transformationProperty ?TP ].
?R ?TP ?G.

?IR grddl:result ?G .

titleauthor.htmlという情報資源には、getAuthor.xsl変換を通した別のGRDDL結果があります。これらの結果を、次の規則によって別の結果と結合できます。

FGIRGRDDL結果である場合、FG統合[RDF-MT]IRGRDDL結果です。
?IR grddl:result ?F, ?G.
(?F ?G) log:conjunction ?H.

?IR grddl:result ?H.

3. XML名前空間ドキュメントでGRDDLの使用

変換は、個々の文献のみにではなく、XML名前空間を共有する複数方言の全体にも関連づけることができます。名前空間URIからの検索に利用できる資源は名前空間ドキュメントです(参照:[WEBARCH]4.5.4項 名前空間ドキュメント)。例えば、名前空間ドキュメントは、XMLスキーマ表現またはRDFスキーマ表現を持つことができ、あるいはコンテンツ・ネゴシエーションを用いてその両方を持つ可能性もあります。

GRDDL変換を方言全体に関連づけるには、grddl:namespaceTransformationプロパティーを名前空間ドキュメントのGRDDL結果に含めてください。

例えば、P3P[P3P]に人為的に類似させたP3Qで書いた次のプライバシーに関する方針について考えてみてください。

<POLICIES xmlns="http://www.w3.org/2004/01/rdxh/p3q-ns-example">
	<EXPIRY max-age="604800"/>
...

P3Qの名前空間ドキュメントは、grokP3Q.xsl変換をすべてのP3Qドキュメントに関連づけます。

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dataview="http://www.w3.org/2003/g/data-view#">
 <rdf:Description rdf:about="http://www.w3.org/2004/01/rdxh/p3q-ns-example">
   <dataview:namespaceTransformation
       rdf:resource="http://www.w3.org/2004/01/rdxh/grokP3Q.xsl"/>
 </rdf:Description>
</rdf:RDF>

つまり、次の図で示すように、ルート名前空間名が...p3q-ns-exampleであるすべてのドキュメントは、GRDDL変換として暗示的にgrokP3Q.xslを持っています。

図: 名前空間を通した収集
名前空間に適用した変換
(svg)

XHTML名前空間ドキュメントhttp://www.w3.org/1999/xhtmlのような、いくつかの名前空間ドキュメントには、非常に多くの参照が付与されています。GRDDLを意識したエージェントが、これらのドキュメントを参照するあるドキュメントを処理するたびに、これらのドキュメントを検索すれば、これらのドキュメントの提供元サーバは過負荷になりえます。したがって、GRDDLを意識したエージェントは、すべての参照においてこのようなドキュメントを検索すべきではなく、何らかのキャッシュを保持するか、それらのドキュメントが示す変換のローカル・メモリを適用すべきです。発表された情報の誤伝を避けるためには、GRDDLを意識したエージェントは、このローカル・メモリを確実に最新のものにしておくべきであり、また、キャッシュを設定または無効にするユーザ・オプションをサポートすべきです。[WEBARCH]3.1. 資源へのアクセスのためのURIの使用の項を参照してください。

一般的な名前空間変換の例は、以下の通りです。

規範的ステートメント機械的な規則
(参考情報)
以下の場合、
  • IRI NSで識別される情報資源NSDOCが、次のトリプルGRDDL結果を持つ
    • 主語がNSDOCであり、
    • その述語がプロパティー<http://www.w3.org/2003/g/data-view#namespaceTransformation>であり、
    • その目的語がTXである
  • かつ、情報資源IRがルート・ノードNODEと 名前空間NSを持つルート要素を持つXML表現を持つ
TXは、NODEGRDDL変換です。
?NSDOC log:uri ?NS;
   grddl:result [
     log:includes [
       rdf:subject ?NSDOC;
       rdf:predicate grddl:namespaceTransformation;
       rdf:object ?TX]].
?IR log:uri [ fn:doc ?NODE].
(?NODE "/*") gspec:xpath ?E.
?E fn:namespace-uri ?NS.

?NODE grddl:transformation ?TX.

基本事例として、RDF/XMLドキュメントのパースの結果がそのドキュメントのGRDDL結果であるということに注意してください。

規範的ステートメント機械的な規則
(参考情報)
情報資源IRが、準拠しているRDF/XMLドキュメント[RDFX]によって表現される場合、そのドキュメントによって表現されたRDFグラフはIRGRDDL結果です。
?IR log:uri [ fn:doc [ gspec:rdfParse ?G ] ].

?IR grddl:result ?G.

application/rdf+xmlメディア・タイプは、ドキュメントがRDF/XMLであることを示す方法の一つですが、「他の手段」によってRDF/XMLドキュメントを識別しうる可能性が、[RDFX]7.2.1 文法の開始の項に残っていることに注意してください。ローカル名がRDFで、名前空間URIがhttp://www.w3.org/1999/02/22-rdf-syntax-ns#であるルート要素は、上記の規則を目的とした、そのような手段の一つです。その一例に関しては、grddlonrdf-xmlmediatypeテスト・ケースを参照してください。

例: XMLスキーマ名前空間ドキュメントでのGRDDLの使用

名前空間変換リンクは、名前空間ドキュメント自体を変換することで、発見できるかもしれません。これが、名前空間ドキュメントが直接RDF/XMLで記述されている必要のないことを意味することに注意してください。

XMLスキーマで表現された名前空間ドキュメントを持つ発注書の例を考えてみましょう。この場合、XMLスキーマは、namespaceTransformationステートメントを含んだステートメントの抽出を許可するdata-view:transformation属性を有しています。

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns="http:.../Order-1.0"
            targetNamespace="http:.../Order-1.0"
            version="1.0"
            ...
            xmlns:data-view="http://www.w3.org/2003/g/data-view#"
            data-view:transformation="http://www.w3.org/2003/g/embeddedRDF.xsl" >
    <xsd:element name="Order" type="OrderType">
    <xsd:annotation 
      <xsd:documentation>This element is the root element.</xsd:documentation>
    </xsd:annotation>
                 ...
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
	<rdf:Description rdf:about="http://www.w3.org/2003/g/po-ex">
	  <data-view:namespaceTransformation
	      rdf:resource="grokPO.xsl" />
	</rdf:Description>
      </rdf:RDF>
    </xsd:appinfo>
  </xsd:annotation>
...

このスキーマを名前空間ドキュメントとして用いるすべての発注書は、以下に示すようにgrokPO.xsl変換にリンクされています。

図: 名前空間を通した収集

XMLスキーマでのGRDDLの使用

(svg)

4.正当なXHTMLでのGRDDLの使用

XHTML[XHTML]のDTDベースの構文に対応するために(これは異質の名前空間からの属性の使用を防ぐ)、http://www.w3.org/2003/g/data-viewをメタデータ・プロファル(参照:[HTML4]7.4.4.3 メタデータ・プロファイルの項)として使用します。

正当なXHTMLドキュメントにGRDDL言明を付加する一般的な形は、head要素のprofile属性にGRDDLプロファイルを指定し、ソース・ドキュメントをRDFに変換することが予期される実行可能なスクリプトやプログラムを参照するIRI参照であるhref属性値を持つlinkまたはa要素のrel属性値としてtransformationを指定することです。この方法は、XML DTDによる制約がある正当なXHTMLドキュメントでの使用に適しています。

ダブリン・コア・メタ変換の例

例えば、このドキュメントは[RFC2731]の慣例に従っており、変換が忠実な翻訳であることを示すために、GRDDLプロファイルを明示的に使用し、RDF/XMLへのXSLT変換にリンクしています。

<html xmlns="http://www.w3.org/1999/xhtml">
  <head profile="http://www.w3.org/2003/g/data-view">
    <title>Some Document</title>

    <link rel="transformation"
       href="http://www.w3.org/2000/06/dc-extract/dc-extract.xsl" />
    <meta name="DC.Subject"
       content="ADAM; Simple Search; Index+; prototype" />
    ...
  </head>
  ...
</html>

以下の図は、ソース・ドキュメント、dc-extract.xsl変換、およびGRDDL結果を示します。

図: 変換へのリンク

HTMLメタデータのRDFへのデコーディング

(svg)

以下は、RDF/XMLでのデータの見え方です。

<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="">
    <dc:subject>ADAM; Simple Search; Index+; prototype</dc:subject>
  </rdf:Description>
</rdf:RDF>

XHTMLにおける複数変換

XHTMLドキュメントは、同時に多くの方言に準拠し、1つ以上のGRDDL変換にリンクされているかもしれません。しかし、linkおよびa要素のhref属性では、一つのIRI参照のみて認められているため、複数のリンクを言明するためには、これらの要素のインスタンスを複数用いなければなりません。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2003/g/data-view">
  <title>Joe Lambda's Home page [an example of RDF in XHTML]</title>

  <link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokFOAF.xsl" />
  <link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokCC.xsl" />
  <link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokGeoURL.xsl" />
...
図: 複数の変換へのリンク

複数の変換

(svg)

正当なXHTMLを持つGRDDLの規則

一般的な規則は以下の通りです。

XPathルート・ノードNとすると、Nメタデータ・プロファイル名http://www.w3.org/2003/g/data-viewを持つ場合、rel属性[HTML4]がその空白で区切られた値の1つとしてtransformationを持つalink子孫要素Eごとに、Eの基底IRIに対するhref属性の絶対形で識別される資源は、NGRDDL変換です。
?N gspec:profileName "http://www.w3.org/2003/g/data-view".
(?N
""".//*[namespace-uri()="http://www.w3.org/1999/xhtml" and
        (local-name() = "a"
         or local-name() = "link")"""
) gspec:xpath ?E.
(?E "@rel") gspec:xpath [ fn:string [
   fn:normalize-space ?E_REL ]].
(?E_REL "[ \t\r\n]+") fn:tokenize [
 list:member "transformation" ].
(?E "@href") gspec:xpath [ fn:string ?T_REF ].
?E gspec:htmlBase ?BASE.
(?T_REF ?BASE) fn:resolve-uri ?TURI.
?T log:uri ?TURI.

?N grddl:transformation ?T.

XHTMLドキュメントの要素ノードの基底IRIは、基底要素[HTML4]検索URIRFC3986などの要素の影響を受けるかもしれません。さらに明確化するためには、htmlbase1などの基底IRI問題の付録とテスト・ケースを参照してください。

上記の規則は、以下のXHTMLでのメタデータ・プロファイルの形式に依存しています。

XHTMLドキュメントのXPathルート・ノードN(すなわち、ルート要素がhtmlのローカル名とhttp://www.w3.org/1999/xhtmlの名前空間名を持つXMLドキュメント)とすると、head要素Eprofile属性[HTML4]の値におけるそれぞれのスペースで区切られたトークンREFごとに、Eの基底IRIに対するREFの絶対形はNメタデータ・プロファイル名です。
(?N
 """
*[local-name()="html" and
  namespace-uri()="http://www.w3.org/1999/xhtml"] /
 *[local-name()="head" and
   namespace-uri()="http://www.w3.org/1999/xhtml"]""")
 gspec:xpath ?E.
(?E "@profile") gspec:xpath [ fn:string ?V ].
?E fn:base-uri ?BASE.
?V fn:normalize-space ?Vnorm.
(?Vnorm "[ \t\r\n]+") fn:tokenize [  list:member ?P_REF ].
(?P_REF ?BASE) fn:resolve-uri ?PROFID.

?N gspec:profileName ?PROFID.

5. HTMLプロファイル用のGRDDL

XHTMLは、プロパティーの意味と、そのプロパティーに対する一連の正当な値にリンクするためのプロファイルの仕組みを提供します。名前空間ドキュメントと同様に、埋め込まれたRDFステートメントとGRDDL変換を持つXHTMLを用いて、プロファイル・ドキュメントを効率的に記述し、適切な用語の定義を抽出できます。そして、これらの用語は、プロファイルに依存した意味を伝えるためにXHTMLドキュメントで使用できます。正当なXHTMLでのGRDDLの使用で論じたように、GRDDLプロファイルは、rel属性の値が変換であるリンク要素にGRDDLセマンティクスを適用するためにXHTMLドキュメントで使用できます。この非常に強力で柔軟なメカニズムは、通常ではセマンティック的に弱いHTMLのマークアップに被せるマイクロフォーマット・プロファイル[MF-RDF-FAQ]とうまく組み合わせられます。

以下の図表は、XFNドキュメント[XFN]であるfriends.htmlがXFNプロファイルを通して間接的にgrokXFN.xsl変換と関連づけられていることを示しています。

図: プロファイルを通して間接的にリンクされた変換

プロファイルを通した間接法

(svg)

プロファイル・ドキュメントへのGRDDLのprofileTransformation言明の追加は、名前空間ドキュメントへのnamespaceTransformation言明の追加とよく似ています。 正当なXHTMLプロファイル・ドキュメントで定義された方言の場合は、head要素にprofile="http://www.w3.org/2003/g/data-view"を追加し、方言の変換にタイプprofileTransformationのリンクを作成してください。

一般的な規則は以下の通りです。

以下の場合、
  • IRI PNAMEで識別される情報資源PDOCが、次のトリプルを含むGRDDL結果を持つ
    • 主語がPDOCであり、
    • その述語がプロパティー<http://www.w3.org/2003/g/data-view#profileTransformation>であり、
    • その目的語がTXである
  • かつ、情報資源IRメタデータ・プロファイル名PNAMEを持つXPathルート・ノードNODEを持つXML表現を持つ
TXは、NODEGRDDL変換です。
?PDOC log:uri ?PNAME;
   grddl:result [
     log:includes [
       rdf:subject ?PDOC;
       rdf:predicate grddl:profileTransformation;
       rdf:object ?TX]].
?IR log:uri [ fn:doc ?NODE].
?NODE gspec:profileName ?PNAME.

?NODE grddl:transformation ?TX.

6. GRDDL変換

上述のように、各GRDDL変換は、XPathドキュメント・ノードからRDFグラフへの機能である変換プロパティーを定めます。この機能は完全である必要はなく、すべてのXMLドキュメント・ノードよりも小さい領域にすることができます。例えば、xsl:messageterminate="yes"と一緒に用いて、入力が変換の領域外であることを示すことができます。

変換の開発者は、広くサポートされている形式で利用可能な表現をすべきです。執筆時点では、XSLT2[XSLT2]の開発が増加しているものの、GRDDLを意識したエージェントが最も広くサポートしている形式はXSLTバージョン1[XSLT1]です。GRDDLの変換を表現するためには、技術的に、Javascript、C、または、実際にはあらゆる他のプログラミング言語を使用できますが、XSLTはXMLからXMLへの変換を表現するために特別に設計されており、いくつかの優れた安全な特徴を持っています。執筆時点では、GRDDLの実装においてXQueryの使用はそれほど広く展開されていませんが、XQueryはXSLTと同様の特徴を持っています。

以下の場合、
  • RDFXMLが、RDFグラフGを表わす適合RDF/XMLドキュメント[RDFX]のルートXPathノードであり、
  • Rが、あるXMLドキュメントのルート・ノードであり、TXNODEがXSLT変換[XSLT1]のルート・ノードであり、
  • TXNODERに適用されるときに、RDFXMLがXSLT結果ツリーのルート・ノードであり、
  • TXDOCが、ルート・ノードTXNODEを持つXMLドキュメントによって表現された変換プロパティーTPを持つ情報資源である
TPRGに関連づけます。
?RDFXML gspec:rdfParse ?G.
(?TXNODE ?R) gspec:resultTree ?RDFXML.
?TXDOC grddl:transformationProperty ?TP;
  log:uri [fn:doc ?TXNODE].

?R ?TP ?G

上記の規則は、RDF/XMLドキュメントを通してXPathドキュメント・ノードをRDFグラフに関連づける変換プロパティーの例を扱っています。変換は、他の未確定の仕組みを使用できます。例えば、テスト#atomttl1を参照してください。この中では、xsl:output要素のmedia-type属性が「application/rdf+xml」以外のメディア・タイプを示す「text/rdf+n3」という値を持っています。このようなメディア・タイプを処理できるGRDDLエージェントは、メディア・タイプに従ってRDFグラフを作成できます。XSLTではない変換は、RDFグラフを、ある他の未確定の方法で示すことができます。

現時点では、情報資源がXMLドキュメントで表現されている場合には、例えば、エージェントが包含、パラメタ・エンティティー、固定およびデフォルトの属性を作り出すのかどうか、デジタル署名を確認するのかどうかによるため、対応するXPathデータ・モデルを完全に決定できるわけではありません。言い換えれば、作者がXMLドキュメントの情報に責任を持つとすれば、作者はどのような情報に厳密には責任を持つのでしょうか?そして、GRDDL変換がGRDDLの忠実な翻訳の保証を満たしていることを、作者はどのようにして保証できるのでしょうか?

この仕様では、エージェントまたはGRDDLを意識したエージェントがどのXMLプロセッサを採用するのかという質問に関しては何も述べていません。XInclude、XML妥当性、XMLスキーマ妥当性、XML署名またはXML暗号の処理が行われるかどうかは、現在未確定です。しかし、この仕様は、XML処理モデル・ワーキング・グループが、デフォルト処理モデルのTAG問題xmlFunctions-34と定義を解決すれば、さらなる明確化とガイダンスが提供されると見込んでおり、これが発表されれば、GRDDLを意識したエージェントがそのようなガイダンスに従うと予想しています。一般的には、GRDDL変換を実行する前に、XSLTプロセッサがそのような処理を要求するという見込みはありません。したがって、GRDDL変換は、関連するDTD、スキーマ、名前空間の処理を含むすべての予期される前処理を実行するように記述されていることが推奨されます。このような手段は、このような前処理によって忠実な情報セット(infoset)を生成する必要のないドキュメントに対しては避けられます。XInclude、DTD、XMLスキーマなどを参照しないドキュメントに対してということです。

ドキュメントの作者、特にXHTMLドキュメントの作者が、自分のドキュメントをGRDDLと一緒の用いるときに、そのドキュメントが明確なものであって欲しいと考えるならば、外部のDTDサブセットへの依存を避けるべきです。特に次の場合。

XMLドキュメント上で実行する操作を記述するための言語であるXProc : XMLパイプライン言語[XPROC]が、W3C草案として最近発表されました。これは、さまざまなXML処理ツールによって処理の流れを制御する必要がある、複雑もしくは高機能な変換を表現するために検討してみる価値があります。XProcを用いれば、XInclude、妥当性検証、変換のような一連の作業をドキュメントに適用でき、例えば、中間段階の結果が有効でない場合には中断できます。

7. GRDDLを意識したエージェント

GRDDLを意識したエージェントは、情報資源のGRDDL結果を算出するソフトウェア・モジュールです。

例えば、SPARQL問合せサービスは、RDFデータを収集するためにGRDDLを意識したエージェントを使用するかもしれません。あるいは、ウェブ・ブラウザがカレンダーや連絡先データを収集する目的のためにGRDDLを意識したエージェントの機能を果たすかもしれません。どの結果をいつ算出するかの適切な方針は、問合せサービスよりもウェブ・ブラウザの場合にユーザからの合図をより待つことを意味する可能性が高いです。

以下のセキュリティに関する考察およびその設定で示されているローカル・ポリシーに従い、情報資源IRおよびIRを表現するためのXPathノードNを仮定するとき、GRDDLを意識したエージェントは以下のように動作するべきです。

  1. Nに関連づけられている次の各変換を発見する。
    1. 整形式XMLへのGRDDLの付加のようにgrddl:transformation属性によってNに関連づけられている各変換
    2. 正当なXHTMLでのGRDDLの使用の項のように、ドキュメントがhttp://www.w3.org/2003/g/data-viewプロファイルを持つ場合の、タイプtransformationのHTMLリンクによってNに関連づけられている各変換
    3. XML名前空間用のGRDDLの項のように、任意の利用可能な名前空間ドキュメントによって示される各変換
    4. HTMLプロファイル用のGRDDLの項のように、任意のXHTMLプロファイルによって示される各変換
  2. GRDDL結果を得るために、任意の、またはすべての発見された変換を選択的に適用する。エージェントの能力、ローカル・セキュリティ・ポリシー、そして、恐らくユーザ/クライアントの介在によって選択が導かれるかもしれないことに注意。
  3. これらのGRDDL結果を統合します。

名前空間またはプロファイル・ドキュメントによる発見が再帰的であることに注意してください。無限再帰を避けるために、プロファイル/名前空間の構造のループを検出する必要があります。

例: GRDDLを意識したエージェントのプロトコルのトレーシング

GRDDLのこの宣言的仕様ではさまざまな実装方法を認めていますが、この例では、多くの典型的な実装に共通する動きをたどります。

http://www.w3.org/2003/g/po-doc.xmlの結果を求められているGRDDLを意識したエージェントを考えてみてください。そのURIを間接参照することで始まります。RDF/XML、HTMLおよびXMLの表現が認められていることに注意してください。

[00:00.000 - client connection from 127.0.0.1:39645]
GET http://www.w3.org/2003/g/po-doc.xml HTTP/1.1
Host: www.w3.org
Accept: application/rdf+xml,application/xml,text/xml,application/xhtml+xml,text/html

[00:00.055 - server connected]
HTTP/1.1 200 OK
Last-Modified: Tue, 07 Dec 2004 22:59:02 GMT
Content-Length: 1302
Content-Type: application/xml; qs=0.9

<purchaseOrder orderDate="1999-10-20"
   xmlns="http://www.w3.org/2003/g/po-ex"
   <shipTo country="US">
      <name>Alice Smith</name>
      <street>123 Maple Street</street>
...

返されるXMLドキュメントには明確な変換マークアップがありませんが、XML名前空間の項の規則では、名前空間ドキュメントからの結果を調べることが勧められています。

[00:00.000 - client connection from 127.0.0.1:39647]
GET http://www.w3.org/2003/g/po-ex HTTP/1.1
Host: www.w3.org
Accept: application/rdf+xml,application/xml,text/xml,application/xhtml+xml,text/html

[00:00.051 - server connected]
HTTP/1.1 200 OK
Content-Location: po-ex.xsd
Last-Modified: Tue, 07 Dec 2004 23:18:25 GMT
Content-Length: 2624
Content-Type: application/xml; qs=0.9

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:po="http://www.w3.org/2003/g/po-ex"
        targetNamespace="http://www.w3.org/2003/g/po-ex"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"

   xmlns:data-view="http://www.w3.org/2003/g/data-view#" 
   data-view:transformation="http://www.w3.org/2003/g/embeddedRDF.xsl"  >

  <xs:annotation>
    <xs:appinfo>
      <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
        <rdf:Description rdf:about="http://www.w3.org/2003/g/po-ex">
          <data-view:namespaceTransformation
              rdf:resource="grokPO.xsl" />
        </rdf:Description>
      </rdf:RDF>
    </xs:appinfo>
  </xs:annotation>
...

まだRDF/XMLドキュメント形式の結果は得られていませんが、今回はGRDDL名前空間における明確なtransformation属性が得られるため、そのリンクをたどります。XML表現が認められていることに注意してください。

00:00.000 - client connection from 127.0.0.1:39649]
GET http://www.w3.org/2003/g/embeddedRDF.xsl HTTP/1.1
Host: www.w3.org
Accept: application/xml

[00:00.054 - server connected]
HTTP/1.1 200 OK
Last-Modified: Wed, 23 Mar 2005 18:49:12 GMT
Content-Length: 797
Content-Type: application/xml; qs=0.9

<xsl:transform
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
...

この変換の適用によって、以下が得られ…

<rdf:RDF
   xmlns:data-view="http://www.w3.org/2003/g/data-view#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>  <rdf:Description rdf:about="http://www.w3.org/2003/g/po-ex">
    <data-view:namespaceTransformation rdf:resource="http://www.w3.org/2003/g/grokPO.xsl"/>
  </rdf:Description>
</rdf:RDF>

これは、.../grokPO.xslが、.../po-ex名前空間中のすべてのドキュメントに対する変換であることを示します。

再帰的に継続し、名前空間ドキュメントにpo-ex.xsdがないかを調べます。これは、有名な名前空間ドキュメントであるため、セキュリティに関する考察の項に従い、リクエスト中にキャッシュされたコピーの最終更新日に注目すれば、そのコピーが最新のものであることを提供元サーバが教えてくれます。

[00:00.000 - client connection from 127.0.0.1:39651]
GET http://www.w3.org/2001/XMLSchema HTTP/1.1
Host: www.w3.org
Accept: application/rdf+xml,application/xml,text/xml,application/xhtml+xml,text/html
If-modified-since: Fri, 16 Dec 2005 14:19:38 GMT

[00:00.047 - server connected]
HTTP/1.1 304 Not Modified
Content-Location: XMLSchema.html
Expires: Wed, 07 Feb 2007 15:09:29 GMT
Cache-Control: max-age=21600
Vary: negotiate, accept, accept-charset

XMLスキーマ名前空間ドキュメントのキャッシュされたコピーは関連するGRDDL変換を示さないため、po-exからの名前空間変換、つまりgrokPO.xslに戻ります。

[00:00.000 - client connection from 127.0.0.1:39653]
GET http://www.w3.org/2003/g/grokPO.xsl HTTP/1.1
Host: www.w3.org
Accept: application/xml

[00:00.048 - server connected]
HTTP/1.1 200 OK
Last-Modified: Tue, 07 Dec 2004 23:33:28 GMT
Content-Length: 1739
Content-Type: application/xml; qs=0.9

<xsl:transform
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:po="http://www.w3.org/2003/g/po-ex"
    xmlns:poF="http://www.w3.org/2003/g/po-ex#"
    >

<xsl:output method="xml" indent="yes" />

<div xmlns="http://www.w3.org/1999/xhtml">
<h1>grokPO.xsl -- interpret purchase order format as RDF</h1>...

この変換をpo-doc.xmlに適用すると、RDF/XMLが得られます。これをRDFグラフにパースし(基底URIとして、ソース・ドキュメントhttp://www.w3.org/2003/g/po-doc.xmlのURIを使用して)、そのグラフをpo-doc.xmlのGRDDL結果として返します。

<rdf:RDF
   xmlns:poF="http://www.w3.org/2003/g/po-ex#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>
  <rdf:Description rdf:nodeID="hOhqYGhx9">
    <poF:city>Mill Valley</poF:city>
    <poF:state>CA</poF:state>
    <poF:zip>90952</poF:zip>
    <poF:street>123 Maple Street</poF:street>
    <poF:name>Alice Smith</poF:name>
  </rdf:Description>
...

HTTPトレース・データは、Shane Hathawayが作成したTCPWatchによって収集しました。詳細に関しては、GRDDLテスト資料のHTTPトレーシングを参照しください。

8. セキュリティに関する考察

汎用プログラミング言語を変換のインタープリターとして実行すると、重大なセキュリティ上の危険性が露呈します。GRDDLを意識したエージェントの設計者は、GRDDL変換を「容易に入手可能な」インタープリターに単に送信するのは避けた方が良いでしょう。通常、信頼できる情報源のドキュメントをGRDDL変換に通すことは安全ですが、開発者は、任意のウェブ・ドキュメントからリンクされた任意のGRDDL変換を実行する性能を追加する前に以下のすべてを検討すべきです。

多くのウェブ技術と同様に、GRDDLは基本的にURIの「間接参照」に依存します。GRDDL変換の作成者は、潜在的に危険なURL操作を採用しない方が良いでしょう。なぜなら、この操作は安全なGRDDLの実装においては利用できない可能性が高いからです。GRDDL変換を実行するソフトウェアは、すべての潜在的に危険なURL操作を完全に無効にするか、その操作に対する特権を譲らないように特別な注意を払う方が良いでしょう。特に、URLを読み書きする操作は、現行ユーザではなく、信頼できない人々に係る特権を用いることでより安全に実行できます。このような無効化および/または確認は、完全に変換言語自体の範囲外で実行すべきです。これらの操作の全機能を搭載したバージョンを復活させる方法が確実に存在しないようにするよう注意が必要です。

この項の残りでは、恐らくすべてではありませんが、いくつかのGRDDL変換の実行に関して起こり得る問題(特にXSLTの変換に関連する)について概説します。

  1. GRDDLを制約なく使用できると、読み書きの権限を、変換の作成者は持っていないが、エンドユーザが持っているURLに、信頼できない変換がアクセスするかもしれません。これは、特にfile:スキームのURLに当てはまりますが、他の多くのスキームも影響を受けます。信頼できないコードは、作成者がアクセスする権限を持っていないドキュメントを読み込むと、URL中のコンテンツをコード化して、任意のウェブ・サーバにドキュメントのコンテンツを送信し、サーバに渡すことができます。
  2. XSLT言語で書かれた危険な操作には、document()doc()unparsed-text()unparsed-text-available()といったURLの取得を伴う操作、およびURLへの書き込みを伴うxsl:result-documentを含まれていますが、これに限られてはいません。xsl:includexsl:importは、変換の実行中ではなく実行前に処理されれば、危険性が少なくなります。
  3. 変換言語の実装によって、その他のプログラミング言語コードを読み込み、実行する機能を提供できることがあります。例えば、XSLTの実装により、Javaコードを実行するための方法が提供されます。このような機能は、明らかに悪用されやすいです。GRDDL変換の設計者は、このような機能を利用しない方が良いでしょう。これらは、実装に固有であるだけではなく、変換言語の安全な実装において入手できない可能性が高いです。GRDDL変換を実行しているソフトウェアで、このような複数のオペレータが出くわした場合には、使用を止めるべきです。
  4. XSLTの実装はしばしば、独自の拡張を行います。GRDDL変換の設計者は、拡張を使用しない方が良いでしょう。なぜなら、その拡張がすべての実装に存在するという保証がないからです。GRDDL変換を実行するソフトウェアは、拡張が確実に安全であり、いかなる脅威も与えないことを確かめるべきです。
  5. システム資源を過度に消費したり、無限にループする変換を書くことが可能であるため、どちらの変換も、疑いを持たない受信者に送信すれば、損害を与える可能性があります。GRDDL変換の設計者は、このような変換の作成と普及を避ける方が良いでしょう。GRDDL変換を実行するソフトウェアは、適度な時間が経過した後に処理を中止するような適切な手段を提供すべきです。さらに、GRDDLのソフトウェアは、適量なシステム資源のみを消費するように制限すべきです。
  6. 最後に、変換言語のインタープリターにはバグが存在する可能性があり、受信者側のシステムへの不正アクセスに利用されるかもしれません。この可能性を注記することとは別に、このようなバグが発見された時にタイムリーな修正を行うのみではなく、これを防止するための具体的な行動を取る方が良いでしょう。

9. GRDDL語彙

以下は、GRDDLプロファイル/名前空間ドキュメントから抜粋しています。

このドキュメントhttp://www.w3.org/2003/g/data-viewは、7.4.4.3 メタデータ・プロファイルの項のHTML仕様という意味におけるメタデータ・プロファイルです。

ここでは、次の用語をXHTMLリンク関係名とRDFプロパティー名として紹介します。

ここでは、次の用語をRDFプロパティーとして紹介します。

次の用語は、既存の規格の概念に結び付いています。

名前空間ドキュメントは、GRDDL語彙の用語に関するRDFデータを含んでいますが、これらのRDFデータは、述語がgrddl:profileTransformationであるトリプルを含んでいません。

XML名前空間ドキュメントでのGRDDLの使用の項においては、明確なgrddl:namespaceTransformationトリプルのみが規則の前提を満たします。同様に、grddl:profileTransformationトリプルは、この項とHTMLプロファイル用のGRDDLの規則の前提を満たすために、プロファイル・ドキュメントのGRDDL結果において明確でなければなりません。GRDDLソース・ドキュメントの作者は、このようなトリプルを含意するものの明確には述べないRDFSまたはOWLの表現を使用しない方が良いでしょう。

10. 参考文献

規範的な参考文献

RFC3987
Internationalized Resource Identifiers (IRIs) Internet RFC 3987 January 2005. Duerst, Suignard
RFC3986
Uniform Resource Identifier (URI): Generic Syntax Internet RFC3986 January 2005. Berners-Lee, Fielding, Masinter
WEBARCH
Architecture of the World Wide Web, Volume One , N. Walsh, I. Jacobs, Editors, W3C Recommendation, 15 December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/ . 最新バージョンは、http://www.w3.org/TR/webarch/にあります。
RDFC04
Resource Description Framework (RDF): Concepts and Abstract Syntax , G. Klyne, J. J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . 最新バージョンは、http://www.w3.org/TR/rdf-concepts/にあります。
RDF-MT
RDF Semantics , P. Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . 最新バージョンは、http://www.w3.org/TR/rdf-mt/にあります。
RDFX
RDF/XML Syntax Specification (Revised), D. Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ . 最新バージョンは、http://www.w3.org/TR/rdf-syntax-grammarにあります。
XMLBASE
XML Base , J. Marsh, Editor, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xmlbase-20010627/ . 最新バージョンは、http://www.w3.org/TR/xmlbase/にあります。
XHTML
Modularization of XHTML™ , S. Schnitzenbaumer, F. Boumphrey, T. Wugofski, S. McCarron, M. Altheim, S. Dooley, Editors, W3C Recommendation, 10 April 2001, http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/ . 最新バージョンは、http://www.w3.org/TR/xhtml-modularization/にあります。
HTML4
HTML 4.01 Specification , D. Raggett, A. Le Hors, I. Jacobs, Editors, W3C Recommendation, 24 December 1999, http://www.w3.org/TR/1999/REC-html401-19991224 . 最新バージョンは、http://www.w3.org/TR/html401にあります。
XPATH
XML Path Language (XPath) Version 1.0 , J. Clark, S. J. DeRose, Editors, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116 . 最新バージョンは、http://www.w3.org/TR/xpathにあります。
XSLT1
XSL Transformations (XSLT) Version 1.0 , J. Clark, Editor, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 . 最新バージョンは、http://www.w3.org/TR/xsltにあります。

参考情報の参考文献

以下のドキュメントでは、補足的な背景を提供しますが、この仕様の一部ではありません。

primer
GRDDL Primer , I. Davis, Editor, W3C Working Draft (work in progress), 2 October 2006, http://www.w3.org/TR/2006/WD-grddl-primer-20061002/ . 最新バージョンは、http://www.w3.org/TR/grddl-primer/にあります。
usecases
GRDDL Use Cases: Scenarios of extracting RDF data from XML documents , F. Gandon, Editor, W3C Working Group Note, 6 April 2007, http://www.w3.org/TR/2007/NOTE-grddl-scenarios-20070406/ . 最新バージョンは、http://www.w3.org/TR/grddl-scenarios/にあります。
GRDDL-TESTS
GRDDL Test Cases , C. Ogbuji, Editor, W3C Recommendation, 11 September 2007, http://www.w3.org/TR/2007/REC-grddl-tests-20070911/ . 最新バージョンは、http://www.w3.org/TR/grddl-tests/にあります。
SPARQL
SPARQL Query Language for RDF , E. Prud'hommeaux, A. Seaborne, Editors, W3C Working Draft (work in progress), 26 March 2007, http://www.w3.org/TR/2007/WD-rdf-sparql-query-20070326/ . 最新バージョンは、http://www.w3.org/TR/rdf-sparql-query/にあります。
XSLT2
XSL Transformations (XSLT) Version 2.0 , M. Kay, Editor, W3C Recommendation, 23 January 2007, http://www.w3.org/TR/2007/REC-xslt20-20070123/ . 最新バージョンは、http://www.w3.org/TR/xslt20にあります。
RFC2731
J. Kunze Encoding Dublin Core Metadata in HTML in 1999
XFN
XFN: Introduction and Examples copyright GMPG 2003-2007. Eric, Tantek, and Matt
DCRDF
Expressing Simple Dublin Core in RDF/XML Beckett, Miller, Brickley 2002-07-31
P3P
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification , M. Marchiori, Editor, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ . 最新バージョンは、http://www.w3.org/TR/P3P/にあります。
STYPI
Associating Style Sheets with XML documents , J. Clark, Editor, W3C Recommendation, 29 June 1999, http://www.w3.org/1999/06/REC-xml-stylesheet-19990629 . 最新バージョンは、http://www.w3.org/TR/xml-stylesheetにあります。
XPROC
XProc: An XML Pipeline Language , N. Walsh, Editor, W3C Working Draft (work in progress), 28 September 2006, http://www.w3.org/TR/2006/WD-xproc-20060928/ . 最新バージョンは、http://www.w3.org/TR/xproc/にあります。
MF-RDF-FAQ
Microformat FAQs for RDF Fans, last modified 17:57, 30 May 2006

付録: スタイル用の変換かデータ抽出用の変換か(参考情報)

xml-stylesheet処理命令[STYPI]は、一般的に自動的な表示処理のために使われます。この種のリンクは、データ抽出の促進を目的としているGRDDL変換アルゴリズムへのリンクとは異るものです。また、XSLTプロセッサなどのXMLツールは処理命令の内容分析をサポートしておらず、処理命令をURIスペースに基づかせることは、属性を持つ名前空間を使用するほど簡単ではありません。

付録: 基底IRI問題

整形式XMLへのGRDDLの付加の項では、以下のようなものがあります。

GRDDL変換で作成されたグラフのシリアル化における相対IRI参照を解釈するための基底IRIはソース・ドキュメントの基底IRIです。

これは、RFC3986の、特に5.1項に対応しており、以下の図で、基底URIの識別を示しています。

         .------------------------------------------------------------------.
         |  .------------------------------------------------------------.  |
         |  |  .------------------------------------------------------.  |  |
         |  |  |  .------------------------------------------------.  |  |  |
         |  |  |  |  .------------------------------------------.  |  |  |  |
         |  |  |  |  |                 <相対参照>               |  |  |  |  |
         |  |  |  |  `------------------------------------------'  |  |  |  |
         |  |  |  |   (5.1.1) コンテンツ内に埋め込まれた基底URI    |  |  |  |
         |  |  |  `------------------------------------------------'  |  |  |
         |  |  |  (5.1.2) カプセル化されたエンティティーからの基底URI |  |  |
         |  |  |          (メッセージ、表現、または、なし)          |  |  |
         |  |  `------------------------------------------------------'  |  |
         |  |      (5.1.3) エンティティーを検索するために使用するURI     |  |
         |  `------------------------------------------------------------'  |
         |          (5.1.4) デフォルト基底URI(アプリケーション依存)       |
         `------------------------------------------------------------------'

典型的なGRDDLの処理中に、中間的なRDF/XMLシリアル化が変換の出力として作成されます。このシリアル化をRDFグラフに変換するために、シリアル化における相対参照がIRIに解決されます。任意の相対参照の解決に適した基底IRIを識別するために、RDF構文で認められているようにXMLベースに従い、最初にこのRDF/XML内に埋め込まれた基底URIを確認してください。このRDF/XML内に埋め込まれた基底URIがなければ、このシリアル化のカプセル化されたエンティティーが入力ドキュメントのルート要素であるため、RFC 3986の5.1.2項が当てはまるかもしれません。この要素が基底URIを定義しない場合は、カプセル化されたエンティティー(入力ドキュメント)が基底IRIを定義するかもしれません。

オリジナル・ドキュメントは、XHTMLファミリー・ドキュメントであるかもしれませんし、その他のXMLドキュメントであるかもしれません。

XHTMLファミリー・ドキュメントの基底IRI

XHTMLファミリー・ドキュメントでは、入力ドキュメントの基底IRIは、<base>要素(もしあるならば)のhref属性の値として指定できます。これは、RFC 3986の5.1.1項に従っています。

他の多くのケースでは、5.1.2項は当てはまらず、5.1.3項が当てはまります。5.1.3項は、基底IRIとしての検索IRIの使用を定めています。さらに、RFC 3986の5.1.3項は、以下を定めています。

検索がリダイレクトされた要求の結果であれば、使用された最後のURI(すなわち、実際の表現の検索をもたらしたURI)が基底URIです。

結果として生成されたIRIは、中間的なRDF/XMLシリアル化を処理するための基底IRIパラメータとして使用されます。

他のXMLドキュメントの基底IRI

他のXMLドキュメントは、XMLベースを使用できます。これは、特定のドキュメントのフォーマットがXMLベースの使用を認めるときのみに勧められます。

XMLドキュメントのルート要素にxml:baseがあるときには、これは、RFC 3986の5.1.1項に従い、そのドキュメントに対する基底IRIを定めています。

ルート要素にxml:base属性がないときには、下位要素にそのような属性があったとしても、RFC 3986の5.1.1項は当てはまりません。

次に、XHTMLの場合のように、RFC 3986の5.1.2項、5.1.3項、5.1.4項を考慮しなくてはなりません。

これらのうち、5.1.3項は最も一般的なケースであり、リダイレクトされた検索に関する注記も当てはまります。

処理パイプラインの基底IRI

以下のとき、GRDDLを意識したエージェントがGRDDL結果を算出します。

情報資源IRのURI I、および、IRの表現に対するXPathノードNのとき

また、XPathノードNと同様に、処理パイプラインでGRDDLを意識したエージェントを使用するためには、対応するIRI Iの指定も必要です。他の仕組みが当てはまらないときには、これは基底IRIとして使用されています。これは、RFC 3986の5.1.4項に対応しています。デフォルトのIRIがXPathノードNとの関係を持たないことさえも可能ですが、そのようなケースでは、次のように読めます

この定義は必然的にアプリケーション依存であるため、他の方法のうちの1つを用いて基底URIを定義しないと、異なる種類のアプリケーションによって異なる解釈がなされた同じコンテンツが作成されるかもしれない。

相対参照を含む表現を送信する人には、その参照に対する基底URIの確立を保証する責任がある。

基底IRIの正しい処理に対する責任

プロファイルと名前空間ドキュメントを含むドキュメントの作者

一般的に、ドキュメントが他のURIから検索可能であれば、ドキュメントの作者は基底URIを含むべきです。

XHTMLファミリー・ドキュメント[XHTML]に関しては、これは、base要素を用いて行います。

他のXMLドキュメントに関しては、フォーマットがxml:baseをサポートする場合に使用すべきです。一般的に、ルート要素でこれを行えば混乱が最も少ないと経験的に言えるでしょう。また、ドキュメントの作者は、ドキュメント・フォーマットで認められている場合、XMLベース[XMLBASE]で定義されているようなセマンティクスで、自分のドキュメントのほかの部分でもxml:base属性を使用できます。

xml:baseをサポートしておらず、XHTMLファミリー・ドキュメントではないフォーマットのXMLドキュメントに関しては、GRDDLにはインラインの基底URIを指定するためのサポートはありません。

例えば、複数のURIでプロファイルまたは名前空間ドキュメントにリダイレクトによってアクセスできるとき、ドキュメントの作者は、一般的に、これらのURIのそれぞれに対してプロファイル変換または名前空間変換を指定するGRDDL結果を提供すべきです。

GRDDLを意識したエージェント

RDF/XML用の規則を用いてGRDDL結果がRDF/XMLで表されるとき、RDF/XML構文仕様[RDFX]の規則に従って、RDFグラフに変換するために、この表現には基底URIが必要でありえます。

他の方法で表されたGRDDL結果は、基底URIも必要でありえます。

上記の分析に従い、相対参照を解決するための基底URIは、RFC 3986の5.1項に従うことで定義されます。

多くのアプリケーションでは、RFC 3986の5.1.4項によれば、GRDDL結果がアプリケーションのデフォルトURIに依存するのは非常に好ましくありません。この可能性をエラーとして扱うGRDDLを意識したエージェントもあるかもしれません。

GRDDL変換の作者

一般に、XHTMLファミリー・ドキュメントからRDF/XMLへのGRDDL変換を書くときには、最善の助言としては、基底URIに関する問題を無視することです。最も簡単な方法は、入力において任意の相対URIに対応し、出力において相対URIを作成することで、任意の概念に対応する絶対URIが変換に組み込まれます。このような相対URIは、GRDDLを意識したエージェントが処理を実行している間に、正しい基底URIに対して解決されるでしょう。

xml:baseをサポートしておらず、インラインの基底URIを表わす手段を持っていないXMLドキュメント・フォーマットに対するGRDDL変換を書くときには、正しい基底の問題を無視する以外に選択肢はほとんどありません。

xml:baseをサポートしていないが、インラインの基底URIを表わす他の手段を持っているXHTMLファミリー・ドキュメントではないXMLドキュメント・フォーマットに対するGRDDL変換を書くときには、GRDDLを意識したエージェントはこの手段を知らず、良くできたGRDDL変換はこれを修正しようと試みるでしょう。このような方法で基底URIが指定されるときには、RDF/XMLパーサがその基底に対して相対URIを解決し、GRDDLを意識したエージェントが通過した基底URIを無視するように(このフォーマットに特有の慣習を無視しながら算出されるでしょう)、基底URIをxml:base属性の値としてRDF/XML出力に挿入することが1つの方法です。

xml:baseをサポートするXMLドキュメント・フォーマットに対するGRDDL変換を書くときには、GRDDLを意識したエージェントにはルート要素のxml:baseを扱う責任があることを覚えていなければなりません。xml:base属性がある場合、GRDDL変換に関する最も簡単な行為は、それを無視することです。

しかし、ルート要素にはない、その他のxml:base属性は、GRDDLを意識したエージェントはこれを無視するため、変換には責任はありません。したがって、最も簡単に出力グラフの適所にそれらをコピーすることで、これらの下位レベルのxml:baseを尊重すべきです。しかし、一般に、値として絶対URIを持つ中間的なxml:base属性がなければ、先祖ノードのxml:base属性も考慮に入れなければなりません。これをうまく行うことは明らかに簡単ではありません。補助のために、GRDDLライブラリは、スタイルシートにインポートするモジュールを提供してくれます。以下を参照してください。

すべての場合に、しばしば不要ではありますが、ドキュメント全体に対して、入力で指定された絶対ベースURIを変換が意識しているならば、例えば、適切なxml:base属性をrdf:RDF要素に加えることにより、出力に対する基底URIとしてこの基底URIを用いることは決して間違いではありません。

これを行う変換は、相対的な基底URIに関する、間違っている可能性のある同様の処理を防ぐ必要があります。例えば、GRDDLを意識した正しいエージェントと出来の悪い変換との間の対話において、ルート要素のxml:base=".."は2度適用され、ディレクトリ階層において間違ったレベルで解決されている相対参照を作成するでしょう。

謝辞および更新履歴

関連するGRDDL設計履歴および論拠は、1997年頃以来のHTML、PICSおよびRDFに関するコンテキストの当該設計について論じています。編集者は、GRDDLの開発におけるコミュニティー・メンバーの多くの貢献に対し感謝申し上げます。

GRDDLワーキンググループは、Harry Halpinを議長として、数人の貢献者と上記の実装者にChimezie Ogbuji、Fabien Gandon、Brian Suda、Rachel Yagerが加わり、2006年8月に開催されました。

Jeremy CarrollがRFC 2046に基づく詳細なセキュリティに関する考察を提供し、Ian Davisの提案に従ってHTTPヘッダ・リンクを実装しました。

ワーキンググループは、2006年10月24日の草案を発表しました。課題リストは、以後の主な設計上の決定事項を示します。

ステイタスの項以外で、2007年7月16日の発表以後の唯一の更新は、以下の通りです。