問題タブ [named-graphs]

私は最近、 SPARQL 1.1 フェデレーション拡張機能のワーキング ドラフトに出くわし、名前付きグラフを使用してこれが既に可能であるかどうか疑問に思いました (前述のドラフトの有用性を損なうものではありません)。

Named Graphs についての私の理解は少しぼんやりしていますが、仕様を読んでわかった唯一のことは、クエリ時の他のグラフとの関連での合併、非合併に関する規則であるということだけです。これは私の理解を完全に満足させるものではないので、私の質問は次のとおりです。

次のクエリがあるとします。

クエリ プロセッサ/エンドポイントが、名前付きグラフのコンテキストで次のことを行うことができる、または行うべきであると想定するのは合理的ですか。

1. 名前付きグラフがローカルに存在することを確認します

2. その後、次の操作を実行しない場合 (上記のクエリの場合、2 番目の名前付きグラフを使用します)

   GET /sparql/?query=EncodedQuery HTTP/1.1 ホスト: www.autotrader.co.uk ユーザーエージェント: my-sparql-client/0.1

EncodedQuery が節に 2 番目の名前付きグラフのみを含み、FROM NAMED節WHEREに応じて節が修正されるGRAPH場合 (たとえば、 aGRAPH <http://www.vw.co.uk/models/used> {...}が使用されている場合)。

上記を実行できない場合のみ、次のいずれかを実行します。

また

3. 適切な検索結果を返します。

OFFSET明らかにとLIMITの周りにいくつかの追加の考慮事項があるかもしれません

また、はるか昔、はるかかなたの銀河系で、SPARQL エンドポイントのデフォルト グラフは、次の規則に従って名前付きグラフにする必要があることを読んだことを覚えています。

For: http://www.vw.co.uk/sparql/には、デフォルトのグラフを表す http://www.vw.co.uk の名前付きグラフが存在する必要があるため、上記のロジックにより、すでに名前付きグラフを使用して SPARQL エンドポイントをフェデレーションできます。

私が尋ねる理由は、上記の例のドメイン間でフェデレーションの促進を開始したいからです。標準を待つ必要はありません。将来。

• インメモリrdfストアでゴマHTTPAPIを使用しています。
• コンテキスト/名前付きグラフにデータ/トリプルをロードします
• 名前付きグラフ/コンテキストを使用してクエリを実行します

2つの質問があります：

• 同じリポジトリ内で、グラフノードを異なる名前のグラフ間で共有できますか？

  • 私のユースケースは、graph1からデータをフィルタリングし、graph2に配置することです。では、ノードはgraph1とgraph2で共有されますか？

• GET操作中に名前付きグラフをO（1）操作で検索していますか？または、名前付きグラフを使用することのパフォーマンス上の利点はありますか？

Virtuosoにいくつかの名前付きグラフが保存されていますが、提供されたリストから最も多くの用語に一致するグラフを見つけたいと思います。

私のクエリはプログラムで作成され、次のようになります。

各用語は別のUNION句になります。

これを行うためのより良い方法はありますか？クエリは長くて醜く速くなり、用語が多すぎるとVirtuosoは文句を言います。

SPARQL コンストラクト クエリを使用して、既存のグラフから新しい名前付きグラフを作成しようとしています。クエリを実行しているデータベースにはhttp://graph.com/old、既存の名前付きグラフが含まれています。Jena TDBをデータベースとして使用しており、 Jena Fusekiエンドポイントを介してアクセスしています。以下のクエリでエラーが発生します。

CONSTRUCT ブロックからグラフ ステートメントを削除すると、クエリは完全に機能しますが、デフォルトのグラフではなく、指定した名前付きグラフにトリプルを配置したいと考えています。

私が見つけた限りでは、CONSTRUCT に関する SPARQL 1.1 セクションには、名前付きグラフの構築については何も書かれていません。これを行う方法はありますか？

ARQ、TDB、Named Graphs のコマンドライン ツールの接続に奇妙な動作があります。名前付きグラフで tdbloader を介してデータをインポートする場合、SPARQL SELECT クエリの GRAPH 句を介してクエリすることはできません。ただし、このクエリは、SPARQL INSERT を使用して同じグラフにデータを挿入する場合に可能です。

次のアセンブラ記述ファイルtdb.ttlがあります。

ファイルdata.ttlにデータセットがあります。

ここで、tdbloader を使用してこのデータを挿入し、次に SPARQL INSERT を使用して別のトリプルを名前付きグラフデータに挿入しています。

これで、次の方法で SPARQL を使用してデータをクエリできます。

すべてが完璧に見えます。しかし今、私はこの特定の名前付きグラフデータのみを照会したいと思います:

tdbloader からインポートされたデータが見つからないのはなぜですか? このクエリの何が問題になっていますか? 両方のインポートから結果を取得するにはどうすればよいですか?

私のRDFストアには次のような状況があります:

名前付きグラフ: A

名前付きグラフ: B

名前付きグラフ: C

ここで、O1 がトリプルにあるすべてのグラフを検索し、それら 3 つのグラフ + トリプルを A+B+C という名前の新しいグラフに格納する SPARQL クエリを定義したいと考えています。

新しい名前付きグラフ: A+B+C

Construct または insert Into を使用すると、トリプルからグラフを作成する方法しかわかりませんでした。グラフを含むグラフを作成する方法ではありませんか?

これは可能ですか？

タンク・ユー

私は現在、SPARQL 1.1 含意レジームについて文書化/テストを行っており、推奨事項には次のように繰り返し述べられています。

スコーピング グラフは、アクティブ グラフと同等のグラフです。

しかし、それはアクティブなグラフが参照しているものを指定していません:それはクエリで使用されるデータセットですか? ストア内のすべてのグラフの和集合?

これを判断するためのテストとして、<http://www.example.org/>RDF スキーマと直接型推論ストア (v2.7.14) を使用してセサミ メモリ ストアでこのグラフを URI 化しました。

私は次のクエリを試しています（つまり、デフォルトのグラフを使用して推論エンジンを使用することを意味します）

予想どおり、3 つのインスタンスすべてが返されます

クエリ中：

返品のみ

上記の状況下では、両方の結果が同じであってはなりませんか?

データとスキーマがストア内の 2 つのグラフ ( と のよう<urn:rdfs-schema>に<urn:data>、またはさらに多くのグラフに散らばっている) に分割され、クエリが両方のグラフ (またはスキーマ関連のグラフのサブセット) をデフォルトのグラフの代わりに FROM 句を使用しますか?

推論はストア全体でグローバルにする必要がありますか、それともクエリ データセットに依存しますか?

それとも、これを実装依存の問題にするほど推奨が緩いのでしょうか?

ライトをありがとう、

最大。

EDITこの質問は、SPARQL 1.1 含意レジームと FROM 句を使用したクエリにリダイレクトされています (フォローアップ)

これは、 SPARQL 1.1 含意レジームと FROM 句を使用したクエリからのフォローアップの質問です。

私は現在、SPARQL 1.1 含意体制について文書化/テストを行っており、推奨事項には次のように繰り返し述べられています。

スコーピング グラフは、アクティブ グラフと同等のグラフです...

したがって、推論スコープ グラフはクエリに依存しているように見えます。

問題は、スコープ グラフがクエリのデータセット (FROM/FROM NAMED 句) に由来するのか、それとも評価されるトリプル パターンの実際の現在アクティブなグラフ コンテキストを参照しているのかということです。

以下のグラフで

次のクエリは何を返す必要がありますか (たとえば、ここでは RDFS 含意体制の下で)、推奨事項に従っていますか?

3 つのリソースすべてを取得する必要があります:

あるいは単に

トリプル パターンのアクティブなグラフは NAMED グラフにスコープされているため、推論の公理はデフォルトのグラフに「配置」されていますか?

あなたの洞察をありがとう、

最大。

カスタム Stardog ルールを試しています。カスタム ルールは基本的に次のようになります。

次の Java コードを含むこの ttl ファイルをアップロードしました。

ルールを別のグラフに保持したいので、ルールのトリプルをhttp://url/rulesグラフにロードしました。tag:stardog:api:context:defaultStardog で表されるデフォルトのグラフには、オントロジーの公理が含まれています。次の SPARQL クエリを使用すると、Stardog ルールが期待どおりに機能します。

おそらく、今では何が問題なのか疑問に思っているでしょう。FROM 句と FROM NAMED 句の理解が間違っていると思います。クエリをFROM <http://url/rules>除外すると、クエリからの結果は期待できません。それでも、元のクエリと同じように結果が得られます。これはどのように可能ですか？これらの条項について、私は次のように考えています。

• FROM <tag:stardog:api:context:default>: デフォルトのグラフのオントロジー公理を使用します
• FROM <http://url/rules>: この特定のクエリでルールを使用します
• FROM NAMED <http://url/datasource>: クエリが必要な実際のデータ

SPARQL クエリから 2 番目の FROM 句を除外すると、正しい結果が得られるのはなぜですか? 参考までに、私はいつも推理系SLを使っています。

@ user1538695の回答後に編集

スキーマ (TBox) にルールを永続化する場合でもFROM <tag:stardog:api:context:default>、クエリを追加する必要があります。名前付きグラフを 1 つだけクエリし、推論のためにスキーマを使用したい。これは、デフォルトのグラフ (スキーマ) を明示的に言及しなくても可能ではないでしょうか? これは私の現在のクエリがどのように見えるかです: