On 17 June 2015 at 14:13, Andy Seaborne a...@apache.org wrote:
On 17/06/15 10:16, Rick Moynihan wrote:
Hi Andy,
Thanks for raising JENA-963 for me - I'll raise the issues directly in the
future. Sometimes it's hard to know whether things are intended (or at
least accepted) behaviours
On 18.06.15 00:55, Andy Seaborne wrote:
Hi Andy,
If you are not seeing the default graph as the union of the two named
graphs, then something is amiss with the setup. How are you setting
unionDefaultGraph? (and which version of code are you running?)
So turns out the config file I was
Hi group,
I can't seem to understand the new structure of Fuseki 2.0 configuration.
In the documentation I read:
https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html
The directory FUSEKI_BASE/configuration/ with one data service
assembler per file (includes endpoint details
On 18.06.15 00:55, Andy Seaborne wrote:
Hi Andy,
This is TDB?
yes
If your turn unionDefaultGraph on, then the stored default graph is not
visible in a query (it can be accessed via a special graph name that is
not included in the union of named graphs) so I'd expect it to be
inaccessible.
On 18/06/15 10:34, Neubert, Joachim wrote:
The culprit for the long execution time on the remote server seems to
be the SERVICE clause. Even when it points to an in-memory endpoint
on the same server, execution took more than 400 sec. After loading
the very same data into a named GRAPH on the
Thanks for the clarification, Andy! Apparently, I messed things up due to an
aborted, yet still running query on the local host.
The culprit for the long execution time on the remote server seems to be the
SERVICE clause. Even when it points to an in-memory endpoint on the same
server,
