Piotr,
As ajs6f says, it is not possible to recreate your examples. We don't
know what' in Fuseki nor how it's configured. The fact some code is
commented out is also puzzling.
Fuseki can be run in the same process as the examples - this is very
useful for testing.
See org.apache.jena.fuseki.embedded.FusekiServer
eg.
FusekiServer server= FusekiServer.create()
.setPort(port)
.setLoopback(true)
.add("/ds", dataset)
.build();
server.start();
>> https://gist.github.com/PiotrNowara/586ebb3539bfbd0244bf7b7f606a64b8
>> https://gist.github.com/PiotrNowara/b3a84262ff0311d748efe03c7cc19d60
> dataset = DatasetFactory.create(
and also
> dataset = conn.fetchDataset()
This is a local, in-memory dataset.
In the conn.fetchDataset case it is copied out of the server.
...
dataset.begin(ReadWrite.WRITE);
executeSPARQLUpdate
This is only updating the local copy of the dataset.
The changes do not go back to Fuseki.
Use RDFConnection.update or UpdateExecutionFactor.createRemote.
Andy
On 21/12/17 14:50, ajs6f wrote:
In the first code example, you have commented out the line that actually runs
an update. That may be a typo, but now we don't know what you are actually
running.
In the second, you don't actually show the query you are running after a
commit, or how you run it.
In both cases, you include a deal of commented-out queries and OntModel
machinery.
Please, a complete and minimal example.
ajs6f
On Dec 21, 2017, at 5:52 AM, Piotr Nowara <[email protected]> wrote:
Here are gist links to the test classes I mentioned in my previous message:
https://gist.github.com/PiotrNowara/586ebb3539bfbd0244bf7b7f606a64b8
https://gist.github.com/PiotrNowara/b3a84262ff0311d748efe03c7cc19d60
Thanks,
Piotr
2017-12-21 10:38 GMT+01:00 Andy Seaborne <[email protected]>:
Attachments don't come through on the list. Please use a paste or gist.
I hope these examples are short and concise. Complete, Minimal Examples
please.
HTML messes up structured text but:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena</artifactId>
<version>3.5.0</version>
<type>zip</type>
</dependency>
should be:
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena-libs</artifactId>
<type>pom</type>
(your picked most of it up via the TDB dependency).
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-csv</artifactId>
<version>3.5.0</version>
<type>jar</type>
</dependency>
Is this necessary for your example?
Andy
On 21/12/17 09:08, Piotr Nowara wrote:
Hi,
I'm attaching two simple JAVA classes which I'm using for testing (there
are some comments there describing what results I got). The JAVA app and
Fuseki are on the same server. The FusekiTest3 is invoking
DatasetAccessorFactory.createHTTP() (so I think this is what you mean by
"remote" implementation) and FusekiTest2 is using
RDFConnection.fetchDataset (which is the slowest operation).
The GRAPH clause gives me expected results (returns the newly added
triple), but why FROM should be wrong?
GRAPH access a named graph.
FROM describes a dataset to be queried.
We use FROM clause in many of our queries and we didn't notice anything
wrong/unexpected when using TDB dataset. With Fuseki FROM seems to return
the content of the default graph and not the graph indicated by the FROM
<named-graph-IRI>.
Both tests fail to preserve the newly added triple.
Here are the maven artifacts I'm using for the client app (maybe I should
download some Fuseki specific JAR?):
<dependency>____
<groupId>org.apache.jena</groupId>____
<artifactId>jena-tdb</artifactId>____
<version>3.5.0</version>____
<type>jar</type>____
</dependency>____
<dependency>____
<groupId>org.apache.jena</groupId>____
<artifactId>apache-jena</artifactId>____
<version>3.5.0</version>____
<type>zip</type>____
</dependency>____
<dependency>____
<groupId>org.apache.jena</groupId>____
<artifactId>jena-csv</artifactId>____
<version>3.5.0</version>____
<type>jar</type>____
</dependency>
Thanks,
Piotr
2017-12-20 16:52 GMT-05:00 Andy Seaborne <[email protected] <mailto:
[email protected]>>:
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
<http://www.myGraph.com/portal>");
Model defaultM = accessor.getModel();
Model external =
accessor.getModel("http://www.myGraph.com/external
<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]
<mailto:[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/
<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
