![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
RDF（Resource Description Framework）を利用すると、データの中央集中を避け、分散化することが可能となります。RDFモデル同士は容易に合体することができ、シリアル化したRDFは単純に、HTTPで交換することができます。アプリケーションは、Web上にある複数のRDFデータ・ソースに疎結合されます。例えばPlanetRDF.comでは、コンテンツをRSS 1.0フィードとしてRDFで提供する作成者からのweblogを配信しています。作成者のフィードのURL自体は、bloggers.rdfと呼ばれるRDFグラフに保持されています。
しかし、必要なデータをRDFグラフ内で見つけ、操作するには、どうすればよいのでしょう。SPARQL（SPARQL Protocol And RDF Query Language）が、現在、W3Cのワーキング・ドラフトとして議論されています。SPARQLは、これまでのRDFクエリー言語（rdfDBやRDQL、SeRQLなど）の上に構築されており、SPARQL自体が、幾つか貴重な新機能を含んでいます。この記事では、PlanetRDF を駆動する3つのタイプのRDFグラフ、（貢献者(contributors)を記述するFOAF、そのRSS 1.0フィード、そしてbloggers graph）を使って、データに対してSPARQLクエリーが行うことの幾つかを紹介します。SPARQLの実装は、様々なプラットフォームや言語用のものが存在しています。この記事では、Javaプラットフォーム用のJena Semantic Web Toolkitに焦点を当てることにします。
この記事では、読者がRDFに関して実際的な知識を持っていること、またDublin CoreやFOAF、RSS 1.0などのRDFボキャブラリーに慣れていることを想定しています。また、Jena Semantic Web Toolkitに関しても多少の経験があることも想定しています。こうした技術に慣れるためには、下記の参考文献にあるリンクを調べてください。
まず、PlanetRDFのbloggers.rdfモデルを見てみましょう。これは非常に単純であり、FOAFとDublin Coreボキャブラリーを使って、各ブログ貢献者の名前やブログ・タイトル、URL、RSSフィード記述などを提供します。図1は、単一の貢献者に対する基本的なグラフ構造を示しています。完全なモデルでは単純に、集約するブログそれぞれに対して、この構造を繰り返します。
図1. bloggers.rdfでの、単一の貢献者に対する基本的なグラフ構造
では、このbloggersモデルに対する、非常に単純なSPARQLクエリーを見てみましょう。このクエリーをリスト1に示しますが、これはつまり、「Jon Foobarという名前の人物によるブログのURLを探せ」と言っています。
リスト1. 貢献者のブログを見つけるためのSPARQLクエリー
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?url
FROM <bloggers.rdf>
WHERE {
?contributor foaf:name "Jon Foobar" .
?contributor foaf:weblog ?url .
}
|
クエリーの第1行は単純に、FOAF名前空間に対するPREFIXを定義しており、参照する度に全部をタイプし直さなくて済むようになっています。SELECT文は、クエリーが何を返すべきか（この場合は、urlという名前の変数）を規定しています。SPARQL変数には、?あるいは$という接頭辞が付きます。この2つは交換可能ですが、この記事では、?を使うことにします。FROMはオプションの文であり、使用すべきデータセットのURIを提供します。ここでは、単にローカル・ファイルを指していますが、Web上のどこかにあるグラフのURLを示すこともできます。最後にWHERE文は、Turtleベースの構文を使って表現された、3つセット（triple）パターンの連続から成っています。こうした3つセットを合わせて、グラフ・パターン と呼びます。
クエリーは、グラフ・パターンの3つセットと、モデルの一致を調べます。モデルのノードに一致したグラフ・パターンの変数のバインディングは、それぞれクエリー・ソリューション となり、SELECT文の中に名前を挙げられた変数の値が、クエリー結果の一部となります。
この例では、WHERE文のグラフ・パターンにある最初の3つセットが、「Jon Foobar」のfoaf:nameプロパティーを持つノードに一致し、contributorという名前の変数にバインドされます。bloggers.rdfモデルでは、contributorが、図1の最上部にあるfoaf:Agent空白ノードと一致します。グラフ・パターンの2番目の3つセットはcontributorのfoaf:weblogプロパティーのオブジェクトに一致します。これはurl変数にバインドされ、クエリー・ソリューションを形成します。
JenaでのSPARQLサポートは現在、ARQというモジュールを利用して行われます。ARQクエリー・エンジンは、SPARQLをサポートすることに加え、RDQL、あるいはARQ自体のクエリー言語で表現されたクエリーを構文解析することができます。ARQは活発な開発が行われており、まだ標準のJenaディストリビューションの一部にはなっていません。しかし、JenaのCVSリポジトリーから、あるいは自己完結のダウンロードとして、入手することができます。
ARQを動くようにするのは簡単です。単純に最新のARQディストリビューション（参考文献にリンクがあります）を入手し、解凍し、環境変数ARQROOTをARQディレクトリーを指すようにするだけです。また、readをリストアし、ARQ binディレクトリーの内容に対してパーミッションを実行する必要があるかも知れません。binディレクトリーはコマンドラインからARQを呼び出すラッパー・スクリプトを含んでいるため、実行パスにbinディレクトリーを追加すると便利です。全て準備が出来たかどうかを確認するために、コマンドラインからsparqlを呼び、使用メッセージが見えることを確認します。これらの全ステップはリスト2に説明されています。リスト2では、UNIXライクのプラットフォームで、あるいはWindowsの下でのCygwinで作業していることを想定しています。（ARQには、Windowsの下で使うための.batスクリプトも付属していますが、その使い方は、この例での使い方と少し異なっています。）
リスト2. Jena ARQを使うために環境を設定する
$ export ARQROOT=~/ARQ-0.9.5
$ chmod +rx $ARQROOT/bin/*
$ export PATH=$PATH:$ARQROOT/bin
$ sparql
Usage: [--data URL] [exprString | --query file]
|
これで、SPARQLクエリー（リスト3を見てください）を実行する準備ができました。ここでは、リスト1のデータセットとクエリーを使います。このクエリーは、使用すべきグラフの指定にFROMキーワードを使うので、sparqlコマンドに対してクエリー・ファイルの位置を提供すればよいだけです。ただし、グラフはクエリーのFROM文にある相対URLを使って規定されるため、クエリーはグラフを含むディレクトリーから実行する必要があります。
リスト3. sparqlコマンドを使って簡単なクエリーを実行する
$ sparql --query jon-url.rq
----------------------------
| url |
============================
| <http://foobar.xx/blog> |
----------------------------
|
場合によると、クエリーにFROM文を含まないようにした方が妥当です。そうすれば、クエリーが実行された時に、グラフがクエリーに渡されるようになります。アプリケーション・コードからSPARQLを使用する場合には、データセットをクエリーにバインドしないようにするのは良い習慣です。それによって、例えば同じくエリーが、別のグラフで再利用できるようになります。グラフは、オプション付きのコマンドライン、sparql --data URLの実行時に規定されます（ここでURLはグラフの位置です）。このURLは、ローカル・ファイルの位置、あるいはリモート・グラフのWebアドレスです。
独立のクエリーを実行する場合には、コマンドラインのsparqlツールも便利ですが、Javaアプリケーションでは直接、JenaのSPARQL機能を使用することができます。com.hp.hpl.jena.queryパッケージの中にあるクラスを利用して、JenaでSPARQLクエリーを作成し、実行することができます。QueryFactoryを使えば、一番単純です。QueryFactoryには、ファイル、あるいはStringから、テキスト型クエリーを読むための様々なcreate()メソッドがあります。create()メソッドは、構文解析されたクエリーをカプセル化した、Queryオブジェクトを返します。
次のステップは、クエリーを1回実行することを表すクラスである、QueryExecutionのインスタンスを作ることです。QueryExecutionを得るためには、QueryExecutionFactory.create(query, model)を呼び、実行すべきQueryと、実行対象となるModelを渡します。クエリーに対するデータはプログラム的に提供されるため、このクエリーにはFROM文が必要ありません。
QueryExecutionには、幾つか異なる実行方法があり、それぞれ異なるタイプのクエリーを行います（囲み記事、「他のタイプのSPARQLクエリー」を見てください）。単純なSELECTクエリーの場合、execSelect()を呼ぶと、ResultSetが返ります。ResultSetを使うと、クエリーで返されたQuerySolutionそれぞれに対して繰り返しを行うことができ、バインドされた変数の値それぞれにアクセスできるようになります。一方ResultSetFormatterは、クエリー結果を様々なフォーマットで出力するために使います。
リスト4は、こうしたステップを簡単にまとめる方法を示しています。これは、bloggers.rdfに対してクエリーを実行し、その結果をコンソールに出力します。
リスト4. JenaのAPIを使って簡単なクエリーを実行する
// Open the bloggers RDF graph from the filesystem
InputStream in = new FileInputStream(new File("bloggers.rdf"));
// Create an empty in-memory model and populate it from the graph
Model model = ModelFactory.createMemModelMaker().createModel();
model.read(in,null); // null base URI, since model URIs are absolute
in.close();
// Create a new query
String queryString =
"PREFIX foaf: <http://xmlns.com/foaf/0.1/> " +
"SELECT ?url " +
"WHERE {" +
" ?contributor foaf:name \"Jon Foobar\" . " +
" ?contributor foaf:weblog ?url . " +
" }";
Query query = QueryFactory.create(queryString);
// Execute the query and obtain results
QueryExecution qe = QueryExecutionFactory.create(query, model);
ResultSet results = qe.execSelect();
// Output query results
ResultSetFormatter.out(System.out, results, query);
// Important - free up resources used running the query
qe.close();
|
ここまでは、簡単なSPARQLクエリーを実行するための、2つの方法を見てきました。1つはコマンドラインのsparqlユティリティーを使い、もう1つはJena APIでJavaコードを使う方法です。このセクションでは、SPARQLの機能をさらに紹介し、もっと複雑なクエリーが行えることを説明します。
RDFは多くの場合、半構造化データ（semi-structured data）を表すために使われます。これは、同じタイプを持つ、モデル中の2つのノードが、異なるプロパティー・セットを持つかも知れないことを意味します。例えば、FOAFモデルでの、ある人物の記述には、eメール・アドレスしか無いかも知れません。あるいは、実際の名前に加えて、IRCニックネーム、その人が写った写真のURL等々、を含んでいるかも知れません。
リスト5は、Turtle構文で表現した、非常に小さなFOAFグラフを示しています。これには4人の架空人物が含まれていますが、それぞれの人物の記述には、別々のプロパティー・セットが入っています。
リスト5. 4人の人物を記述したFOAFグラフ
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Jon Foobar" ;
foaf:mbox <mailto:jon@foobar.xx> ;
foaf:depiction <http://foobar.xx/2005/04/jon.jpg> .
_:b foaf:name "A. N. O'Ther" ;
foaf:mbox <mailto:a.n.other@example.net> ;
foaf:depiction <http://example.net/photos/an-2005.jpg> .
_:c foaf:name "Liz Somebody" ;
foaf:mbox_sha1sum "3f01fa9929df769aff173f57dec2fe0c2290aeea"
_:d foaf:name "M Benn" ;
foaf:depiction <http://mbe.nn/pics/me.jpeg> .
|
例えば、リスト5のグラフで記述された全ての人物の名前と、その人物の写真へのリンクがある場合には、そのリンクも返すクエリーを書きたい、としましょう。グラフ・パターンにfoaf:depictionを含むSELECTクエリーは、3つのソリューションのみを見つけます。Liz Somebodyにはfoaf:nameがありますが、foaf:depictionプロパティーがありません。クエリーに一致するためには両方が必要なため、Liz Somebodyはソリューションになりません。
ここで、SPARQLのOPTIONALキーワードという助けが利用できます。オプション・ブロック（Optional blocks）が追加のグラフ・パターンを定義し、ソリューションは、一致しなくても拒否されず、一致する可能性がある場合にはグラフにバインドされるのです。リスト6は、リスト5のFAOFデータにある各人物のfoaf:nameを見つけてから、オプションとして、付随するfoaf:depictionを見つけるクエリーを示しています。
リスト6. オプション・ブロックでFOAFデータをクエリーする
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?depiction
WHERE { ?person foaf:name ?name .
OPTIONAL {
?person foaf:depiction ?depiction .
} .
}
|
リスト7は、リスト6でのクエリーを実行した結果を示しています。全クエリー・ソリューションが人物の名前を含んでいますが、オプションのグラフ・パターンは、foaf:depictionプロパティーが存在する場合にのみバインドされます。存在しない場合には、単純にソリューションから省略されます。この点に関しては、このクエリーは、SQLでの左外部結合（left outer join）に似ています。
リスト7. リスト6でのクエリーの結果
------------------------------------------------------------
| name | depiction |
============================================================
| "A. N. O'Ther" | <http://example.net/photos/an-2005.jpg> |
| "Jon Foobar" | <http://foobar.xx/2005/04/jon.jpg> |
| "Liz Somebody" | |
| "M Benn" | <http://mbe.nn/pics/me.jpeg> |
------------------------------------------------------------
|
オプション・ブロックは、リスト6に示した単一の3つセットだけではなく、任意のグラフ・パターンを含むことができます。オプション・パターンがクエリー・ソリューションの一部を成すためには、オプション・ブロックでのクエリー・パターン全体が一致する必要があります。クエリーが複数のオプション・ブロックを持つ場合には、それぞれのブロックが独立に動作します。それぞれが、ソリューションから省略されたり、ソリューションの中に入ったりします。また、オプション・ブロックはネストすることもできます。その場合、内部のオプション・ブロックは、外部のオプション・ブロックのパターンがグラフに一致する場合のみ、考慮の対象となります。
FOAFグラフは、人物のeメール・アドレスを使って、その人を固有識別します。人によっては、プライバシーの観点から、eメール・アドレスのハッシュコードを使いたがります。プレーン・テキストのeメール・アドレスはfoaf:mboxプロパティーを使って表現されますが、eメール・アドレスのハッシュコードは、foaf:mbox_sha1sumプロパティーを使って表現されます。両者は通常、人物のFOAF記述では、相互排他的です。そうした場合には、SPARQLの代替一致（alternative matches）機能を使って、どちらのプロパティーであっても、得られる方のプロパティーを返すクエリーを書くことができます。
代替一致の定義は、複数の代替グラフ・パターンを記述し、それらをUNIONキーワードを使って組み合わせることによって行います。リスト8に示すクエリーは、リスト5のFOAFグラフにある各人物の名前と共に、foaf:mbox、あるいはfoaf:mbox_sha1sumを見つけます。M Bennは、foaf:mboxプロパティーもfoaf:mbox_sha1sumプロパティーも持っていないため、クエリー・ソリューションではありません。代替一致ではOPTIONALグラフ・パターンとは対照的に、どれか1つが、完全に、クエリー・ソリューションと一致する必要があります。UNIONでの分岐の両方が一致する場合には、2つのソリューションが生成されます。
リスト8. 代替一致でのクエリーと、その結果
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?name ?mbox
WHERE {
?person foaf:name ?name .
{
{ ?person foaf:mbox ?mbox } UNION { ?person foaf:mbox_sha1sum ?mbox }
}
}
---------------------------------------------------------------------
| name | mbox |
=====================================================================
| "Jon Foobar" | <mailto:jon@foobar.xx> |
| "A. N. O'Ther" | <mailto:a.n.other@example.net> |
| "Liz Somebody" | "3f01fa9929df769aff173f57dec2fe0c2290aeea" |
---------------------------------------------------------------------
|
SPARQLでのFILTERキーワードは、バインドされた変数値に対して制限を課すことによって、クエリー結果を制限します。値に対する、こうした制限は、ブール値に対して評価される論理表現であり、場合によっては論理演算子&& や論理演算子|| と組み合わせられます。例えば、名前のリストを返すクエリーであれば、与えられた正規表現に一致する名前のみを返すように、フィルターによって修正することができます。あるいは、リスト9に示すように、2つの日付の間に公開されるRSSフィードにあるアイテムであれば、アイテムの公開日に制限を加えるフィルターを使って見つけることができます。リスト9はまた、SPARQLのXPath流のキャスト機能がどのように使われるか（ここでは、date変数をXMLスキーマのdateTime値にキャストします）、また、リテラルのdateストリングと同じデータ・タイプを、^^xsd:dateTimeによって規定する方法も示しています。これによって、クエリーで使われるのは標準のストリング比較ではなく、日付の比較であることが保証されるようになります。
リスト9. フィルターを使って、2005年4月に公開されたRSSフィード・アイテムを検索する
PREFIX rss: <http://purl.org/rss/1.0/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?item_title ?pub_date
WHERE {
?item rss:title ?item_title .
?item dc:date ?pub_date .
FILTER xsd:dateTime(?pub_date) >= "2005-04-01T00:00:00Z"^^xsd:dateTime &&
xsd:dateTime(?pub_date) < "2005-05-01T00:00:00Z"^^xsd:dateTime
}
|
ここまでに示したクエリーは全て、単一のRDFグラフから成るデータセットのみを扱いました。SPARQLの用語を使うと、こうしたクエリーは、バックグラウンド・グラフ（background graph）に対して実行したことになります。バックグラウンド・グラフというのは、クエリーのFROM文やsparqlコマンドの--dataスイッチによって、あるいはJenaのAPIを使う場合に、モデルをQueryExecutionFactory.create()に渡すことによって規定されるものを言います。
SPARQLではバックグラウンド・グラフに加えて、任意の数の名前付きグラフ（named graphs）をクエリーすることができます。バックグラウンド・グラフはURIによって規定され、クエリー内では、それぞれ別々です。名前付きグラフの使い方を検証する前に、どうやって名前付きグラフをクエリーに入れるかを説明しましょう。名前付きグラフもバックグラウンド・グラフと同様、クエリー自体の中で、FROM NAMED <URI>を使って規定することができます（URIがグラフを規定します）。あるいは、--named URLを付けたsparqlコマンドで名前付きグラフを提供することもできます（URLがグラフの位置を示します）。最後に、JenaのDataSetFactoryクラスを使って、名前付きグラフをプログラム的にクエリーするように規定する方法もあります。
名前付きグラフは、SPARQLクエリーの中で、グラフのURIあるいは変数名と共に、GRAPHキーワードと組み合わせて使います。このキーワードの後には、対象となるグラフに一致するグラフ・パターンが続きます。
グラフのURI（あるいは、既にグラフのURIにバインドされた変数）でGRAPHキーワードが使われると、そのグラフ・パターンは、そのURIによって識別されるグラフの全てに適用されます。指定されたグラフで一致が見つかると、その一致がクエリー・ソリューションの一部となります。リスト10では、名前付きFOAFグラフが2つ、クエリーに渡されます。クエリー・ソリューションは、両方のグラフで見つかる人々の名前です。2つのFOAFグラフそれぞれで、人物を表すノードは空白ノードであり、これらの空白ノードを含むグラフ内にしかスコープがないことには注意してください。つまり、同じ人物ノードが、クエリー中の名前付きグラフの両方に存在することはできず、従って別々の変数（xとy）を使って表す必要があるのです。
リスト10. 名前付きFOAFグラフ2つの中で記述された人物を見つけるクエリー
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?name
FROM NAMED <jon-foaf.rdf>
FROM NAMED <liz-foaf.rdf>
WHERE {
GRAPH <jon-foaf.rdf> {
?x rdf:type foaf:Person .
?x foaf:name ?name .
} .
GRAPH <liz-foaf.rdf> {
?y rdf:type foaf:Person .
?y foaf:name ?name .
} .
}
|
GRAPHにはもう一つの使い方として、バウンドされていない変数でGRAPHを探す使い方があります。この場合には、クエリー中にある、名前付きグラフのそれぞれに対してグラフ・パターンが適用されます。そのパターンが、名前付きグラフの1つに一致すれば、そのグラフのURIはGRAPHの変数にバインドされていることになります。リスト11のGRAPH文は、クエリーに与えられた、名前付きFOAFグラフにある人物ノードそれぞれに一致します。一致した人物名はname変数にバインドされており、graph_uri変数は、そのパターンに一致したグラフのURIにバインドされます。リスト11には、このクエリーの結果も示してあります。A. N. O'Therという人物は、jon-foaf.rdfとliz-foaf.rdfの両方で記述されているため、1つの名前が2回一致しています。
リスト11. 別々の人物を記述するグラフがどれかを判定する
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?name ?graph_uri
FROM NAMED <jon-foaf.rdf>
FROM NAMED <liz-foaf.rdf>
WHERE {
GRAPH ?graph_uri {
?x rdf:type foaf:Person .
?x foaf:name ?name .
}
}
--------------------------------------------------------
| name | graph_uri |
========================================================
| "Liz Somebody" | <file://.../jon-foaf.rdf> |
| "A. N. O'Ther" | <file://.../jon-foaf.rdf> |
| "Jon Foobar" | <file://.../liz-foaf.rdf> |
| "A. N. O'Ther" | <file://.../liz-foaf.rdf> |
--------------------------------------------------------
|
クエリーが、名前付きグラフと組み合わせた背景データを使う場合もあります。リスト12は、PlanetRDF.comからライブ集約されたRSSフィードを背景データとして使い、私独自のFOAFプロファイルを含む名前付きグラフと組み合わせて、背景データをクエリーします。考え方としては、私が知っているbloggerがポストしたアイテムの内、最新の10アイテムを見つけることによって、カスタム化したフィードを作る、ということです。クエリーの最初の部分では、FOAFファイルの中で私を表すノードを見つけてから、（グラフによると）私が知っている人物の名前を見つけます。2番目の部分では、こうした人達によって作られたアイテムを、RSSフィードの中で探します。最後に、見つかったセットはアイテムの作成日でソートされ、10アイテムのみを結果として返すように制限されます。
リスト12. カスタム化した、ライブのPlanetRDFフィードを取得する
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rss: <http://purl.org/rss/1.0/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?title ?known_name ?link
FROM <http://planetrdf.com/index.rdf>
FROM NAMED <phil-foaf.rdf>
WHERE {
GRAPH <phil-foaf.rdf> {
?me foaf:name "Phil McCarthy" .
?me foaf:knows ?known_person .
?known_person foaf:name ?known_name .
} .
?item dc:creator ?known_name .
?item rss:title ?title .
?item rss:link ?link .
?item dc:date ?date.
}
ORDER BY DESC[?date] LIMIT 10
|
このクエリーは単純に、タイトルと名前とURLのリストを返すだけですが、もっと複雑なクエリーを使えば、一致したアイテムの中にある全データを抽出することもできます。SPARQLのXML結果フォーマット（囲み記事「XMLフォーマットでのクエリー結果」を見てください）と、XSLスタイルシートと組み合わせて使うことによって、ブログ・アイテムのHTMLビューをカスタム化したり、さらには、別のRSSフィードを作ったりすることもできます。
この記事で取り上げた例によって、皆さんはSPARQLの基本機能や構文を理解でき、またSPARQLがRDFアプリケーションにもたらす利点も理解できたと思います。また、オプション一致や代替一致を補助として使うことによって、半構造化されている、実世界のRDFグラフの持つ特質をSPARQLで取り扱う方法を学びました。名前付きグラフを使った例では、SPARQLで複数のグラフを組み合わせることによって、クエリーのオプションが広がることを示しました。さらに、JenaのAPIを使えば、JavaコードからSPARQLクエリーを実行することが簡単であることも見てきました。
SPARQLには他にも、この記事では書ききれないほど、様々なことを行うことができます。下記の参考文献を活用して、さらにSPARQLについて学んで下さい。SPARQLの仕様を見れば、SPARQLの組み込み機能や演算子、クエリー形式や構文について学ぶことができ、また、SPARQLクエリーの例も数多く挙げられています。
もちろん、SPARQLについて学ぶために一番良いのは、自分でクエリーを書いてみることです。皆さんもWebから幾つかRDFデータを取得し、Jena ARQモジュールをダウンロードし、実験を始めてみてください。
- Philip McCarthyによる別の記事、「Jena入門書」（developerWorks, 2004年6月）は、RDFクエリー言語の詳細を含めて、Jena Semantic Web Toolkitの概要を説明しています。
- 最新版のSPARQL仕様書では、SPARQLでのクエリー構文と機能について、明確に記述されています。
- Dave Beckettが、簡潔なSPARQL Language Quick Referenceを作っています。印刷して、自分の机の前に貼っておくのに最適です。
-
SPARQL Query Results XML Formatは、「XMLフォーマットでのクエリー結果」で議論した結果フォーマットを記述しています。
-
Jena SourceForge projectでは、Jena Semantic Web Toolkitのドキュメンテーションやダウンロードをホストしています。
- Andy SeaborneによるARQ home pageには、CVSからARQを得るための手順が説明されています。最新のARQディストリビューションは、ARQ's downloadsページから入手することができます。
-
SPARQLerは、JenaのSPARQLクエリー・エンジンに関するオンライン・デモです。これを利用して、SPARQLクエリーを実験することができます。
- Dave BeckettによるRasqal RDF Query Libraryは、SPARQLをサポートするオープンソースのCライブラリーであり、様々な言語のバインディングがあります。
-
FOAF Projectは、機械読み取り可能なRDFボキャブラリーを使って人物や関係を記述するための実験です。FOAF Vocabulary Specificationでは、この記事で使用しているFOAF用語を定義しています。
-
Dublin Core Metadata Element Setは、一般的に使用されるメタデータ用語を集めたものとして標準的なものであり、FOAFやRSS 1.0など、多くのRDFボキャブラリーやフォーマットで採用されています。
- SPARQLのグラフ・パターンは、Turtle -- Terse RDF Triple Languageの構文に基づいています。
-
PlanetRDF.comは、セマンティックWebコミュニティーの開発者のweblogを集約しており、この領域での開発に追いつくために便利です。この記事の記事では、PlanetRDFのRSS feed とRDF blogrollを使っています。
-
developerWorksのJava technologyゾーンには他にも、Javaプログラミングのあらゆる面に関する記事が豊富に用意されています。
-
Developer Bookstoreには、Java関連の書籍をはじめ、広範な話題を網羅した技術書が豊富に用意されていますので、ぜひご利用ください。
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ