Hi,
thanks for answering so quickly.
I tried two different solutions:
1) Merging models obtained using DatasetAccessor
Model portal = accessor.getModel("http://www.myGraph.com/portal";);
Model defaultM = accessor.getModel();
Model external = accessor.getModel("http://www.myGraph.com/external
");
dataset = DatasetFactory.create(external.add(portal).add(defaultM));
2) RDFConnection - works much slower than the method above (which is not
surprise since you said it can affect the performance negatively)
I noticed two confusing issues when working with those datasets:
Issue 1: SPARQL SELECT would produce diferent results depending on where
the named graph IRI was defined in the query (FROM clause vd. WHERE clause):
SELECT * FROM <http://www.myGraph.com/portal> WHERE {?s ?p ?o}
behaves differently than:
SELECT * WHERE {GRAPH <http://www.myGraph.com/portal> {?s ?p ?o}}
Issue 2: After ading a triple using INSERT DATA statement the triple was
present in the graph but dissapeard after closing the connection despite
the fact I did dataset.commit()
We didn't experience those issues when working with a "local" Jena TDB. For
now we will probably stick to the TDB version, but someday we would need
the multi-user functionality Fuseki offers anyway. It seems that we will
have to revise all our SPARQL queries to make it Fuseki-ready which means
migrating from TDB to Fuseki will be more difficult for us than migrating
from another triple-store we were using in the past to Jena TDB that went
very smoothly. I'm still wondering whether or not I'm missing something
regarding Fuseki.
Thanks,
Piotr
2017-12-20 5:40 GMT-05:00 Andy Seaborne <[email protected]>:
>
>
> On 19/12/17 21:41, Piotr Nowara wrote:
>
>> Hi,
>>
>> I got a TDB powered JAVA app which is issuing a lot of SPARQL UPDATES and
>> SELECTS (most of them accessing multiple named graphs at once). My app
>> obtains a Jena connection using this simple API call:
>>
>> this.dataset = TDBFactory.createDataset(this.storagePath);
>>
>> Then this dataset object is used to run SPARQL UPDATES and SELECTS.
>>
>> I would like to replicate this solution using Jena Fuseki but I wonder if
>> that’s possible since the DatasetAccessor class provides only methods to
>> access separate named graphs. What I need is a database/dataset level
>> access. The Fuseki database should be persistent.
>>
>> I'd be grateful for any clue or code example.
>>
> Query and update work on datasets.
>
> RDFConnection
> http://jena.apache.org/documentation/rdfconnection/
> is the combined interface to both local and remote datasets and includes
> some operations that include whole GET/POST/PUT of datasets
>
> RDFConnection.connect("http:/localhost:3030/myDataset")
>
> for migration from local, note that data is copied across the network when
> doing dataset operations. RDFConnection has whole dataset operations in the
> style of SPARQL Graph Store Protocol (=DatasetAccessor) operations.
> If your graphs and dataset are large is maybe not what you want.
>
> Because this across the network, the semantics of lcoal and remote are not
> identical unless you ask the local mode to do copying:
>
> RDFConnection.connect(datasets, Isolation.COPY)
>
> which is a good simulation for a local/remote (and slower for local than
> no COPY)
>
> Andy
>
>
>>
>> Thanks,
>>
>> Piotr
>>
>>
