AW: Failure initializing default system SSL context
The reason why I use Jena 2.10.0 is an IllegalAccessError exception with Pellet that I get whenever I use a Jena version post 2.10.0. The error message looks like this: java.lang.IllegalAccessError: tried to access field com.hp.hpl.jena.reasoner.BaseInfGraph.isPrepared from class org.mindswap.pellet.jena.PelletInfGraph at org.mindswap.pellet.jena.PelletInfGraph.isPrepared(PelletInfGraph.java:178) at org.mindswap.pellet.jena.PelletInfGraph.prepare(PelletInfGraph.java:234) at org.mindswap.pellet.jena.PelletInfGraph.prepare(PelletInfGraph.java:230) at org.mindswap.pellet.jena.PelletInfGraph.isConsistent(PelletInfGraph.java:258) … I got this information from http://datababel.wordpress.com/2013/06/18/jena-2-10-1-and-pellet-2-3-4-illegalaccesserror/ I would gladly switch to a newer release but I guess that I have to use a different reasoned since Pellet doesn't seem to work with newer releases of Jena. Can you recommend a different Reasoner that is comparable with Pellet? Greetings -Ursprüngliche Nachricht- Von: Rob Vesse [mailto:rve...@dotnetrdf.org] Gesendet: Donnerstag, 1. Mai 2014 10:50 An: users@jena.apache.org Betreff: Re: Failure initializing default system SSL context Is there a particular reason why you are using an old version of Jena? 2.10.0 is from Feb 2013 so about a year or so out of date, we've made three releases since and 2.11.1 is the latest stable release Rob On 30/04/2014 16:58, Zindel, Andreas andreas.zin...@eads.net wrote: I'm developing on Eclipse for OEPE (Kepler) with Jena 2.10.0 Glassfish 4.0 (build 89) and use Pellet (2.3.1) as a reasoned. Any help is appreciated.
AW: Failure initializing default system SSL context
See the reason why I send this to the Jena mailing list is that I don't have any deeper knowledge about SSL. Because this exception is thrown while executing Jena code and the exception states that the error is caused by the Jena framework (that is my interpretation) I thought maybe the mailing list had dealt with this problem before. The other thing is that in the offline Java application that I wrote as an example this exception isn't thrown and everything works as expected. So I think that the imports are working. Greetings -Ursprüngliche Nachricht- Von: Andy Seaborne [mailto:a...@apache.org] Gesendet: Mittwoch, 30. April 2014 22:14 An: users@jena.apache.org Betreff: Re: Failure initializing default system SSL context Googling for 'Failure initializing default system SSL context' suggests it's the SSL setup, not a Jena specific issue. Then (maybe), it looks like read isn't able to read the imports but that's a guess. Andy
Re: AW: Failure initializing default system SSL context
On 05/05/14 08:59, Zindel, Andreas wrote: See the reason why I send this to the Jena mailing list is that I don't have any deeper knowledge about SSL. Because this exception is thrown while executing Jena code and the exception states that the error is caused by the Jena framework (that is my interpretation) I thought maybe the mailing list had dealt with this problem before. Jena just uses Apache HTTP Client and hence gets SSL support. One way forward would be to write a small program that uses Apache HTTP Client with SSL; it might be easier to see what's going on without the Jena overlay. The other thing is that in the offline Java application that I wrote as an example this exception isn't thrown and everything works as expected. So I think that the imports are working. Sure - if they can be read. I was hazarding a guess that the SSL issue stops the imports being read. Greetings -Ursprüngliche Nachricht- Von: Andy Seaborne [mailto:a...@apache.org] Gesendet: Mittwoch, 30. April 2014 22:14 An: users@jena.apache.org Betreff: Re: Failure initializing default system SSL context Googling for 'Failure initializing default system SSL context' suggests it's the SSL setup, not a Jena specific issue. Then (maybe), it looks like read isn't able to read the imports but that's a guess. Andy
Re: Failure initializing default system SSL context
Hi Andreas, I’m not sure that the reason of your Exception is somewhere in Jena. When I lokk at the stack trace you sent, the initial cause I read is : Caused by: java.security.UnrecoverableKeyException: Password verification failed at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770) So, my interpretation is that you got an SSL exception because you entered the wrong id/pass. Chris. Le 5 mai 2014 à 12:51, Andy Seaborne a...@apache.org a écrit : On 05/05/14 08:59, Zindel, Andreas wrote: See the reason why I send this to the Jena mailing list is that I don't have any deeper knowledge about SSL. Because this exception is thrown while executing Jena code and the exception states that the error is caused by the Jena framework (that is my interpretation) I thought maybe the mailing list had dealt with this problem before. Jena just uses Apache HTTP Client and hence gets SSL support. One way forward would be to write a small program that uses Apache HTTP Client with SSL; it might be easier to see what's going on without the Jena overlay. The other thing is that in the offline Java application that I wrote as an example this exception isn't thrown and everything works as expected. So I think that the imports are working. Sure - if they can be read. I was hazarding a guess that the SSL issue stops the imports being read. Greetings -Ursprüngliche Nachricht- Von: Andy Seaborne [mailto:a...@apache.org] Gesendet: Mittwoch, 30. April 2014 22:14 An: users@jena.apache.org Betreff: Re: Failure initializing default system SSL context Googling for 'Failure initializing default system SSL context' suggests it's the SSL setup, not a Jena specific issue. Then (maybe), it looks like read isn't able to read the imports but that's a guess. Andy : : . . . . . . . . . . . . . . . . . . . . . . . : : Christophe FAGOT, PhD Responsable RD informatique intactile DESIGN : : Création d’interfaces subtiles : : +33 (0)4 67 52 88 61 +33 (0)9 50 12 05 66 20 rue du carré du roi 34000 MONTPELLIER, France http://www.intactile.com Hugh MacLeod : It's not what the software does, it's what the user does Les informations contenues dans cet email et ses documents attachés sont confidentielles. Elles sont exclusivement adressées aux destinataires explicitement désignés ci-dessus et ne peuvent être divulguées sans consentement de son auteur. Si vous n'êtes pas le destinataire de cet email vous ne devez pas employer, révéler, distribuer, copier, imprimer ou transmettre le contenu de cet email et devez le détruire immédiatement.
Re: Getting classes from an ontology
Hi, Andy - Answers inline. On May 3, 2014, at 4:53 AM, Andy Seaborne wrote: On 05/03/14 00:02, Cindy A McMullen wrote: Unfortunately, we're using an older version of Jena (2.7.2) for compatibility with the Oracle Jena adapter. I see more recent versions have these methods on OntModel: listClasses() listDatatypeProperties() and so on. How can I do the equivalent using Jena 2.7.2? Those exist in my copies of jena 2.7.2 (and earlier as well). I don't see them. Which jars do you have? /Users/cindymc/dev/discovery:$ find . -name *jena*.jar ./_deps/jena-arq-2.9.2.jar ./_deps/jena-core-2.7.2.jar ./_deps/jena-iri-0.9.2.jar /Users/cindymc/dev/discovery:$ find . -name *jena*.jar | xargs grep listClasses (Your other choice is to look at the source code for a later version and see what the code does then provide the same functionality). Andy Thanks - -- Cindy
Re: Getting classes from an ontology
On 05/05/14 16:49, Cindy A McMullen wrote: Hi, Andy - Answers inline. On May 3, 2014, at 4:53 AM, Andy Seaborne wrote: On 05/03/14 00:02, Cindy A McMullen wrote: Unfortunately, we're using an older version of Jena (2.7.2) for compatibility with the Oracle Jena adapter. I see more recent versions have these methods on OntModel: listClasses() listDatatypeProperties() and so on. How can I do the equivalent using Jena 2.7.2? Those exist in my copies of jena 2.7.2 (and earlier as well). I don't see them. Which jars do you have? jena-core /Users/cindymc/dev/discovery:$ find . -name *jena*.jar ./_deps/jena-arq-2.9.2.jar ./_deps/jena-core-2.7.2.jar ./_deps/jena-iri-0.9.2.jar /Users/cindymc/dev/discovery:$ find . -name *jena*.jar | xargs grep listClasses jar files are compressed - you can't grep them for strings. You'll need to unzip jena-core-2.7.2-sources.jar then grep the file tree Andy (Your other choice is to look at the source code for a later version and see what the code does then provide the same functionality). Andy Thanks - -- Cindy
Re: Reading TDB dataset in a union model
On 25/04/14 04:41, Karen Menz wrote: (your message got dumped in my gmail spam folder) Hi, I'm able to store a set of RDF/OWL files in a TDB dataset. Now, I wonder if there's a way to read this dataset back (by another application) into a union model of all files, to use the rich API for Model. This feature was supported by TDB-0.9.1, as: Model model = TDBFactory.createModel(directory); But now it's deprecated in Jena-2.11.1, which is the version I'm using. I'm trying the following: Looks good Dataset ds = TDBFactory.createDataset(directory); ds.begin(ReadWrite.READ); Model model = ds.getDefaultModel();// null ... ds.close(); and getting the following: Exception in thread main java.lang.NullPointerException at com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.readPrefixMap(DatasetPrefixesTDB.java:174) This suggests that at some time in the past, the database was used non transactionally and didn't shutdown cleanly. You can try deleting the prefix map tables -- prefix*.* at com.hp.hpl.jena.sparql.graph.GraphPrefixesProjection.getNsPrefixMap(GraphPrefixesProjection.java:62) at com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.getPrefixMapping(DatasetPrefixesTDB.java:223) at com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.getPrefixMapping(DatasetPrefixesTDB.java:214) at com.hp.hpl.jena.tdb.store.GraphTDB.createPrefixMapping(GraphTDB.java:78) at com.hp.hpl.jena.graph.impl.GraphBase.getPrefixMapping(GraphBase.java:186) at com.hp.hpl.jena.rdf.model.impl.ModelCom.getPrefixMapping(ModelCom.java:980) at com.hp.hpl.jena.rdf.model.impl.ModelCom.withDefaultMappings(ModelCom.java:1024) at com.hp.hpl.jena.rdf.model.impl.ModelCom.init(ModelCom.java:74) at com.hp.hpl.jena.rdf.model.impl.ModelCom.init(ModelCom.java:70) at com.hp.hpl.jena.rdf.model.ModelFactory.createModelForGraph(ModelFactory.java:176) at com.hp.hpl.jena.sparql.core.DatasetImpl.graph2model(DatasetImpl.java:271) at com.hp.hpl.jena.sparql.core.DatasetImpl.getDefaultModel(DatasetImpl.java:103) at TestTDB.main(TestTDB.java:43) Thanks in advance, Karen
inserting data into triplestore with less main memory foot print
Hi All,
I am trying to insert triples into Jena TDB (triples are added into simple
models and then inserted).
The models are built at runtime for a particular group of triples, and then
it needs to be persisted into Jena TDB.
Pseudocode:
Resource node = getRdfModel().createResource(nodeStr);
for (EntryString, Object entry : attributes.entrySet()) {
String attributeName = entry.getKey();
attributeName = processAttributes(attributeName);
propertyStr = buildURI(attributeName, source, elementType.property,
nodeStr);
String val = processValue(entry);
node.addProperty(getRdfModel().createProperty(propertyStr),
getRdfModel().createLiteral(val));
}
dataset.begin(ReadWrite.WRITE);
try {
// TODO: This insert is not really effecient. The getnamed model loads the
data from the TDB into memory which is making the insert slow. Is there a
effecient way of inserting the data to TDB like a cursor with less memory
usage ?
dataset.getNamedModel(source).add(getRdfModel());
dataset.commit();
//After commit the getRDFModel() will be reseted.
} finally {
dataset.end();
}
Problem:
When I call the getNamedmodel function, it loads the data from TDB which is
quite large. Is there a way to insert the data without loading the data
into main memory ?
or any other effecient way of inserting data using Jena api?
This is a data migration study project, so more data will keep flowing in.
Thanks in advance for your help guidance.
Thanks
Ganesh
