instanceof versus canAs

[Steve Vestal]

In some places I use e.g. (resource instanceof Individual) , but in 
others it seems I need resource.canAs(Individual.class).  If you have 
brief guidelines on when to use what, I would appreciate that.  A 
specific case is punning in an OntModel.  Is that a case where 
canAs(Individual.class) and canAs(OntClass.class) should be used?

Re: TDB2 Exception in initialisation

[Enrico . Daga]

Hi Andy,

Many thanks for the quick reply -- in the end, it was a misplaced ARQ.init() -- 
the version of this project is 3.13.1 -- I should have checked and mentioned 
that. We will need to upgrade it at some point.

Best wishes,

Enrico


--
Enrico Daga, PhD

www.enridaga.net | @enridaga

SPARQL Anything http://sparql-anything.cc
Polifonia http://polifonia-project.eu
SPICE http://spice-h2020.eu
Open Knowledge Graph http://data.open.ac.uk

Senior Research Fellow, Knowledge Media Institute, STEM Faculty
The Open University
Level 4 Berrill Building, Walton Hall, Milton Keynes, MK7 6AA
Direct: +44 (0) 1908 654887

From: Andy Seaborne 
Sent: 25 August 2023 12:31
To: users@jena.apache.org 
Subject: Re: TDB2 Exception in initialisation



On 25/08/2023 09:04, Enrico.Daga wrote:
> Hi,
>
> I am having a strange error while attempting to initialise a TDB2 dataset:
>
> TDB2Factory.connectDataset(tdb2location);
>
> tdb2location existing. However, I am getting the error below, which I don't 
> understand. It seems related to some file system issue, but I can initialise 
> and connect to TDB2 instances fine in other parts of the app, on the same 
> host (my laptop, btw...).
>
> Any clue?

Hi - which version is this ? SystemTDB.java:379 does not align with the
current codebase (nor to the other stacktrace lines)

The only NPE possibility I see when it checks the system context. If
initialization has a problem,

1/ Have you repacked the jars in anyway?

2/ Before the first call by any code into Jena, try calling
JenaSystem.init. This forces it to happen in a more predicable way.
The automatic way is at-rick from class loader ordering.

3/ Before any jena code, set the init logging
  JenaSystem.DEBUG_INIT = true

You should see on stderr

   JenaInitLevel0   [0]
   InitJenaCore [10]
   InitRIOT [20]
   InitARQ  [30]
   InitTDB2 [42]
   InitPatch[60]
   InitRDFS [60]
   InitShacl[95]
   InitShex [96]

then a record of everythign called.

 Andy

>
> Thx!
>
> Enrico
>
> ---
>
> java.lang.ExceptionInInitializerError: null
>   at 
> org.apache.jena.tdb2.params.StoreParams.getDftStoreParams(StoreParams.java:121)
>   at 
> org.apache.jena.tdb2.store.TDB2StorageBuilder.build(TDB2StorageBuilder.java:91)
>   at 
> org.apache.jena.tdb2.sys.StoreConnection.make(StoreConnection.java:93)
>   at 
> org.apache.jena.tdb2.sys.StoreConnection.connectCreate(StoreConnection.java:61)
>   at 
> org.apache.jena.tdb2.sys.DatabaseOps.createSwitchable(DatabaseOps.java:96)
>   at org.apache.jena.tdb2.sys.DatabaseOps.create(DatabaseOps.java:77)
>   at 
> org.apache.jena.tdb2.sys.DatabaseConnection.build(DatabaseConnection.java:103)
>   at 
> org.apache.jena.tdb2.sys.DatabaseConnection.lambda$make$0(DatabaseConnection.java:74)
>   at 
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
>  ~[?:1.8.0_292]
>   at 
> org.apache.jena.tdb2.sys.DatabaseConnection.make(DatabaseConnection.java:74)
>   at 
> org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:63)
>   at 
> org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:54)
>   at 
> org.apache.jena.tdb2.DatabaseMgr.DB_ConnectCreate(DatabaseMgr.java:41)
>   at 
> org.apache.jena.tdb2.DatabaseMgr.connectDatasetGraph(DatabaseMgr.java:46)
>   at org.apache.jena.tdb2.TDB2Factory.connectDataset(TDB2Factory.java:52)
>   at org.apache.jena.tdb2.TDB2Factory.connectDataset(TDB2Factory.java:70)
> [...]
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.jena.tdb2.sys.SystemTDB.determineFileMode(SystemTDB.java:379)
>   at org.apache.jena.tdb2.sys.SystemTDB.fileMode(SystemTDB.java:357)
>   at 
> org.apache.jena.tdb2.params.StoreParamsConst.(StoreParamsConst.java:33)
>
>
> --
> Enrico Daga, PhD
>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.enridaga.net%2F=05%7C01%7Cenrico.daga%40open.ac.uk%7C76a0822043564d7b418208dba55ed091%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%7C638285598866607397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3R2Cjw4f4CqtPvmqmQR8Ktw%2BQCuKpuilIicWUsvRerw%3D=0
>  | @enridaga
>
> SPARQL Anything 
> 

Re: Mystery memory leak in fuseki

[Dave Reynolds]

On 25/08/2023 11:44, Andy Seaborne wrote:



On 03/07/2023 14:20, Dave Reynolds wrote:
We have a very strange problem with recent fuseki versions when 
running (in docker containers) on small machines. Suspect a jetty 
issue but it's not clear.


 From the threads here, it does seem to be Jetty related.


Yes.

We've followed up on Rob's suggestions for tuning the jetty settings so 
we can use a stock fuseki. On 4.9.0 if we switch off direct buffer using 
in jetty altogether the problem does seem to go away. The performance 
hit we see is small and barely above noise.


We currently have a soak test of leaving direct buffers on but limiting 
max and retained levels, that looks promising but too early to be sure.


I haven't managed to reproduce the situation on my machine in any sort 
of predictable way where I can look at what's going on.


Understood. While we can reproduce some effects in desktop test set ups 
the only real test has been to leave configurations running for days at 
a time in the real dev setting with all it's monitoring and 
instrumentation. Which makes testing any changes very painful, let alone 
deeper investigations.


For Jena5, there will be a switch to a Jetty to use uses jakarta.* 
packages. That's no more than a rename of imports. The migration 
EE8->EE9 is only repackaging.  That's Jetty10->Jetty11.


There is now Jetty12. It is a major re-architecture of Jetty including 
it's network handling for better HTTP/2 and HTTP/3.


If there has been some behaviour of Jetty involved in the memory growth, 
it is quite unlikely to carried over to Jetty12.


Jetty12 is not a simple switch of artifacts for Fuseki. APIs have 
changed but it's a step that going to be needed sometime.


If it does not turn out that Fuseki needs a major re-architecture, I 
think that Jena5 should be based on Jetty12. So far, it looks doable.


Sound promising. Agreed that jetty12 is enough of a new build it's 
unlikely to have the same behaviour.


We've being testing some of our troublesome queries on 4.9.0 on java 11 
vs java 17 and see a 10-15% performance hit on java 17 (even after we 
take control of the GC by forcing both to use the old parallel GC 
instead of G1). No idea why, seems wrong! Makes us inclined to stick 
with java 11 and thus jena 4.x series as long as we can.


Dave

Re: TDB2 Exception in initialisation

[Andy Seaborne]

On 25/08/2023 09:04, Enrico.Daga wrote:

Hi,

I am having a strange error while attempting to initialise a TDB2 dataset:

TDB2Factory.connectDataset(tdb2location);

tdb2location existing. However, I am getting the error below, which I don't 
understand. It seems related to some file system issue, but I can initialise 
and connect to TDB2 instances fine in other parts of the app, on the same host 
(my laptop, btw...).

Any clue?


Hi - which version is this ? SystemTDB.java:379 does not align with the 
current codebase (nor to the other stacktrace lines)


The only NPE possibility I see when it checks the system context. If 
initialization has a problem,


1/ Have you repacked the jars in anyway?

2/ Before the first call by any code into Jena, try calling 
JenaSystem.init. This forces it to happen in a more predicable way.

The automatic way is at-rick from class loader ordering.

3/ Before any jena code, set the init logging
 JenaSystem.DEBUG_INIT = true

You should see on stderr

  JenaInitLevel0   [0]
  InitJenaCore [10]
  InitRIOT [20]
  InitARQ  [30]
  InitTDB2 [42]
  InitPatch[60]
  InitRDFS [60]
  InitShacl[95]
  InitShex [96]

then a record of everythign called.

Andy



Thx!

Enrico

---

java.lang.ExceptionInInitializerError: null
  at 
org.apache.jena.tdb2.params.StoreParams.getDftStoreParams(StoreParams.java:121)
  at 
org.apache.jena.tdb2.store.TDB2StorageBuilder.build(TDB2StorageBuilder.java:91)
  at org.apache.jena.tdb2.sys.StoreConnection.make(StoreConnection.java:93)
  at 
org.apache.jena.tdb2.sys.StoreConnection.connectCreate(StoreConnection.java:61)
  at 
org.apache.jena.tdb2.sys.DatabaseOps.createSwitchable(DatabaseOps.java:96)
  at org.apache.jena.tdb2.sys.DatabaseOps.create(DatabaseOps.java:77)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.build(DatabaseConnection.java:103)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.lambda$make$0(DatabaseConnection.java:74)
  at 
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
 ~[?:1.8.0_292]
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.make(DatabaseConnection.java:74)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:63)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:54)
  at org.apache.jena.tdb2.DatabaseMgr.DB_ConnectCreate(DatabaseMgr.java:41)
  at 
org.apache.jena.tdb2.DatabaseMgr.connectDatasetGraph(DatabaseMgr.java:46)
  at org.apache.jena.tdb2.TDB2Factory.connectDataset(TDB2Factory.java:52)
  at org.apache.jena.tdb2.TDB2Factory.connectDataset(TDB2Factory.java:70)
[...]
Caused by: java.lang.NullPointerException
  at 
org.apache.jena.tdb2.sys.SystemTDB.determineFileMode(SystemTDB.java:379)
  at org.apache.jena.tdb2.sys.SystemTDB.fileMode(SystemTDB.java:357)
  at 
org.apache.jena.tdb2.params.StoreParamsConst.(StoreParamsConst.java:33)


--
Enrico Daga, PhD

www.enridaga.net | @enridaga

SPARQL Anything http://sparql-anything.cc
Polifonia http://polifonia-project.eu
SPICE http://spice-h2020.eu
Open Knowledge Graph http://data.open.ac.uk

Senior Research Fellow, Knowledge Media Institute, STEM Faculty
The Open University
Level 4 Berrill Building, Walton Hall, Milton Keynes, MK7 6AA
Direct: +44 (0) 1908 654887

Re: Transactions over http (fuseki)

[Andy Seaborne]

On 18/08/2023 07:38, Gaspar Bartalus wrote:

Hi,

We would like to execute queries (construct) and updates (insert/delete
data) in one transaction.
Very similar I think to what Andy described here:
https://github.com/w3c/sparql-dev/issues/83


Something that has not quite ever managed to bubble up my todo list!

By exposing transaction control, there will have to be some defensive 
features like timeouts because otherwise an errant client could disrupt 
a server.


Andy



Gaspar

On Thu, Aug 17, 2023 at 7:54 PM Marco Neumann 
wrote:


Caspar, while you are looking into the extensions how would you like to use
transactions in your use case?

Marco

On Thu, 17 Aug 2023 at 13:44, Gaspar Bartalus  wrote:


Hi Lorenz,

Thanks for the quick response. That sounds indeed very promising.
Looking forward to knowing more details about the fuseki extension
mechanism, or a transaction module in particular.

Gaspar

On Thu, Aug 17, 2023 at 9:17 AM Lorenz Buehmann <
buehm...@informatik.uni-leipzig.de> wrote:


Hi,

that is an open issue in the SPARQL standard and Andy already opened a
ticket [1] regarding this maybe w.r.t. an upcoming SPARQL 1.2

I think mixed query types are still not possible via standard Fuseki in
a single transaction, but indeed an extension like you're planning
should be possible. Andy is already working on a newer Fuseki extension
mechanism (it's basically already there) where you can plugin so-called
Fuseki modules. This would be the way I'd try to add this extension to
Fuseki.

Indeed, Andy knows better and can give you more specific code or
pointers - maybe he even has such a module or code part implemented
somewhere.


Regards,

Lorenz


[1] https://github.com/w3c/sparql-dev/issues/83

On 16.08.23 17:20, Gaspar Bartalus wrote:

Hi,

We’ve been using jena-fuseki to store and interact with RDF data by

running

queries over the http endpoints.
We are now facing the challenge to use transactional operations on

the

triple store, i.e. running multiple sparql queries (both select and

update

queries) in a single transaction.
I would like to ask what your suggestion might be to achieve this.

The idea we have in mind is to extend jena-fuseki with new http

endpoints

for handling transactions.
Would this be technically feasible, i.e. could we reach the internal
transaction API (store API?) from jena-fuseki?
Would you agree with this approach conceptually, or would you

recommend

something different?

Thanks in advance,
Gaspar

PS: Sorry for the duplicate, I have the feeling that my other email

address

is blocked somehow.


--
Lorenz Bühmann
Research Associate/Scientific Developer

Email buehm...@infai.org

Institute for Applied Informatics e.V. (InfAI) | Goerdelerring 9 |

04109

Leipzig | Germany





--


---
Marco Neumann

Re: RSIterator deprecation

[Andy Seaborne]

On 21/08/2023 19:19, Andrii Berezovskyi wrote:

Hello Andy,

Thank you for the pointer to ReifierStd, it seems to do the job as expected 
[1]. I hope we are using the new API correctly (I would be very thankful for 
any feedback).


ReifierStd is the code behind the Model reification - yes, that looks right.



While working on the changes, I re-discovered that Model.getResource() only accepts 
Strings and simply passing "node.getURI()" fails on blank nodes. I found that 
[2] from SPDX tools implements the logic I expect. Would such method make sense on a Jena 
Model (as in, to be added to the org.apache.jena.rdf.model.Model API)?



That would be add to add "Resource getResource(AnonId)" c.f. 
model.createResource(AnonId) ?


While Model.getResource does describe itself as legacy, it does seem 
like a more natural name than createResource


So yes, that does seem reasonable and not disruptive.

Andy



And I would like to thank you for your help and continued work on the Jena 
project!

–Andrew.

[1]: 
https://github.com/eclipse/lyo/pull/389/files?diff=split=1#diff-0fd9d8b08e29abbd461bbfb2cf63649a4c027397fb7f4161e8932a282ad42afcL952-R1014
[2]: 
https://github.com/spdx/tools/blob/bc35e25dacb728bf8332b82b509bb3efacd6c64e/src/org/spdx/rdfparser/SPDXDocument.java#L1225-L1235

On 16 Aug 2023, at 18:18, Andrii Berezovskyi  wrote:

Thanks Andy,

On 15 Aug 2023, at 10:12, Andy Seaborne  wrote:

That's quite a long method!

Yes, not proudest part of Lyo. To my shame, I was reluctant to refactor it 
since I took over the project. Looks like you are providing us with a necessary 
push.

What is reification used for in Lyo?
Do quoted triples provide the same capability?

Lyo provides support for implementing OASIS OSLC standards. To be brief, OSLC 
(Core) is both a predecessor and a superset to the W3C LDP. OSLC allows 
metadata to be placed on link triples using RDF 1.1 reification [1].

Assuming that by quoted triples you refer to RDF-star, yes, they provide the 
same capability and would fully cover OSLC needs. However, Lyo still needs to 
support what is standardized in OSLC. Additionally, I was under impression that 
RDF-star haven't reached W3C Recommendation status and OASIS discourages citing 
documents that haven't reached the standard/recommendation status in its 
standards-track specs. Regardless, OSLC standards try to maintain backwards 
compat, which means the committee will only vote to add RDF-star support to the 
standard (e.g., via a SHOULD clause) but not remove RDF 1.1 reification for 
backwards compatibility reasons.

Reification support is all calculation library code - it's a way to
present reification. It does not affect storage.

Jena2 had variations of reification which did impact storage - these
have not existed in releases for a long time.

The library that backs the reification support is ReifierStd and it will
be available in jena5. ReifierStd works on graphs, not models. Writing
companion code to provide the functionality for the Model API
equivalents would be possible. Contributions welcome.

RSIterator isn't necessary. It's a "typed next()" iterator that came
about in the pre-generics times.

I am not quite sure I understand the impact of the change. Do we need to 
implement any support if we need RDF 1.1 reification and are ready to switch to 
Graph and ReifierStd APIs, and drop the use of RSIterator?


To be clear : this is not RDF-star quoted triples.

To be clear from our side too, we are certainly interested in adopting RDF-star 
quoted triples in the future. We are not ready to drop RDF 1.1 reification 
until/unless RDF 1.2 drops it (when it reaches W3C Rec).


Also, do I understand correctly that the removal is planned for Jena 5.x after 
JDK 21 release?

Yes, sometime after Java21. Jena5 will require Java17, in line with
supporting two LTS versions of Java.

Jena is already built and tested on Java17 as part of our CI.  Users can
switch to java17 in deployments now. It is a bit faster and has Java
improvements and fixes not backported to Java11.

We've been testing Lyo on JDK 11, 17, 20, and 21-ea. We are ready for the JDK 
17 migration, it's just that some of the Lyo users use it in legacy 
environments, but we've communicated to them that Lyo will drop JDK 11 support 
when Jena does.

–Andrew.

[1]: https://oslc-op.github.io/oslc-specs/notes/link-guidance.html#Anchor

Re: Mystery memory leak in fuseki

[Andy Seaborne]

On 03/07/2023 14:20, Dave Reynolds wrote:
We have a very strange problem with recent fuseki versions when running 
(in docker containers) on small machines. Suspect a jetty issue but it's 
not clear.


From the threads here, it does seem to be Jetty related.

I haven't managed to reproduce the situation on my machine in any sort 
of predictable way where I can look at what's going on.



For Jena5, there will be a switch to a Jetty to use uses jakarta.* 
packages. That's no more than a rename of imports. The migration 
EE8->EE9 is only repackaging.  That's Jetty10->Jetty11.


There is now Jetty12. It is a major re-architecture of Jetty including 
it's network handling for better HTTP/2 and HTTP/3.


If there has been some behaviour of Jetty involved in the memory growth, 
it is quite unlikely to carried over to Jetty12.


Jetty12 is not a simple switch of artifacts for Fuseki. APIs have 
changed but it's a step that going to be needed sometime.


If it does not turn out that Fuseki needs a major re-architecture, I 
think that Jena5 should be based on Jetty12. So far, it looks doable.


Andy

Re: Commercial Fuseki operational support

[Martynas Jusevičius]

Nicholas,

Fuseki is present on the AWS marketplace, if you follow your own link :)

The product is built using CDK, CloudFormation and Docker. If you’d be
interested to collaborate on that, send me an email off-list.

Martynas
atomgraph.com

On Fri, 25 Aug 2023 at 10.52, Nicholas Car  wrote:

> Hi Jena users,
>
> Just so everyone is aware: I have had several companies contact me about
> various levels of commercial Fuseki support.
>
> For users' interest, these are my observations of their Fuseki offerings:
>
> - many companies use Fuseki commercially as part of holistic Knowledge
> Graph architectures
> - no companies offer SLA-backed Fuseki support as a distinct service right
> now
>
> - other than mine! and this offer is new with SLAs still being worked out (
> https://kurrawong.ai/supported-products/fuseki/) so it is not very mature
> - several companies that use Fuseki are able to, and are interested in,
> offering distinct support if a serious request appears
> - lots of companies maintain Fuseki in Docker and similar container images
>
> - just search for Fuseki on Docker Hub and similar:
>
> - https://hub.docker.com/search?q=fuseki
> - https://github.com/search?q=fuseki=registrypackages
> - Fuseki is not present, in standalone form, the AWS or Azure marketplaces
> yet:
>
> - https://aws.amazon.com/marketplace/search/results?searchTerms=fuseki
> -
> https://azuremarketplace.microsoft.com/en-gb/marketplace/apps?search=fuseki=1
>
> If anything here is incorrect, please reply back to the mailing list to
> point out errors.
>
> Cheers, Nick
>
> --- Original Message ---
> On Wednesday, August 23rd, 2023 at 10:55, Nicholas Car 
> wrote:
>
> > Dear Jena users,
> >
> > Do any of you know companies that offer commercial support with Service
> Level Agreements for Fuseki?
> >
> > I have a government department here in Australia that wishes to run
> operational Fuseki instances with patching/config support for strong
> operations.
> >
> > Thanks, Nick

Re: Commercial Fuseki operational support

[Nicholas Car]

Hi Jena users,

Just so everyone is aware: I have had several companies contact me about 
various levels of commercial Fuseki support.

For users' interest, these are my observations of their Fuseki offerings:

- many companies use Fuseki commercially as part of holistic Knowledge Graph 
architectures
- no companies offer SLA-backed Fuseki support as a distinct service right now

- other than mine! and this offer is new with SLAs still being worked out 
(https://kurrawong.ai/supported-products/fuseki/) so it is not very mature
- several companies that use Fuseki are able to, and are interested in, 
offering distinct support if a serious request appears
- lots of companies maintain Fuseki in Docker and similar container images

- just search for Fuseki on Docker Hub and similar:

- https://hub.docker.com/search?q=fuseki
- https://github.com/search?q=fuseki=registrypackages
- Fuseki is not present, in standalone form, the AWS or Azure marketplaces yet:

- https://aws.amazon.com/marketplace/search/results?searchTerms=fuseki
- 
https://azuremarketplace.microsoft.com/en-gb/marketplace/apps?search=fuseki=1

If anything here is incorrect, please reply back to the mailing list to point 
out errors.

Cheers, Nick

--- Original Message ---
On Wednesday, August 23rd, 2023 at 10:55, Nicholas Car  
wrote:

> Dear Jena users,
>
> Do any of you know companies that offer commercial support with Service Level 
> Agreements for Fuseki?
>
> I have a government department here in Australia that wishes to run 
> operational Fuseki instances with patching/config support for strong 
> operations.
>
> Thanks, Nick

TDB2 Exception in initialisation

[Enrico . Daga]

Hi,

I am having a strange error while attempting to initialise a TDB2 dataset:

TDB2Factory.connectDataset(tdb2location);

tdb2location existing. However, I am getting the error below, which I don't 
understand. It seems related to some file system issue, but I can initialise 
and connect to TDB2 instances fine in other parts of the app, on the same host 
(my laptop, btw...).

Any clue?

Thx!

Enrico

---

java.lang.ExceptionInInitializerError: null
  at 
org.apache.jena.tdb2.params.StoreParams.getDftStoreParams(StoreParams.java:121)
  at 
org.apache.jena.tdb2.store.TDB2StorageBuilder.build(TDB2StorageBuilder.java:91)
  at org.apache.jena.tdb2.sys.StoreConnection.make(StoreConnection.java:93)
  at 
org.apache.jena.tdb2.sys.StoreConnection.connectCreate(StoreConnection.java:61)
  at 
org.apache.jena.tdb2.sys.DatabaseOps.createSwitchable(DatabaseOps.java:96)
  at org.apache.jena.tdb2.sys.DatabaseOps.create(DatabaseOps.java:77)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.build(DatabaseConnection.java:103)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.lambda$make$0(DatabaseConnection.java:74)
  at 
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
 ~[?:1.8.0_292]
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.make(DatabaseConnection.java:74)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:63)
  at 
org.apache.jena.tdb2.sys.DatabaseConnection.connectCreate(DatabaseConnection.java:54)
  at org.apache.jena.tdb2.DatabaseMgr.DB_ConnectCreate(DatabaseMgr.java:41)
  at 
org.apache.jena.tdb2.DatabaseMgr.connectDatasetGraph(DatabaseMgr.java:46)
  at org.apache.jena.tdb2.TDB2Factory.connectDataset(TDB2Factory.java:52)
  at org.apache.jena.tdb2.TDB2Factory.connectDataset(TDB2Factory.java:70)
[...]
Caused by: java.lang.NullPointerException
  at 
org.apache.jena.tdb2.sys.SystemTDB.determineFileMode(SystemTDB.java:379)
  at org.apache.jena.tdb2.sys.SystemTDB.fileMode(SystemTDB.java:357)
  at 
org.apache.jena.tdb2.params.StoreParamsConst.(StoreParamsConst.java:33)


--
Enrico Daga, PhD

www.enridaga.net | @enridaga

SPARQL Anything http://sparql-anything.cc
Polifonia http://polifonia-project.eu
SPICE http://spice-h2020.eu
Open Knowledge Graph http://data.open.ac.uk

Senior Research Fellow, Knowledge Media Institute, STEM Faculty
The Open University
Level 4 Berrill Building, Walton Hall, Milton Keynes, MK7 6AA
Direct: +44 (0) 1908 654887