Closed KonradHoeffner closed 2 years ago
This will be put on hold until https://github.com/SmartDataAnalytics/jena-sparql-api/issues/43 is resolved, then this pull request will be updated and merged. @Aklakan: Please notify us when that is resolved.
You're mixing Jena 4.4.0 with Jena-SPARQL-API 3.x - that's error prone and only works if you get lucky with the classpath loader. Jena SPARQL API is based on Jena 3.x - it never made it to a 4.x release although a branch exists. Apparently, the API is more or less discontinued now and @Aklakan migrated it into JenaX
@LorenzBuehmann: Thanks for the advice! Will JenaX be available as a Maven dependency in the near future?
I have created a configuration file called test.xml
and s small dataset called test.nt
so you can test Limes using these files. Both files in dataset folder. https://github.com/dice-group/LIMES/blob/hotfix/limes-core/src/main/resources/datasets/test.nt
and https://github.com/dice-group/LIMES/blob/hotfix/limes-core/src/main/resources/datasets/test.xml
.
See https://github.com/dice-group/LIMES/tree/hotfix
Is this not covered by the unit tests?
Jenax is a refactoring of Jena-sparql-api; the code is mostly the same but artifact names have changed. I am in the process of creating a maven Central release; should be done this week. The illegal module access stuff has already been fixed in that code.
@Aklakan: Thanks! Please give me a quick notice when it is available on Maven central.
@Aklakan will release the jenax Maven (as a snapshot?) until tomorrow and we will try to refactor LIMES accordingly then.
There are still some problems in the cache component of jenax, which @Aklakan will fix soon.
Due to the heroic efforts of @Aklakan, this works now without needing any special parameters.
@Aklakan will release his dependencies as non-snapshot today, then we can finish this.
The non-snapshot dependency jenax:jenax-rx-dataaccess:jar:4.4.0-1 is not yet on Maven central, which is why the checks fail. Please rerun checks after it jenax is deployed.
hi, jenax 4.4.0-1 is now released and I updated the ResilientSparqlQueryModule of limes accordingly. The old sparql caching system of jenax supported caching of 'pages' of query results and resuming from already retrieved pages when retrieval was interrupted e.g. by hitting ctrl+c. The new caching system can now operate on arbitrary ranges of data: e.g. if there is a query using limit X offset Y then it can match any portions of data in the cache.
I noticed a quirk in the limes config: It turns out that in the <SOURCE>
tag the following rules apply:
<TYPE>sparql</TYPE>
and the SparqlQueryModule is used<TYPE></TYPE>
then the ResilientSparqlQueryModule is used.Many thanks @Aklakan! @MSherif the pull request is now ready to be merged.
@KonradHoeffner @Aklakan Thanks indeed for you both for your help.
Resolves #271 and #272. Successfully tested with and without docker. However on Java 16 without docker, the following parameters are needed:
java --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED -jar ~/mydirectory/limes/limes-core/target/limes-core-1.7.7-SNAPSHOT.jar myfile.xml
This will not be necessary, when the jena-sparql-api update is published, see https://github.com/SmartDataAnalytics/jena-sparql-api/issues/43.