問題タブ [tdb]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
rdf - 大文字と小文字を区別せずに文字列リテラルを効率的に照合する SPARQL クエリの書き方
私は Jena ARQ を使用して、rdfs ラベルに基づいて概念に関連付けられた型を見つけるために、Jena TDB から読み取られる大規模なオントロジーに対して SPARQL クエリを作成しています。
これは非常にうまく機能し、実際には非常に高速です (<1 秒)。残念ながら、用語によっては、大文字と小文字を区別しない方法でこのクエリを実行する必要があります。たとえば、ラベル"Tylenol"
はオントロジーにありますが、ない"tylenol"
ため、次のクエリは空になります。
次のように、FILTER 構文を使用して、このクエリの大文字と小文字を区別しないバージョンを作成できます。
しかし今では、クエリが完了するまでに 1 分以上かかります。大文字と小文字を区別しないクエリをより効率的な方法で作成する方法はありますか?
java - 空のフィールドになる Jena TDB 挿入ステートメント
Jena API を使用して、Jena TDB でトリプルを挿入および更新しています。私の設計では、挿入操作のそれぞれがトランザクション コントロール内にあるようになっています。例えば:
この後、READ トランザクションを使用して TDB にクエリを実行すると、一部のエントリ (主語、述語、または目的語) が空であることがわかります。ネストされたトランザクションを使用していないのに、なぜこのように動作するのですか?
コードを挿入
クエリコード
jena - Jena/TDB アーカイブのサイズ制限
Jena TDB を使用して、大きなプロジェクト (多くのメタデータを含む) に取り組んでいます。約 1 か月前に、メモリに関する問題が突然発生しました。プログラムは何か月も正常に動作しており、変更は行われていませんでした。これ以上データをアップロードできません。
この問題に数週間取り組んできましたが、一部の.dat
ファイルのサイズが 16Gb を超えているために問題が発生していると考えています。TDB に使用されるインデックス システムでは、各インデックスに 64 ビットが使用されていることがわかりました。タイプに 8 ビット + ディスク割り当てに 44 ビット + vnode に 12 ビットです。44 ビットで 16GB を管理できますが、ここでメモリの問題が発生すると考えています。
私たちが正しいか教えてください。もしそうなら、最善の解決策を教えていただけませんか?
jena - テキスト検索を実装するための既存の Apache Jena TDB の Lucene インデックスの作成
大規模な Apache Jena TDB があります。新しいテキスト検索機能で使用するために、Apache Jena 2.10.2 を使用して Lucene インデックスを構築したいと考えています。ドキュメントに従うのは難しいと思います。
最初にコードで構成を使用しようとしましたが、依存関係に問題がありました。lecene-core と solr-solrj を組み合わせると、特定の「classNotFound」エラーまたは「StandardAnalyzer overrides final method tokenStream」エラーが発生します。コードの例:
唯一の解決策は Text Dataset Assembler を作成することだと思いますが、これをコードで作成することについてアドバイスがある場合は、その方法で行うことをお勧めします。
rdf - 奇妙な Apache Jena OPTIONAL 動作
Maven リポジトリの Jena (TDB 0.10.1、CORE/ARQ 2.10.1) を使用しています。このファイルをインポートしました:
私は今、このモデルを次のようにクエリしようとしています:
残念ながら、これは空の結果セットを返します。wgs パターンを別の OPTIONAL に移動すると、正しい結果が得られます。
これは Jena のバグですか、それともクエリが間違っていますか? 乾杯、ダニエル
java - Jena ARQ/TDB クエリの最適化
約 500k のトリプルを含むかなり小さなグラフがあります。また、stats.opt ファイルを生成し、かなり高速なコンピューター (クアッド コア、16 GB RAM、SSD ドライブ) でコードを実行しました。結果セットを反復処理します。結果セットには約 15000 行あり、反復には 4 秒かかります。これはエンドユーザーには受け入れられません。クエリの実行にはわずか 90 ミリ秒しかかかりません (実際の作業はカーソルの反復によって行われるのでしょうか?)。なぜこれが遅いのですか?結果セットの反復を高速化するにはどうすればよいですか?
クエリは次のとおりです。
(これらの bnode を照会するより良い方法はありますか?hasNearbyPark、?hasNearbySupermarket)
そして、クエリを実行するコード:
owl - owl:布石輸入
私はここが初めてで、このようなものを検索しましたが、答えが見つかりませんでした. そこで私の質問です: Fuseki は owl:imports をどのように処理しますか?
詳細: さまざまな owl ファイルでオントロジーのセットを定義しました。subDomainA.owl
それらのうちの 2 つをと と呼びましょうsubDomainB.owl.
これらのオントロジーを「結合」するために、他のオントロジーをインポートする単一のフクロウ ファイルを定義しました。completeDomain.owl
それを、 owl:importssubDomainA.owl
と呼びましょうsubDomainB.owl
。で明示的に宣言されたステートメントがいくつかありますcompleteDomain.owl
。sweetAll.owl
明確でない場合は、SWEETのようなものです。
Fuseki を使用して、これらのフクロウ ファイル (RDF/XML 構文を使用) を TDB にインポートする必要があります。これらの輸入はどのように処理されますか? completeDomain.owl
つまり、デフォルトのグラフとsubDomainA.owl
それぞれのグラフにロードする必要がありますsubDomainB.owl
。Fuseki はインポートを「理解」し、それらすべてを一度にクエリできるようにしますか?
使い方tdb:unionDefaultGraph
は同じですか?completeDomain.owl
subDomain オントロジーで宣言されたエンティティを使用するで宣言されたステートメントはどうなりますか? tdb:unionDefaultGraph
また、とUnion Modelの違いもわかりませんでした。
ご覧のとおり、私は少し混乱しています。助けていただければ幸いです。
sparql - tbloader と SPARQL INSERT - 名前付きグラフで動作が異なるのはなぜですか?
ARQ、TDB、Named Graphs のコマンドライン ツールの接続に奇妙な動作があります。名前付きグラフで tdbloader を介してデータをインポートする場合、SPARQL SELECT クエリの GRAPH 句を介してクエリすることはできません。ただし、このクエリは、SPARQL INSERT を使用して同じグラフにデータを挿入する場合に可能です。
次のアセンブラ記述ファイルtdb.ttlがあります。
ファイルdata.ttlにデータセットがあります。
ここで、tdbloader を使用してこのデータを挿入し、次に SPARQL INSERT を使用して別のトリプルを名前付きグラフデータに挿入しています。
これで、次の方法で SPARQL を使用してデータをクエリできます。
すべてが完璧に見えます。しかし今、私はこの特定の名前付きグラフデータのみを照会したいと思います:
tdbloader からインポートされたデータが見つからないのはなぜですか? このクエリの何が問題になっていますか? 両方のインポートから結果を取得するにはどうすればよいですか?
multithreading - 同じデータセット ファイルに同時に書き込むことはできますが、異なる名前のグラフ (各スレッドが異なる名前のグラフに書き込む) に書き込むことはできますか?
Jena の TDB では、複数の「名前付きグラフ」を含むことができる「データセット」(ディレクトリで指定) によってデータが編成されているようです。
このようなデータをクエリする同時実行ポリシーに関して、同時実行に関連して私が見つけた唯一のドキュメントは、TDB ドキュメントの次の文TDB Java APIです。
同時アクセスのための複数リーダーまたは単一ライター (MRSW) ポリシーを使用すると、トランザクションなしでデータセットを直接操作できます。
ただし、そのような MRSW ポリシーの粒度についてはよくわかりません。データセット全体ですか、それともデータセット内の個々の名前付きグラフですか?
編集:より具体的には、私の要件は、読み取り操作なしで、異なる名前付きグラフ (各スレッドが異なる名前付きグラフに書き込む) に対して書き込みのみの更新を行いたいということですが、可能でしょうか? または、一度に 1 つのスレッドを更新する必要がありますか。