【注意】 このドキュメントは、W3CのSPARQL 1.1 Federated Query W3C Recommendation 21 March 2013の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2013年8月8日
このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。
翻訳版も参照してください。
Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
RDFは、ウェブ上で情報を表すための、有向性の、ラベル付けされたグラフ・データ形式です。SPARQLは、データがRDFそのものとして保存されているか、ミドルウェアを通してRDFとして見えるのかにかかわらず、さまざまなデータ情報源にまたがるクエリを表すために使用できます。この仕様は、様々なSPARQLエンドポイント上に分散されたクエリを実行するための、SPARQL 1.1統合クエリ拡張の構文とセマンティクスを定義しています。SERVICEキーワードは、SPARQL 1.1を拡張し、ウェブ上に分散するデータを統合するクエリをサポートします。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。
このドキュメントは、SPARQLワーキンググループが作成した以下の11のSPARQL 1.1勧告のうちの1つです。
旧バージョン以降、このドキュメントには実質的な変更はありませんでした。マイナーな編集上の変更がある場合には、変更履歴に詳細が記述されており、色分けした差分として見ることができます。
public-rdf-dawg-comments@w3.org(公開アーカイブ)にコメントをお送りください。このドキュメントに対するSPARQLワーキンググループの作業は完了していますが、コメントは正誤表や今後の改定で扱われることがあります。公開討論は、public-sparql-dev@w3.org(公開アーカイブ)で歓迎します。
このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
1 はじめに
1.1 ドキュメントの規定
1.1.1 名前空間
1.1.2 結果の記述
1.1.3 用語
2 SPARQL 1.1統合クエリ拡張
2.1 遠隔のSPARQLエンドポイントへのシンプルなクエリ
2.2 OPTIONALを用いた2つの遠隔のSPARQLエンドポイントに対するSPARQLクエリ
2.3 サービス実行の失敗
2.4 SERVICEとVALUESの相互作用(参考情報)
3 SPARQL 1.1シンプルな統合拡張: セマンティクス
3.1 SPARQL代数への置換
3.2 SPARQL 1.1シンプルな統合拡張代数
3.2.1 SERVICEの例
4 変数(参考情報)
5 適合性
6 セキュリティに関する留意点(参考情報)
A 参考文献
A.1 規範的な参考文献
A.2 その他の参考文献
B 謝辞
C CVS履歴(最終草案以後)
SPARQLクエリ・サービスの増加により、データの利用者が、ウェブ上に分散するデータを統合する機会が提供されています。この仕様は、SPARQL 1.1クエリ言語に対するSERVICEの拡張の構文とセマンティクスを定義しています。この拡張により、クエリの作成者は、クエリの一部を特定のSPARQLエンドポイントに向けて実行することができるようになります。結果は統合クエリ・プロセッサに返され、残りのクエリの結果と結合されます。
このドキュメントは、SPARQL 1.1クエリ・ドキュメントと同じ名前空間を用いています。
結果集合は、SPARQL 1.1クエリ・ドキュメントと同じく、表形式で示されます。
「バインディング」は、対(変数、RDF用語)です。x、y、z(列の見出しとして示される)という3つの変数があります。各ソリューションは、表の本文の1つの行として示されています。ここでは、1つのソリューションがあり、変数xは"Alice"にバインドされており、変数yはhttp://example/aにバインドされており、変数zはRDF用語にバインドされていません。ソリューションでは、変数は、必ずしもバインドされている必要はありません。
次の用語は、SPARQL 1.1クエリ言語 [SQRY]で定義されており、このドキュメントでも使用しています。
RDF URI reference)に対応)SERVICEキーワードは、遠隔のSPARQLエンドポイントに対し、一部のSPARQLクエリを呼び出すように統合クエリ・プロセッサに命じます。この項では、SERVICEキーワードを用いる方法の例を示します。以下の項では、この拡張の構文とセマンティクスを定義します。
この例では、遠隔のSPARQLエンドポイントにクエリを行い、返されたデータをローカルのRDFデータセットのデータと結合する方法を示しています。我々が知っている人々の名前を発見するためのクエリを考えてみます。様々な人々の名前に関するデータは、http://people.example.org/sparqlのエンドポイントで入手できます。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix : <http://example.org/> . :people15 foaf:name "Alice" . :people16 foaf:name "Bob" . :people17 foaf:name "Charles" . :people18 foaf:name "Daisy" .そして、1つのトリプルが含まれているローカルのFOAFファイル
http://example.org/myfoaf.rdfと結合したいとします。
<http://example.org/myfoaf/I> <http://xmlns.com/foaf/0.1/knows> <http://example.org/people15> .
人々にクエリを行い、オプションとして彼らの興味と彼らが知っている人々の名前を得たいとします。例えば、人々に関するデータが含まれている2つのエンドポイントを想像してください。
遠隔のSPARQLエンドポイントhttp://people.example.org/sparqlのデフォルト・グラフのデータ:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix : <http://example.org/> . :people15 foaf:name "Alice" . :people16 foaf:name "Bob" . :people17 foaf:name "Charles" . :people17 foaf:interest <http://www.w3.org/2001/sw/rdb2rdf/> .
そして、遠隔のSPARQLエンドポイントhttp://people2.example.org/sparqlのデフォルト・グラフのデータ:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix : <http://example.org/> . :people15 foaf:knows :people18 . :people18 foaf:name "Mike" . :people17 foaf:knows :people19 . :people19 foaf:name "Daisy" .
クエリ:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?person ?interest ?known
WHERE
{
SERVICE <http://people.example.org/sparql> {
?person foaf:name ?name .
OPTIONAL {
?person foaf:interest ?interest .
SERVICE <http://people2.example.org/sparql> {
?person foaf:knows ?known . } }
}
}
上記のデータに基づくこのクエリには3つのソリューションがあります。
クエリ結果:
上記のクエリには、OPTIONAL句内に入れ子のSERVICEがあることに注意してください。基本的な統合クエリをサポートするために、このクエリにはhttp://people.example.org/sparqlのSPARQLクエリ・サービスが必要です。
SERVICEパターンの実行は、いくつかの理由により失敗する可能性があります。遠隔のサービスがダウンしているかもしれませんし、サービスのIRIが逆参照可能ではないかもしれませんし、エンドポイントがクエリにエラーを返すかもしれません。通常、そのような状況では、SERVICEパターンが含まれている、呼び出されたクエリは全体として失敗となります。SILENTキーワードを用いれば、クエリは、失敗したSERVICEリクエストを明示的に認めることができます。SILENTキーワードは、遠隔のSPARQLエンドポイントにアクセスしている間に遭遇したエラーは、クエリの処理中は無視されるべきであるということを示します。失敗したSERVICE句は、バインディングのない1つのソリューションの結果があるかのように扱われます。
次のクエリには、SILENTキーワードが存在しています。SPARQLエンドポイントが存在していない、ダウンしている、または、アクセス可能ではという理由で遠隔のSPARQLエンドポイントが利用できない場合、クエリは、1つの空のソリューション・マッピングのソリューション・シーケンスを返すでしょう。SILENTキーワードが存在していなければ、クエリは停止し、エラーを返すでしょう。
<http://people.example.org/sparql>エンドポイントのデータ:
<http://example.org/people15> <http://xmlns.com/foaf/0.1/name> "Charles" .
SPARQL 1.1クエリには、VALUES句(VALUES)が含まれており、それはクエリ評価の結果と結合される順不同のソリューション・シーケンスを提供するために使用できます。SPARQL 1.1統合クエリの実装者は、クエリの他の部分の評価から得られたソリューションのバインディングに基づき、遠隔のエンドポイントから受け取った結果を制約するためにVALUES句を使用できます。
次の例は、どのようにSERVICEとVALUESが連携可能かを示しています。デフォルト・グラフ内のfoaf:Personと彼らが知っている人々のすべてのインスタンスを、遠隔のエンドポイントhttp://example.org/sparqlで求めるクエリを想定してください。
デフォルト・グラフ内のデータ:
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix : <http://example.org/> .
:a a foaf:Person ;
foaf:name "Alan" ;
foaf:mbox; "alan@example.org" .
:b a foaf:Person ;
foaf:name "Bob" ;
foaf:mbox "bob@example.org" .
そして、遠隔のSPARQLエンドポイントhttp://example.org/sparqlのデフォルト・グラフ内のデータ:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix : <http://example.org/> . :a foaf:knows :b . :b foaf:knows :c . :c foaf:knows :a . :a foaf:interest "SPARQL 1.1 Basic Federated Query" . :b foaf:interest "SPARQL 1.1 Query" . :c foaf:interest "RDB2RDF Direct mapping" .
クエリ:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?s
{
?s a foaf:Person .
SERVICE <http://example.org/sparql> {?s foaf:knows ?o }
}
サービスの呼び出しに制約がなく、元のクエリが単純に実行されれば、エンドポイントは必要以上の結果を返すかもしれません。また、SPARQLエンドポイントがすべての結果を返すとは限らないかもしれません。多くの既存のSPARQLエンドポイントには、それらが返す結果の数に制限があり、ローカルのデフォルト・グラフの主語?sと一致するものを逃す可能性があります。したがって、統合クエリに対するクエリ・プランナの実装は、代わりにクエリを2つのクエリに分解することにするかもしれず、その場合、ローカルのデフォルト・グラフのバインディングが最初に評価されます。
クエリ:
PREFIX : <http://example.org/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?s
{
?s a foaf:Person
}
上記のデータに基づくこのクエリには2つのソリューションがあります。
クエリ結果:
次に、?sのソリューションを持つ制約されたクエリを、遠隔のエンドポイント<http://example.org/sparql>に送ります。
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX : <http://example.org/>
SELECT * {?s foaf:knows ?o } VALUES (?s) { (:a) (:b) }
SERVICEが含まれているクエリ・プロセスは、返されるデータを、全体的なクエリに必要なデータの範囲に制限します。
SERVICE拡張は、SPARQLクエリ1.1のTransform(構文形式)への追加を伴った、GroupGraphPatternの付加的な形と定義されます。
形式が
GroupGraphPatternである場合[SPARQL 1.1クエリ言語]のグラフ・パターンの置換の項から、GroupGraphPatternの変換を拡張して
SERVICEパターンの変換を定義します。
Let FS := the empty set
Let G := the empty pattern, Z, a basic graph pattern which is the empty set.
Let SilentOp := boolean, indicating SERVICE error behavior.
For each element E in the GroupGraphPattern
If E is of the form FILTER(expr)
FS := FS ∪ {expr}
End
If E is of the form OPTIONAL{P}
Let A := Transform(P)
If A is of the form Filter(F, A2)
G := LeftJoin(G, A2, F)
Else
G := LeftJoin(G, A, true)
End
End
If E is of the form MINUS{P}
G := Minus(G, Transform(P))
End
If E is of the form BIND(expr AS var)
G := Extend(G, var, expr)
End
If E is any other form
Let A := Transform(E)
G := Join(G, A)
End
If E is of the form SERVICE [SILENT] IRI {P}
Let G := Join(G, Service(IRI, Transform(P), SilentOp))
End
End
If FS is not empty:
Let X := Conjunction of expressions in FS
G := Filter(X, G)
The result is G.
SERVICEの評価は、入れ子のグラフ・パターンのSPARQLプロトコル[SPROT]の実行により返されるSPARQL結果[RESULTS]で定義されます。
定義: サービス・パターンの評価
次のとおりとします。Ω0を1つの空のソリューションを持つソリューションの集合とし、すると、次のとおりとなります。
SELECT * WHERE Qの結果に対応したソリューション・マッピングの多重集合です。そうでない場合は、Ω0.です。そうでない場合は、以下の項では、SPARQL代数におけるSERVICEパターンの評価を示す2つの例を紹介します。
例: 一連のjoinのSERVICEグラフ・パターン:
例: 一連のjoinのSERVICE SILENTグラフ・パターン:
この項では、SPARQLパターンSERVICE VARに対する公式な評価のセマンティクスを提供しません。SPARQLパターンSERVICE VARの評価をどのように評価できるかに関する指示を提供するだけです。
サービスIRIの代わりに変数が用いられていれば、それは、ソリューションに対するサービスの呼び出しが、そのソリューションでは、その変数のバインディングに依存していることを表します。例えば、デフォルト・グラフには、プロジェクトのエンドポイントに関するデータがどのサービスに含まれいるかに関するデータが含まれているかもしれません。これらのプロジェクト(DOAP語彙を用いた)に関するデータにクエリを行うことができるSPARQLエンドポイントに関する情報が含まれている様々なプロジェクトに関し、次のデータを仮定しています。
@prefix void: <http://rdfs.org/ns/void#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix doap: <http://usefulinc.com/ns/doap#> . [] dc:subject "Querying RDF" ; void:sparqlEndpoint <http://projects1.example.org/sparql> . [] dc:subject "Querying RDF remotely" ; void:sparqlEndpoint <http://projects2.example.org/sparql> . [] dc:subject "Updating RDF remotely" ; void:sparqlEndpoint <http://projects3.example.org/sparql> .
遠隔のSPARQLエンドポイントhttp://projects2.example.org/sparqlのデフォルト・グラフ内のデータ:
_:project1 doap:name "Query remote RDF Data" . _:project1 doap:created "2011-02-12"^^xsd:date . _:project2 doap:name "Querying multiple SPARQL endpoints" . _:project2 doap:created "2011-02-13"^^xsd:date .
遠隔のSPARQLエンドポイントhttp://projects3.example.org/sparqlのデフォルト・グラフ内のデータ:
_:project3 doap:name "Update remote RDF Data" . _:project3 doap:created "2011-02-14"^^xsd:date .
次に、「remote」という主語についてプロジェクトのプロジェクト名にクエリを行いたいとします。
PREFIX void: <http://rdfs.org/ns/void#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX doap: <http://usefulinc.com/ns/doap#>
SELECT ?service ?projectName
WHERE {
# 主語「remote」を持つサービスを発見する。
?p dc:subject ?projectSubject ;
void:sparqlEndpoint ?service .
FILTER regex(?projectSubject, "remote")
# サービスのプロジェクトにクエリを実行する。
SERVICE ?service {
?project doap:name ?projectName . }
}
次の表は、上記のデータを用いたこのクエリに対する直観的なソリューションを示しています。
クエリ結果:
変数が含まれているSERVICE句は、SPARQLクエリ・サービスを個別に続けて呼び出すことで実行できます。個々の呼び出しの結果は、和集合で組み合わせられます。
クエリ・エンジンは、対象となりえるSPARQLクエリ・サービスを決定しなければなりません。これを行うための正確な仕組みは、このドキュメントでは定義していません。実行の順序も、試みるべきサービスのリストを決定するために使用できます。上記の例は、実行の具体的な順序を提案しています。つまり、基本的なグラフ・パターンとSERVICEブロックの外のフィルタを最初に評価すると、?serviceに対するバインディングが生成され、その後、それを、SERVICEブロックを評価するために利用できるでしょう。
?p dc:subject ?projectSubject ; void:sparqlEndpoint ?service FILTER regex(?projectSubject, "remote")
?serviceサービスが一度評価されれば、?serviceの個々の値に対してSERVICEを実行できます。
SERVICE ?service {
?project doap:name ?projectName . }
空白ノードは、それをシリアル化するドキュメントに固有のものであることに注意してください。さらに、SERVICEの呼び出しは、シリアル化されたRDFドキュメントを転送し、空白ノードをサービスの呼び出しの間で一意にするSPARQLプロトコル[SPROT]に依存します。
SPARQL 1.1統合クエリ拡張が含まれているSPARQLクエリ文字列の適合性に関しては、4項のSPARQL 1.1統合クエリ文法を参照してください。SERVICEキーワードに対するクエリ結果の適合性に関しては、3.1項のSERVICEの定義を参照してください。
この仕様は、 SPARQL 1.1クエリ言語との併用を意図しています。その適合性基準については、その仕様を参照してください。
SERVICEを用いたSPARQLクエリは、URIが逆参照され、その結果が作業用のデータセットに組み入れられるということを意味します。SPARQLプロトコル1.1[SPROT]の3.1項、SPARQL 1.1クエリ[SQRY]の21項、URI(Uniform Resource Identifier):一般的構文 [RFC3986]の7項のすべてのセキュリティ上の課題を考慮すべきです。
SPARQL 1.1統合クエリ・ドキュメントは、W3C SPARQLワーキンググループ全体の成果であり、議論、コメントおよびレビューに対して、すべての現在および過去のメンバーに感謝します。
さらに、我々は、ワーキンググループのコメント・リストを通じて、多くの人々とコメントや議論のやり取りを行いました。すべてのコメントがより良いドキュメントの作成に繋がりました。さらに、Carlosは、統合クエリ拡張の構文とセマンティックスに関する議論に関し、特にJorge Perez、Oscar Corcho、およびMarcelo Arenasに感謝しています。