ジャパンサーチのSPARQLエンドポイント

1. ジャパンサーチのRDFモデル | 2. いつ、どこ、だれ、なに | 3. クエリの応用 | 4. 簡単クエリ：EasySPARQL

ジャパンサーチのRDFモデル

ジャパンサーチ（以下JPS）利活用スキーマのRDFモデルは、Schema.orgプロパティを用いたシンプルな直接記述と、JPSで定義するプロパティを用いた構造化記述を併せ持っています。またコンテンツ自身の情報に加え、コンテンツにアクセスするための情報と、コンテンツ情報の提供元（データベース）に関する情報もそれぞれまとめて記述しています。

RDFとSPARQLクエリ

RDF（Resource Description Framework）は、さまざまな情報を「主語 - 述語 - 目的語」3点セット（トリプル）の組み合わせによって記述するものです。RDFトリプルの集まりをグラフと呼びます。主語／目的語は作品／作者など、述語はその関係（プロパティ）を表し、しばしば次のような円と矢印の図で表現されます。

（RDFトリプルの主語 - 述語 - 目的語にはURIを用いますが、ここでは分かりやすくするためにURIの前半（名前空間URI）をschema:などの短い接頭辞に置き換えた短縮名とします。またここでは、接頭辞:に続くspatialなどの個別名を名前部分と呼ぶことにします）

SPARQLは、RDFはグラフの中から目的にあった部分を選び出すためのクエリ（問い合わせの記述）を表現する言語です。クエリはRDFグラフの中で調べたい（未知の）値を持つトリプルを、その未知の要素を ? で始まる変数としたトリプルパターンで表現します。たとえば図1の主語部分（ex:aBook）が未知の値だとすると、次のようなトリプルパターンとなります。

SPARQLのクエリは、必要なトリプルパターンを集めたグラフパターンを組み立て、データベース中のRDFグラフからそのパターンに合致する部分を選び出します。次節ではクエリの部品を順に説明し、最後に実際のクエリを組み立ててJPSに問い合わせができるようにします。

Schema.orgプロパティを用いたシンプルな検索

JPSのRDFモデル（RDFグラフの基本設計）は、多彩な提供元からのデータ（以下、元データと呼びます）を一貫した形で検索・閲覧できるように、「いつ」を年、「どこ」を都道府県といった大きなくくりで正規化し、URIを付与しています。また「だれ」についても表記の揺れや別名を可能な限り集約し、正規化名のURIを付与しています。これらの値は、Schema.orgのプロパティを用いた直接記述の値になっており、シンプルなSPARQLクエリで検索可能です。

たとえば「三重県に関係があるコンテンツ」を調べたいなら、場所関係を示すschema:spatialとJPS正規化地名「place:三重」（図2）を用いることができます（場所の正規化名＝短縮名の名前部分には「都道府県」は付かないことに注意してください）。

SPARQLの構文は、RDFのTurtle構文に準ずるもので、このトリプルパターンを「主語述語目的語」3点セットを並べて記述していきます。

?s schema:spatial place:三重

このトリプルパターンで検索すると、三重県に関係するコンテンツのURIが、変数 ?s の答えとして得られます。ただコンテンツURIは識別番号などのIDを元に作られているため、それだけではどんなコンテンツなのかを判別できません。

そこで、調べたいことと合わせてそのコンテンツのラベル（タイトル／名称）も加えたグラフパターンを用います。ラベルを記述するプロパティはrdfs:labelです。

図3のグラフパターンは、場所とラベルに対応する2つのトリプルパターンの組み合わせです。両者は同じ主語を持つため、同じ円から2つの矢印が伸びる形になっています。

SPARQLでこのグラフパターンを記述するときは、トリプルパターンをピリオド . で区切ってそのまま列挙します。

?s schema:spatial place:三重 .
?s rdfs:label ?label .

また同じ主語の場合は2回目を省略し、;で連結する構文を使うこともできます。

?s schema:spatial place:三重 ;
    rdfs:label ?label .

ラベルは多くの場合、提供元データベースの文脈や背景を前提にして付けられているため、JPSのような複合ソースを集約したデータベースにおいては、ラベルだけでは内容がよく分からないことも少なくありません。ラベルと合わせてコンテンツの型（クラス）も調べることで、内容の判別が容易になります。

型を表すプロパティはrdf:typeですが、これは頻繁に用いられるため、SPARQL構文では a の一文字で簡略表記することができます。

?s schema:spatial place:三重 ;
    rdfs:label ?label ;
    a ?type .

逆に、1つの直接記述プロパティだけでは得られる結果が多すぎて扱いにくいときに、型（クラス）を限定することでより焦点を絞った検索が可能です。

?s schema:spatial place:三重 ;
    rdfs:label ?label ;
    a type:陶磁 .

最後のグラフパターンを用いて、実際にサーバーに問い合わせるためのSPARQLクエリを、次の要領で組み立ててみましょう。

問い合わせたいグラフパターンを{}で囲んで、条件句を表すWHEREの後に置く
グラフパターンに用いた変数のうち、結果として受け取りたいものを空白区切りで列挙してSELECTの後に置く（すべての変数が必要な場合は * と表記できます）
URIを短縮記述した接頭辞と元のURIの対応をPREFIXで列挙する

以上をまとめたクエリが次の例です（この例は実際にJPSサーバーに問い合わせてみることができます）。

同様にして、時間関係はschema:temporal、作者はschema:creatorで検索できます。JPSで利用できるプロパティは利活用スキーマ概説を、またJPSでのクラスは現在用いられているクラスとその上位クラスを参照してください。

（※次節以降の例は、名前空間を記述するPREFIX句を省略していますが、そのまま実行できます）

構造化プロパティを用いたさまざまな精度の検索

schema:spatialはある場所に関するコンテンツを幅広く検索できますが、その場所はコンテンツの制作地であったり、展示（公開）されている場所であったり、あるいはコンテンツの内容に描かれた場所であったりします。

構造化記述は、直接記述の値がどういう役割（制作地、公開地、など）においてコンテンツと関係しているのかを示すjps:relationTypeを持っています。直接記述の値とはjps:valueで繋がります。

つまり構造化記述（jps:spatial）は、対応する直接記述（schema:spatial）をより詳しく表現したものというわけです。この関係を利用すれば、「三重県で制作された陶磁」といったクエリを組み立てることができます（SPARQLクエリの構文では、構造化部分は [] で囲んで入れ子記述します。JSONのオブジェクト記述と似た形と考えると分かりやすいかもしれません）。

逆に「だれ」の場合、直接記述ではschema:creator、schema:contributorのようにプロパティを使い分けていますが、構造化プロパティではこの違いはjps:relationTypeが担うため、jps:agentialを用いることで役割の違いに関わらず「だれ」を一括して調べることができます。

構造化記述は、jps:relationTypeを「role:内容」として、コンテンツを作った人だけでなくコンテンツの内容（主題）である人をも記述します。そのため、上記のjps:agentialによるクエリは森鴎外の著作（誰が）だけでなく、森鴎外「について」のコンテンツ（誰を）も合わせて調べることができます（直接記述ではschema:aboutになります）。

（役割については3.1 役割の階層構造も参照してください）

アクセス情報とソース情報

コンテンツにアクセスするための情報と、コンテンツ情報の提供元（データベース）に関する情報は、それぞれjps:accessInfo、jps:sourceInfoの値として構造化記述しています。構造化記述内では、いずれも提供者はschema:providerで表現されます。

図5のグラフは、この三重県で制作された陶磁が「東京国立博物館に収蔵されており、そのコンテンツ情報はColBase（国立博物館所蔵品統合検索システム）によって提供された」ことを表しています。

この構造を用いて、たとえば「東京国立博物館でアクセス可能な陶磁」を次のクエリで知ることができます。

JPSのコンテンツ情報は、さまざまな情報を一貫した形で扱えるように整理したものですが、その元になった情報はこのjps:sourceInfoを介して確認できます。また、次のGROUP BYを用いたクエリは、どのデータベースからどれだけのコンテンツ情報が提供されているかを一覧表示するものです。

いつ、どこ、だれ、なに

JPS利活用スキーマの構造を利用して、「いつ」「どこ」「だれ」「なに」の切り口でよりきめ細かな検索を実行できます。

いつ：時間範囲と時代

JPS利活用スキーマでの時間情報は、年を単位に正規化し、文字列ではなく時間範囲などを持つ構造化情報として扱っています。構造化情報は年を名前部分に用いたURIで識別します。

制作時期が「1192年」と特定できる作品を調べるには、時間情報のURIであるtime:1192を直接記述の値にしてクエリを送ります。

作品情報は必ずしも明確な年があるわけではなく、「○○世紀」「△△時代」としか時間情報が与えられない場合もあります。たとえば「12世紀」とされているコンテンツは、時間範囲を名前部分にしたtime:1101-1200という形のURIを時間情報値としています。

ただし上のクエリは時間情報が「12世紀」であるコンテンツを検索できる一方、個別年を持つtime:1192は探せません。両者をもれなく見つけるためには、範囲検索が必要です。

JPSの時間情報は、すべて開始年と終了年をその構造化値として持ちます（単一年は開始年と終了年の値が同じです）。

time:1192 jps:start 1192; jps:end 1192 .
time:1100-1199 jps:start 1101; jps:end 1200 .

これを利用すると、12世紀の作品を求めるクエリは次のように記述できます。FILTERは変数の値を絞り込むための制約記述、DISTINCTは結果の値に重複がないように限定するための記述です。

「△△時代」も同様にして、開始年と終了年を用いて調べることができますが、元データに「△△時代」が含まれている場合は、時間関係の構造化値としてjps:eraを用いて記述しています。

鎌倉時代の作品を調べたければ、次のようなクエリが記述できるでしょう。

（元データの時間が「△△時代」のみの場合は、schema:temporalの値も時代になりますが、時代と年が併記されている場合は、schema:temporalの値には年を採用しています）

どこ：位置情報とGeohash

JPS利活用スキーマでの場所情報は、都道府県（海外の場合は国）を単位に正規化し、同じ地域のコンテンツを簡単に検索できるようにしています。元データの値は、構造化記述のschema:descriptionに保持しているので、より詳細な住所がある場合はここで確認できます。

元データに緯度経度があればその値を、あるいは住所記述があったり、美術館、寺社などよく知られた地物が対象である場合は可能な範囲で緯度経度情報を推定して、構造化情報にschema:geoを加えています。また緯度経度からGeohashを算出し、（推定）緯度の精度を踏まえて4～6桁のハッシュ値によるURIをschema:geoCoveredByの値として付与しています。

たとえば三重県桑名市にある句碑のデータには、所在地の緯度経度35.065502284, 136.692193566とそこから算出したGeohashを用いて次のような位置情報が記述されています（TurtleおよびSPARQL構文では、接頭辞を用いないフルURIは <> で、また文字列は引用符 "" で囲んで記述します）。

<https://jpsearch.go.jp/data/kuhi-457423>
    jps:spatial [
        schema:geo <http://geohash.org/xn1pqx2pqgquz1pz> ;
        schema:description "所在地: 桑名市北寺町本統寺" ;
        schema:geoCoveredBy <http://geohash.org/xn1pqx> ;
        jps:note "元項目:geoは緯度・経度から" ;
        jps:region place:三重.桑名市
    ]
 .
<http://geohash.org/xn1pqx2pqgquz1pz>
    schema:latitude 35.065502284 ;
    schema:longitude 136.692193566 
 .

構造化部分を図示すると次のような形です。

Geohashのハッシュ値は一定範囲の緯度経度に対応し、桁数が多いほど詳細な範囲を表します（4～6桁はそれぞれ20Km四方程度、5Km四方程度、1Km四方程度の範囲に概ね対応します）。また上位桁の値が同じであれば、長いハッシュ値の場所は同じ上位桁の緯度経度範囲に含まれるという性質を持っています。

これを利用して、この句碑の近くにあるコンテンツを次のように検索することができます。

上の例でjps:spatialとschema:gerCoveredByを / で連結した記法は、SPARQL 1.1のプロパティ・パス構文です。JavaScriptのドット記法のように、プロパティ階層を連結して簡潔に記述できます。

GeohashのURIは、一桁小さいGeohashのURIとjps:withinで結びつけられているので、SPARQL 1.1のプロパティ反復構文（ ? を付加）を利用すると、より広い範囲のコンテンツを検索できます。

URIのGeohash桁数が1つ減り、jps:withinに ? が加わっていることに注意してください。? はプロパティの0回もしくは1回の出現を表します。つまり、句碑と同じgeoCoveredByのgeohashエリア（withinは0回、すなわちgeoCoveredByのみ）と、その1レベル広域（geoCoveredByに加えてwithinは1回）を一度に検索することになります。

だれ：JPS正規化名とLOD

構造化プロパティの例ではchname:森鴎外を検索してみましたが、この名前部分を「夏目漱石」に、?typeをtype:図書に変えるとほとんど何もヒットしないかもしれません。これは、JPSに「夏目漱石に関する図書」がないのではなく、図書（書籍）の場合はNDLAの典拠IDを用いて作者を識別しているからです。

このままでは、典拠IDを知らないと検索できない、図書と文化財を一緒に検索できないといった使いにくさが生じるため、JPSの正規化名URIはowl:sameAsでNDLAをはじめとする外部典拠LOD（Linked Open Data）のURIと関連付けられています。

そこで「夏目漱石に関するコンテンツ」は次のようにして検索できます。

owl:sameAsの後に加えた * は、このプロパティが0回以上連続することを表します（0回も含むということは、JPS正規化名が直接与えられているコンテンツも検索できることを意味します）。

JPS正規化名URIは、ほかにもWikidata、VIAF、DBpedia日本語版などとowl:sameAsで関連付けられているので、これらのIDを利用したクエリを組み立てることも可能です。

なに：階層関係を利用した範囲の拡大

「なに」という場合は、コンテンツが「どんな種類」かを考えているときと、「何について」を考えるときがあります。前者はコンテンツのクラス（rdf:type、略してa）、後者は主題（schema:about）で調べることができます。

たとえば神奈川県に関係する絵画を知りたければ、次のクエリで種類と場所を問い合わせます。

ただしコンテンツのクラスは元データの種別などの情報に基づいているので、あるものは「水彩」や「版画」といったクラスが付与されているかもしれません。JPSのクラスは階層構造を持ち、「水彩」や「版画」は「絵画」の下位クラスと位置づけられています。下位クラスはrdfs:subClassOfで記述されることと、「だれ」で使った0回以上の反復を組み合わせると、「絵画とその下位クラス」のコンテンツを検索できます。

JPSでのschema:aboutの値は、国立国会図書館件名標目（NDLSH）や日本十進分類（NDC）のような典拠（統制語彙）のURIの場合と、元データのキーワードをそのままURI化したもの（非統制語）の場合があります。前者は典拠の名前空間URI、後者はJPSのkeyword:名前空間のURIとなっています。

たとえば「食」をキーワードにしたコンテンツなら次のように検索します。

NDLSHやNDCは、それぞれ典拠ID、分類記号が分からないとURIによる検索ができませんが、主なものにはJPSのRDFストアにもラベル（rdfs:label）を格納しており、キーワードのような形で検索ができます。たとえば「フランス詩」を主題とするコンテンツなら次のような具合です。

さらにJPSでラベルを保持するNDLSHの件名については、階層（上位件名）および関連するNDCも格納しています。これらはいずれもrdfs:seeAlsoとして関連付けているので、これを利用すると、やはり反復構文を用いて「フランス詩に関係する」主題のコンテンツを調べることができます。

この場合は、rdfs:seeAlsoを0回以上反復した上で、さらにrdfs:labelをプロパティ・パスの最後に加えているわけです。

クエリの応用

少し踏み込んだ応用編をご紹介します。ここで取り上げるSPARQLの機能は、全て解説すると煩雑になるため、最小限にとどめています。詳細は適宜仕様書|t:SPARQL 1.1 Query Languageなどを参照してください。

役割の階層構造

構造化記述で説明した役割（jps:relationTypeの値）は、元データのフィールド名（撮影年、出版地、作者など）や項目値（三代歌川豊国筆、平田禿木訳など）から取っており、ある程度正規化はしているものの、多くのバリエーションがあります。このままでは、検索に利用するのは容易ではありません。

そこでJPSのRDFモデルでの役割値は、個別の役割を「制作」「公開」「発見」「取得」「記録」「出演」「内容」「支援」「関連」の9つにグループ化し、「制作.撮影」「公開.出版」という具合に大分類をピリオドでつないで前置する形にしています。

個々の役割と大分類の役割は、skos:broaderによって関連付けられています。これを利用して、「神奈川県で公開されている（された）コンテンツ」を次のように検索することができます。

プロパティパス構文で階層を表現するのは「なに」のクラス階層の例と同様ですが、ここではskos:broaderによる上位関係は1段階しかないので、0回もしくは1回を意味する ? を加えています。

画像とIIIFマニフェスト

画像あるいはサムネイルが提供されるコンテンツは、schema:imageでそのURIを示しています。たとえば北斎の作品で画像があるものは次のようにして調べることができます。

IIIFのマニフェストが提供されている場合は、画像ではなく、アクセス情報のURLとして記述されます。このとき、このリソースにはIIIFのManifest型を付与しているので、これを利用してIIIFマニフェストの一覧を得ることができます。

最後に加えたLIMITは、取得結果の最大数を指定するものです。

ライセンス

JPSのアイテム情報は（少なくとも画像がある場合は）原則としてライセンスを明示しており、アクセス情報にschema:licenseを用いてそのURIを記述しています。

たとえば次のアイテムは、CC BY-SAのライセンスで利用できることがわかります。

<https://jpsearch.go.jp/data/irc01-lb0tdQdIpYEimKbUrdNSJk00214845>
    rdfs:label "京都市名所圖" ;
    jps:accessInfo [
        schema:license <http://creativecommons.org/licenses/by-sa/4.0/>
    ] .

ただ、同じCC BY-SAのライセンスであっても、機関ごとにバージョン（上の例では4.0）が異なったり、ライセンスURIのスキームがhttps:になっていたりとばらつきがあり、ライセンスURIだけで同じライセンスのコンテンツを拾い上げることが難しくなっています。

そこでJPS/RDFでは、バージョンやURI記述の揺れなどの違いによる差異を吸収するために、基本参照ポリシー（ReferencePolicy）として標準URIを定め、各バリエーションからdct:isVersionOfで関連付けるようにしました。これを利用すると、CC BY-SAのライセンスで提供されるアイテムを網羅的に検索できます。

またさまざまなライセンスを、商用利用可（AllowCommercial）、非商用のみ利用可（NonCommercialOnly）などのカテゴリに区分しています。これを利用すると、商用もしくは非商用利用が可能な画像ありコンテンツを検索することができます。

外部エンドポイントとの統合クエリ

SPARQL1.1は外部のエンドポイントと連携した統合クエリ（Federated Query）を規定しています。この機能を用いると、JPSとLODACやEuropeanaなどの外部サービスを横断した検索が可能です。

英国図書館との統合クエリ

英国図書館は英国書誌データをRDF化してSPARQLエンドポイントで提供しているので、これをJPSと合わせて検索してみましょう。英国図書館は独自の典拠URIを使って作者を識別しますが、この値はVIAFとowl:sameAs関連付けられています。JPS正規化名URIも同様にowl:sameAsでVIAFと結びつけていますから、これを利用して「葛飾北斎」を調べるクエリを組み立ててみましょう。

まず正規化名URIからVIAFのURIを取り出します。JPS正規化名は複数のLODとowl:sameAs関係を持っていますが、それぞれがどの典拠によるものかはrdfs:isDefinedByで区別できます。

chname:葛飾北斎 owl:sameAs ?viaf .
?viaf rdfs:isDefinedBy <http://viaf.org/> .

次に英国図書館のクエリです。英国図書館のRDFはDublin Core、FOAF、Bibontなどの語彙で記述されており、著者はdct:creator、作品タイトルはdct:titleです（この語彙はJPSに含まれないので、接頭辞をあとで宣言します）。

?creator owl:sameAs ?viaf .
?s dct:creator ?creator ;
    dct:title ?title .

このクエリを英国図書館に送って検索結果を返してもらうためには、SERVICE句を用いて英国図書館のエンドポイントを指定します。

SERVICE <http://bnb.data.bl.uk/sparql> {
    ?creator owl:sameAs ?viaf .
    ?s dct:creator ?creator ;
        dct:title ?label .
}

JPSでの検索はこれまで見てきた通りです。

?s rdfs:label ?label;
    schema:creator/owl:sameAs? chname:葛飾北斎 .

両者のクエリ結果をUNIONで統合し、必要な変数?s ?labelを取得するのが次のクエリです。

Europeanaとの統合クエリ

Europeanaのデータモデル（EDM）は、データが(1)提供元（所蔵館）から受け取った値のグループと(2)Europeanaで整理した値のグループとに分かれています。URIで正規化された著者は(2)に用意されている一方で、画像など所蔵館のリソースは(1)にまとめられるという具合になっており、クエリが少々厄介です。

まずこちらは、作者をDBpedia（英語版）を介してつないでみます（今度は北斎を例にします）。

chname:葛飾北斎 owl:sameAs ?loduri .
FILTER(strstarts(str(?loduri), "http://dbpedia.org/"))

2つのデータグループはEDMモデルでProxyと呼ばれるリソースを中心にまとめられ、同じ「作品リソース」（CHO）とore:proxyForで結ばれています。(1)の提供元Proxy（edm:europeanaProxyがfalse）はore:proxyInで提供元のリソース集合（Aggregation）に結ばれ、そこにedm:objectとして画像が含まれています（画像でない場合もありますが、話を単純化しておきます）。

?proxy dc:creator ?loduri ;            #(2)EuropeanaのProxy
    ore:proxyFor ?cho .
?s ore:proxyFor ?cho ;                 #(1)提供元のProxy
    edm:europeanaProxy "false" ;
    dc:title ?label ; 
    ore:proxyIn [ edm:object ?image ]  #(1)提供元のAggregation

あとは英国図書館の場合と同様なので、JPSのクエリとまとめてUNIONとします。

提供元のグループ（Proxy）には文字列で作者が記されていおり、こちらを使ってクエリを組み立てればSERVICEでの問い合わせはもう少しシンプルになります。ただし逆に表記の揺れがあるため、多少複雑でもURIを使うほうが確実です。

英語ラベル

JPSのコンテンツ情報は全てが英語の記述を持っているわけではありませんが、正規化名URIのリソースに英語ラベルを加えることで、英語によるクエリにもある程度対応できるようにしています。

たとえば「なに」で調べた「神奈川県に関係する絵画」を英語で検索するためには、type:絵画とplace:神奈川の英語ラベルを使うことができます。英語ラベルはschema:nameに言語タグ付きで付与しています。

「フランス文学に関係する」主題の場合も同様です。

タイトルについては、英語タイトルが提供されるものもありますが、日本語の読みだけが付与されているものもあります。これらを英語でも検索できるようにするため、試験的に日本語読みをローマ字化してやはりschema:nameとして加えています（ローマ字だと言語タグは本来ja-Latnですが、英語ラベルと同時に検索できるよう、en-JPという変則的なものにしています）。

読みが分かち書きされていないと何が何だかわからない文字列に見えますが、使ってみると案外役に立つこともあります。たとえば、タイトルに"kodomo"が含まれる絵画を検索してみましょう。

大規模なRDFグラフでテキスト検索は負荷が重いので、Virtuoso独自のFILTER bif:contains()を利用しています。またクラスや場所などで限定を加えないと、テキストマッチを調べる対象が多すぎて時間切れエラーになってしまうかも知れません。

簡単クエリ：EasySPARQL

SPARQLは高機能である一方、手軽にアプリケーションで利用したいという場合には少々敷居が高いかもしれません。JPSでは、通常のSPARQLエンドポイントに加えて、シンプルなRESTパラメータを送るとサーバ側でSPARQLクエリに変換して結果セットを返す「EasySPARQL」を提供しています。

EasySPARQLのパラメータ

リクエストに用いるパラメータは次の表に示すものです。

EasySPARQLのパラメータ
パラメータ	値	備考
`when`	YYYY[,YYYY] \| 時代名	YYYYは西暦年（の範囲）
`where`	都道府県名 \| nnn,mmm	nnn,mmmは緯度経度の数字
`who`	名前	先頭に`~`を加えると別名も含め検索
`what`	クラス名	先頭に`~`を加えると上位クラスも含め検索
`keyword`	主題／キーワード	先頭に`=`を加えると完全一致
`title`	タイトル（に含まれる文字列）	先頭に`=`を加えると完全一致
`text`	任意の文字列	すべての文字列フィールド対象
`format`	json \| xml	返り値のフォーマット（略すとAcceptヘッダによる）
`limit`	最大取得件数	略すとシステム設定値

たとえば「夏目漱石に関するコンテンツ」ならば次のようにリクエストを送ります。

https://jpsearch.go.jp/rdf/sparql/easy/?who=夏目漱石

パラメータ値には、URIや短縮名ではなく通常の名前を用います。場所の末尾「都道府県」はあってもなくても構いません。

EasySPARQLの返り値

返り値はformatで指定したSPARQL結果フォーマット（JSON結果フォーマットもしくはXML結果フォーマット）で、次の変数を含みます。

EasySPARQL共通の返り値
変数名	内容
`s`	リソース（コンテンツ）のURI
`label`	コンテンツのタイトル（`rdfs:label`の値）
`creator`	コンテンツの作者URI（`schema:creator`の値）
`type`	コンテンツのクラスURI（`rdf:type`の値）

またパラメータごとに次の変数が加わります。

EasySPARQL共通の追加返り値
パラメータ	変数名	内容
`when`	`when`	年／時代URI（`schema:temporal`の値）
`where`	`lat` `long`	緯度経度（数値）
`who`	-	（追加なし）
`what`	-	（追加なし）
`keyword`	`class`	キーワード／主題URI（`schema:about`の値）
`title`	-	（追加なし）
`text`	-	（追加なし）

葛飾北斎の検索（who=葛飾北斎）で取得したJSONフォーマットによる結果の冒頭を、例として次に示します。

{
    "head": {
        "link": [ ],
        "vars": [ "s", "label", "creator", "type" ]
    },
    "results": {
        "distinct": false,
        "ordered": true,
        "bindings": [
            {
                "s": {
                    "type": "uri",
                    "value": "https://jpsearch.go.jp/data/cobas-47301"
                },
                "label": {
                    "type": "literal",
                    "value": "富嶽三十六景"
                },
                "creator": {
                    "type": "uri",
                    "value": "https://jpsearch.go.jp/entity/chname/葛飾北斎"
                },
                "type": {
                    "type": "uri",
                    "value": "https://jpsearch.go.jp/term/type/絵画"
                }
            },
            ...
        ]
    }
}

エラーがなければ、結果セットはresults.bindingsに配列として入ります。bindingsの各要素は、変数名をキーに{"type": "uri | literal", "value": "変数の値"}という形の値を持つオブジェクトで構成されます。最初のタイトル（label）ならば、results.bindings[0].label.valueという具合にアクセスできます。

なおブラウザでEasySPARQLを利用すれば、サーバ側で組み立てて実行されたSPARQLクエリを確認できますので、適宜手を加えてカスタマイズしてください。

例：EasySPARQLで取得したデータをLeaflet.jsを用いて地図表示する

jQueryなどのAJAXが使えるライブラリとLeaflet.jsを用いて、EasySPARQL経由でJPSのRDFを取得し、地図に表示させるJavaScriptの例を示します。

//jQueryとLeaflet.jsをロードし、地図を表示するdiv要素をid="mymap"として用意しておく
var map = L.map('mymap');
function maptest(lat, long){
    var easy = "https://jpsearch.go.jp/rdf/sparql/easy?where=" + lat + "," + long + "&format=json";
    map.setView([ lat, long ], 13);
    L.tileLayer("https://cyberjapandata.gsi.go.jp/xyz/pale/{z}/{x}/{y}.png", {
           attribution: '<a href="http://www.gsi.go.jp/kikakuchousei/kikakuchousei40182.html">国土地理院</a>'
    }).addTo(map);
    $.getJSON(easy, function(res){
        res.results.bindings.forEach(function(bind){
        var marker = L.marker([ bind.lat.value, bind.long.value ].addTo(map);
        marker.bindPopup("<a href='"+bind.s.value+"'>" + bind.label.value + "</a>");
        });
    });
}

緯度経度を指定し、EasySPARQLでコンテンツ情報を取得してみましょう。初期値は「どこ」の例に挙げた桑名市近郊の緯度経度です。

緯度経度