【注意】 このドキュメントは、W3CのSPARQL Query Language for RDF W3C Recommendation 15 January 2008の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2013年7月21日
このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。
翻訳版も参照してください。
Copyright © 2006-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
RDFは、ウェブ上で情報を表すための、有向性の、ラベル付けされたグラフ・データ形式です。この仕様では、RDFに対するSPARQLクエリ言語の構文とセマンティクスを定義しています。SPARQLは、データがRDFそのものとして保存されているか、ミドルウェアを通してRDFとして見えるのかにかかわらず、さまざまなデータ情報源にまたがるクエリを表すために使用できます。SPARQLには、必須および任意のグラフ・パターンをその論理積と論理和とともに問い合わせる性能が含まれています。SPARQLは、ソースRDFグラフによる拡張可能な値テストやクエリの制約もサポートします。SPARQLクエリの結果は、結果集合またはRDFグラフでありえます。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。
これは、W3C勧告です。
このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
このドキュメントに関するコメントは、公開アーカイブ付きのメーリングリスト、public-rdf-dawg-comments@w3.orgにお送りください。拡張や機能を含むこの仕様とは関連のないSPARQLに関する質問とコメントは、メーリングリストpublic-sparql-dev@w3.org(公開アーカイブ)で議論できます。
このドキュメントは、RDFデータ・アクセス・ワーキンググループが作成したもので、W3Cセマンティック・ウェブ・アクティビティの一部です。このドキュメントの草案としての最初の公開は2004年10月12日で、ワーキンググループは、それ以後に受け取った多くのコメントと課題に取り組んで来ました。2007年11月の勧告案の公表以後に2つの変更が行われ、記録されています。
ワーキンググループのRDF用クエリ言語SPARQL実装報告書は、2007年6月の勧告候補で設定された相互運用可能な実装という目標が達成されたことを示しています。
データ・アクセス・ワーキンググループは、集約関数、および更新言語を含む12の課題を先送りしました。
このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。
RDFは、ウェブ上で情報を表すための、有向性の、ラベル付けされたグラフ・データの形式です。RDFは、異なる情報源を統合する手段の提供に加え、とりわけ、個人的な情報、ソーシャル・ネットワーク、デジタル・アーティファクトに関するメタデータを表すためにしばしば使用されます。この仕様では、RDF用クエリ言語SPARQLの構文およびセマンティクスを定義しています。
RDF用クエリ言語SPARQLは、RDFデータ・アクセス・ユースケースおよび要件[UCNR]でRDFデータ・アクセス・ワーキンググループが指定しているユースケースおよび要件を満たすように設計されています。
SPARQLクエリ言語は、次の仕様と密接に関連しています。
項の先頭で特に注記がなければ、このドキュメントのすべての項と付録は規範的です。
ドキュメントのこの項(1項)では、SPARQLクエリ言語の仕様を紹介します。この仕様ドキュメントの構成と、仕様で使用されている慣習を示します。
仕様の2項では、一連のクエリとクエリ結果の例により、SPARQLクエリ言語自体を紹介します。3項では、クエリの結果に現れるRDF用語において制約を表現するSPARQLの性能を示す例をより多く用いて、SPARQLクエリ言語の紹介を継続して行います。
4項では、SPARQLクエリ言語の構文の詳細を示します。これは、言語の完全な構文への手引きであり、文法構造がどのようにIRI、空白ノード、リテラル、変数を表すかを定義します。4項では、より冗長な表現に対する糖衣構文として役立ついくつかの文法構造の意味も定義します。
5項では、基本グラフ・パターンとグループ・グラフ・パターン、より複雑なSPARQLクエリ・パターンの構成要素を紹介します。6、7、8項では、SPARQLグラフ・パターンをより大きなグラフ・パターンに組み合わせる構成子を提示します。特に、6項では、クエリ・オプションの一部を作成する性能を紹介し、7項では、代替グラフ・パターンの論理和を表す性能を紹介し、そして、8項では、クエリの一部を特定のソース・グラフに制約する性能を紹介します。8項では、クエリに対してソース・グラフを定義するSPARQLの仕組みも提示します。
9項は、順序付け、スライス、プロジェクション、制限、ソリューションのシーケンスからの重複の排除によるクエリのソリューションに影響する構成子を定義します。
10項では、異なる形式の結果を生む4種類のSPARQLクエリを定義します。
11項では、SPARQLの拡張可能な値テストの枠組みを定義します。また、クエリの結果に現れる値を制約するために使用できる関数と演算子を提示します。
12項は、SPARQLグラフ・パターンとソリューション修飾子の評価に関する形式的な定義です。
付録Aは、EBNF表記法で示されている文法で規定されているような、SPARQLクエリ言語の構文の規範的な定義を含んでいます。
このドキュメントでは、特に注記がなければ、例では、次の名前空間は接頭辞バインディングを想定しています。
接頭辞 | IRI |
---|---|
rdf: |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: |
http://www.w3.org/2000/01/rdf-schema# |
xsd: |
http://www.w3.org/2001/XMLSchema# |
fn: |
http://www.w3.org/2005/xpath-functions# |
このドキュメントでは、各トリプルを明示的に表示するためにTurtle[TURTLE]を使用します。Turtleでは、接頭辞を用いてIRIを省略することが認められています。
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . :book1 dc:title "SPARQL Tutorial" .
結果集合は、表形式で示されます。
x | y | z |
---|---|---|
"Alice" | <http://example/a> |
「バインディング」は、(変数、RDF用語)の対です。この結果集合には、x
、y
、z
(列の見出しとして示されている)という3つの変数があります。各ソリューションは、表の本文の1つの列として示されています。ここでは、1つのソリューションがあり、変数x
は"Alice"
にバインドされており、変数y
は<http://example/a>
にバインドされており、変数z
はRDF用語にバインドされていません。ソリューションでは、変数は、バインドされている必要はありません。
SPARQL言語には、スペースを省略するRDF URI参照のサブセットであるIRIが含まれています。SPARQLクエリでは、すべてのIRIが絶対的であることに注意してください。IRIには、フラグメント識別子[RFC3987、3.1項]を含むことも含まないことも可能です。IRIには、URI[RFC3986]とURLが含まれます。SPARQL構文の省略形(相対IRIおよび接頭辞付き名前)が解決されると、絶対IRIが作成されます。
次の用語は、RDF概念および抽象構文 [CONCEPTS]で定義されており、SPARQLで使用されます。
RDF URI reference
)に対応)datatype URI
)という用語に対応)SPARQLクエリのほとんどの形式には、基本グラフ・パターンと呼ばれる1組のトリプル・パターンが含まれています。それぞれの主語、述語、目的語が変数でありえることを除き、トリプル・パターンはRDFトリプルに類似しています。サブグラフからのRDF用語を変数に代替でき、結果がサブグラフに同等なRDFグラフである場合、基本グラフ・パターンはそのRDFデータのサブグラフにマッチします。
次の例は、与えられたデータ・グラフから書名(title)を発見するためのSPARQLクエリを示しています。クエリは、次の2つで構成されています。SELECT
句はクエリの結果に現れる変数を識別し、WHERE
句はデータ・グラフにマッチする基本グラフ・パターンを提供します。この例の基本グラフ・パターンは、目的語の位置に1つの変数(?title
)を持つ、1つのトリプル・のパターンから成ります。
データ:
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .
クエリ:
SELECT ?title WHERE{ <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> ?title . }
上記のデータのこのクエリには、次の1つのソリューションがあります。
クエリ結果:
title |
---|
"SPARQL Tutorial" |
クエリの結果は、クエリのグラフ・パターンがデータにマッチする方法に従ったソリューション・シーケンスです。クエリに対し、0、1または複数のソリューションがありえます。
データ:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Johnny Lee Outlaw" . _:a foaf:mbox <mailto:jlow@example.com> . _:b foaf:name "Peter Goodguy" . _:b foaf:mbox <mailto:peter@example.org> . _:c foaf:mbox <mailto:carol@example.org> .
クエリ:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . ?x foaf:mbox ?mbox }
クエリ結果:
name | mbox |
---|---|
"Johnny Lee Outlaw" | <mailto:jlow@example.com> |
"Peter Goodguy" | <mailto:peter@example.org> |
各ソリューションは、クエリ・パターンがデータにマッチするように、選択された変数をRDF用語にバインドできる1つの方法を提示します。結果集合は、すべての可能なソリューションを示します。上例では、次の2つのデータのサブセットが2つのマッチをもたらしました。
_:a foaf:name "Johnny Lee Outlaw" . _:a foaf:box <mailto:jlow@example.com> .
_:b foaf:name "Peter Goodguy" . _:b foaf:box <mailto:peter@example.org> .
これは、基本グラフ・パターン・マッチで、クエリ・パターンで使用されるすべての変数がすべてのソリューションにバインドされていなければなりません。
次のデータには、3つのRDFリテラルが含まれています。
@prefix dt: <http://example.org/datatype#> .
@prefix ns: <http://example.org/ns#> .
@prefix : <http://example.org/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
:x ns:p "cat"@en .
:y ns:p "42"^^xsd:integer .
:z ns:p "abc"^^dt:specialDatatype .
Turtleでは"cat"@en
が字句形式「cat」と言語en
を持つRDFリテラルであることに注意してください。"42"^^xsd:integer
は、データ型http://www.w3.org/2001/XMLSchema#integer
を持つ型付きリテラルであり、"abc"^^dt:specialDatatype
は、データ型http://example.org/datatype#specialDatatype
を持つ型付きリテラルです。
このRDFデータは、2.3.1~2.3.3項のクエリの例に用いるデータ・グラフです。
SPARQLの言語タグは、ベスト・コモン・プラクティス47[BCP47]で定められているように、@
と言語タグを用いて表されます。
次のクエリでは、"cat"
が"cat"@en
と同じRDFリテラルではないため、ソリューションはありません。
SELECT ?v WHERE { ?v ?p "cat" }
v |
---|
しかし、次のクエリは、言語タグが指定されており、与えられたデータにマッチするため、変数v
が:x
にバインドされているソリューションが見つかるでしょう。
SELECT ?v WHERE { ?v ?p "cat"@en }
v |
---|
<http://example.org/ns#x> |
SPARQLクエリの整数は、データ型xsd:integer
を持つRDF型付きリテラルです。例えば、42
は、"42"^^<http://www.w3.org/2001/XMLSchema#integer>
の省略形です。
次のクエリのパターンには、:y
にバインドされている変数v
を持つソリューションがあります。
SELECT ?v WHERE { ?v ?p 42 }
v |
---|
<http://example.org/ns#y> |
4.1.2項では、xsd:float
とxsd:double
のSPARQL省略形を定義しています。
次のクエリには、:z
にバインドされている変数v
を持つソリューションがあります。クエリ・プロセッサがデータ型のスペースの値を理解している必要はありません。字句形式とデータ型IRIの両方がマッチするため、リテラルはマッチします。
SELECT ?v WHERE { ?v ?p "abc"^^<http://example.org/datatype#specialDatatype> }
v |
---|
<http://example.org/ns#z> |
クエリの結果には、空白ノードを含むことができます。このドキュメントの例では、結果集合の空白ノードは、"_:"の後に空白ノード・ラベルが続く形で書かれています。
空白ノード・ラベルは結果集合(「SPARQLクエリ結果XMLフォーマット」で定められているように)で有効であり、CONSTRUCT
クエリ形式の場合は結果グラフで有効です。結果集合内での同じラベルの使用は、同じ空白ノードを表します。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?x ?name WHERE { ?x foaf:name ?name }
x | name |
---|---|
_:c | "Alice" |
_:d | "Bob" |
上記の結果は、結果におけるラベルがソリューション内のRDF用語が同じか異なるかを示すだけであるため、異なる空白ノード・ラベルでも同じく得ることができます。
x | name |
---|---|
_:r | "Alice" |
_:s | "Bob" |
これらの2つの結果は同じ情報を持っていますが、2つのソリューションでは、クエリにマッチさせるために用いられる空白ノードが異なっています。結果集合のラベル_:a
と、同じラベルを持つデータ・グラフの空白ノードとの間に関係がある必要はありません。
アプリケーションの作成者は、クエリの空白ノード・ラベルがデータの特定の空白ノードを参照することを期待すべきではありません。
SPARQLには、いくつかのクエリ形式があります。SELECT
というクエリ形式は、変数バインディングを返します。CONSTRUCT
というクエリ形式はRDFグラフを返します。グラフは、クエリのグラフ・パターンをマッチングした結果に基づくRDFトリプルを作成するために用いられるテンプレートに基づいて構築されます。
データ:
@prefix org: <http://example.com/ns#> . _:a org:employeeName "Alice" . _:a org:employeeId 12345 . _:b org:employeeName "Bob" . _:b org:employeeId 67890 .
クエリ:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX org: <http://example.com/ns#> CONSTRUCT { ?x foaf:name ?name } WHERE { ?x org:employeeName ?name }
結果:
@prefix org: <http://example.com/ns#> . _:x foaf:name "Alice" . _:y foaf:name "Bob" .
これは、次のとおり、RDF/XMLでシリアル化できます。
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/" > <rdf:Description> <foaf:name>Alice</foaf:name> </rdf:Description> <rdf:Description> <foaf:name>Bob</foaf:name> </rdf:Description> </rdf:RDF>
グラフ・パターン・マッチングはソリューション・シーケンスを作成し、その各ソリューションは、RDF用語に対する変数バインディングの集合を持ちます。SPARQLのFILTER
は、フィルタの式が真(TRUE
)であるものにソリューションを制限します。
この項では、SPARQLのFILTER
に関する非形式的な手引きを提供します。このセマンティクスは、11項 値のテストで定められています。この項の例では、次の1つの入力グラフを共用しています。
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 .
regex
のようなSPARQLのFILTER
関数は、RDFリテラルをテストできます。regex
は、言語タグを持たないプレーン・リテラルのみにマッチします。regex
は、str関数を用いて他のリテラルの字句形式にマッチさせるために使用できます。
クエリ:
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title ?title FILTER regex(?title, "^SPARQL") }
クエリ結果:
title |
---|
"SPARQL Tutorial" |
正規表現マッチでは、「i
」フラグを用いて大文字・小文字を区別しないようにすることができます。
クエリ:
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title ?title FILTER regex(?title, "web", "i" ) }
クエリ結果:
title |
---|
"The Semantic Web" |
正規表現言語は、XQuery 1.0とXPath 2.0関数および演算子で定められており、XMLスキーマ正規表現に基づいています。
SPARQLのFILTER
は、計算式を制限できます。
クエリ:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?price WHERE { ?x ns:price ?price . FILTER (?price < 30.5) ?x dc:title ?title . }
クエリ結果:
title | price |
---|---|
"The Semantic Web" | 23 |
:book2
のみが30.5
未満の価格を持っているため、price
変数を制約することで、フィルタ条件の要求に従い、:book2
のみがクエリにマッチします。
数値型に加え、SPARQLは、xsd:string
、xsd:boolean
、xsd:dateTime
という型をサポートしています(11.1 オペランド・データ型を参照してください)。11.3 演算子マッピングには、BOUND
、isLITERAL
、langMATCHES
を含むテスト関数と、STR
、LANG
、DATATYPE
を含むアクセサがリストアップされています。11.5 コンストラクタ関数には、ある型から別の型に値をキャストするためのSPARQL言語に含まれているXMLスキーマ・コンストラクタ関数がリストアップされています。
この項では、RDF用語およびトリプル・パターンに対してSPARQLが用いる構文をカバーしています。完全な文法は付録Aで示します。
IRIref生成規則は、IRI[RFC3987]の集合を指定します。IRIは、URI[RFC3986]を一般化したものであり、URIおよびURLと完全に互換性があります。PrefixedName生成規則は、接頭辞名を指定します。接頭辞名からIRIへのマッピングについて、以下で説明しています。IRI参照(相対的または絶対的なIRI)は、IRI_REF生成規則によって指定され、「<」と「>」の区切り記号はIRI参照の一部にはなりません。相対IRIは、[RFC3987]の2.2 IRI参照とIRIに対するABNFの項のirelative-refにマッチし、下記のIRIに解決されます。
[67] |
IRIref |
::= | IRI_REF | PrefixedName |
[68] |
PrefixedName |
::= | PNAME_LN | PNAME_NS |
[69] |
BlankNode |
::= | BLANK_NODE_LABEL | ANON |
[70] |
IRI_REF |
::= | '<' ([^<>"{}|^`\]-[#x00-#x20])* '>' |
[71] |
PNAME_NS |
::= | PN_PREFIX? ':' |
[72] |
PNAME_LN |
::= | PNAME_NS PN_LOCAL |
SPARQL用語にはIRIが含まれていますが、RDF概念および抽象構文で定義されているRDF用語にはRDF URI参照が含まれています。「<
」、「>
」、「"
」(ダブル引用符)、スペース、「{
」、「}
」、「|
」、「\
」、「^
」、「`
」を含むRDF URI参照は、IRIではありません。このようなRDF URI参照で構成されたRDFステートメントに対するSPARQLクエリの動作は定められていません。
PREFIX
キーワードは、接頭辞ラベルをIRIに関連付けます。接頭辞名は、コロン「:
」によって区切られた、接頭辞ラベルとローカル部分(local part)です。接頭辞名は、接頭辞に関連付けられたIRIとローカル部分とを連結することによって、IRIにマッピングされます。接頭辞ラベルまたはローカル部分は、空でありえます。先頭桁(leading digit)は、XMLローカル名では認められていませんが、SPARQLローカル名では認められていることに注意してください。
相対IRIは、URI(Uniform Resource Identifier): 一般的構文[RFC3986]にあるとおり、5.2項の基本アルゴリズムのみを用いて、基底IRIに組み合わされます。構文に基づく正規化もスキームに基づく正規化も(RFC3986の6.2.2および6.2.3項に記述されている)実行されません。IRI参照で追加的に認められている文字は、IRI(Internationalized Resource Identifiers)[RFC3987]の6.5項にあるとおり、URI参照で無制限の文字が扱われているのと同じ方法で扱われます。
BASE
キーワードは、RFC3986の5.1.1項「コンテンツ内に組み込まれた基底URI」にあるとおり、相対IRIを解決するために用いられる基底IRIを定めます。5.1.2項「カプセル化されたエンティティーからの基底URI」は、xml:base指示子を持つSOAPエンベロープやContent-Locationヘッダーを持つマイム・マルチパート・ドキュメントのようなカプセル化されたドキュメントから、どのように基底IRIを持ってくることができるかを定めています。5.1.3「検索URIからの基底URI」で識別された「検索URI」は、特定のSPARQLクエリが検索されたURLです。上記のどれもが基底URIを指定しない場合は、デフォルト基底URI(5.1.4項「デフォルト基底URI」を参照)が用いられます。
次のフラグメントは、同じIRIを記述する別々の方法の一部です。
<http://example.org/book/book1>
BASE <http://example.org/book/> <book1>
PREFIX book: <http://example.org/book/> book:book1
リテラルの一般的な構文は、言語タグのオプション(@
で導入される)か、データ型IRIまたは接頭辞名のオプション(^^
で導入される)かのどちらかを持つ文字列(ダブル引用符"..."
、または、シングル引用符'...'
で囲まれた)です。
便宜上、整数を直接記述(引用符と明示的なデータ型IRIなしに)でき、これはデータ型xsd:integer
の型付きリテラルとして解釈され、数字の中に「.」があるけれども指数がない小数はxsd:decimal
と解釈され、指数がある数はxsd:double
と解釈されます。型xsd:boolean
の値は、真(true
)または偽(false
)と記述できます。
自身に引用符を含む、または、長くて改行文字を含むリテラル値の記述を容易にするために、SPARQLでは、リテラルを3つのシングル引用符またはダブル引用符で囲んだ引用構成子も提供されています。
SPARQLのリテラル構文の例は、次のとおりです。
"chat"
'chat'@fr
"xyz"^^<http://example.org/ns/userDatatype>
"abc"^^appNS:appDataType
'''The librarian said, "Perhaps you would enjoy 'War and Peace'."'''
1
、これは"1"^^xsd:integer
と同じ1.3
、 これは"1.3"^^xsd:decimal
と同じ1.300
、 これは"1.300"^^xsd:decimal
と同じ1.0e6
、 これは"1.0e6"^^xsd:double
と同じtrue
、 これは"true"^^xsd:boolean
と同じfalse
、 これは"false"^^xsd:boolean
と同じ生成規則INTEGER、DECIMAL、DOUBLE、BooleanLiteralにマッチするトークンは、トークンの字句値と、対応するデータ型(xsd:integer
、xsd:decimal
、xsd:double
、xsd:boolean
)を持つ型付きテラルと同等です。
SPARQLクエリのクエリ変数は、グローバルな範囲を持っています。与えられた変数名をクエリ内の任意の場所で用いると、同じ変数を識別します。変数の前には「?」か「$」のどちらかが置かれますが、「?」や「$」は変数名の一部ではありません。クエリでは、$abc
と?abc
は同じ変数を識別します。SPARQL文法では、変数に対して可能な名前が与えられます。
[44] |
Var |
::= | VAR1 | VAR2 |
[74] |
VAR1 |
::= | '?' VARNAME |
[75] |
VAR2 |
::= | '$' VARNAME |
[97] |
VARNAME |
::= | ( PN_CHARS_U | [0-9] ) ( PN_CHARS_U | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )* |
グラフ・パターンの空白ノードは、問い合わされたデータの特定の空白ノードの参照としてではなく、非識別変数として機能します。
空白ノードは、「_:abc
」などのラベル形式か、省略形「[]
」のどちらかで示されます。クエリ構文の1箇所でしか使うことができない空白ノードは[]
で示すことができます。ユニークな空白ノードは、トリプル・パターンを形成するために用いられるでしょう。ラベル「abc
」を持つ空白ノードに対する空白ノード・ラベルは「_:abc
」と書かれます。同じ空白ノード・ラベルは、同じクエリ内の2つの異なる基本グラフ・パターンに使用することはできません。
[:p :v]
構成子は、トリプル・パターンで用いることができます。これは、すべてを含んだ述語-目的語の対の主語として用いられる空白ノード・ラベルを作成します。作成された空白ノードは、さらに他のトリプル・パターンの主語と目的語の位置でも使用できます。
次の2つの形式
[ :p "v" ] .
[] :p "v" .
は、ユニークな空白ノード・ラベル(ここでは「b57
」)を割り当てると、次の記述と同等です。
_:b57 :p "v" .
割り当てられたこの空白ノード・ラベルは、さらに別のトリプル・パターンの主語または目的語として使用できます。例えば、主語として用いると次のようになります。
[ :p "v" ] :q "w" .
これは、次の2つのトリプルと同等です。
_:b57 :p "v" . _:b57 :q "w" .
そして、目的語として用いると次のようになります。
:x :q [ :p "v" ] .
これは、次の2つのトリプルと同等です。
:x :q _:b57 . _:b57 :p "v" .
省略化された空白ノード構文は、共通の主語と共通の述語に対する他の省略語と組み合わせることができます。
[ foaf:name ?name ; foaf:mbox <mailto:alice@example.org> ]
これは、あるユニークに割り当てられた空白ノード・ラベル「b18
」に対する次の基本グラフ・パターンの記述と同じです。
_:b18 foaf:name ?name . _:b18 foaf:mbox <mailto:alice@example.org> .
[39] |
BlankNodePropertyList |
::= | '['PropertyListNotEmpty']' |
[69] |
BlankNode |
::= | BLANK_NODE_LABEL | ANON |
[73] |
BLANK_NODE_LABEL |
::= | '_:' PN_LOCAL |
[94] |
ANON |
::= | '[' WS* ']' |
トリプル・パターンは、スペースで区切られた主語、述語、目的語のリストとして書かれます。いくつかの共通するトリプル・パターン構成子を省略して書く方法があります。
次の例は、同じクエリを表します。
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { <http://example.org/book/book1> dc:title ?title }
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX : <http://example.org/book/> SELECT $title WHERE { :book1 dc:title $title }
BASE <http://example.org/book/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT $title WHERE { <book1> dc:title ?title }
[32] |
TriplesSameSubject |
::= | VarOrTerm PropertyListNotEmpty | |
[33] |
PropertyListNotEmpty |
::= | Verb ObjectList ( ';' ( Verb ObjectList )? )* |
[34] |
PropertyList |
::= | PropertyListNotEmpty? |
[35] |
ObjectList |
::= | Object ( ',' Object )* |
[37] |
Verb |
::= | VarOrIRIref | 'a' |
共通の主語を持つトリプル・パターンは、主語を1度だけ記述し、「;
」表記法を用いて1つ以上のトリプル・パターンで用いられるように記述できます。
?x foaf:name ?name ; foaf:mbox ?mbox .
これは、次のトリプル・パターンの記述と同じです。
?x foaf:name ?name . ?x foaf:mbox ?mbox .
トリプル・パターンが主語と述語の両方を共有する場合、目的語を「,
」で区切ることができます。
?x foaf:nick "Alice" , "Alice_" .
上記は、次のトリプル・パターンの記述と同じです。
?x foaf:nick "Alice" . ?x foaf:nick "Alice_" .
次のように、目的語のリストを述語-目的語のリストと組み合わせることができます。
?x foaf:name ?name ; foaf:nick "Alice" , "Alice_" .
これは、次と同等です。
?x foaf:name ?name . ?x foaf:nick "Alice" . ?x foaf:nick "Alice_" .
「(element1 element2 ...)」という構文を用いてトリプル・パターンにRDFコレクションを記述できます。形式「()
」は、http://www.w3.org/1999/02/22-rdf-syntax-ns#nil
というIRIの代替です。(1 ?x 3 4)
のようなコレクション要素とともに用いれば、空白ノードを持つトリプル・パターンがコレクションに割り当てられます。コレクションの先頭の空白ノードは、他のトリプル・パターンの主語または目的語として使用できます。コレクション構文で割り当てられた空白ノードは、クエリのほかの場所では出現しません。
(1 ?x 3 4) :p "w" .
上記は、次に対する糖衣構文です(b0
、b1
、b2
、b3
がクエリの他のどこかで出現しないことを意味する)。
_:b0 rdf:first 1 ; rdf:rest _:b1 . _:b1 rdf:first ?x ; rdf:rest _:b2 . _:b2 rdf:first 3 ; rdf:rest _:b3 . _:b3 rdf:first 4 ; rdf:rest rdf:nil . _:b0 :p "w" .
RDFコレクションは、入れ子にすることができ、他の構文を含むことができます。
(1 [:p :q] ( 2 ) ) .
上記は、次に対する糖衣構文です。
_:b0 rdf:first 1 ; rdf:rest _:b1 . _:b1 rdf:first _:b2 . _:b2 :p :q . _:b1 rdf:rest _:b3 . _:b3 rdf:first _:b4 . _:b4 rdf:first 2 ; rdf:rest rdf:nil . _:b3 rdf:rest rdf:nil .
[40] |
Collection |
::= | '(' GraphNode+ ')' |
[92] |
NIL |
::= | '(' WS* ')' |
キーワード「a
」は、トリプル・パターンで述語として使用でき、http://www.w3.org/1999/02/22-rdf-syntax-ns#type
というIRIの代替です。このキーワードは大文字・小文字を区別します。
?x a :Class1 . [ a :appClass ] :p "v" .
上記は、次に対する糖衣構文です。
?x rdf:type :Class1 . _:b0 rdf:type :appClass . _:b0 :p "v" .
SPARQLはグラフ・パターン・マッチングを基本としています。より複雑なグラフ・パターンは、小さなパターンを様々な方法で組み合わせて作成できます。
この項では、論理積でパターンを組み合わせる2つの形式について説明します。それらは、トリプル・パターンを組み合わせる基本グラフ・パターンと、他のすべてのパターンを組み合わせるグループ・グラフ・パターンです。
最も外側のクエリのグラフ・パターンは、クエリ・パターンと呼ばれます。これは、文法上、次のGroupGraphPattern
で識別されます。
[13] |
WhereClause |
::= | 'WHERE'? GroupGraphPattern |
基本グラフ・パターンはトリプル・パターンの集合です。SPARQLのグラフ・パターン・マッチングは、マッチした基本グラフ・パターンの結果を組み合わせるという観点で定義されます。
フィルタの割り込みがあったトリプル・パターンのシーケンスは、1つの基本グラフ・パターンから成ります。任意のグラフ・パターンが、基本グラフ・パターンを終了させます。
形式_:abc
の空白ノードを用いるときには、空白ノードのラベルは基本グラフ・パターンで有効です。1つのラベルは、任意のクエリにおける1つの基本グラフ・パターンのみで使用できます。
SPARQLは、RDFグラフをシンプルな含意にマッチさせるために定義されます。以下の記述のような、ある特定の状況が与えられれば、SPARQLを他の形式の含意に拡張できます。
SPARQLのクエリ文字列では、グループ・グラフ・パターンは中括弧({}
)で区切られます。例えば、このクエリのクエリ・パターンは、1つの基本グラフ・パターンからなるグループ・グラフ・パターンです。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . ?x foaf:mbox ?mbox . }
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { { ?x foaf:name ?name . } { ?x foaf:mbox ?mbox . } }
[20]
|
GroupGraphPattern
|
::= |
'{' TriplesBlock? ( ( GraphPatternNotTriples | Filter ) '.'? TriplesBlock? )* '}'
|
[21]
|
TriplesBlock
|
::= | TriplesSameSubject ( '.' TriplesBlock? )?
|
[22] |
GraphPatternNotTriples |
::= |
OptionalGraphPattern | GroupOrUnionGraphPattern | GraphGraphPattern
|
グループ・パターン
{ }
は、任意のグラフ(空のグラフを含む)を、変数をバインドしない1つのソリューションにマッチさせます。例えば、
SELECT ?x WHERE {}
は、変数x
がバインドされていない1つのソリューションとマッチします。
FILTER
キーワードによって表される制約は、フィルタが出現するすべてのグループにまたがるソリューションに対する制限です。次のパターンはすべて、同じソリューションを持ちます。
{ ?x foaf:name ?name . ?x foaf:mbox ?mbox . FILTER regex(?name, "Smith") }
{ FILTER regex(?name, "Smith") ?x foaf:name ?name . ?x foaf:mbox ?mbox . }
{ ?x foaf:name ?name . FILTER regex(?name, "Smith") ?x foaf:mbox ?mbox . }
{ ?x foaf:name ?name . ?x foaf:mbox ?mbox . }
は、1つの基本グラフ・パターンからなるグループで、その基本グラフ・パターンは、2つのトリプル・パタ ーンから構成されています。
{ ?x foaf:name ?name . FILTER regex(?name, "Smith") ?x foaf:mbox ?mbox . }
は、1つの基本グラフ・パターンとフィルタからなるグループで、その基本グラフ・パターンは、2つのトリプル・パターンから構成されています。フィルタは基本グラフ・パターンを2つの基本グラフ・パターンに分割しません。
{ ?x foaf:name ?name . {} ?x foaf:mbox ?mbox . }
は、1つのトリプル・パターンからなる基本グラフ・パターン、空のグループ、1つのトリプル・パターンからなる別の基本グラフ・パターンという、3つの要素のグループです。
基本グラフ・パターンでは、アプリケーションは、ソリューションが生成されるようにクエリ・パターンの全体がマッチしなければならないようなクエリを作成できます。少なくとも1つの基本グラフ・パターンを持つグループ・グラフ・パターンのみを含むクエリのすべてのソリューションでは、すべての変数は、あるソリューションのあるRDF用語にバインドされます。しかし、すべてのRDFグラフにおいて、正規の、完全な構成を想定することはできません。情報が利用できるソリューションに情報を追加できるクエリを持つことができると便利ですが、クエリ・パターンの一部がマッチしないという理由でソリューションを拒絶すべきではありません。オプションのマッチングは、この機能を提供します。オプション部分がマッチしない場合は、バインディングを作成しませんが、ソリューションは排除しません。
グラフ・パターンのオプション部分は、次のグラフ・パターンに当てはまるOPTIONALキーワードで構文的に指定されます。
pattern OPTIONAL { pattern }
構文形式
{ OPTIONAL { pattern } }
は次と同等です。
{ { } OPTIONAL { pattern } }
[23] |
OptionalGraphPattern |
::= | 'OPTIONAL' GroupGraphPattern |
OPTIONAL
キーワードは左結合的で、
pattern OPTIONAL { pattern } OPTIONAL { pattern }
次と同じです。
{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }
オプションのマッチでは、オプションのグラフ・パターンがグラフにマッチし、その結果、1つ以上のソリューションに対し、バインディングを定義し追加するか、追加のバインディングを加えずにソリューションをそのままにします。
データ:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . _:a rdf:type foaf:Person . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@example.com> . _:a foaf:mbox <mailto:alice@work.example> . _:b rdf:type foaf:Person . _:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . OPTIONAL { ?x foaf:mbox ?mbox } }
上記のデータを用いると、クエリ結果は次の通りです。
name | mbox |
---|---|
"Alice" | <mailto:alice@example.com> |
"Alice" | <mailto:alice@work.example> |
"Bob" |
名前が"Bob"
であるソリューションのmbox
の値はありません。
このクエリはデータ内の人名を発見します。述語mbox
と、同じ主語を持つトリプルがある場合、ソリューションにはそのトリプルの目的語も含まれるでしょう。この例では、クエリのオプションのマッチ部分では1つのトリプル・パターンのみが得られますが、一般に、オプションの部分は任意のグラフ・パターンでありえます。オプションのグラフ・パターンの全体は、クエリのソリューションに影響するように、オプションのグラフ・パターンにマッチしなければなりません。
オプションのグラフ・パターンでは、制約を付与できます。例えば、次のとおりです。
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 .
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?price WHERE { ?x dc:title ?title . OPTIONAL { ?x ns:price ?price . FILTER (?price < 30) } }
title | price |
---|---|
"SPARQL Tutorial" | |
"The Semantic Web" | 23 |
「SPARQL Tutorial」というタイトルの本には、価格が表示されません。なぜならば、オプションのグラフ・パターンが変数「price
」を伴うソリューションをもたらさなかったからです。
グラフ・パターンは再帰的に定義されます。グラフ・パターンは0以上のオプションのグラフ・パターンを持つことができ、クエリ・パターンのどの部分もオプション部分を持つことができます。この例には、2つのオプションのグラフ・パターンがあります。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox ?hpage WHERE { ?x foaf:name ?name . OPTIONAL { ?x foaf:mbox ?mbox } . OPTIONAL { ?x foaf:homepage ?hpage } }
クエリ結果:
name | mbox | hpage |
---|---|---|
"Alice" | <http://work.example.org/alice/> | |
"Bob" | <mailto:bob@work.example> |
SPARQLは、いくつかの代替グラフ・パターンの1つがマッチするようにグラフ・パターンを組み合わせる方法を備えています。1つ以上の代替がマッチすれば、すべてのありえるパターンのソリューションが見つかります。
パターン代替は、UNION
キーワードで構文的に指定されます。
@prefix dc10: <http://purl.org/dc/elements/1.0/> . @prefix dc11: <http://purl.org/dc/elements/1.1/> . _:a dc10:title "SPARQL Query Language Tutorial" . _:a dc10:creator "Alice" . _:b dc11:title "SPARQL Protocol Tutorial" . _:b dc11:creator "Bob" . _:c dc10:title "SPARQL" . _:c dc11:title "SPARQL (updated)" .
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { { ?book dc10:title ?title } UNION { ?book dc11:title ?title } }
クエリ結果:
title |
---|
"SPARQL Protocol Tutorial" |
"SPARQL" |
"SPARQL (updated)" |
"SPARQL Query Language Tutorial" |
このクエリは、バージョン1.0、バージョン1.1のどちらのダブリン・コアのプロパティーを用いてタイトルが記録されているかに関係なく、データ中の本のタイトルを発見します。情報の記録方法を厳密に判別するために、クエリは2つの代替に対して異なる変数を用いることができます。
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?x ?y WHERE { { ?book dc10:title ?x } UNION { ?book dc11:title ?y } }
x | y |
---|---|
"SPARQL (updated)" | |
"SPARQL Protocol Tutorial" | |
"SPARQL" | |
"SPARQL Query Language Tutorial" |
これは、UNION
の左辺のソリューションにバインドされた変数x
と、右辺のソリューションにバインドされたy
を持った結果を返すでしょう。UNION
パターンのどちらの部分にもマッチしない場合、グラフ・パターンはマッチしないでしょう。
UNION
パターンはグラフ・パターンを組み合わせます。それぞれの代替に、1つ以上のトリプル・パターンを含むことができます。
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?title ?author WHERE { { ?book dc10:title ?title . ?book dc10:creator ?author } UNION { ?book dc11:title ?title . ?book dc11:creator ?author } }
author | title |
---|---|
"Alice" | "SPARQL Protocol Tutorial" |
"Bob" | "SPARQL Query Language Tutorial" |
ダブリン・コアの同じバージョンのタイトルと著者の両方の述語がある場合にのみ、このクエリは本にマッチするでしょう。
[25] |
GroupOrUnionGraphPattern |
::= | GroupGraphPattern
|
RDFデータ・モデルは、主語、述語、目的語のトリプルから成るグラフとして情報を表します。多くのRDFデータを蓄積すると、複数のRDFグラフと各グラフに関する記録情報が保持され、それによって、アプリケーションは1つ以上のグラフの情報を含むクエリを作成できます。
SPARQLのクエリは、グラフのコレクションを表すRDFデータセットに対して実行されます。1つのRDFデータセットは、名前のない1つのグラフ(デフォルト・グラフ)と、名前付きグラフがそれぞれにIRIで識別される0以上の名前付きグラフから成ります。SPARQLのクエリは、8.3 データセットのクエリの項で述べるように、クエリ・パターンの異なる部分を異なるグラフに対してマッチさせることができます。
RDFデータセットには、0の名前付きグラフを含むことができます。RDFデータセットには、常に1つのデフォルト・グラフが含まれます。クエリは、デフォルト・グラフのマッチングを含る必要はありません。クエリは、名前付きグラフのマッチングを含むことができるだけです。
基本グラフ・パターンをマッチングさせるために用いるグラフは、アクティブ・グラフです。前項までは、すべてのクエリは、アクティブ・グラフとしてのRDFデータセットのデフォルト・グラフである、1つのグラフに対して実行したものを示してきました。GRAPH
キーワードは、アクティブ・グラフを、クエリの一部に対するデータセット内のすべての名前付きグラフのうちの1つにするために用いられます。
RDFデータセットの定義は、名前付きグラフとデフォルト・グラフの関係を制限しません。異なるグラフで情報を繰り返すことができ、グラフ間の関係を公開できます。次の2つの有益な処理があります。
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> . <http://example.org/bob> dc:publisher "Bob" . <http://example.org/alice> dc:publisher "Alice" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example.org> .
この例では、デフォルト・グラフには、2つの名前付きグラフの公開者名が含まれています。名前付きグラフのトリプルは、この例のデフォルト・グラフでは表示されません。
例2:
RDFデータは、グラフのRDFマージ[RDF-MT]によって組み合わすことができます。RDFデータセットにおける、グラフの1つの可能な処理は、デフォルト・グラフを名前付きグラフの情報の一部またはすべてのRDFマージにすることです。
次の例では、名前付きグラフには、以前と同じトリプルが含まれています。RDFデータセットは、デフォルト・グラフに名前付きグラフのRDFマージを含んでおり、再ラベル付けを行って空白ノードを異なったものにしておきます。
# Default graph @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Bob" . _:x foaf:mbox <mailto:bob@oldcorp.example.org> . _:y foaf:name "Alice" . _:y foaf:mbox <mailto:alice@work.example.org> .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
RDFマージでは、マージされたグラフの空白ノードと、マージされているグラフからの空白ノードとは共有されません。
SPARQLクエリは、RDFデータセットを記述するために、FROM
句とFROM NAMED
句を用いて、マッチングに用いるデータセットを指定できます。クエリがそのようなデータセットの記述を提供していれば、それは、データセットの記述がクエリで提供されない場合にクエリ・サービスが使用する任意のデータセットの代わりに使用しています。また、RDFデータセットは、SPARQLプロトコル要求で指定することもできます。その場合、プロトコルの記述により、クエリ自体のあらゆる記述は無効になります。クエリ・サービスがデータセットの記述を許容できない場合には、サービスはクエリ要求を拒否するかもしれません。
FROM
とFROM NAMED
キーワードによって、クエリは参照によってRDFデータセットを指定できます。これは、データセットが、与えられたIRI(すなわち、与えられたIRI参照の絶対形式)によって識別された資源の表現から得られるグラフを含むべきであるということを示しています。いくつかのFROM
とFROM NAMED
句から生じるデータセットは次の通りです。
FROM
句で参照されたグラフのRDFマージから成るデフォルト・グラフ、およびFROM NAMED
句から1つずつ。FROM
句はないけれども複数のFROM NAMED
句がある場合は、データセットにはデフォルト・グラフに対する空のグラフが含まれています。
[9] |
DatasetClause |
::= | 'FROM' ( DefaultGraphClause | NamedGraphClause ) |
[10] |
DefaultGraphClause |
::= | SourceSelector |
[11] |
NamedGraphClause |
::= | 'NAMED' SourceSelector |
[12] | SourceSelector |
::= | IRIref |
各FROM
句には、デフォルト・グラフを作成するために用いるグラフを示すIRIが含まれています。これは、グラフを名前付きグラフとして位置づけるものではありません。
この例では、RDFデータセットは、1つのデフォルト・グラフを含み、名前付きグラフを含んでいません。
# Default graph (stored at http://example.org/foaf/aliceFoaf) @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name FROM <http://example.org/foaf/aliceFoaf> WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
クエリが1つ以上のFROM
句を提供し、デフォルト・グラフを示すために1つ以上のIRIを提供する場合、デフォルト・グラフは与えられたIRIによって識別される資源の表現から得られたグラフのRDFマージに基づいています。
FROM NAMED
句を用いれば、クエリは、RDFデータセットの名前付きグラフにIRIを提供できます。各IRIは、RDFデータセットの1つの名前付きグラフを提供するために用いられます。2つ以上のFROM NAMED
句で同じIRIを用いると、データセットに現れる当該IRIを持つ1つの名前付きグラフになります。
# Graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
... FROM NAMED <http://example.org/alice> FROM NAMED <http://example.org/bob> ...
FROM NAMED
構文は、IRIが対応するグラフを識別するということを示唆しますが、RDFデータセットのIRIとグラフとの関係は間接的です。IRIが資源を識別し、資源はグラフで(あるいは、より正確には、グラフをシリアル化したドキュメントで)表されます。詳細については[WEBARCH]を参照してください。
FROM
句とFROM NAMED
句は、同じクエリ内で使用できます。
# Default graph (stored at http://example.org/dft.ttl) @prefix dc: <http://purl.org/dc/elements/1.1/> . <http://example.org/bob> dc:publisher "Bob Hacker" . <http://example.org/alice> dc:publisher "Alice Hacker" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example.org> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?who ?g ?mbox FROM <http://example.org/dft.ttl> FROM NAMED <http://example.org/alice> FROM NAMED <http://example.org/bob> WHERE { ?g dc:publisher ?who . GRAPH ?g { ?x foaf:mbox ?mbox } }
このクエリに対するRDFデータセットには、1つのデフォルト・グラフと2つの名前付きグラフが含まれています。GRAPH
キーワードに関しては、以下で説明しています。
データセットを構築するために必要なアクションは、データセットの記述のみでは決められません。2つのFROM
句、または、1つのFROM
句と1つのFROM NAMED
句を用いてデータセットの記述にIRIが2度付与されている場合は、きっかり1回または、きっかり2回の試みでIRIに関連付けられた1つのRDFグラフを得たとは想定しません。したがって、データセットの記述に存在する2つから得られたトリプル中の空白ノードのアイデンティティに関する想定を行えません。概して、グラフの同等性に関する想定を行えません。
グラフのコレクションにクエリを実行する際には、GRAPH
キーワードを用いて、名前付きグラフに対してパターンをマッチングさせます。GRAPH
は、IRIを提供して1つのグラフを選択するか、クエリのRDFデータセット内のすべての名前付きグラフのIRIの範囲をカバーする変数を使用できます。
GRAPH
を用いれば、クエリの一部で基本グラフ・パターンをマッチングさせるためのアクティブ・グラフが変更されます。GRAPH
を用いない場合は、デフォルト・グラフは基本グラフ・パターンによってマッチングされます。
以下の例では、次の2つのグラフを用います。
# Named graph: http://example.org/foaf/aliceFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:a foaf:knows _:b . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> . _:b foaf:nick "Bobby" . _:b rdfs:seeAlso <http://example.org/foaf/bobFoaf> . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
# Named graph: http://example.org/foaf/bobFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:z foaf:mbox <mailto:bob@work.example> . _:z rdfs:seeAlso <http://example.org/foaf/bobFoaf> . _:z foaf:nick "Robert" . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
[24] |
GraphGraphPattern |
::= | 'GRAPH' VarOrIRIref GroupGraphPattern |
次のクエリは、データセットの各名前付きグラフにグラフ・パターンをマッチングさせ、マッチしたグラフのIRIにバインドされたsrc
変数を持つソリューションを作成します。グラフ・パターンは、データセットの各名前付きグラフであるアクティブ・グラフとマッチします。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?src ?bobNick FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH ?src { ?x foaf:mbox <mailto:bob@work.example> . ?x foaf:nick ?bobNick } }
クエリの結果は、情報が発見されたグラフの名前と、Bobのnickの値を提示します。
src | bobNick |
---|---|
<http://example.org/foaf/aliceFoaf> | "Bobby" |
<http://example.org/foaf/bobFoaf> | "Robert" |
クエリは、グラフIRIの提供により、特定のグラフに適用されたマッチングを制限できます。これは、IRIで名前付けされたグラフに、アクティブ・グラフを設定します。このクエリは、グラフhttp://example.org/foaf/bobFoaf
で示されているように、Bobのnickを検索します。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX data: <http://example.org/foaf/> SELECT ?nick FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH data:bobFoaf { ?x foaf:mbox <mailto:bob@work.example> . ?x foaf:nick ?nick } }
これにより、次の1つのソリューションが得られます。
nick |
---|
"Robert" |
GRAPH
句で用いられる変数は、もう1つのGRAPH
句、または、データセットのデフォルト・グラフにマッチしたグラフ・パターンでも使用できます。
次のクエリは、Bobのプロフィール・ドキュメントを発見するためにIRI http://example.org/foaf/aliceFoaf
を持つグラフを用いており、そのグラフに別のパターンをマッチさせます。AliceのFOAFファイルからファイルの変数whom
にマッチングさせるため用いられる空白ノードは、プロフィール・ドキュメントの空白ノードと同じではないため(異なるグラフに存在する)、2番目のGRAPH
句のパターンは、最初のGRAPH
句(変数whom
)で発見されたのと同じメールボックス(変数mbox
によって示される)を持つ人の空白ノード(変数w
)を発見します。
PREFIX data: <http://example.org/foaf/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?mbox ?nick ?ppd FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH data:aliceFoaf { ?alice foaf:mbox <mailto:alice@work.example> ; foaf:knows ?whom . ?whom foaf:mbox ?mbox ; rdfs:seeAlso ?ppd . ?ppd a foaf:PersonalProfileDocument . } . GRAPH ?ppd { ?w foaf:mbox ?mbox ; foaf:nick ?nick } }
mbox | nick | ppd |
---|---|---|
<mailto:bob@work.example> | "Robert" | <http://example.org/foaf/bobFoaf> |
変数nick
を含むパターンがppd
によって特定のパーソナル・プロフィール・ドキュメントに制限されているため、Bobのnick
を示しているAliceのFOAFファイルのトリプルは、Bobにnickを提供するために用いられていません。
クエリ・パターンは、デフォルト・グラフと名前付グラフの両方を含むことができます。この例では、アグリゲータは、2回の別の機会に1つのウェブ資源を読み込みました。グラフには、アグリゲータに読み込まれるたびに、ローカル・システムによってIRIが与えられます。これらのグラフはほぼ同じですが、「Bob」のEメール・アドレスが変更されました。
この例では、デフォルト・グラフは、来歴情報を記録するために用いられており、実際に読み込まれたRDFデータは2つの別々のグラフに保持され、システムはそれぞれに異なるIRIを与えます。RDFデータセットは、2つの名前付きグラフとそれらに関する情報で構成されます。
RDFデータセット:
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix g: <tag:example.org,2005-06-06:> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . g:graph1 dc:publisher "Bob" . g:graph1 dc:date "2004-12-06"^^xsd:date . g:graph2 dc:publisher "Bob" . g:graph2 dc:date "2005-01-10"^^xsd:date .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph1 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph2 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@newcorp.example.org> .
このクエリは、Eメール・アドレスを発見し、人名と情報が発見された日時を詳細化します。
PREFIX foaf: <http://xmlns.com/foaf/0.1/>PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name ?mbox ?date WHERE { ?g dc:publisher ?name ; dc:date ?date . GRAPH ?g { ?person foaf:name ?name ; foaf:mbox ?mbox } }
結果は、「Bob」のEメール・アドレスが変更されたことを示します。
name | mbox | date |
---|---|---|
"Bob" | <mailto:bob@oldcorp.example.org> | "2004-12-06"^^xsd:date |
"Bob" | <mailto:bob@newcorp.example.org> | "2005-01-10"^^xsd:date |
日時のデータ型に関するIRIは、結果では、明確さのために省略化されています。
クエリ・パターンは、各ソリューションが変数からRDF用語への部分関数である、順不同のソリューションのコレクションを作成します。次に、これらのソリューションは、シーケンス(ソリューション・シーケンス)として処理されます。最初は特に順序付けのないシーケンスで、後で、任意のシーケンス修飾子を適用して別のシーケンスを作成します。最終的に、この後者のシーケンスを用いて、SPARQLクエリ形式の結果の1つを生成します。
ソリューション・シーケンス修飾子は、次のいずれか1つです。
修飾子は、上記リストで示されている順序で適用されます。
[5] |
SelectQuery |
::= | 'SELECT' (
'DISTINCT' | 'REDUCED' )? ( Var+ | '*'
) DatasetClause*
WhereClause SolutionModifier |
[14] |
SolutionModifier |
::= | OrderClause?
LimitOffsetClauses? |
[15] |
LimitOffsetClauses |
::= | ( LimitClause
OffsetClause? | OffsetClause
LimitClause? ) |
[16] |
OrderClause |
::= | 'ORDER'
'BY' OrderCondition+ |
ORDER BY
句は、ソリューション・シーケンスの順序を定めます。
ORDER BY
句の後には、式と、オプションの順序修飾子(ASC()
かDESC()
のどちらか)で構成された順序コンパレータ(order comparator)のシーケンスが続きます。各順序付けコンパレータは、昇順(ASC()
修飾子、または、修飾子なしで示される)か、降順(DESC()
修飾子で示される)です。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } ORDER BY ?name
PREFIX : <http://example.org/ns#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?name WHERE { ?x foaf:name ?name ; :empId ?emp } ORDER BY DESC(?emp)
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name ; :empId ?emp } ORDER BY ?name DESC(?emp)
「<」という演算子(演算子マッピングおよび11.3.1 演算子の拡張性を参照)は、数値(numerics
)、シンプルなリテラル(simple literals
)、xsd:strings
、xsd:booleans
、xsd:dateTimes
の対の相対順序を定めます。IRIの対は、simple literals
として比較し、順序付けられます。
SPARQLは、次の、別の方法では順序付けられない数種のRDF用語間の順序も定めます。
プレーン・リテラルは、同じ字句形式の型xsd:string
を持つRDFリテラルよりも順序が低いです。
SPARQLは、可能な限りのあらゆるRDF用語の全体的な順序付けを定めるわけではありません。以下は、相対順序が定められていない対の用語のいくつかの例です。
この変数バインディングのリストは、昇順です。
RDFの用語 | 理由 |
---|---|
バインドされていない結果が最初にソートされます。 | |
_:z | バインドされていないものの次は空白ノードです。 |
_:a | 空白ノードには相対的な順序付けがありません。 |
<http://script.example/Latin> | 空白ノードの次はIRIです。 |
<http://script.example/Кириллица> | 23番目に位置する文字「К」は、Unicodeのコードポイント0x41Aを持っており、これは0x4C(「L」)より順序が高いです。 |
<http://script.example/漢字> | 23番目に位置する文字「漢」は、Unicodeのコードポイント0x6F22を持っており、これは0x41A(「К」)より順序が高いです。 |
"http://script.example/Latin" | IRIの次はシンプルなリテラルです。 |
"http://script.example/Latin"^^xsd:string | シンプルなリテラルの次はxsd:stringです。 |
順序付けコンパレータに対する2つのソリューションの昇順は、ソリューションのバインディングを式に代入し、それを「<」演算子で比較することで定めることができます。降順は昇順の逆です。
2つのソリューションの相対順序は、シーケンス内の最初の順序付けコンパレータに対する2つのソリューションの相対順序です。ソリューション・バインディングの置換が同じRDF用語を作成するソリューションの場合は、順序は次の順序付けコンパレータに対する2つのソリューションの相対順序です。2つのソリューションに対して評価が行われた順序の式が別々のRDF用語を作成しない場合、2つのソリューションの相対順序は未定義です。
ソリューションのシーケンスの順序付けは、常に、その内部に同数のソリューションを持つシーケンスになります。
ソリューション・シーケンスでCONSTRUCT
またはDESCRIBE
クエリに対しORDER BY
を使用すると、SELECT
のみが結果のシーケンスを返すため、直接的な効果はありません。LIMIT
やOFFSET
と組み合わせて用いれば、ORDER BY
は、ソリューション・シーケンスの異なる部分から生じる結果を返すために使用できます。ASK
クエリは、ORDER BY
、LIMIT
、または、OFFSET
を含みません。
[16] |
OrderClause |
::= | 'ORDER' 'BY' OrderCondition+ |
[17] |
OrderCondition |
::= | ( ( 'ASC' | 'DESC' ) BrackettedExpression ) |
[18] |
LimitClause |
::= | 'LIMIT' INTEGER |
[19] |
OffsetClause |
::= | 'OFFSET' INTEGER |
ソリューション・シーケンスは変数のサブセットのみを含むものに変換できます。シーケンスの各ソリューションに対し、SELECTクエリ形式を用いて変数の指定選択を用いることで新しいソリューションが作成されます。
以下の例では、FOAFプロパティーを用いて、RDFグラフで記述された人名のみを抽出するためのクエリを示しています。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Bob" |
"Alice" |
DISTINCT
またはREDUCED
というクエリ修飾子を用いないソリューション・シーケンスは、複製のソリューションを保持するでしょう。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Alice" . _:x foaf:mbox <mailto:alice@example.com> . _:y foaf:name "Alice" . _:y foaf:mbox <mailto:asmith@example.com> . _:z foaf:name "Alice" . _:z foaf:mbox <mailto:alice.smith@example.com> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
"Alice" |
"Alice" |
DISTINCT
およびREDUCED
の修飾子は、クエリの結果に重複が含まれるかどうかに影響を与えます。
DISTINCT
ソリューション修飾子は、重複するソリューションを排除します。具体的には、別のソリューションと同じRDF用語に同じ変数をバインドする各ソリューションが、ソリューション集合から排除されます。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
ソリューション・シーケンス修飾子の順序にあるように、limitかoffsetのいずれかが適用される前に重複が排除されることに注意してください。
DISTINCT
修飾子は、ソリューション集合から重複したソリューションを確実に排除しますが、REDUCED
は、単にそれらを排除することを許可するだけです。REDUCED
ソリューション集合の変数バインディング集合のカーディナリティーは、少なくとも1で、多くともDISTINCT
またはREDUCED
修飾子を用いないソリューション集合のカーディナリティーを超えません。例えば、上記のデータを用いた場合、次のクエリは、
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT REDUCED ?name WHERE { ?x foaf:name ?name }
1、2(ここで示しているもの)、または、3つのソリューションを持つことができます。
name |
---|
"Alice" |
"Alice" |
OFFSET
は、指定された数のソリューションの後でソリューションが始まるようにします。OFFSET
を0にすれば効果はありません。
クエリのソリューションの異なるサブセットを選択するためにLIMIT
とOFFSET
を用いても、ORDER BY
を用いて順序を予測できるようにしないと、有効ではないでしょう。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } ORDER BY ?name LIMIT 5 OFFSET 10
LIMIT
句は、返されるソリューションの数に上限を設けます。実際のソリューションの数がlimitより大きい場合は、最大で、limitの数のソリューションが返されるでしょう。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } LIMIT 20
LIMIT
を0にすれば、結果を返さないでしょう。limitは負の数であってはなりません。
SPARQLには、4つのクエリ形式があります。これらのクエリ形式は、パターン・マッチングのソリューションを用いて、結果集合またはRDFグラフを作成します。クエリ形式は、次の通りです。
- SELECT
- クエリ・パターンにバインドされた変数の、すべてまたはサブセットを返す。
- CONSTRUCT
- 1組のトリプル・テンプレートに変数を代入して構築したRDFグラフを返す。
- ASK
- クエリ・パターンがマッチするかどうかを示すブール値を返す。
- DESCRIBE
- 発見した資源に関して記述したRDFグラフを返す。
SELECT
クエリからの結果集合、または、ASK
クエリのブール演算結果をシリアル化するためにSPARQL変数バインディング結果XMLフォーマットを使用できます。
結果のSELECT形式は、変数とそのバインディングを直接返します。構文SELECT*
は、クエリ中の変数のすべてを選択するための省略形です。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:knows _:b . _:a foaf:knows _:c . _:b foaf:name "Bob" . _:c foaf:name "Clare" . _:c foaf:nick "CT" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?nameX ?nameY ?nickY WHERE { ?x foaf:knows ?y ; foaf:name ?nameX . ?y foaf:name ?nameY . OPTIONAL { ?y foaf:nick ?nickY } }
nameX | nameY | nickY |
---|---|---|
"Alice" | "Bob" | |
"Alice" | "Clare" | "CT" |
結果集合は、ローカルAPIからアクセスできますが、XMLかRDFグラフのどちらかにシリアル化することも可能です。XMLフォーマットは、SPARQLクエリ結果XMLフォーマットで記述されており、次の例で示しています。
<?xml version="1.0"?> <sparql xmlns="http://www.w3.org/2005/sparql-results#"> <head> <variable name="nameX"/> <variable name="nameY"/> <variable name="nickY"/> </head> <results> <result> <binding name="nameX"> <literal>Alice</literal> </binding> <binding name="nameY"> <literal>Bob</literal> </binding> </result> <result> <binding name="nameX"> <literal>Alice</literal> </binding> <binding name="nameY"> <literal>Clare</literal> </binding> <binding name="nickY"> <literal>CT</literal> </binding> </result> </results> </sparql>
[5] |
SelectQuery |
::= | 'SELECT' ( 'DISTINCT' | 'REDUCED' )? ( Var+ | '*' ) |
CONSTRUCT
クエリ形式は、グラフ・テンプレートで指定された1つのRDFグラフを返します。結果は、各クエリのソリューションをソリューション・シーケンスに取り込み、グラフ・テンプレートに変数を代入し、和集合によってトリプルを1つのRDFグラフに結合して作成されたRDFグラフです。
このようなインスタンス化が、主語または述語の位置にあるリテラルなどの、バインドされていない変数または不正なRDF構成子を含むトリプルを作成する場合は、そのトリプルは出力RDFグラフに含まれません。グラフ・テンプレートは、変数を持たないトリプル(基底的または明示的なトリプルとして知られる)を含むことができ、これらはCONSTRUCTクエリ形式が返した出力RDFグラフにも表示されます。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@example.org> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> CONSTRUCT { <http://example.org/person#Alice> vcard:FN ?name } WHERE { ?x foaf:name ?name }
は、FOAF情報からvcardプロパティーを作成します。
@prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . <http://example.org/person#Alice> vcard:FN "Alice" .
テンプレートは、空白ノードを含んだRDFグラフを作成できます。空白ノード・ラベルは、各ソリューションに対するテンプレートで有効です。同じラベルが1つのテンプレートで2回出現する場合は、各クエリ・ソリューションに対して作成された1つの空白ノードが存在するでしょうが、別のクエリ・ソリューションによって生成されたトリプルに対する別の空白ノードが存在するでしょう。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:givenname "Alice" . _:a foaf:family_name "Hacker" . _:b foaf:firstname "Bob" . _:b foaf:surname "Hacker" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> CONSTRUCT { ?x vcard:N _:v . _:v vcard:givenName ?gname . _:v vcard:familyName ?fname } WHERE { { ?x foaf:firstname ?gname } UNION { ?x foaf:givenname ?gname } . { ?x foaf:surname ?fname } UNION { ?x foaf:family_name ?fname } . }
は、FOAF情報に対応するvcardプロパティーを作成します。
@prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . _:v1 vcard:N _:x . _:x vcard:givenName "Alice" . _:x vcard:familyName "Hacker" . _:v2 vcard:N _:z . _:z vcard:givenName "Bob" . _:z vcard:familyName "Hacker" .
テンプレートで変数x
を用いると(この例では、データ内でラベル_:a
と_:b
を持つ空白ノードにバインドされているでしょう)、結果として生成されるRDFグラフの中に別の空白ノード・ラベル(_:v1
と_:v2
)が生成されます。
CONSTRUCT
を用いて、ターゲットのRDFデータセットからグラフの部分または全体を抽出することが可能です。この最初の例は、IRIラベルhttp://example.org/aGraph
を持つグラフ(それがデータセットにあれば)を返します。さもなければ、空のグラフを返します。
CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://example.org/aGraph> { ?s ?p ?o } . }
グラフへのアクセスは、他の情報を条件としている場合があります。例えば、デフォルト・グラフがデータセットの名前付きグラフに関するメタデータを含んでいる場合、次のようなクエリは、名前付きグラフに関する情報に基づく1つのグラフを抽出できます。
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX app: <http://example.org/ns#> CONSTRUCT { ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p ?o } . { ?g dc:publisher <http://www.w3.org/> } . { ?g dc:date ?date } . FILTER ( app:customDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime ) . }
ここでは、app:customDate
が拡張関数を識別し、データ・フォーマットをxsd:dateTime
というRDF用語に変えました。
[6] |
ConstructQuery |
::= | 'CONSTRUCT' ConstructTemplate |
クエリのソリューション修飾子は、CONSTRUCT
クエリの結果に影響を与えます。この例では、CONSTRUCT
テンプレートからの出力グラフは、グラフ・パターン・マッチング2つのソリューションのみから形成されます。クエリは、ヒット率で格付けされたトップ2のサイトを持つ人々の名前を持つグラフを出力します。RDFグラフ中のトリプルは順序付けされていません。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix site: <http://example.org/stats#> . _:a foaf:name "Alice" . _:a site:hits 2349 . _:b foaf:name "Bob" . _:b site:hits 105 . _:c foaf:name "Eve" . _:c site:hits 181 .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX site: <http://example.org/stats#> CONSTRUCT { [] foaf:name ?name } WHERE { [] foaf:name ?name ; site:hits ?hits . } ORDER BY desc(?hits) LIMIT 2
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Alice" . _:y foaf:name "Eve" .
アプリケーションは、クエリ・パターンにソリューションがあるか否かをテストするためにASK
形式を使用できます。ありえるクエリのソリューションに関する情報は返さず、ソリューションが存在しているか否かのみです。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" }
yes
この結果集合のSPARQLクエリ結果XMLフォーマットの形式は、次のようになります。
<?xml version="1.0"?> <sparql xmlns="http://www.w3.org/2005/sparql-results#"> <head></head> <results> <boolean>true</boolean> </results> </sparql>
同じデータを用いた場合、次の例は、Aliceのmbox
が記述されていないため、マッチを返しません。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" ; foaf:mbox <mailto:alice@work.example> }
no
[8] |
AskQuery |
::= | 'ASK' DatasetClause* WhereClause |
DESCRIBE
形式は、資源に関するRDFデータを含んだ1つの結果RDFグラフを返します。SPARQLのクエリではこのデータは規定されておらず、この場合には、クエリのクライアントがデータ情報源内のRDFの構造を知っている必要があるでしょうが、その代わりにSPARQLクエリ・プロセッサがこのデータを決定します。クエリ・パターンを用いて結果集合を作成します。DESCRIBE
形式は、IRIで直接指定された任意の資源と一緒に、識別された各資源をソリューションに取り込み、ターゲットのRDFデータセットを含んでいる利用可能な任意の情報から得られる「記述」を持ってくることによって、1つのRDFグラフを組み立てます。記述はクエリ・サービスが決定します。DESCRIBE *
という構文は、クエリ内のすべての変数を記述するための省略形です。
DESCRIBE
句自身がIRIを取り込んで資源を識別することができます。最もシンプルなDESCRIBE
クエリは、次のようなDESCRIBE
句内にIRIのみがあるものです。
DESCRIBE <http://example.org/>
記述される資源は、クエリ変数へのバインディングから結果集合に取り込むこともできます。これによって、次のような、資源がIRIによって識別されるのか、データセットの空白ノードによって識別されるのかの記述が可能になります。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x WHERE { ?x foaf:mbox <mailto:alice@org> }
プロパティーfoaf:mbox
は、FOAF語彙では、逆関数プロパティーであると定義されています。そういうものとして処理すると、このクエリは、高々1人の人物に関する情報を返すでしょう。しかし、クエリ・パターンに複数のソリューションがある場合は、それぞれに対するRDFデータは、すべてのRDFグラフ記述の和集合です。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x WHERE { ?x foaf:name "Alice" }
次のように、1つ以上のIRIまたは変数を作成できます。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x ?y <http://example.org/> WHERE {?x foaf:knows ?y}
返されるRDFは、情報の発行者が決定します。これは、サービスが資源について有する有益な情報です。他の資源に関する情報を含むことができます。例えば、本のRDFデータには、著者に関する詳細を含むこともできます。
次のようなシンプルなクエリは、
PREFIX ent: <http://org.example.com/employees#> DESCRIBE ?x WHERE { ?x ent:employeeId "1234" }
下記のような、従業員の記述や、何らかの他の潜在的に役に立つ詳細情報を返すかもしれません。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0> . @prefix exOrg: <http://org.example.com/employees#> . @prefixrdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix owl: <http://www.w3.org/2002/07/owl#>
_:a exOrg:employeeId "1234" ;foaf:mbox_sha1sum "ABCD1234" ;
vcard:N [ vcard:Family "Smith" ; vcard:Given "John" ] .foaf:mbox_sha1sum rdf:type owl:InverseFunctionalProperty .
これには、vcard語彙vcard:Nに対する空白ノード・クロージャが含まれいます。どのような情報を返すかを決定できる他のメカニズムには、Concise Bounded Descriptions[CBD]などもあります。
FOAFなどの語彙では、通常は、資源は空白ノードであるため、InverseFunctionalPropertyであるfoaf:mbox_sha1sum
などのノードを識別するのに十分な情報や、名前やその他の詳細データといった情報を返すのが適切でしょう。例では、WHERE句に対するマッチが返されましたが、これは必須ではありません。
[7] |
DescribeQuery |
::= | 'DESCRIBE' ( VarOrIRIref+ | '*' ) |
SPARQLのFILTER
は、与えられた式に従ってグラフ・パターン・マッチのソリューションを制限します。具体的には、FILTER
は、式に代入したときに、偽(false
)の有効なブール値になったり、エラーを起こしたりするソリューションを排除します。有効なブール値は11.2.2 有効なブール値の項で定義されており、エラーはXQuery1.0: XMLクエリ言語[XQUERY]の2.3.1, エラーの種類の項で定義されています。これらのエラーは、FILTER
の評価以外には影響を与えません。
RDFリテラルは、データ型IRIを持つことができます。
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . _:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:a dc:date "2004-12-31T19:00:00-05:00" . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:date "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
最初のdc:date
トリプルの目的語には、型情報が全くありません。2番目のものには、xsd:dateTime
というデータ型があります。
SPARQLの式は文法に従って構築され、関数(IRIによって名前が付けられる)と演算子関数へのアクセスを提供します(SPARQL文法のキーワードとシンボルで呼び出される)。SPARQLの演算子は、型付リテラルの値を比較するために使用できます。
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?annot WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . ?annot dc:date ?date . FILTER ( ?date > "2005-01-01T00:00:00Z"^^xsd:dateTime ) }
SPARQLの演算子は、11.3項に記載されており、文法上の生成規則に関連付けられています。
さらに、SPARQLは、11.5項に記載している、XPathキャスト関数のサブセットを含む、任意の関数を呼び出す能力を提供します。これらの関数は、名前(IRI)によってSPARQLクエリの中に呼び出されます。例えば次のとおりです。
... FILTER ( xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00:00Z") ) ...
この項では、次の表記上の規定を用いています。
op:
でラベル付けされています。XPath演算子には名前空間がなく、op:
はラベル付け上の慣習です。SPARQLの関数と演算子は、RDF用語とSPARQL変数を演算します。これらの関数および演算子のサブセットは、XQuery 1.0とXPath 2.0関数および演算子[FUNCOP]から持って来たもので、XMLスキーマ型付き値の引数を持っており、型を返します。これらの関数と演算子に引数として渡されたRDF型付きリテラル(typed literals
)は、字句形式(lexical form
)の文字列の値を持つXMLスキーマの型付き値と、datatype IRI(データ型IRI)に対応するアトミックなデータ型にマッピングされます。返された型付き値は、同様にRDFの型付きリテラル(typed literals
)にマッピングし返されます。
SPARQLには、RDF用語の特定のサブセットに基づいて演算する付加的な演算子があります。型について述べるときには、次の用語は、XMLスキーマ[XSDT]のデータ型IRIに対応する型付きリテラル(typed literal
)を表します。
次の用語は、SPARQL値テストに用いられる付加的な型を識別します。
xsd:integer
、xsd:decimal
、xsd:float
、および、xsd:double
を持つ型付きリテラル(typed literals
)を表します。language tag
)を持たないプレーン・リテラル(plain literal
)を表します。IRI
、リテラル(literal
)、および、空白ノード(blank node
)の型を表します。次の型は、数値の型から得られ、数値引数を取る関数と演算子に対する有効な引数です。
xsd:nonPositiveInteger
xsd:negativeInteger
xsd:long
xsd:int
xsd:short
xsd:byte
xsd:nonNegativeInteger
xsd:unsignedLong
xsd:unsignedInt
xsd:unsignedShort
xsd:unsignedByte
xsd:positiveInteger
SPARQLの言語拡張は、付加的な型をXMLスキーマ・データ型から得られるものとして扱うことができます。
SPARQLは、XQuery演算子マッピングで定義された関数と演算子のサブセットを提供します。XQuery 1.0の2.2.3 式の処理の項では、XPath関数の呼び出しについて説明しています。次の規則は、XQueryとSPARQLのデータと実行モデルの違いを調整します。
xsd:boolean
に強制変換されます。||
)または論理AND(&&
)を除く任意の式は、エラーを起こすでしょう。真(T)、偽(F)、エラー(E)に対する論理ANDと論理ORの真理値表は次の通りです。
A | B | A || B | A && B |
---|---|---|---|
T | T | T | T |
T | F | T | F |
F | T | T | F |
F | F | F | F |
T | E | T | E |
E | T | T | E |
F | E | E | F |
E | F | E | F |
E | E | E | E |
SPARQLは、引数のリストに関数と演算子を呼び出すための構文を定義しています。これらは、次の通りに呼び出されます。
これらのステップのどれかが失敗すれば、呼び出しはエラーを起こします。エラーの影響は、フィルタ評価で定義されています。
有効なブール値は、論理AND、論理OR、およびfn:notの論理関数に対する引数を計算するために用いられ、また、FILTER
式の結果の評価も行います。
XQueryの有効なブール値の規則は、XPathのfn:booleanの定義に依存しています。以下の規則は、SPARQLのクエリに存在している引数の型に適用されたfn:boolean
の規則を反映しています。
xsd:boolean
または数値(numeric)である任意のリテラルのEBVは、字句形式がそのデータ型(例えば、"abc"^^xsd:integer)に対して偽である場合は、偽です。xsd:boolean
のデータ型を持つ型付きリテラルである場合、EBVはその引数の値です。xsd:string
のデータ型を持つ型付きリテラルである場合、オペランド値に0の長さがあるならEBVは偽で、そうれなければEBVは真です。真(true
)のEBVは、xsd:boolean
のデータ型および「真」の字句値を持つ型付きリテラルとして表され、
偽(false)のEBVは、xsd:boolean
のデータ型および「偽」の字句値を持つ型付きリテラルとして表されます。
SPARQLの文法は、一連の演算子を識別し(例えば、&&、*、isIRI)、制約を構築するために用いられます。以下のテーブルは、これらのそれぞれの文法上の生成規則と、XQuery 1.0とXPath 2.0関数および演算子[FUNCOP]、または11.4項のSPARQL演算子のいずれかによって定義されている適切なオペランドおよび演算子関数とを関連付けます。一連のパラメータに対する演算子定義を選択する際には、最も明確なパラメータを持つ定義が適用されます。例えば、xsd:integer = xsd:signedInt
を評価する際には、2つのRDF用語を持つ=
に対する定義ではなく、2つの数値(numeric
)パラメータを持つ=
に対する定義が適用されます。表は、最も実行可能性のある候補が最も明確になるように配列されています。適切なオペランドなしに呼び出された演算子は、型エラーになります。
SPARQLは、XPathの数値型昇格(numeric type promotion)に対するスキームと、数値演算子への引数に対する部分型置換(subtype substitution)に従います。数値オペランド(xsd:integer
、xsd:decimal
、xsd:float
、xsd:double
、および数値型から得られた型)のXPath演算子マッピング規則は、SPARQL演算子にも適用されます(数値型昇格および部分型置換の定義に関しては、XMLパス言語(XPath)2.0[XPATH20]を参照してください)。演算子の一部は、入れ子にされた関数式、例えばfn:not(op:numeric-equal(A, B))
に関連しています。XPathの定義によって、fn:not
およびop:numeric-equal
は、引数がエラーである場合にはエラーを起こします。
fn:compare
の照合順序は、XPathで定義され、http://www.w3.org/2005/xpath-functions/collation/codepoint
で識別されます。この照合順序は、コードポイント値に基づく文字列の比較を可能にします。コードポイント文字列の同等性は、RDF用語の同等性でテストできます。
演算子 | 型(A) | 関数 | 結果の型 | |
---|---|---|---|---|
XQuery単項演算子 | ||||
! A | xsd:boolean (EBV) | fn:not(A) | xsd:boolean | |
+ A | 数値 | op:numeric-unary-plus(A) | 数値 | |
- A | 数値 | op:numeric-unary-minus(A) | 数値 | |
SPARQLテスト(11.4項で定義されている) | ||||
BOUND(A) | 変数 | bound(A) | xsd:boolean | |
isIRI(A) isURI(A) |
RDF用語 | isIRI(A) | xsd:boolean | |
isBLANK(A) | RDF用語 | isBlank(A) | xsd:boolean | |
isLITERAL(A) | RDF用語 | isLiteral(A) | xsd:boolean | |
SPARQLアクセサ(11.4項で定義されている) | ||||
STR(A) | リテラル | str(A) | シンプルなリテラル | |
STR(A) | IRI | str(A) | シンプルなリテラル | |
LANG(A) | リテラル | lang(A) | シンプルなリテラル | |
DATATYPE(A) | 型付きリテラル | datatype(A) | IRI | |
DATATYPE(A) | シンプルなリテラル | datatype(A) | IRI |
演算子 | 型(A) | 型(B) | 関数 | 結果の型 |
---|---|---|---|---|
論理結合子(11.4項で定義されている) | ||||
A || B | xsd:boolean (EBV) | xsd:boolean (EBV) | logical-or(A, B) | xsd:boolean |
A && B | xsd:boolean (EBV) | xsd:boolean (EBV) | logical-and(A, B) | xsd:boolean |
XPathテスト | ||||
A = B | 数値 | 数値 | op:numeric-equal(A, B) | xsd:boolean |
A = B | シンプルなリテラル | シンプルなリテラル | op:numeric-equal(fn:compare(A, B), 0) | xsd:boolean |
A = B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), 0) | xsd:boolean |
A = B | xsd:boolean | xsd:boolean | op:boolean-equal(A, B) | xsd:boolean |
A = B | xsd:dateTime | xsd:dateTime | op:dateTime-equal(A, B) | xsd:boolean |
A != B | 数値 | 数値 | fn:not(op:numeric-equal(A, B)) | xsd:boolean |
A != B | シンプルなリテラル | シンプルなリテラル | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xsd:boolean |
A != B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 0)) | xsd:boolean |
A != B | xsd:boolean | xsd:boolean | fn:not(op:boolean-equal(A, B)) | xsd:boolean |
A != B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-equal(A, B)) | xsd:boolean |
A < B | 数値 | 数値 | op:numeric-less-than(A, B) | xsd:boolean |
A < B | シンプルなリテラル | シンプルなリテラル | op:numeric-equal(fn:compare(A, B), -1) | xsd:boolean |
A < B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), -1) | xsd:boolean |
A < B | xsd:boolean | xsd:boolean | op:boolean-less-than(A, B) | xsd:boolean |
A < B | xsd:dateTime | xsd:dateTime | op:dateTime-less-than(A, B) | xsd:boolean |
A > B | 数値 | 数値 | op:numeric-greater-than(A, B) | xsd:boolean |
A > B | シンプルなリテラル | シンプルなリテラル | op:numeric-equal(fn:compare(A, B), 1) | xsd:boolean |
A > B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), 1) | xsd:boolean |
A > B | xsd:boolean | xsd:boolean | op:boolean-greater-than(A, B) | xsd:boolean |
A > B | xsd:dateTime | xsd:dateTime | op:dateTime-greater-than(A, B) | xsd:boolean |
A <= B | 数値 | 数値 | logical-or(op:numeric-less-than(A, B), op:numeric-equal(A, B)) | xsd:boolean |
A <= B | シンプルなリテラル | シンプルなリテラル | fn:not(op:numeric-equal(fn:compare(A, B), 1)) | xsd:boolean |
A <= B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 1)) | xsd:boolean |
A <= B | xsd:boolean | xsd:boolean | fn:not(op:boolean-greater-than(A, B)) | xsd:boolean |
A <= B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-greater-than(A, B)) | xsd:boolean |
A >= B | 数値 | 数値 | logical-or(op:numeric-greater-than(A, B), op:numeric-equal(A, B)) | xsd:boolean |
A >= B | シンプルなリテラル | シンプルなリテラル | fn:not(op:numeric-equal(fn:compare(A, B), -1)) | xsd:boolean |
A >= B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), -1)) | xsd:boolean |
A >= B | xsd:boolean | xsd:boolean | fn:not(op:boolean-less-than(A, B)) | xsd:boolean |
A >= B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-less-than(A, B)) | xsd:boolean |
XPath計算 | ||||
A * B | 数値 | 数値 | op:numeric-multiply(A, B) | 数値 |
A / B | 数値 | 数値 | op:numeric-divide(A, B) | 数値; but xsd:decimal if both operands are xsd:integer |
A + B | 数値 | 数値 | op:numeric-add(A, B) | 数値 |
A - B | 数値 | 数値 | op:numeric-subtract(A, B) | 数値 |
SPARQLテスト(11.4項で定義されている) | ||||
A = B | RDF用語 | RDF用語 | RDFterm-equal(A, B) | xsd:boolean |
A != B | RDF用語 | RDF用語 | fn:not(RDFterm-equal(A, B)) | xsd:boolean |
sameTERM(A) | RDF用語 | RDF用語 | sameTerm(A, B) | xsd:boolean |
langMATCHES(A, B) | シンプルなリテラル | シンプルなリテラル | langMatches(A, B) | xsd:boolean |
REGEX(STRING, PATTERN) | シンプルなリテラル | シンプルなリテラル | fn:matches(STRING, PATTERN) | xsd:boolean |
演算子 | 型(A) | 型(B) | 型(C) | 関数 | 結果の型 |
---|---|---|---|---|---|
SPARQLテスト(11.4項で定義されている) | |||||
REGEX(STRING, PATTERN, FLAGS) | シンプルなリテラル | シンプルなリテラル | シンプルなリテラル | fn:matches(STRING, PATTERN, FLAGS) | xsd:boolean |
「(EBV)」と共にマーク付けされたxsd:boolean関数の引数は、その引数の有効なブール値の評価によるxsd:booleanに強制されます。
SPARQLの言語拡張は、演算子と演算子関数の間の付加的な関連付けを提供でき、これは、上記の表に列を加えることに等しいです。付加的な演算子は、上記で定義したセマンティクスにおける型エラー以外の結果に代わる結果をもたらさないかもしれません。この規則の結果は、SPARQLの拡張が少なくとも同じソリューションを未拡張の実装として作成し、いくつかのクエリに対し、より多くのソリューションを作成するかもしれないというものです。
「<」演算子の追加マッピングは、特に、ORDER BY
句で用いられるときに、オペランドの相対的な順序付けを制御すると予想されます。
この項では、SPARQLクエリ言語で導入された演算子を定義します。例では、適切な文法構造によって呼び出される際の演算子の動作を示しています。
xsd:boolean
bound
(variable
var
)
var
が値にバインドされている場合は、真(true)を返します。そうでない場合は、偽(false)を返します。NaNまたはINFの値を持つ変数は、バインドされているとみなされます。
データ:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a foaf:givenName "Alice". _:b foaf:givenName "Bob" . _:b dc:date "2005-04-04T04:04:04Z"^^xsd:dateTime .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>SELECT ?name WHERE { ?x foaf:givenName ?givenName . OPTIONAL { ?x dc:date ?date } . FILTER ( bound(?date) ) }
クエリ結果:
givenName |
---|
"Bob" |
変数を導入するOPTIONAL
グラフ・パターンを指定し、変数がバインドされていない(not
bound
)ことを確認するテストを行うことによってグラフ・パターンが表されていないことをテストできます。これは論理プログラミングでは、失敗による否定(Negation as Failure)と呼ばれます。
このクエリは、名前(name
)を持つが、日付(date
)の表現を持たない人にマッチします。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name WHERE { ?x foaf:givenName ?name . OPTIONAL { ?x dc:date ?date } . FILTER (!bound(?date)) }
クエリ結果:
name |
---|
"Alice" |
Bobのdc:date
は既知であったため、"Bob"
はクエリのソリューションにはなりませんでした。
xsd:boolean
isIRI
(RDF term
term
)xsd:boolean
isURI
(RDF term
term
)
用語(term
)がIRIである場合は、真(true
)を返します。そうでない場合は、偽(false
)を返します。isURI
は、isIRI
演算子の別のスペルです。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox "bob@work.example" .
このクエリは、名前(name
)と、IRIであるmbox
を持つ人にマッチします。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER isIRI(?mbox) }
クエリ結果:
name | mbox |
---|---|
"Alice" | <mailto:alice@work.example> |
xsd:boolean
isBlank
(RDF term
term
)
用語(term
)が空白ノードである場合は、真(true
)を返します。そうでない場合は、偽(false
)を返します。
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:a dc:creator "Alice B. Toeclips" . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:creator _:c . _:c foaf:given "Bob". _:c foaf:family "Smith".
このクエリは、名前を表すためにFOAF語彙の述語を用いているdc:creator
を持つ人にマッチします。
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#>PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?given ?family WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . ?annot dc:creator ?c . OPTIONAL { ?c foaf:given ?given ; foaf:family ?family } . FILTER isBlank(?c) }
クエリ結果:
given | family |
---|---|
"Bob" | "Smith" |
この例では、foaf:knows
という述語の目的語が2つありましたが、たった1つの(_:c
)が空白ノードでした。
xsd:boolean
isLiteral
(RDF term
term
)
用語(term
)がリテラルである場合、真(true
)を返します。そうでない場合は、偽(false
)を返します。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox "bob@work.example" .
このクエリは、名前(name
)と、リテラルであるmbox
を持つ人にマッチする点を除いて、11.4.2のものと類似しています。これは、エラーのあるデータを探すために使用できるでしょう(foaf:mbox
は、目的語として1つのIRIのみを持っているはずです)。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER isLiteral(?mbox) }
クエリ結果:
name | mbox |
---|---|
"Bob" | "bob@work.example" |
simple literal
str
(literal
ltrl
)simple literal
str
(IRI
rsrc
)
ltrl
(リテラル)の字句形式を返し、rsrc
(IRI)コードポイント表現を返します。これは、IRIの部分、例えば、ホスト名を調べるのに役に立ちます。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@home.example> .
このクエリは、次のとおり、自分達のfoafプロフィールでwork.example
のアドレスを使用する人々の集合を選び出します。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER regex(str(?mbox), "@work.example") }
クエリ結果:
name | mbox |
---|---|
"Alice" | <mailto:alice@work.example> |
simple literal
lang
(literal
ltrl
)
ltrl
の言語タグ(language tag
)(それがある場合)を返します。ltrl
に言語タグ(language tag
)がない場合は、""
を返します。RDFデータ・モデルが空の言語タグ(language tag
)を持つリテラルを含んでいないことに注意してください。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Robert"@EN. _:a foaf:name "Roberto"@ES. _:a foaf:mbox <mailto:bob@work.example> .
このクエリは、スペイン語のfoaf:name
とfoaf:mbox
を発見します。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER ( lang(?name) = "ES" ) }
クエリ結果:
name | mbox |
---|---|
"Roberto"@ES | <mailto:bob@work.example> |
IRI
datatype
(typed literal
typedLit
)IRI
datatype
(simple literal
simpleLit
)
typedLit
のデータ型IRI(datatype IRI
)を返し、パラメータがシンプルなリテラルである場合は、xsd:string
を返します。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix eg: <http://biometrics.example/ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a foaf:name "Alice". _:a eg:shoeSize "9.5"^^xsd:float . _:b foaf:name "Bob". _:b eg:shoeSize "42"^^xsd:integer .
このクエリは、整数であるshoeSizeを持つすべての人のfoaf:name
とfoaf:shoeSize
を発見します。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX eg: <http://biometrics.example/ns#> SELECT ?name ?shoeSize WHERE { ?x foaf:name ?name ; eg:shoeSize ?shoeSize . FILTER ( datatype(?shoeSize) = xsd:integer ) }
クエリ結果:
name | shoeSize |
---|---|
"Bob" | 42 |
xsd:boolean
xsd:boolean
left
||
xsd:boolean
right
左(left
)と右(right
)の論理和(OR
)を返します。logical-or
がその引数の有効なブール値に基づいて演算を行うことに注意してください。
注意: ||
演算子のエラーの処理に関しては、11.2項のフィルタ評価を参照してください。
xsd:boolean
xsd:boolean
left
&&
xsd:boolean
right
左(left
)と右(right
)の論理積(AND
)を返します。logical-and
がその引数の有効なブール値に基づいて演算することに注意してください。
注意: &&
演算子のエラーの処理に関しては、11.2項のフィルタ評価を参照してください。
xsd:boolean
RDF term
term1
=
RDF term
term2
RDF(Resource Description Framework): 概念および抽象構文[CONCEPTS]で定義されているとおり、term1
とterm2
が同じRDF用語*でない場合は、TRUEを返します。両方の引数がリテラルであるけれども同じRDF用語ではない場合は、型エラーを起こし、そうでない場合は、FALSEを返します。次のいずれかが真である場合は、term1
とterm2
は同じです。
term1
とterm2
は、[CONCEPTS]の6.4 RDF URI参照で定義されているとおり、同等なIRIです。term1
とterm2
は、[CONCEPTS]の6.5.1 リテラルの同等性で定義されているとおり、同等なリテラルです。term1
とterm2
は、[CONCEPTS]の6.6 空白ノードで述べられているとおり、同じ空白ノードです。@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Ms A.". _:b foaf:mbox <mailto:alice@work.example> .
このクエリは、複数のfoaf:name
トリプルを持つ人を発見します。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name1 ?name2 WHERE { ?x foaf:name ?name1 ; foaf:mbox ?mbox1 . ?y foaf:name ?name2 ; foaf:mbox ?mbox2 . FILTER (?mbox1 = ?mbox2 && ?name1 != ?name2) }
クエリ結果:
name1 | name2 |
---|---|
"Alice" | "Ms A." |
"Ms A." | "Alice" |
元日(2004年か2005年)にアノテーションを付与されたドキュメントに関するこのクエリは、RDF用語は同じではありませんが、同等な値を持っています。
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:date "2004-12-31T19:00:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?annotates WHERE { ?annot a:annotates ?annotates . ?annot dc:date ?date . FILTER ( ?date = xsd:dateTime("2005-01-01T00:00:00Z") ) }
annotates |
---|
<http://www.w3.org/TR/rdf-sparql-query/> |
* 2つの型付きリテラルにRDFterm-equalを呼び出すことで、同等な値をテストします。拡張された実装には、付加的なデータ型のサポートがあるかもしれません。未サポートのデータ型(および、異なる字句形式とデータ型IRI)の同等性をテストするクエリを処理する実装はエラーを返し、値が同等かどうかを決定できなかったことを示します。例えば、"iiii"^^my:romanNumeral = "iv"^^my:romanNumeral
か"iiii"^^my:romanNumeral != "iv"^^my:romanNumeral
のいずれかのテストを行った場合、未拡張の実装にエラーが生じます。
xsd:boolean
sameTerm
(RDF term
term1
,RDF term
term2
)
RDF(Resource Description Framework): 概念および抽象構文[CONCEPTS]で定義されているとおり、term1
とterm2
が同じRDF用語である場合は、TRUEを返し、そうでない場合は、FALSEを返します。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Ms A.". _:b foaf:mbox <mailto:alice@work.example> .
このクエリは、複数のfoaf:name
トリプルを持つ人を発見します。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name1 ?name2 WHERE { ?x foaf:name ?name1 ; foaf:mbox ?mbox1 . ?y foaf:name ?name2 ; foaf:mbox ?mbox2 . FILTER (sameTerm(?mbox1, ?mbox2) && !sameTerm(?name1, ?name2)) }
クエリ結果:
name1 | name2 |
---|---|
"Alice" | "Ms A." |
"Ms A." | "Alice" |
RDFterm-equal
とは異なり、sameTerm
は、未サポートのデータ型を持つ非同等な型付きリテラルをテストするために使用できます。
@prefix : <http://example.org/WMterms#> . @prefix t: <http://example.org/types#> . _:c1 :label "Container 1" . _:c1 :weight "100"^^t:kilos . _:c1 :displacement "100"^^t:liters . _:c2 :label "Container 2" . _:c2 :weight "100"^^t:kilos . _:c2 :displacement "85"^^t:liters . _:c3 :label "Container 3" . _:c3 :weight "85"^^t:kilos . _:c3 :displacement "85"^^t:liters .
PREFIX : <http://example.org/WMterms#> PREFIX t: <http://example.org/types#> SELECT ?aLabel1 ?bLabel WHERE { ?a :label ?aLabel . ?a :weight ?aWeight . ?a :displacement ?aDisp . ?b :label ?bLabel . ?b :weight ?bWeight . ?b :displacement ?bDisp . FILTER ( sameTerm(?aWeight, ?bWeight) && !sameTerm(?aDisp, ?bDisp) }
aLabel | bLabel |
---|---|
"Container 1" | "Container 2" |
"Container 2" | "Container 1" |
"100"^^t:kilos = "85"^^t:kilos
のテストが、その生成されうるソリューションを排除して、エラーをもたらすため、同じ重さの箱のテストは「=」演算子(RDFterm-equal)でも行えます。
xsd:boolean
langMatches
(simple literal
language-tag
,simple literal
language-range
)
language-tag
(最初の引数)が、[RFC4647]の3.3.1項で定義されている基本的なフィルタリング・スキームでlanguage-range
(2番目の引数)にマッチする場合は、真(true
)を返します。language-range
は、[RFC4647]の2.1.項の言語タグのマッチングにあるとおりの基本言語の範囲です。「*」のlanguage-range
は、任意の空でないlanguage-tag
文字列にマッチします。
@prefix dc: <http://purl.org/dc/elements/1.1/> . _:a dc:title "That Seventies Show"@en . _:a dc:title "Cette Série des Années Soixante-dix"@fr . _:a dc:title "Cette Série des Années Septante"@fr-BE . _:b dc:title "Il Buono, il Bruto, il Cattivo" .
このクエリでは、英語で「That Seventies Show」として知られているショーに対するフランス語のタイトルを発見するために、langMatches
とlang
(11.2.3.8項で述べた)を使用しています。
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title "That Seventies Show"@en ; dc:title ?title . FILTER langMatches( lang(?title), "FR" ) }
クエリ結果:
title |
---|
"Cette Série des Années Soixante-dix"@fr |
"Cette Série des Années Septante"@fr-BE |
成句的表現langMatches( lang( ?v ), "*" )
は、lang( ?v )
が空の文字列を返すため、言語タグなしではリテラルにマッチしないでしょう。そのため、
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title ?title . FILTER langMatches( lang(?title), "*" ) }
は、言語タグを持つタイトルのすべてを報告するでしょう。
title |
---|
"That Seventies Show"@en |
"Cette Série des Années Soixante-dix"@fr |
"Cette Série des Années Septante"@fr-BE |
xsd:boolean
regex
(simple literal
text
,simple literal
pattern
)xsd:boolean
regex
(simple literal
text
,simple literal
pattern
,simple literal
flags
)
正規表現パターン(pattern
)に対してテキスト(text
)をマッチさせるためにXPath fn:matches関数を呼び出します。正規表現言語は、XQuery 1.0とXPath 2.0関数および演算子の7.6.1 正規表現構文[FUNCOP]の項で定義されています。
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice"._:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name FILTER regex(?name, "^ali", "i") }
クエリ結果:
name |
---|
"Alice" |
SPARQLは、XQuery 1.0とXPath 2.0関数および演算子[FUNCOP]の17.1 プリミティブ型からプリミティブ型へのキャスティングで定義されているXPathコンストラクタ関数のサブセットをインポートします。SPARQLコンストラクタは、RDFデータ・モデルが規定しているSPARQLオペランド・データ型と付加的なデータ型のXPathコンストラクタのすべてを含んでいます。SPARQLのキャスティングは、情報源の型のオペランドにターゲット型に対するコンストラクタ関数を呼び出すことによって実行されます。
XPathは、1つのXMLスキーマ・データ型から別のデータ型へのキャストのみを定義しています。残りのキャストは、次の通り定義されています。
xsd:string
にキャストすると、そのIRIを構成するコードポイントの字句値を持つ型付きリテラル、およびxsd:string
のデータ型が作成されます。xsd:string
をキャストしたときの生成物であると定義されます。次の表では、キャスティング操作が常に許されるもの(Y)、決して許されないもの(N)、字句値次第のもの(M)にまとめています。例えば、xsd:string
(最初の行)からxsd:float
(2番目の列)へのキャスティング操作は、字句値(M)次第です。
bool = xsd:boolean
dbl = xsd:double
flt = xsd:float
dec = xsd:decimal
int = xsd:integer
dT = xsd:dateTime
str = xsd:string
IRI = IRI
ltrl =simple literal
From \ To | str | flt | dbl | dec | int | dT | bool |
---|---|---|---|---|---|---|---|
str | Y | M | M | M | M | M | M |
flt | Y | Y | Y | M | M | N | Y |
dbl | Y | Y | Y | M | M | N | Y |
dec | Y | Y | Y | Y | Y | N | Y |
int | Y | Y | Y | Y | Y | N | Y |
dT | Y | N | N | N | N | Y | N |
bool | Y | Y | Y | Y | Y | N | Y |
IRI | Y | N | N | N | N | N | N |
ltrl | Y | M | M | M | M | M | M |
PrimaryExpressionの文法規則は、IRIで指定された拡張関数への呼び出しでありえます。拡張関数は、RDF用語のいくつかを引数と見なして、RDF用語を返します。これらの関数のセマンティクスは、関数を識別するIRIによって識別されます。
拡張関数を用いるSPARQLクエリは、相互運用性を制限する可能性があります。
例として、func:even
と呼ばれる関数を取り上げます。
xsd:boolean
func:even
(numeric
value
)
この関数は、次のとおり、そういうものとしてFILTERに呼び出されるでしょう。
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX func: <http://example.org/functions#> SELECT ?name ?id WHERE { ?x foaf:name ?name ; func:empId ?id . FILTER (func:even(?id)) }
2番目の例では、2つの地点の間の距離を計算する関数aGeo:distance
について考えてみます。ここでは、これをグルノーブル(Grenoble)付近の場所を発見するために用います。
xsd:double
aGeo:distance
(numeric
x1
,numeric
y1
,numeric
x2
,numeric
y2
)
PREFIX aGeo: <http://example.org/geo#> SELECT ?neighbor WHERE { ?a aGeo:placeName "Grenoble" . ?a aGeo:location ?axLoc . ?a aGeo:location ?ayLoc . ?b aGeo:placeName ?neighbor . ?b aGeo:location ?bxLoc . ?b aGeo:location ?byLoc . FILTER ( aGeo:distance(?axLoc, ?ayLoc, ?bxLoc, ?byLoc) < 10 ) . }
拡張関数は、コアSPARQL仕様でサポートされていないアプリケーション・データ型をテストするために用いられるかもしれず、例えばこれは、別の日付フォーマットからXSD dateTime RDF用語へのデータ型フォーマット間の変換であるかもしれません。
この項では、クエリ文字列とRDFデータセットを前提に、グラフ・パターンとソリューション修飾子の評価のに対する正しい行動を定義します。これは、SPARQL実装がここで定義されたプロセスを使用しなければならないということを意味しません。
SPARQLを実行した結果は、SPARQLクエリを文字列として開始し、その文字列を抽象構文形式に変え、次に、その抽象構文をSPARQLの代数の演算子で構成されるSPARQL抽象クエリに変える、という一連のステップで定義されます。その後、この抽象クエリは、RDFデータセットで評価されます。
SPARQLは、IRI[RFC3987]の用語で定義されています。IRIは、スペースを省略するRDF URI参照のサブセットです。
IをすべてのIRIの集合とする。
RDF-LをすべてのRDFリテラルの集合とする。
RDF-BをすべてのRDFグラフにおける空白ノードの集合とする。
RDF用語の集合、RDF-Tは、I union RDF-L union RDF-Bです。
RDF用語のこの定義は、RDFデータ・モデルのいくつかの基本的な概念をまとめていますが、RDF URI参照ではなくIRIを参照言するように更新されています。
RDFデータセットは以下の集合です。
{ G, (<u1>, G1), (<u2>, G2), . . .
(<un>, Gn) }
ここでは、Gと各Giはグラフであり、各<ui>はIRIです。各<ui>はdistinctです。
Gはデフォルト・グラフと呼ばれます。(<ui>, Gi)は名前付きグラフと呼ばれます。
アクティブ・グラフは、基本グラフパターン・マッチングに用いられるデータセットのグ ラフです。
クエリ変数は、Vが無限であり、RDF-Tと互いに素な集合Vのメンバーです。
トリプル・パターンは、次の集合のメンバーです。
(RDF-T union V) x (I union V) x (RDF-T union V)
トリプル・パターンのこの定義には、リテラルの主語が含まれています。これは、RDF-コアで注記されています。
「[RDFコア・ワーキンググループは]リテラルが主語であってはならない理由がないことを 承知していると述べました。そして、より制限のない憲章を持つ将来のWGは、ステートメン トの主語としてのリテラルを許容するように構文を拡張するかもしれません。」
RDFグラフはリテラルの主語を含まないかもしれないため、リテラルを主語として持つ任意のSPARQLトリプル・パターンは、どんなRDFグラフにもマッチしないでしょう。
基本グラフ・パターンは、トリプル・パターンの集合です。
空のグラフ・パターンは、空集合である基本グラフ・パターンです。
ソリューション・マッピングは、1組の変数から1組のRDF用語へのマッピングです。我々は、それが明確である場合に「ソリューション」という用語を使用します。
ソリューション・シーケンスは、ソリューションのリストで、順不同でありえます。
ソリューション・シーケンス修飾子は、次のうちの1つです。
この項は、SPARQLクエリ文字列内のグラフ・パターンとソリューション修飾子をSPARQL代数式に変換するプロセスを定義します。
SPARQLクエリ文字列を分析し、4項で示したIRIとトリプル・パターンに省略形を適用した後に、次の表で構成される抽象構文木があります。
パターン | 修飾子 | クエリ形式 |
---|---|---|
RDF terms | DISTINCT | SELECT |
triple patterns | REDUCED | CONSTRUCT |
Basic graph patterns | PROJECT | DESCRIBE |
Groups | ORDER BY | ASK |
OPTIONAL | LIMIT | |
UNION | OFFSET | |
GRAPH | ||
FILTER |
このような抽象構文木を変換した結果は、次の表の符号をSPARQL代数で用いるSPARQLクエリです。
グラフ・パターン | ソリューション修飾子 |
---|---|
BGP | ToList |
Join | OrderBy |
LeftJoin | Project |
Filter | Distinct |
Union | Reduced |
Graph | Slice |
Sliceは、OFFSETとLIMITを組み合わせたものです。modは、ソリューション修飾子のうちの1つです。
ToListはグラフ・パターン・マッチングの結果からシーケンスへの変換が起こる場合に用いられます。
この項では、SPARQLグラフ・パターンをSPARQL代数式に変換するプロセスについて述べます。IRIとトリプル・パターンの構文上の省略形を変換した後に、構文形式を再帰的に処理して代数式にします。
OPTIONAL { { ... FILTER ( ... ?x ... ) } }.
.
次の2つの規範的でないテストケースでこれを例証します。
まず最初に、4項で示したIRIとトリプル・パターンの省略形を拡張してください。
WhereClause
は、次の形式から成るGroupGraphPattern
で構成されています。
それぞれは、次の手順で変換されます。
Transform(syntax form)
形式が
TriplesBlock
である場合
The result is BGP(list of triple patterns)
形式が
GroupOrUnionGraphPattern
である場合
Let A := undefined For each element G in the GroupOrUnionGraphPattern If A is undefined A := Transform(G) Else A := Union(A, Transform(G)) The result is A
形式が
GraphGraphPattern
である場合
If the form is GRAPH IRI GroupGraphPattern The result is Graph(IRI, Transform(GroupGraphPattern)) If the form is GRAPH Var GroupGraphPattern The result is Graph(Var, Transform(GroupGraphPattern))
形式が
GroupGraphPattern
である場合次のシンボルを導入します。
- Join(Pattern, Pattern)
- LeftJoin(Pattern, Pattern, expression)
- Filter(expression, Pattern)
Let FS := the empty set Let G := the empty pattern, Z, a basic graph pattern which is the empty set. For each element E in the GroupGraphPattern If E is of the form FILTER(expr) FS := FS set-union {expr} If E is of the form OPTIONAL{P} Then Let A := Transform(P) If A is of the form Filter(F, A2) G := LeftJoin(G, A2, F) else G := LeftJoin(G, A, true) If E is any other form: Let A := Transform(E) G := Join(G, A) If FS is not empty: Let X := Conjunction of expressions in FS G := Filter(X, G) The result is G.
単純化のステップ
1つのグラフ・パターン(フィルタではない)のグループは、join(Z, A)になり、Aで置き換えることができます。空のグラフ・パターンZは、joinと同値です。
Replace join(Z, A) by A Replace join(A, Z) by A
書き換えの例の2番目の形式は、1番目のものに単純化のステップで削除した空のグループのjoinを付けたものです。
例: 1つのトリプル・パターンから成る1つの基本グラフ・パターンを持つグループ
例: 2つのトリプル・パターンから成る1つの基本グラフ・パターンを持つグループ
例: 2つの基本グラフ・パターンの和集合から成るグループ
例: 1つの和集合と1つの基本グラフ・パターンの和集合から成るグループ
例: 1つの基本グラフ・パターンと1つのオプションのグラフ・パターンから成るグループ
例: 1つの基本グラフ・パターンと2つのオプションのグラフ・パターンから成るグループ
例: 1つの基本グラフ・パターンとフィルタを持つ1つのオプションのグラフ・パターンから成るグループ
例: 1つの和集合のグラフ・パターンと1つのオプションのグラフ・パターンから成るグループ
例: 1つの基本グラフ・パターン、1つのフィルタ、および1つのオプションのグラフ・パターンから成るグループ
ステップ1 : ToList
ToListは、多重集合を、同じ要素とカーディナリティーを持つシーケンスに変えます。シーケンスに対する暗黙的な順序付けはありません。同じものが隣接している必要はありません。
Let M := ToList(Pattern)
ステップ2 : ORDER BY
クエリ文字列にORDER BY句がある場合、
M := OrderBy(M, list of order comparators)
ステップ3 : Projection
M := Project(M, vars)
ここでは、varsは、SELECT句で記述された変数の集合であるか、SELECT *が用いられた場合には、クエリ中のすべての名前付き変数です。
ステップ4 : DISTINCT
クエリがDISTINCTを含んでいる場合、
M := Distinct(M)
ステップ5 : REDUCED
クエリがREDUCEDを含んでいる場合、
M := Reduced(M)
ステップ6 : OFFSETとLIMIT
クエリが「OFFSET開始」または「LIMITの長さ」を含んでいる場合、
M := Slice(M, start, length)
start defaults to 0
length defaults to (size(M)-start).
全般的な抽象クエリはMです。
グラフ・パターンをマッチさせるときには、可能なソリューションは、バッグ(bag)としても知られている多重集合[multiset]を形成します。多重集合は、各要素が1回以上出現しうる要素の順不同のコレクションです。これは、多重集合内の集合の各要素の出現回数を示す、1組の要素とカーディナリティー関数で記述されます。
ソリューション・マッピングを、μと記述し、
dom(μ0)が空の集合であるようなマッピングを、μ0と記述します。
カーディナリティー1を持つ、空のマッピングμ0,からきっかり成る多重集合を、Ω0と記述します。これは、joinと同値です。
RDF用語t : { (x, t) }に対するソリューション・マッピング変数xを、μ(?x->t)と記述します。
きっかりμ(?x->t)から成る多重集合、つまり、カーディナリティー1を持つ{ { (x, t) } }を、Ω(?x->t)と記述します。
2つのソリューション・マッピングμ1とμ2は、dom(μ1)およびdom(μ2)のすべての変数vに対し、μ1(v) = μ2(v)である場合、互換性があります。
μ1とμ2に互換性がある場合、μ1 set-union(和集合) μ2もマッピングです。μ1 set-union μ2を、merge(μ1, μ2)と記述します。
マッピングΩの多重集合におけるソリューション・マッピングμのカーディナリティーを、card[Ω](μ)と記述します。
基本グラフ・パターンは、SPARQLパターン・マッチングの基礎を形成します。基本グラフ・パターンは、クエリの当該部分に対するアクティブ・グラフにマッチングします。変数と空白ノードの両方を用語に置き換えることによって、インスタンスの2つの概念を示し、基本グラフ・パターンをインスタンス化できます。空白ノードは、RDFインスタンス・マッピング σを用いて空白ノードからRDF用語に置き換えられ、変数は、ソリューション・マッピングによってクエリ変数からRDF用語に置き換えられます。
パターン・インスタンス・マッピングPは、RDFインスタンス・マッピングσとソリューション・マッピングμの組み合わせです。 P(x) = μ(σ(x))
任意のパターン・インスタンス・マッピングは、それぞれクエリ変数と空白ノードに制限することによって得られた、ユニークなソリューション・マッピングおよびユニークなRDFインスタンス・マッピングを定義します。
BGPを基本グラフ・パターンとし、GをRDFグラフとします。
P(BGP)がGのサブグラフであり、μがBGPのクエリ変数に対するPの制限であるような、パターン・インスタンス・マッピングPがあるとき、μは、GからのBGPのソリューションです。
card[Ω](μ) = card[Ω](P = μ(σ) であるような異なるRDFインスタンス・マッピングの数、σはパターン・インスタンス・マッピングであり、P(BGP)はGのサブグラフです)。
基本グラフ・パターンが空の集合である場合、ソリューションはΩ0です。
この定義によって、ソリューション・マッピングは、基本グラフ・パターンであるBGPの変数をGの空白ノードにバインドできます。SPARQLは、SPARQLクエリ結果XMLフォーマットドキュメントの空白ノード識別子をそのドキュメントに対して有効であるものとして扱うため、データセットのアクティブ・グラフにおけるノードを識別しているとは解釈されません。したがって、DSがクエリのデータセットである場合、パターンのソリューションはDS自身のアクティブ・グラフからのものではなくRDFグラフからのものであると解釈され、これはスコーピング・グラフと呼ばれ、DSのアクティブ・グラフに対しグラフ同等(graph-equivalent)であるけれどもDSまたはBGPと空白ノードを共有しません。スコーピング・グラフは、1つのクエリに対するすべてのソリューションに用いられます。スコーピング・グラフは、純粋に理論的構成概念(theoretical construct)で、実際には、単なる空白ノード識別子に対するドキュメント範囲の慣習によって効果が得られます。
RDFの空白ノードが多くのパターンに対する多くの重複するソリューションを無限に許すため、多くのパターンのソリューション(空白ノードを別の空白ノードに置き換えることによって得られる)が無限に存在しえます。したがって、何らかの形で基本グラフ・パターンのソリューションを区切る必要があります。SPARQLは、基本グラフ・パターンのソリューションを決定するために、サブグラフ・マッチの基準を用います。基本グラフ・パターンからアクティブ・グラフのサブセットにマッピングする異なるパターンのインスタンスに対し、それぞれ1つのソリューションが存在します。
これは、重複の排除よりむしろ計算の容易さのために最適化されます。これによって、データセットのアクティブ・グラフが貧弱であるときでも、クエリ結果に重複を含むことができ、論理的に同等なデータセットが異なるクエリ結果を出すことが可能になります。
SPARQLの抽象クエリに内の各シンボルに対し、評価のための演算子を定義しています。同じ名前のSPARQL代数演算子は、「評価セマンティクス」の項で記述されているように、SPARQLの抽象クエリ・ノードを評価するために用いられます。
定義: Filter
Ωをソリューション・マッピングの多重集合とし、exprを式とします。次のとおり定義します。
Filter(expr, Ω) = { μ | μ in Ω and expr(μ) is an expression that has an effective boolean value of true }
card[Filter(expr, Ω)](μ) = card[Ω](μ)
定義: Join
Ω1とΩ2をソリューション・マッピングの多重集合とします。次のとおり定義します。
Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and μ1 and μ2 are compatible }
card[Join(Ω1, Ω2)](μ) =
for each merge(μ1, μ2), μ1
in Ω1and μ2 in Ω2 such that μ = merge(μ1, μ2),
sum over (μ1, μ2), card[Ω1](μ1)*card[Ω2](μ2)
Joinにおけるソリューション・マッピングμは、異なるソリューション・マッピング、結合された多重集合におけるμ1とμ2において出現することは可能です。μのカーディナリティーは、すべての可能性のカーディナリティーの合計です。
定義: Diff
Ω1とΩ2をソリューション・マッピングの多重集合とします。次のとおり定義します。
Diff(Ω1, Ω2, expr) = { μ | μ in Ω1 such that for all μ′ in Ω2, either μ and μ′ are not compatible or μ and μ' are compatible and expr(merge(μ, μ')) has an effective boolean value of false }
card[Diff(Ω1, Ω2, expr)](μ) = card[Ω1](μ)
Diffは、LeftJoinの定義のために内部的に使用されます。
定義: LeftJoin
Ω1とΩ2をソリューション・マッピングの多重集合とし、exprを式とします。次のとおり定義します。
LeftJoin(Ω1, Ω2, expr) = Filter(expr, Join(Ω1, Ω2)) set-union Diff(Ω1, Ω2, expr)
card[LeftJoin(Ω1, Ω2, expr)](μ) = card[Filter(expr, Join(Ω1, Ω2))](μ) + card[Diff(Ω1, Ω2, expr)](μ)
これは、完全形で記述すれば、次の通りです。
LeftJoin(Ω1, Ω2, expr) =
{ merge(μ1, μ2) | μ1 in Ω1and μ2 in
Ω2, and μ1 and μ2 are compatible and expr(merge(μ1,
μ2)) is true }
set-union
{ μ1 | μ1 in Ω1and μ2 in Ω2, and
μ1 and μ2 are not compatible }
set-union
{ μ1 | μ1 in Ω1and μ2 in Ω2, and
μ1 and μ2 are compatible and expr(merge(μ1, μ2)) is false
}
これらが異なっているため、LeftJoinのカーディナリティーは、定義のこれらの個々の構成要素のカーディナリティーです。
定義: Union
Ω1とΩ2をソリューション・マッピングの多重集合とします。次のとおり定義します。
Union(Ω1, Ω2) = { μ | μ in Ω1 or μ in Ω2 }
card[Union(Ω1, Ω2)](μ) = card[Ω1](μ) + card[Ω2](μ)
C(x)が真である要素のシーケンスを[x | C]と記述します。
Lにおけるxのカーディナリティーになるようにcard[L](x)を記述します。
Ωをソリューション・マッピングの多重集合とします。次のとおり定義します。
ToList(Ω) = a sequence of mappings μ in Ω in any order, with card[Ω](μ) occurrences of μ
card[ToList(Ω)](μ) = card[Ω](μ)
Ψをソリューション・マッピングのシーケンスとします。次のとおり定義します。
OrderBy(Ψ, condition) = [ μ | μ in Ψ and the sequence satisfies the ordering condition]
card[OrderBy(Ψ, condition)](μ) = card[Ψ](μ)
Ψをソリューション・マッピングのシーケンスとし、PVを変数の集合とします。
マッピングμに対し、PVの変数に対するμの制限になるようにProj(μ, PV)を記述します。
Project(Ψ, PV) = [ Proj(Ψ[μ], PV) | μ in Ψ ]
card[Project(Ψ, PV)](μ) = card[Ψ](μ)
Project(Ψ, PV)の順序は、OrderByによって与えられた順序付けを保持しなければなりません。
Ψをソリューション・マッピングのシーケンスとします。次のとおり定義します。
Distinct(Ψ) = [ μ | μ in Ψ ]
card[Distinct(Ψ)](μ) = 1
Distinct(Ψ)の順序は、OrderByによって与えられた順序付けを保持しなければなりません。
Ψをソリューション・マッピングのシーケンスとします。次のとおり定義します。
Reduced(Ψ) = [ μ | μ in Ψ ]
card[Reduced(Ψ)](μ) is between 1 and card[Ψ](μ)
Reduced(Ψ)の順序は、OrderByによって与えられた順序付けを保持しなければなりません。
Reducedソリューション・シーケンス修飾子は、定義済みのカーディナリティーを保証しません。
Ψをソリューション・マッピングのシーケンスとします。次のとおり定義します。
Slice(Ψ, start, length)[i] = Ψ[start+i] for i = 0 to (length-1)
我々は、eval(D(G), graph pattern)を、アクティブ・グラフGを持つデータセットDに関するグラフ・パターンの評価であると定義しています。アクティブ・グラフは、最初はデフォルト・グラフです。
D : データセット D(G) : アクティブ・グラフGを持つデータセットD(パターンがマッチするもの) D[i] : データセットDにIRI iを持つグラフ D[DFT] : Dのデフォルト・グラフ P, P1, P2 : グラフ・パターン L : ソリューション・シーケンス
eval(D(G), Filter(F, P)) = Filter(F, eval(D(G),P))
eval(D(G), Join(P1, P2)) = Join(eval(D(G), P1), eval(D(G), P2))
eval(D(G), LeftJoin(P1, P2, F)) = LeftJoin(eval(D(G), P1), eval(D(G), P2), F)
eval(D(G), Union(P1,P2)) = Union(eval(D(G), P1), eval(D(G), P2))
if IRI is a graph name in D eval(D(G), Graph(IRI,P)) = eval(D(D[IRI]), P)
if IRI is not a graph name in D eval(D(G), Graph(IRI,P)) = the empty multiset
eval(D(G), Graph(var,P)) = Let R be the empty multiset foreach IRI i in D R := Union(R, Join( eval(D(D[i]), P) , Ω(?var->i) ) the result is R
グラフの評価は、SPARQL代数和集合演算子を使用します。ソリューション・マッピングのカーディナリティーは、それぞれのjoinの操作における、そのソリューション・マッピングのカーディナリティーの合計です。
eval(D, ToList(P)) = ToList(eval(D(D[DFT]), P))
eval(D, Distict(L)) = Distinct(eval(D, L))
eval(D, Reduced(L)) = Reduced(eval(D, L))
eval(D, Project(L, vars)) = Project(eval(D, L), vars)
eval(D, OrderBy(L, condition)) = OrderBy(eval(D, L), condition)
eval(D, Slice(L, start, length)) = Slice(eval(D, L), start, length)
SPARQLの全体的な設計は、基本グラフ・パターンにマッチングした条件を書き直すことによって、シンプルな含意ではなく、より精緻な形式の含意を想定したクエリに使用できます。1つの一般的な形式でそのような条件を記述し、それをすべての形式の含意に適用して不必要または不適切な重複を最適に排除することは、未解決の研究課題であるため、このドキュメントは、そのようなソリューションが満たすべき必要条件を提示するのみです。これらは、それぞれの具体的な事例に対する完全な定義に拡張する必要があるでしょう。
基本グラフ・パターンは、RDFグラフがRDFトリプルに対して行うトリプルのパターンと同じ関係にあり、同じ用語の多くをそれらに適用できます。特に、トリプル(M(s), M(p) M(o))が2番目のパターンにある場合に限りトリプル(s, p, o)が最初のパターンに存在するような、空白ノードを空白ノードにマッピングし、変数、リテラル、およびIRIをそれら自身にマッピングするトリプル・パターンの用語間に全単射Mがある場合、2つの基本グラフ・パターンはが同等であると述べられます。この定義は、変数名を同等なパターン全体で保持することによって、RDFグラフの同等性に対し、それを基本グラフ・パターンに拡張します。
含意レジーム(entailment regime)は、次の仕様を定めます。
含意レジームに関する例には、シンプルな含意(simple entailment)[RDF-MT]、RDF含意(RDF entailment)[RDF-MT]、RDFS含意(RDFS entailment)[RDF-MT]、D-含意(D-entailment)[RDF-MT]、およびOWL-DL含意(OWL-DL entailment)[OWL-Semantics]が含まれています。これらのうち、OWL-DL含意のみが整形式グラフの集合を制限します。Eが含意レジームである場合、この名前付けの慣習に従い、E-含意(E-entailment)、E-整合性(E-consistency)などについて言及します。
いくつかの含意レジームは、いくつかのRDFグラフを、矛盾すると分類することができます。例えば、次のRDFグラフは、
_:x rdf:type xsd:string ._:x rdf:type xsd:decimal .
DがXSDデータ型を含んでいる場合、D矛盾です。矛盾したグラフへのクエリの効果は、この仕様ではカバーしていませんが、特定のSPARQLの拡張で指定しなければなりません。
E-含意(E-entailment)へのSPARQLの拡張は、以下の条件を満たさなければなりません。
1 -- 任意の整合性のあるアクティブ・グラフAGに対応しているスコーピング・グラフSGは、一意に指定され、AGにE-同等(E-equivalent)です。
2 -- 任意の基本グラフ・パターンBGPとパターン・ソリューション・マッピングPの場合、P(BGP)はEに対する整形式です。
3 -- 基本グラフ・パターンBGPに対する任意のスコーピング・グラフSGおよび答えの集合{P1 ... Pn}の場合、そして、{BGP1 .... BGPn}がBGPにすべて同等な基本グラフ・パターンの集合である場合は、これらのうちのどれもが、他のものまたはSGと空白ノードを共有しません。
SG E-entails (SG union P1(BGP1) union ... union Pn(BGPn))
RDFがいくらでも重複を許すため、これらの条件は、ありえる答えの集合を完全に決定するわけではありません。さらに、したがって、下記が当てはまらなければなりません。
4 -- それぞれのSPARQLの拡張は、すべてのBGPとAGが、RDFグラフ同等性を除いて一意である有限の答えの集合を持つことを保証する答えの集合における条件を提供しなければなりません。
(a) SGは、しばしばAGと同等のグラフになるでしょうが、これをE-同等(E-equivalence)に制限すると、例えばセマンティックな重複の排除などのいくつかの形式の正規化をクエリの実行前にソース・ドキュメントに適用することが可能になります。
(b) 条件3の構築は、空白ノードがSGで出現する方法と内部的に整合性があるような方法で、ソリューション・マッピングによって導入された任意の空白ノードが確実に用いられるようになります。これにより、答えの集合の中の1つ以上の答えで、そのように識別された空白ノードが本当にSGにおいて同じであるときにのみ、空白ノード識別子が確実に生じます。拡張が空白ノードへの答えのバインディングを許さない場合、この条件は以下の条件に簡略化できます。
SG E-entails P(BGP) for each pattern solution P.
(c) これらの条件は、SGがAGまたはBGPと空白ノードを共有しないという要件をSPARQLに課しません。特に、これによって、SGが実際にAGになることが可能になります。これにより、空白ノード識別子がクエリとソース・ドキュメントの間や複数のクエリにまたがって意味を保有するクエリ・プロトコルが可能になります。しかし、そのようなプロトコルは、現在のSPARQLプロトコル仕様ではサポートされていません。
(d) 条件1~3のみが答えにおける必要条件であるため、条件4では、正当な答えの集合を様々な方法で制限しうるケースが許されます。例えば、OWL-DLクエリの最新技術は、空白ノードへの答えのバインディングが禁止されているケースに注目しています。これらの条件が、すべてのクエリが空の答えの集合を有する病的な「ミュート」のケースさえ許すことに注意してください。
(e) これらの条件は、BGPの空白ノードにおけるインスタンス・マッピングを明示的に参照しません。いくつかの含意レジームに関しては、1つのインスタンス・マッピングの存在によって、空白ノードの存在を表す解釈を完全に得ることができるわけではありません。これらの条件は、このようなレジームがクエリ・パターンの空白ノードに「完全に存在する」読込みを与えることを許します。
SGにおけるSPARQL条件が、AGにグラフ同等(graph-equivalent)であるけれども、AGやBGPと空白ノードを共有しないという(最初の条件を満たす)ものである場合、Eがシンプルな含意であるケースのこれらの条件をSPARQLが満たすということを示すと分かりやすいです。唯一の重要な条件は(3)です。
すべての答えPiは、Mi(BGPi)がSGのサブグラフであるようなSPARQLインスタンスMiのソリューション・マッピングの制限です。BGPiとSGが共通の空白ノードを持たないため、Miの範囲にはBGPiの空白ノードは含まれません。したがって、ソリューション・マッピングPiとMiのRDFインスタンス・マッピングIi構成要素は交換され、したがって、Mi(BGPi) = Ii(Pi(BGPi))です。したがって、次のとおりです。
M1(BGP1) union ... union Mn(BGPn)
= I1(P1(BGP1)) union ... union In(Pn(BGPn))
= [ I1 + ... + In]( P1(BGP1) union
... union Pn(BGPn) )
これは、Iiインスタンス・マッピングの定義域がすべて互いに排他的であるためです。これらがSGから排他的であるためでもあります。
SG union [ I1 + ... + In]( P1(BGP1)
union ... union Pn(BGPn) )
= [ I1 + ... + In](SG union P1(BGP1) union ... union Pn(BGPn) )
すなわち、
SG union P1(BGP1) union ... union Pn(BGPn)
は、SGのサブグラフであるインスタンスを持っており、そのため、RDF補間定理[RDF-MT]によるSGによって簡単に含意されます。
SPARQLクエリ文字列は、Queryの生成規則で始まる、以下の文法によって定義された言語のUnicodeの文字列(参照:[CHARMOD]の6.1項 文字列の概念)です。Unicodeの将来のバージョンとの互換性のために、この文字列中の文字には、この公表日の時点で割り当てられていないUnicodeコードポイントを含むことができるようになっています(識別子とパターン構文[UNIID]の4項 パターン構文を参照)。除外されている文字クラスを伴う生成規則(例えば、[^<>'{}|^`]
)では、それらの文字は#x0 - #x10FFFF
の範囲から除外されます。
SPARQLクエリ文字列は、以下のEBNFで定義された文法によって分析する前に、コードポイント・エスケープ・シーケンス用に処理されます。SPARQLクエリ文字列用のコードポイント・エスケープ・シーケンスは、以下の通りです。
エスケープ | Unicodeコードポイント |
---|---|
'\u' HEX HEX HEX HEX | コード化された16進の値に対応する包括的な範囲U+0~U+FFFFのUnicodeコード・ポイント。 |
'\U' HEX HEX HEX HEX HEX HEX HEX HEX | コード化された16進の値に対応する包括的な範囲U+0~U+10FFFFのUnicodeコード・ポイント。 |
ここでは、HEXは16進の文字です。
HEX ::= [0-9] | [A-F] | [a-f]
例:
<ab\u00E9xy> # Codepoint 00E9 is Latin small e with acute - é \u03B1:a # Codepoint x03B1 is Greek small alpha - α a\u003Ab # a:b -- codepoint x3A is colon
コードポイント・エスケープ・シーケンスは、クエリ文字列のどこにでも出現できます。これらは、文法規則に基づいた分析の前に処理され、したがって、接頭辞付き名前をマーク付けする「:
」のような、文法中で重要性を持つコードポイントに置き換えられることがあります。
これらのエスケープ・シーケンスは、以下の文法に含まれていません。その時点で文法上正当な文字列のエスケープ・シーケンスのみが示されるかもしれません。例えば、変数「?x\u0020y
」は、正当ではありません(\u0020
はスペースであり、変数名では許されていない)。
空白(生成規則WS
)は2つの終端記号を区切るために用いられ、そうでなければ、1つの終端記号として(誤)認識されます。下記の大文字の規則名は、空白が重要である場合を示します。これらは、SPARQLパーサを構築するための可能な端末の選択を形成します。文字列において空白は重要です。
例えば、
?a<?b&&?c>?d
は、トークン・シーケンスの変数「?a
」、IRI「<?b&&?c>
」、変数「?d
」であり、「<
」(小なり)および「>
」(大なり)を用いた2つの式を結合した演算子「&&
」を含んだ式ではありません。
SPARQLクエリにおけるコメントは、IRI中または文字列中以外では、「#
」の形式をとり、これは、行末(文字列0x0D
または0x0A
でマーク付けされる)まで続くか、コメント・マーカーの後に行末がなければファイルの終りまで続きます。コメントは空白として扱われます。
IRI_REF
生成規則およびPrefixedName
(接頭辞拡張の後の)生成規則でマッチングされたテキストは、エスケープ処理の後に、RFC 3987[RFC3987]の2.2項「IRI参照およびIRIのためのABNF」のIRI参照の一般的な構文に適合していなければなりません。例えば、IRI_REF
<abc#def>
は、SPARQLクエリ文字列で出現可能ですが、IRI_REF
<abc##def>
は出現できません。
キーワードBASEで宣言された基底IRIは、絶対IRIでなければなりません。キーワードPREFIXで宣言された接頭辞は、同じクエリ中で再宣言できません。BASEとPREFIXの記述に関しては、2.1.1項、IRI用語の構文を参照してください。
1つのクエリを持つ2つの別々の基本グラフ・パターンでは、同じ空白ノード・ラベルを使用してはなりません。
コードポイント・エスケープ・シーケンスに加え、下記は、任意のstring
生成規則(例えば、STRING_LITERAL1
、STRING_LITERAL2
、STRING_LITERAL_LONG1
、STRING_LITERAL_LONG2
)のエスケープ・シーケンスを行います。
エスケープ | Unicodeコードポイント |
---|---|
'\t' | U+0009(タブ) |
'\n' | U+000A(改行) |
'\r' | U+000D(復帰) |
'\b' | U+0008(バックスペース) |
'\f' | U+000C(改ページ) |
'\"' | U+0022(引用符、二重引用符) |
"\'" | U+0027(アポストロフィ、一重引用符) |
'\\' | U+005C(逆斜線) |
例:
"abc\n" "xy\rz" 'xy\tz'
文法で用いられるEBNF表記法は、XML(Extensible Markup Language)1.1[XML11]の6項の表記法で定義されています。
キーワードは、TurtleとN3に沿ってIRI rdf:type
の代わりに用いられるキーワード「a
」を除き、大文字・小文字を区別しない方法でマッチします(完全形では、http://www.w3.org/1999/02/22-rdf-syntax-ns#type
)。
キーワード:
BASE | SELECT | ORDER BY | FROM | GRAPH | STR | isURI |
PREFIX | CONSTRUCT | LIMIT | FROM NAMED | OPTIONAL | LANG | isIRI |
DESCRIBE | OFFSET | WHERE | UNION | LANGMATCHES | isLITERAL | |
ASK | DISTINCT | FILTER | DATATYPE | REGEX | ||
REDUCED | a | BOUND | true | |||
sameTERM | false |
エスケープ・シーケンスは、大文字と小文字を区別します。
マッチする規則を選選択するときには、最も長いマッチが選ばれます。
終端記号の生成規則:
[70] |
IRI_REF |
::= | '<' ([^<>"{}|^`\]-[#x00-#x20])* '>' |
[71] |
PNAME_NS |
::= | PN_PREFIX? ':' |
[72] |
PNAME_LN |
::= | PNAME_NS PN_LOCAL |
[73] |
BLANK_NODE_LABEL |
::= | '_:' PN_LOCAL |
[74] |
VAR1 |
::= | '?' VARNAME |
[75] |
VAR2 |
::= | '$' VARNAME |
[76] |
LANGTAG |
::= | '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)* |
[77] |
INTEGER |
::= | [0-9]+ |
[78] |
DECIMAL |
::= | [0-9]+ '.' [0-9]* | '.' [0-9]+ |
[79] |
DOUBLE |
::= | [0-9]+ '.' [0-9]* EXPONENT | '.' ([0-9])+ EXPONENT | ([0-9])+ EXPONENT |
[80] |
INTEGER_POSITIVE |
::= | '+' INTEGER |
[81] |
DECIMAL_POSITIVE |
::= | '+' DECIMAL |
[82] |
DOUBLE_POSITIVE |
::= | '+' DOUBLE |
[83] |
INTEGER_NEGATIVE |
::= | '-' INTEGER |
[84] |
DECIMAL_NEGATIVE |
::= | '-' DECIMAL |
[85] |
DOUBLE_NEGATIVE |
::= | '-' DOUBLE |
[86] |
EXPONENT |
::= | [eE] [+-]? [0-9]+ |
[87] |
STRING_LITERAL1 |
::= | "'" ( ([^#x27#x5C#xA#xD]) | ECHAR )* "'" |
[88] |
STRING_LITERAL2 |
::= | '"' ( ([^#x22#x5C#xA#xD]) | ECHAR )* '"' |
[89] |
STRING_LITERAL_LONG1 |
::= | "'''" ( ( "'" | "''" )? ( [^'\] | ECHAR ) )* "'''" |
[90] |
STRING_LITERAL_LONG2 |
::= | '"""' ( ( '"' | '""' )? ( [^"\] | ECHAR ) )* '"""' |
[91] |
ECHAR |
::= | '\' [tbnrf\"'] |
[92] |
NIL |
::= | '(' WS* ')' |
[93] |
WS |
::= | #x20 | #x9 | #xD | #xA |
[94] |
ANON |
::= | '[' WS* ']' |
[95] |
PN_CHARS_BASE |
::= | [A-Z] | [a-z] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x02FF] | [#x0370-#x037D] | [#x037F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] |
[96] |
PN_CHARS_U |
::= | PN_CHARS_BASE | '_' |
[97] |
VARNAME |
::= | ( PN_CHARS_U | [0-9] ) ( PN_CHARS_U | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )* |
[98] |
PN_CHARS |
::= | PN_CHARS_U | '-' | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] |
[99] |
PN_PREFIX |
::= | PN_CHARS_BASE ((PN_CHARS|'.')* PN_CHARS)? |
[100] |
PN_LOCAL |
::= | ( PN_CHARS_U | [0-9] ) ((PN_CHARS|'.')* PN_CHARS)? Note that SPARQL local names allow leading digits while XML local names do not. |
注意:
AdditiveExpression
文法規則は、符号付きの数字が後続する式の2つのケースをカバーすることで、これを可能にします。これらにより、必要に応じて、符号のない数の加算または減算が生じます。よく用いられているツールの文法ファイルをここで入手できます。
SPARQLクエリ文字列の適合性に関しては付録のSPARQL文法を、クエリ結果の適合性に関しては10 クエリ形式の項を参照してください。application/sparql-queryメディア・タイプへの適合性に関しては付録 E. インターネット・メディア・タイプを参照してください。
この仕様は、SPARQLプロトコル[SPROT]およびSPARQLクエリ結果XMLフォーマット[RESULTS]との併用を意図しています。これらの適合性基準に関してはそれらの仕様を参照してください。
SPARQLプロトコルがネットワーク・プロトコルのみならず抽象的なインターフェースも記述し、抽象的なインターフェースがネットワーク・インターフェースのみならずAPIにも当てはまるかもしれないことに注意してください。
FROM、FROM NAMED、またはGRAPHを用いたSPARQLクエリは、指定されたURIを逆参照するかもしれません。これは、サービスの拒否などの関連する副次的な問題と共に、ネットワーク、ディスクまたはCPU資源の追加使用を招くかもしれません。URI(Uniform Resource Identifier):一般的構文[RFC3986]の7項のセキュリティ問題について考察する必要があります。さらに、場合によっては、file:
URIのコンテンツにアクセスし、処理し、結果として返すことができ、ローカル資源への予期しないアクセスが行われます。
SPARQL言語は拡張を認めており、それには独自のセキュリティ上の影響があるでしょう。
複数のIRIが同じ外観を持っているかもしれません。異なるスクリプトの文字が同じに見えるかもしれません(キリル文字の「о」はラテン文字の「o」と同じに見えるかもしれません)。 結合文字が後続する文字は、別の文字と同じ視覚的表現を持っているかもしれません(結合アキュート・アクセントが後続するラテン小文字Eは、アキュート付きラテン小文字Eと同じ視覚的表現を持っています)。SPARQLのユーザは、注意してデータ中のIRIにマッチするIRIを持つクエリを構築しなければなりません。類似している文字のマッチングに関する詳細は、Unicodeセキュリティに関する留意点[UNISEC]およびIRI(Internationalized Resource Identifiers)[RFC3987]の8項にあります。
SPARQLクエリ言語のインターネット・メディア・タイプ/MIMEタイプは、「application/sparql-query」です。
sparqlクエリ・ファイルは、すべてのプラットホーム上で拡張子「.rq」(すべて小文字)であることが推奨されます。
マッキントッシュHFSファイル・システム上に保存されたsparqlクエリ・ファイルには、ファイル・タイプ「TEXT」が付与されていることが推奨されます。
SPARQL RDFクエリ言語は、W3C RDFデータ・アクセス・ワーキンググループ全体の成果であり、議論、コメントおよびレビューに対し、すべての現在および過去のメンバーに感謝します。
さらに、我々は、ワーキンググループのコメント・リストを通じて、多くの人々とコメントや議論のやり取りを行いました。すべてのコメントがより良いドキュメントの作成に繋がりました。Andyはまた、SPARQLに関連する特定課題の調査に対し、特にJorge Peérez、Geoff Chappell、Bob MacGregor、Yosi Scharf、およびRichard Newmanに感謝しています。Ericは、Björn Höhrmannの貴重な援助に対し謝辞を表します。
これは、2007年6月14日 勧告候補の発表以降のこのドキュメントに行われた変更の高レベルな概要です。
application/sparql-query
が承認されたため、その要求のステータスに関する文章を削除しました。