問題タブ [rdf4j]

全文クエリを使用するために、しばらくの間、ゴマ RDF リポジトリ (現在は RDF4j と呼ばれています) を構成しようとしています。

この構成に関するドキュメントはあまり見つかりませんでした。コンソールで使用できるように、テンプレート ファイルを作成する必要があると思います。トピックに関する小さな情報は次のとおりですhttps://groups.google.com/forum/#!topic/rdf4j-users/xw2UJCziKl8

Lucene を使用した RDF4j の構成に関する情報を知っている人はいますか? 手がかりは非常に高く評価されます。それ以外の場合は、たとえば virtuoso のように、リポジトリ全体を別のものに変更することを考えます。

前もって感謝します、

この投稿の長さをお詫び申し上げます。この遅いルールの問題を再現できるようにしています。

TopBraid Composer FE を使用して、オントロジーと SPIN コンストラクターを含む RDF ファイルを作成しています。SPIN コンストラクターの目的は、オントロジーで定義されたクラスの個々のインスタンス化におけるコンプライアンスをチェックすることです。SPIN コンストラクターの実行が非常に遅いことがわかりました。その理由を知りたいです。

SPIN コンストラクタを含むオントロジー SXIComplianceCheck18.rdf

リポジトリ (RDFS+SPIN をサポートするメモリ内ストア) を変更/クリアし、このオントロジーを RDF4J ワークベンチにロードします。

次に、2 つの SPARQL Update クエリを順番に使用して、オントロジー (上記の RDF ファイル) で定義されたクラスの個々を作成し、実行中の SPIN コンストラクターを刺激します。

最初の SPARQL Update クエリ (個々のデータ項目をインスタンス化し、必要に応じて解析コンストラクターを呼び出します... すばやく実行されます):

2 番目の SPARQL Update クエリ (最初のクエリによってインスタンス化されたデータ項目を結合する提案をインスタンス化し、コンプライアンス チェック コンストラクターを実行します... 非常に遅く、私のコンピューターでは約 20 秒実行されます):

この 2 番目のクエリの実行には、約 20 秒と長い時間がかかります。これは、他のコンプライアンス チェックと一致しません (この RDF には含まれていません)。この 1 つのルールは、他の 13 の同様のルール (主に文字列の解析と比較) の中から分離しました。

（正しいが遅れた）結果：

問題の SPIN コンストラクター (sxxicc:Pub7Proposalクラス用):

このコンストラクターが最新の PC (AMD クアッド コア 2.3 GHz、16 GB の物理メモリで Windows 8 を実行し、追加のアプリケーションの読み込みがほとんどない) で実行速度が非常に遅いのはなぜですか? 他のコンストラクターは、同じマシン上ですばやく実行され、同じ事実を使用して、明らかに同様のことを行います。

この例を実行したときの Java VisualVM Sampler の出力は次のとおりです。

RDF4J org.eclipse.rdf4j.common.concurrent.locks.LockManager$1.release() および org.eclipse.rdf4j.common.concurrent.locks.LockManager.createLock() が Self Time を支配します。どうして？？この時間の消費を避けるためにルールを書き直すためにできることはありますか?

ノート：

1. ?this は自動的に設定されるため、SPIN コンストラクターでは WHERE 句の最初のトリプルは必要ありません。ただし、このコンストラクターをワークベンチの SPARQL クエリ (Explore/Query) にコピーしてデバッグを容易にするために、これを含めます。また、CONSTRUCT 句を "SELECT DISTINCT *" に置き換え、コンストラクターのデバッグ用に WHERE 句をそのままにしておくと便利です。
2. このコンストラクターの WHERE 句の唯一の目的は、CONSTRUCT 句の固定エラー メッセージのエラー条件が存在することを示すグラフ パターンの一致を提供することです。WHERE 句から CONSTRUCT 句に引き継がれるバインディングはありませんが、WHERE 句は引き続き CONSTRUCT 句のトリプルのアサーションを制御します。

アップデート

コンストラクターから 1 つの FILTER と関連するトリプルを削除して、コンストラクターを変更しました。

これにより、TBC FE で以下に示すコンストラクターが生成されます。

同じ 2 つの SPARQL 更新クエリで同じテストを実行すると、2 番目のクエリの実行時間は 20 秒以上から 2 秒未満に非常に非線形に短縮されます。繰り返しますが、これは正しくないようです。

別の投稿で指摘したように、一部の SPIN コンストラクターが非常に限られたデータを実行するのに過度の時間を費やしているという問題があります。別のアプローチを取り、コンストラクターの実行をプロファイリングして、特にどこで過度の時間を費やしているかについての洞察を得ることができるかどうかを確認することにしました。

RDF4J サーバーでコンストラクターの実行をプロファイリングするにはどうすればよいですか? SPARQL update ( INSERT DATA) クエリを介してインスタンス化しています。RDF4J ワークベンチのシステム情報は次のとおりです。

を使用して、RDF4J サーバーが実行されている Tomcat サーバーのプロファイルを作成しようとしましたが、jvisualvm.exeあまり洞察が得られませんでした。理想的には、RDF4J 内のクラス/メソッド レベルに到達して、実行速度が遅い問題についてより詳細なリクエストを投稿したり、クエリ自体をより効率的にするように修正したりしたいと考えています。

Java Visual VM のバージョンは次のとおりです。

RDF4J は Apache Tomcat 8.5.5 で実行されています。

Tomcat の概要情報を確認できます。

モニター タブとスレッドも表示されます。

ただし、私が本当に見たいのはプロファイラーです。これにより、遅いクエリがどこで多くの時間を費やしているかを確認できます。Java 1.8用に調整されたプロファイラーがないため、調整でハングします。

このボックスの接続試行は無期限に持続します。これをキャンセルすると、実際には何も実行されず、Java VisualVM を強制終了する必要がある行き止まりのハングである [調整の実行] メッセージが表示されます。

Java Visual VM を強制終了し、再起動して [オプション] --> [プロファイリング] --> [キャリブレーション データ] を確認すると、Java 7 だけにキャリブレーション データがあることがわかります。

Tomcat を Java 7 で実行するように切り替えてみましたが、うまくいきました。

プロファイラーはTomcatを思いつきました：

ただし、Tomcat が Java 7 で実行されているときに RDF4J ワークベンチにアクセスしようとすると、ワークベンチを実行できませんでした。

だから、私はまだ立ち往生しています。RDF4J では、Tomcat が Java 1.7 ではなく、Java 1.8 で実行されている必要があるようです。Java 1.8 でプロファイルできません。

Java VisualVM に関するこの問題に関する他の投稿を見たことがありますが、適用可能な解決策の 1 つは、開発環境 (Eclipse など) ですべてを起動し、ターゲット コードが Java 1.8 で実行されたら、デバッガーのブレークポイントでプロファイラーを動的に呼び出すことです。 . 私はTomcatとRDF4Jでそれを行うように設定されておらず、ポインタが必要です. 私の意図は、Tomcat や RDF4J のコントリビューターになることではありませんでした (私のタスクではそれが許可されていないため... その時間に対して報酬が支払われることはありません) よりも、私の SPIN コンストラクター ( s) RDF4J サーバー クラスの観点から、gitub の RDF4J 開発者コミュニティに助けを求めてください。

Java VisualVM キャリブレーションをバイパスできますか? 失敗するキャリブレーション データを測定しようとする代わりに、Java VisualVM が使用するキャリブレーション ファイルまたはディレクトリをどこかにロードできますか? 絶対的なメトリックではなく、クラスの相対的な CPU 負荷にのみ関心があり、他のマシンの測定値と比較する必要はありません。

ありがとう。

RDF4J (以前のセサミ) フレームワークを使用して、リモートの GraphDB トリプル ストアに対して sparql クエリを実行しています。

これは、Graphdb サーバーの URL とリポジトリ ID を受け取る rdf4j HTTPRepository インターフェースを介して正常に機能しますが、sparlq エンドポイント URL をパラメーターとして受け取る rdf4j SPARQLRepository インターフェースを使用すると失敗します。

クエリを実行すると、クエリの検証で例外が発生します

"サーバー プロトコルの取得に失敗しました。このサーバーにはそのようなリソースはありません: http:///sparql?sparql?queryLn=SPARQL&query=",

sparql エンドポイントの URLと思われる場所http://<host:port>/sparqlはどこですか。これは sesame 2.7.8 と rdf4j M3 ライブラリの両方で発生しており、2 つの「すぐに使用できる」ライブラリ、つまり起動スクリプトで開始された、graphdb free 6.6.2 と 7.0.3 のインストールでも同様に発生しています。また、rdf4j SPARQLRepository インターフェイスを介して sparlq エンドポイントhttp://factforge.net/sparqlに接続しようとしたときにも発生します。これは、graphdb で実行されることがわかっています。

実際の sparql エンドポイントの URL は http:///sparql ではなく、graphdb のドキュメントに記載されていない別のものである可能性があります。誰もがこれを照らす可能性のある光に感謝します。

編集: Factforge の sparql エンドポイントに対して実行されたコード:

次の例外が生成されます。

ご協力ありがとうございました

Java アプリケーションで SPARQL および SPARQL Update クエリを解析する必要があります。rdf4j ライブラリを使用してこれを実行しようとしました。このライブラリは、クエリを解析する可能性 (例: QueryParserUtil.parseQuery(...) または SyntaxTreeBuilder.parseQuery(...)) と、更新を解析する可能性 (例: QueryParserUtil.parseUpdate(...) または SyntaxTreeBuilder.parseUpdateSequence(...) を提供します。 )))。しかし、それらの両方を解析できる方法はありません。したがって、クエリ文字列がクエリまたは更新を表しているかどうかを把握する必要があります。

更新文字列が parseQuery() メソッドに適用されると、ParseException がスローされます。これは逆の場合も同様です。もちろん、例外がスローされた場合は、常に他の方法を試すことができます。しかし、それは悪いプログラミング スタイルです。

queryString が更新または単純なクエリを表しているかどうかを確認するために使用できるメソッドが rdf4j ライブラリにありますか?

そうでない場合、更新とクエリの両方を解析するための他のソリューションはありますか?

私たちは rdf クエリの 90% でhttp://www.openrdf.org/contrib/lucenesail#検索を使用しています。ファイル/sesame-data/openrdf-sesame/logs/main.logのエラー「org.openrdf.query.QueryEvaluationException: java.util.ConcurrentModificationException」を修正する方法を誰かが知っているかどうかを確認したいと思います。エラーが発生すると、rdf サーバーの CPU 使用率が急速に上昇し、rdf サーバーが応答しなくなり、サーバーの再起動が必要になります。特定のクエリとは関係なく、ランダムに発生するようです。クエリを lucenesail クエリに変換するまでこれらのエラーは見られなかったので、エラーは lucenesail と rdf データの相互作用の使用に関連している可能性があるのではないかと思います。ご意見をお待ちしております。お時間をいただきありがとうございます。これは完全なエラー トレースです。

私はRDF4Jワークベンチを使用しています:

github の RDF4J リポジトリで GeoSPARQL への参照を確認できますが、現時点では実装されていないようです。RDF4J ワークベンチでのテストを設定するために、クリアされた「RDFS+SPIN サポートを使用したメモリ内ストア」リポジトリで次の SPARQL 更新クエリを実行しました。

これにより、1 つのファクトを持つリポジトリが作成されます。

ここで、次のクエリを使用してリテラル ポリゴンとのオーバーラップを検索しようとします。これにより、上記で設定した 1 つのファクトが検出されます。

このクエリは、レンダリングした HTML としてエラー結果を返します。

これは次のことを示しているようです。

1. このテストの設定で何か間違ったことをしました (もしそうなら、何をしますか?) または

2. RDF4J は GeoSPARQL をサポートしていません (少なくとも geof:sfIntersects 関数はサポートしていません)。

1および/または2またはその他の何か？

ありがとう。

GraphDB のドキュメントによると、基礎となる RDF4J データベースに対して直接プログラミングすることが可能です。2 つの別々のアプリケーションが同じデータベース ファイルに同時にアクセスできるというのは、私の直感に反します。同時書き込みを含め、これは正しく処理されていますか?

GraphDB は古い Sesame 2.9 バージョンを使用していると思います。最新の RDF4J 2.1 バージョンでファイル形式は変更されましたか? それとも、代わりにこの古い Sesame バージョンを使用する必要がありますか?

上記のすべてが正しければ、HTTP 接続と比較してパフォーマンスが大幅に向上すると思います。これを裏付けるテスト結果はありますか?

openrdf-sesame 環境を実行している Tomcat インスタンスがあります。デフォルトでは、openrdf-sesame データベース構成とデータの場所は %APPDATA%\aduna です。このデータが保存される場所を C:\aduna のようなカスタムに変更しようとしています。ドキュメントをオンラインで見ましたが、これがどこかの構成ファイルで定義されているか、ハードコードされた場所であるかは指定されていません。また、RDF4J が openrdf-sesame の新しい代替品であることもわかりましたか? データの保存先を指定した結果が得られるのであれば、アップグレードしてもかまいません。何か案は？