2

データ型プロパティの範囲から実行時に既知の特定のデータ型を持つ DatatypeProperty の値/リテラル​​を追加する目的で、既存のオントロジー (OntModel) に個人を追加しようとしています。私の OntModel は、データセットにリンクされた TDBStore に支えられています (そのため、OntModel に加えられた変更はすべて、私の TDBStore/データセットに反映されます)。個人は次のコードに従って追加されます。

Individual ind =oc.createIndividual(namespace+nameOfIndividual); // oc is OntClass object
Literal l = ontModel.createTypedLiteral("1230",dp.getRange().getURI()); //dp is a DatatypeProperty object
ind.addLiteral(dp,l);

コードが実行されると、リテラルが追加され、sparql クエリが追加されます。

"SELECT *  WHERE {  ?s :ABCConstant ?o }";  //:ABCConstant is the datatypeProperty for which the literal is added by the above code.

次の結果が得られます。

------------------------------------------------------------------------------------------------------------------------------------------------
| s                                                                                     | o                                                    |
================================================================================================================================================
| <http://www.semanticweb.org/ontologies/2012/10/Ontology.owl#individual1ABCDConstant>    | "10000.0"^^<http://www.w3.org/2001/XMLSchema#int> |
| <http://www.semanticweb.org/ontologies/2012/10/Ontology.owl#individual2ABCDConstant> | 1230                                                 |
------------------------------------------------------------------------------------------------------------------------------------------------

しかし、2回目の実行で同じクエリを使用しようとすると(今回は個人を作成せずに)、プログラムが結果を表示/アクセスしようとすると、次の例外が発生します:

Exception in thread "main" com.hp.hpl.jena.tdb.base.file.FileException: ObjectFileStorage.read[nodes](181624)[filesize=248062][file.size()=248062]: Impossibly large object : 1634628966 bytes > filesize-(loc+SizeOfInt)=66434
    at com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:346)
    at com.hp.hpl.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:78)
    at com.hp.hpl.jena.tdb.nodetable.NodeTableNative.readNodeFromTable(NodeTableNative.java:178)
    at com.hp.hpl.jena.tdb.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
    at com.hp.hpl.jena.tdb.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:74)
    at com.hp.hpl.jena.tdb.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:103)
    at com.hp.hpl.jena.tdb.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:74)
    at com.hp.hpl.jena.tdb.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:55)
    at com.hp.hpl.jena.tdb.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:67)
    at com.hp.hpl.jena.tdb.lib.TupleLib.triple(TupleLib.java:126)
    at com.hp.hpl.jena.tdb.lib.TupleLib.triple(TupleLib.java:114)
    at com.hp.hpl.jena.tdb.lib.TupleLib.access$000(TupleLib.java:45)
    at com.hp.hpl.jena.tdb.lib.TupleLib$3.convert(TupleLib.java:76)
    at com.hp.hpl.jena.tdb.lib.TupleLib$3.convert(TupleLib.java:72)
    at org.apache.jena.atlas.iterator.Iter$4.next(Iter.java:317)
    at org.apache.jena.atlas.iterator.Iter$4.next(Iter.java:317)
    at org.apache.jena.atlas.iterator.Iter$4.next(Iter.java:317)
    at org.apache.jena.atlas.iterator.Iter.next(Iter.java:915)
    at com.hp.hpl.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:94)
    at com.hp.hpl.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:94)
    at com.hp.hpl.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:55)
    at com.hp.hpl.jena.graph.compose.CompositionBase$2.hasNext(CompositionBase.java:94)
    at com.hp.hpl.jena.util.iterator.NiceIterator$1.hasNext(NiceIterator.java:103)
    at com.hp.hpl.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIterTriplePattern$TripleMapper.hasNextBinding(QueryIterTriplePattern.java:151)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:112)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:81)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:112)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIterBlockTriples.hasNextBinding(QueryIterBlockTriples.java:64)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:112)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:40)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:112)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:40)
    at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:112)
    at com.hp.hpl.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:75)
    at com.hp.hpl.jena.sparql.resultset.ResultSetMem.<init>(ResultSetMem.java:97)
    at com.hp.hpl.jena.query.ResultSetFactory.makeRewindable(ResultSetFactory.java:420)
    at com.hp.hpl.jena.sparql.resultset.TextOutput.write(TextOutput.java:149)
    at com.hp.hpl.jena.sparql.resultset.TextOutput.write(TextOutput.java:132)
    at com.hp.hpl.jena.sparql.resultset.TextOutput.write(TextOutput.java:120)
    at com.hp.hpl.jena.sparql.resultset.TextOutput.format(TextOutput.java:67)
    at com.hp.hpl.jena.query.ResultSetFormatter.out(ResultSetFormatter.java:122)
    at com.hp.hpl.jena.query.ResultSetFormatter.out(ResultSetFormatter.java:74)
    at com.hp.hpl.jena.query.ResultSetFormatter.out(ResultSetFormatter.java:65)
    at senseXploreApi.SparqlQuery.sparqlQuery(SparqlQuery.java:82)
    at senseXploreApi.TryMain.main(TryMain.java:39)

注: 追加された個人を表示する他のクエリは正常に実行されます。ただし、「SELECT * WHERE { ?s ?o 1230}」のようなクエリでも同じエラーが発生します。

また、次のようなクエリ: "SELECT * WHERE { ?s ?o 10000.0}" OR "SELECT * WHERE { ?s ?o 10000}" エラーは発生しませんが、結果には何も返されません。

次のステートメントを使用して、リテラル 10000 が追加されました。

ind.addLiteral(opp,new Integer(10000));

私を助けてください!!どこが間違っているのですか..個人を作成するために使用される手順は間違っていますか? もし、そうなら!それでは、実行時に既知の特定のデータ型を持つリテラルを追加する他の可能な方法は何でしょうか?

4

1 に答える 1

3

このImpossibly Large Objectメッセージは、TDB データベースが (部分的に) 破損していることを意味します。具体的には、データベースの内部識別子と元の RDF 用語との間をマッピングするノード テーブルの一部が破損しています。ノード テーブルのその部分に触れるクエリにはこのエラーが表示されますが、他のクエリは問題なく実行される可能性があります。

データベースを回復する唯一の方法は、元のデータから再構築することです。破損が発生すると、修復することはできません。

腐敗はさまざまな方法で発生する可能性がありますが、最も一般的なものは次のとおりです。

  • 非トランザクションの方法で TDB にアクセスし、sync()変更を行った後にデータセットの呼び出しに失敗する (または、変更を行っclose()た後に呼び出しに失敗する可能性が高いModel)
  • 複数の JVM が同じ TDB データセットに同時にアクセスする場合、アプリケーションでこれが必要な場合は、Fuseki などのサーバーを使用してデータベースへのアクセスを集中化します。

TDB をトランザクション的に使用する方法についてはTDB トランザクションを参照してください。また、TDB データベースを複数の JVM に同時に公開する必要がある場合は、 Fusekiのドキュメントを参照してください。

于 2013-10-28T09:34:04.907 に答える