1

モデルをトリプル ストア (永続化) に保存しています。あるドキュメント名に関連するすべての個人を選択したいと考えています。

私は2つの方法でそれを行うことができます

1) SPARQL リクエスト:

 PREFIX base:<http://example#>
  select ?s2 ?p2 ?o2 
    where {
      {?doc base:fullName <file:/c:/1.txt>; ?p1 ?o1
  } UNION { 
    ?s2 ?p2 ?o2 ;
    base:documentID ?doc    } 
  }

質問: ResultSet から Jena のモデルを作成する方法は?

2) StmtIterator stmtIterator = model.listStatements(...)

model.listStatements(...) 操作を数回使用する必要があるというこのアプローチの問題:

a) ドキュメント名でドキュメント URI を取得する

b) このドキュメント URI に関連する個人 ID のリストを取得する

c) 最後に - 個人のコレクションを取得する

パフォーマンスが心配です - model.listStatements(...) を 3 回実行します - 多くのデータベース要求。

または、モデルの作成中にデータベースからすべてのデータがメモリに読み込まれます(私はそれについて疑問があります):

     Dataset ds = RdfStoreFactory.connectDataset(store, conn);
     GraphStore graphStore = GraphStoreFactory.create(ds) ;

?

4

1 に答える 1

0

少し立ち止まって、自分がやろうとしていることについてもっと明確に考える必要があります。sparql クエリが修正されると (以下を参照)、結果セットに対してイテレータを完全に適切に生成し、探している各ドキュメントのプロパティを提供します。s2具体的には、それぞれの、p2およびo2結果セット内の各値に対して 1 つのバインディング セットを取得します。それはあなたが指定するときにあなたが求めるものですselect ?s2 ?p2 ?o2。そして、それは通常あなたが望むものです: 通常、何らかの方法でそれらを処理するためにトリプルストアからいくつかの値を選択します (たとえば、UI のリストにレンダリングするなど)。SPARQL のおかげで、クエリで結果セットではなくモデルを返すことができますコンストラクトquery または SPARQL describe。ただし、モデル内のリソースを反復処理する必要があるため、それほど先に進むことはできません (モデルが小さく、メモリ内にあることを除いて)。

ちなみに、クエリは改善できます。変数p1とo1クエリエンジンは、それらを使用することはなく、ユニオンも必要ないため、無駄な作業を行います。修正されました。クエリは次のようになります。

PREFIX base:<http://example#>

select ?s2 ?p2 ?o2 
where {
  ?doc base:fullName <file:/c:/1.txt> .
  ?s2 base:documentID ?doc ;
      ?p2 ?o2 .
}

Java からクエリ、選択、記述、または構築を実行するには、Jena のドキュメントを参照してください。

モデル API を使用して、クエリと同じ結果を効率的に得ることができます。例: (未テスト):

Model m = ..... ; // your model here
String baseNS = "http://example#";
Resource fileName = m.createResource( "file:/c:/1.txt" );

// create RDF property objects for the properties we need. This can be done in
// a vocab class, or automated with schemagen
Property fullName = m.createProperty( baseNS + "fullName" );
Property documentID = m.createProperty( baseNS + "documentID" );

// find the ?doc with the given fullName
for (ResIterator i = m.listSubjectsWithProperty( fullName, fileName ); i.hasNext(); ) {
  Resource doc = i.next();

  // find all of the ?s2 whose documentID is ?doc
  for (StmtIterator j = m.listStatements( null, documentID, doc ); j.hasNext(); ) {
    Resource s2 = j.next().getSubject();

    // list the properties of ?s2
    for (StmtIterator k = s2.listProperties(); k.hasNext(); ) {
      Statement stmt = k.next();
      Property p2 = stmt.getPredicate();
      RDFNode o2 = stmt.getObject();

      // do something with s2 p2 o2 ...
    }
  }
}

スキーマの設計により、これは必要以上に複雑になることに注意してください。たとえば、ドキュメントのフル ネーム リソースにbase:isFullNameOfプロパティがある場合、単純にルックアップを実行してdoc. doc同様に、なぜとを区別する必要があるのか​​が明確ではありs2ません: 単純にドキュメント プロパティをdocリソースに添付しないのはなぜでしょうか?

最後に: いいえ、データベース接続を開いても、DB 全体がメモリにロードされるわけではありません。ただし、特に TDB は、クエリをより効率的にするために、グラフの領域のキャッシュを広範囲に使用します。

于 2012-07-27T07:46:22.043 に答える