【注意】 このドキュメントは、W3CのGleaning Resource Descriptions from Dialects of Languages (GRDDL) W3C Recommendation 11 September 2007の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2007年11月3日
このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。
翻訳版も参照してください。
Copyright © 2006-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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の役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
このドキュメントに関するコメントは、公開アーカイブ付きのメーリングリスト、[email protected]にお送りください。
このドキュメントは、GRDDLワーキンググループが作成したもので、W3Cセマンティック・ウェブ・アクティビティの一部です。このドキュメントの草案としての最初の公開は2006年10月24日で、ワーキンググループは、それ以後に受け取った多くのコメントと課題に取り組んで来ました。規範的な記述は、このようにマークアップされています。
ワーキンググループの実装報告では、このドキュメントの2007年5月の勧告候補草案で設定された相互運用可能な実装の目標が達成されたことを実証しています。
GRDDLは、RDFinXHTML-35、namespaceDocument-8、xmlFunctions-34などのウェブ・アーキテクチャの課題や、rdfms-validating-embedded-rdfやfaq-html-complianceなどのRDFコア・ワーキンググループが先送りした課題への対処に貢献することを目的としています。特に、GRDDLワーキンググループは、issue-faithful-infosetを先送りしており、TAG（訳注：Technical Architecture Groupの略）の課題xmlFunctions-34の解決により、さらなる明確化と指針がもたらされることを予期しています。
このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権（Essential Claim(s)）を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
この草案の一部であった課題付録は、ワーキンググループ課題リストに移動しました。具体的には、issue-whichlangs、issue-output-formats、issue-base-param、issue-tx-element、issue-html-nsdoc、issue-faithful-infoset、issue-mt-ns、issue-conformance-labels、issue-http-header-linksです。
ウェブ上の多くのXMLドキュメントで実際に用いられている、領域固有の言語（「方言」）が多く存在しています。詩から散文まで、発注書から請求書まで、集計表からデータベースまで、スキーマからスクリプトまで、リンク・リストからオントロジーまでのすべてを表すために用いられるXHTML、XML、RDFという方言が存在しています。
この表現の幅が全く自由で、新しい方言による情報表現を促進している一方で、異なる領域や分野を越えた理解にとっては障壁になりえます。例えば、ソフトウェアは、いかにして詩、集計表、オントロジーの作者を発見するでしょうか?そして、それぞれの作者が実際には同じ人物であるか否かをソフトウェアはどのように決定できるでしょうか?
以下は、同じ音楽作品が異なるXML方言でいかに記述されうるかの例です。
<key>Artist</key> <string>The Jimi Hendrix Experience</string> <key>Album</key> <string>Are You Experienced?</string>
<album>
<artist mbid="">The Jimi Hendrix Experience</artist>
<name>Are You Experienced?</name>
...
</album>
<entry ... > <title>Are You Experienced?</title> <author> <name>The Jimi Hendrix Experience</name> </author> ... </entry>
<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おｔ整形式のXMLドキュメントで用いるGRDDL構文と、GRDDLを名前空間とHTMLプロファイルにコード化する方法を定めています。GRDDL変換に関する議論に関するリンクとセキュリティ問題も取り上げています。付録では、より広範な例と、GRDDLを採用している既存のソフトウェアとサービスへのリンクを提供しています。
GRDDL入門[primer]は、GRDDLの仕組みを段階的に解説しています。GRDDLユースケース・ドキュメントに基づく多くの例を作成し、ドキュメントとRDFを抽出するための変換とを関連付けるためのGRDDLの手法を例示しています。
ユースケース・ドキュメント[usecases]は、GRDDLに対する目標と要件を有する多くのユースケースを集めています。これらのユースケースは、マイクロフォーマット、組み込みRDF、またはRDFaステートメントを、どのようにXMLおよびXHTMLドキュメントに付加して、様々なタスクを自動化するために後で使用できる有益なデータの抽出を担うGRDDL変換をサポートできるかを示しています。
GRDDLテスト・ケース[GRDDL-TESTS]は、この仕様を例証するテスト集を提供します。一部のテストによって、規範的なテキストが意図する解釈を明確化できるようになるかもしれません。
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>
後の項で示すように、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]に対するNのGRDDL変換です。
スペースで区切られたトークンは、空白文字#x9、xA、#xD、#x20を含まない最大の空でない部分列です。 |
|
上記の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を作成する場合、GはIRのGRDDL結果です。 |
|
titleauthor.htmlという情報資源には、getAuthor.xsl変換を通した別のGRDDL結果があります。これらの結果を、次の規則によって別の結果と結合できます。
| FとGがIRのGRDDL結果である場合、FとGの統合[RDF-MT]もIRの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を持っています。
XHTML名前空間ドキュメントhttp://www.w3.org/1999/xhtmlのような、いくつかの名前空間ドキュメントには、非常に多くの参照が付与されています。GRDDLを意識したエージェントが、これらのドキュメントを参照するあるドキュメントを処理するたびに、これらのドキュメントを検索すれば、これらのドキュメントの提供元サーバは過負荷になりえます。したがって、GRDDLを意識したエージェントは、すべての参照においてこのようなドキュメントを検索すべきではなく、何らかのキャッシュを保持するか、それらのドキュメントが示す変換のローカル・メモリを適用すべきです。発表された情報の誤伝を避けるためには、GRDDLを意識したエージェントは、このローカル・メモリを確実に最新のものにしておくべきであり、また、キャッシュを設定または無効にするユーザ・オプションをサポートすべきです。[WEBARCH]の3.1. 資源へのアクセスのためのURIの使用の項を参照してください。
一般的な名前空間変換の例は、以下の通りです。
| 規範的ステートメント | 機械的な規則 （参考情報） |
|||
|---|---|---|---|---|
以下の場合、
|
|
基本事例として、RDF/XMLドキュメントのパースの結果がそのドキュメントのGRDDL結果であるということに注意してください。
| 規範的ステートメント | 機械的な規則 （参考情報） |
|||
|---|---|---|---|---|
| 情報資源IRが、適合RDF/XMLドキュメント[RDFX]によって表現される場合、そのドキュメントによって表現されたRDFグラフはIRのGRDDL結果です。 |
|
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テスト・ケースを参照してください。
名前空間変換リンクは、名前空間ドキュメント自体を変換することで、発見できるかもしれません。これが、名前空間ドキュメントが直接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変換にリンクされています。
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結果を示します。
以下は、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ドキュメントは、同時に多くの方言に準拠し、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" />
...
一般的な規則は以下の通りです。
| XPathルート・ノードNとすると、Nがメタデータ・プロファイル名http://www.w3.org/2003/g/data-viewを持つ場合、rel属性[HTML4]がその空白で区切られた値の1つとしてtransformationを持つaとlink子孫要素Eごとに、Eの基底IRIに対するhref属性の絶対形で識別される資源は、NのGRDDL変換です。 |
|
XHTMLドキュメントの要素ノードの基底IRIは、基底要素[HTML4]の検索URIRFC3986などの要素の影響を受けるかもしれません。さらに明確化するためには、htmlbase1などの基底IRI問題の付録とテスト・ケースを参照してください。
上記の規則は、以下のXHTMLでのメタデータ・プロファイルの形式に依存しています。
| XHTMLドキュメントのXPathルート・ノードN（すなわち、ルート要素がhtmlのローカル名とhttp://www.w3.org/1999/xhtmlの名前空間名を持つXMLドキュメント）とすると、head要素Eのprofile属性[HTML4]の値におけるそれぞれのスペースで区切られたトークンREFごとに、Eの基底IRIに対するREFの絶対形はNのメタデータ・プロファイル名です。 |
|
XHTMLは、プロパティーの意味と、そのプロパティーに対する一連の正当な値にリンクするためのプロファイルの仕組みを提供します。名前空間ドキュメントと同様に、組み込まれたRDFステートメントとGRDDL変換を持つXHTMLを用いて、プロファイル・ドキュメントを効率的に記述し、適切な用語の定義を抽出できます。そして、これらの用語は、プロファイルに依存した意味を伝えるためにXHTMLドキュメントで使用できます。正当なXHTMLでのGRDDLの使用で論じたように、GRDDLプロファイルは、rel属性の値が変換であるリンク要素にGRDDLセマンティクスを適用するためにXHTMLドキュメントで使用できます。この非常に強力で柔軟なメカニズムは、通常ではセマンティック的に弱いHTMLのマークアップに被せるマイクロフォーマット・プロファイル[MF-RDF-FAQ]とうまく組み合わせられます。
以下の図表は、XFNドキュメント[XFN]であるfriends.htmlがXFNプロファイルを通して間接的にgrokXFN.xsl変換と関連付けられていることを示しています。
プロファイル・ドキュメントへのGRDDLのprofileTransformation言明の追加は、名前空間ドキュメントへのnamespaceTransformation言明の追加とよく似ています。 正当なXHTMLプロファイル・ドキュメントで定義された方言の場合は、head要素にprofile="http://www.w3.org/2003/g/data-view"を追加し、方言の変換にタイプprofileTransformationのリンクを作成してください。
一般的な規則は以下の通りです。
以下の場合、
|
|
上述のように、各GRDDL変換は、XPathドキュメント・ノードからRDFグラフへの機能である変換プロパティーを定めます。この機能は完全である必要はなく、すべてのXMLドキュメント・ノードよりも小さい領域にすることができます。例えば、xsl:messageをterminate="yes"と一緒に用いて、入力が変換の領域外であることを示すことができます。
変換の開発者は、広くサポートされている形式で利用可能な表現をすべきです。執筆時点では、XSLT2[XSLT2]の開発が増加しているものの、GRDDLを意識したエージェントが最も広くサポートしている形式はXSLTバージョン1[XSLT1]です。GRDDLの変換を表現するためには、技術的に、Javascript、C、または、実際にはあらゆる他のプログラミング言語を使用できますが、XSLTはXMLからXMLへの変換を表現するために特別に設計されており、いくつかの優れた安全な特徴を持っています。執筆時点では、GRDDLの実装においてXQueryの使用はそれほど広く展開されていませんが、XQueryはXSLTと同様の特徴を持っています。
以下の場合、
|
|
上記の規則は、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、妥当性検証、変換のような一連の作業をドキュメントに適用でき、例えば、中間段階の結果が有効でない場合には中断できます。
GRDDLを意識したエージェントは、情報資源のGRDDL結果を算出するソフトウェア・モジュールです。
例えば、SPARQL問合せサービスは、RDFデータを収集するためにGRDDLを意識したエージェントを使用するかもしれません。あるいは、ウェブ・ブラウザがカレンダーや連絡先データを収集する目的のためにGRDDLを意識したエージェントの機能を果たすかもしれません。どの結果をいつ算出するかの適切な方針は、問合せサービスよりもウェブ・ブラウザの場合にユーザからの合図をより待つことを意味する可能性が高いです。
以下のセキュリティに関する留意点およびその設定で示されているローカル・ポリシーに従い、情報資源IRおよびIRを表現するためのXPathノードNを仮定するとき、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 GMTContent-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トレーシングを参照しください。
汎用プログラミング言語を変換のインタープリターとして実行すると、重大なセキュリティ上の危険性が露呈します。GRDDLを意識したエージェントの設計者は、GRDDL変換を「容易に入手可能な」インタープリターに単に送信するのは避けた方が良いでしょう。通常、信頼できる情報源のドキュメントをGRDDL変換に通すことは安全ですが、開発者は、任意のウェブ・ドキュメントからリンクされた任意のGRDDL変換を実行する性能を追加する前に以下のすべてを検討すべきです。
多くのウェブ技術と同様に、GRDDLは基本的にURIの「間接参照」に依存します。GRDDL変換の作成者は、潜在的に危険なURL操作を採用しない方が良いでしょう。なぜなら、この操作は安全なGRDDLの実装においては利用できない可能性が高いからです。GRDDL変換を実行するソフトウェアは、すべての潜在的に危険なURL操作を完全に無効にするか、その操作に対する特権を譲らないように特別な注意を払う方が良いでしょう。特に、URLを読み書きする操作は、現行ユーザではなく、信頼できない人々に係る特権を用いることでより安全に実行できます。このような無効化および/または確認は、完全に変換言語自体の範囲外で実行すべきです。これらの操作の全機能を搭載したバージョンを復活させる方法が確実に存在しないようにするよう注意が必要です。
この項の残りでは、恐らくすべてではありませんが、いくつかのGRDDL変換の実行に関して起こり得る問題（特にXSLTの変換に関連する）について概説します。
以下は、GRDDLプロファイル/名前空間ドキュメントから抜粋しています。
このドキュメントhttp://www.w3.org/2003/g/data-viewは、7.4.4.3 メタデータ・プロファイルの項のHTML仕様という意味におけるメタデータ・プロファイルです。
ここでは、次の用語をXHTMLリンク関係名とRDFプロパティー名として紹介します。
- transformation: ソース・ドキュメントを変換に関連付けます。通常、XSLTで表され、ソース・ドキュメント構文をRDFグラフ構文に関連付けます。定義域: RootNode; 値域: Transformation
ここでは、次の用語をRDFプロパティーとして紹介します。
- namespaceTransformation: 名前空間をその名前空間内のすべてのドキュメントに対する変換に関連付けます。値域: Transformation
- profileTransformation: プロフファイル・ドキュメントをそのプロファイルを持つすべてのドキュメントに対する変換に関連付けます。値域: Transformation
- result: 標準的なRDF/XML構文で表現を直接パースするか、ドキュメントが指定する変換を用いて他の方言を間接的にパースすることにより、情報資源から得られたRDFグラフです。定義域: InformationResource; 値域: RDFGraph
- transformationProperty: XMLドキュメント・ノード・ドメインからRDFグラフを算出するプロパティーが指定するアルゴリズムに変換を関連付けます。定義域: Transformation 値域: TransformationProperty
- Transformation: 1つのXMLドキュメントからRDFグラフへの変換を指定するInformationResourceです。各変換は、TransformationPropertyであるtransformationPropertyを少なくとも1つは持っています。
- TransformationProperty: XMLドキュメント・ルート・ノードをRDFグラフに関連付けるFunctionalPropertyです。
次の用語は、既存の規格の概念に結び付いています。
- RootNode: XML Path Language(XPath)バージョン1.0の5.1項 ルート・ノードにある、XPathデータ・モデルのツリーのルートです。
- RDFGraph: RDF（Resource Description Framework）: 概念および抽象構文の定義にある、1つのRDFトリプルです。
- InformationResource: ウェブ・アーキテクチャ 第1巻の定義にある、すべての本質的特性をメッセージで伝えることができるプロパティーを持っている資源です。
名前空間ドキュメントは、GRDDL語彙の用語に関するRDFデータを含んでいますが、これらのRDFデータは、述語がgrddl:profileTransformationであるトリプルを含んでいません。
XML名前空間ドキュメントでのGRDDLの使用の項においては、明確なgrddl:namespaceTransformationトリプルのみが規則の前提を満たします。同様に、grddl:profileTransformationトリプルは、この項とHTMLプロファイル用のGRDDLの規則の前提を満たすために、プロファイル・ドキュメントのGRDDL結果において明確でなければなりません。GRDDLソース・ドキュメントの作者は、このようなトリプルを含意するものの明確には述べないRDFSまたはOWLの表現を使用しない方が良いでしょう。
以下のドキュメントでは、補足的な背景を提供しますが、この仕様の一部ではありません。
xml-stylesheet処理命令[STYPI]は、一般的に自動的な表示処理のために使われます。この種のリンクは、データ抽出の促進を目的としているGRDDL変換アルゴリズムへのリンクとは異るものです。また、XSLTプロセッサなどのXMLツールは処理命令の内容分析をサポートしておらず、処理命令をURIスペースに基づかせることは、属性を持つ名前空間を使用するほど簡単ではありません。
整形式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は、<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ドキュメントは、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項は最も一般的なケースであり、リダイレクトされた検索に関する注記も当てはまります。
以下のとき、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の確立を保証する責任がある。
一般的に、ドキュメントが他のURIから検索可能であれば、ドキュメントの作者は基底URIを含むべきです。
XHTMLファミリー・ドキュメント[XHTML]に関しては、これは、base要素を用いて行います。
他のXMLドキュメントに関しては、フォーマットがxml:baseをサポートする場合に使用すべきです。一般的に、ルート要素でこれを行えば混乱が最も少ないと経験的に言えるでしょう。また、ドキュメントの作者は、ドキュメント・フォーマットで認められている場合、XMLベース[XMLBASE]で定義されているようなセマンティクスで、自分のドキュメントのほかの部分でもxml:base属性を使用できます。
xml:baseをサポートしておらず、XHTMLファミリー・ドキュメントではないフォーマットのXMLドキュメントに関しては、GRDDLにはインラインの基底URIを指定するためのサポートはありません。
例えば、複数のURIでプロファイルまたは名前空間ドキュメントにリダイレクトによってアクセスできるとき、ドキュメントの作者は、一般的に、これらのURIのそれぞれに対してプロファイル変換または名前空間変換を指定する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を意識したエージェントもあるかもしれません。
一般に、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の開発におけるコミュニティー・メンバーの多くの貢献に対し感謝申し上げます。
推奨される、HTMLへのRDFメタデータの包含方法は、HTML4.01やXHTMLに準拠していない。2001年4月に、Lee Jonasがrdfms-validating-embedded-rdf問題を提起:
XHTMLとその他のXMLドキュメントに組み込まれたRDFの検証は困難。
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日の発表以後の唯一の変更は、以下の通りです。