On 20/12/17 18:28, Piotr Nowara wrote:
Hi,
thanks for answering so quickly.
I tried two different solutions:
1) Merging models obtained using DatasetAccessor
Which implementation of DatasetAccessor? (local or remote?)
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)
and this is a remote RDFConnection? (otherwise it should perform, with
default Isolation, the same)
I noticed two confusing issues when working with those datasets:
Issue 1: SPARQL SELECT would produce diferent results
in what way different?
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}}
GRAPH is correct, FROM is wrong.
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()
Complete example?
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
