SPARQLエンドポイントの特徴あるいは制約SPARQL endpoint behaviors

ジャパンサーチ（JPS）のSPARQLエンドポイントは、Virtuosoのバージョン7.2（公開時点）を用いています。このクエリエンジンの実装（癖？）およびサーバー環境のため、いくつかの制約というか留意点があります。

Japan Search (JPS) employs Virtuoso 7.2 for its SPARQL endpoint. Due to the implimentation of this query engine and the server environment, there are some odd behavior or limitation.

TurtleのIRIIRIs in Turtle output
IRIの非ASCII文字列がUnicodeエンコード（URLエンコードではなく\uxxxx）されてしまいます。接頭辞を用いたQNameはエンコードされないのですが、国俊_(刀剣)のようにQNameにできないローカル名を持つIRIの場合、\u56FD\u4FCA_(\u5200\u5263)となって返ってきます。リテラル値も同様なので、Turtleフォーマットを利用する場合は注意してください。
JSONフォーマットも値はすべてUnicodeエンコードされますが、デコード時に元の文字に戻すのが普通なので、特に留意する必要はありません。RDF/XMLではこの問題は生じません。
Non-ASCII characters in IRIs are Unicode encoded. While QNames are OK, some local names e.g. 国俊_(刀剣) are returned as \u56FD\u4FCA_(\u5200\u5263), incorrect IRIs (although JSON data is also Unicode encoded, it is an expected behavior). XML format has no such problem.
プロパティパスの反復オペレータUnary operators of property path
JPSのRDFモデルでは、異なる典拠の識別子を一括検索したりクラス階層を利用して検索するために、SPARQL 1.1のプロパティパスが重要な役割を果たします。VirtuosoはSPARQL 1.1対応で、基本的にはプロパティパスも機能するのですが、重いクエリではこれが思うように働いてくれないことがあります。
JPS RDF model expects heavy use of SPARQL 1.1 property path. Altough Virtuoso supports property path, it behavies odd in some heavy queries.
例えば「室町時代の絵画」を調べるために《サブクエリで室町時代の開始／終了年を得てから、その時間範囲をフィルタにして絵画とそのサブクラスを得る》というクエリを使うとき、
For example, in order to get "Paintings (絵画) in Muromachi Period", we could build a query that "get start/end year of Muromachi Period by a sub query, then select Paintings (type:絵画) and its sub classes and filter with start/end year". If we write this subclass pattern as

?s a/rdfs:subClassOf* type:絵画

とすると重い上に本来得られるはずの結果の一部しか返ってきません。不思議なことに、クラスをIRIではなくラベルで指定する方が応答が速く、結果も漏れなく取得できます。
then the endpoint returns only partial result (because its heavy?). But if we use label for the end of property path, it returns full results (with a bit faster response).

?s a/rdfs:subClassOf*/rdfs:label "絵画"

また、比較的シンプルな役割の階層構造を利用したクエリでも、場所と役割の組み合わせによっては応答にとても時間がかかることがあります（例えばplace:岡山とrole:制作）。ところがこれも、役割のプロパティパス終点をIRIではなくラベルにすると速い応答が得られます。
Even for simpler query as role hierarchy pattern, if use IRI for the role (role:制作) the query takes much longer time. Label terminal works better again.
rdfs:subClassOfやowl:sameAsなどは、複雑なクエリでなければプロパティパスにしてもそれなりに速く答えが得られるので、RDFでの推論に用いられるものは特別な最適化が行なわれているのかも知れません。
In simple query, property path of rdfs:subClassOf and owl:sameAs works fine. There might be some internal optimization for RDF inference properties.
プロパティパスの主語/目的語Subject/object of property path
プロパティの反復を含むパス構文を用いるとき、その主語・目的語は変数もしくはQNameとする必要があり、空白ノードだとエラーになります。たとえば例1のサブクラス反復は
When property path containts a repeating property, its subject/object needs to be either variable or QName, not a blank node. The path in example 1 can be written as

?s a [rdfs:subClassOf* type:絵画]

と書いてもSPARQL 1.1の文法上は問題ありませんが、VirtuosoはSubject of transitive triple pattern should be variable or QName, not literal or blank nodeというエラーを生じます。
according to SPARQL 1.1 grammer. However, Virtuoso throws an error Subject of transitive triple pattern should be variable or QName, not literal or blank node and does not process this pattern.
統合クエリの制約Federated Query limitation
JPSのエンドポイントはSERVICE句による外部エンドポイントとの統合クエリを有効にしていますが、サーバー環境の制約で、現在のところWikidataなどのHTTPSのエンドポイントとVirtuosoが通信できていません。この非公式サポートページでこれらのエンドポイントとの統合クエリツールを提供しています。
While JPS endpoint makes SPARQL 1.1 federated query available, Virtuoso cannot acces to HTTP endpoints e.g. Wikidata at this moment, due to server's environment. This unofficial support page provides federated query tool with those endpoints.