So, this sounds like an XY problem. You haven’t described why it’s necessary
to change Jena initialisation (which is generally a bad idea), presumably it
causes you some problem, but without knowing what that problem is we can’t give
you an answer on whether this is the right solution
If you
FYI
The Jena PMC received a report of a security vulnerability in Jena SDB and has
issued a CVE as a result which you will find forwarded below.
SDB has been End of Life (EOL) since December 2020 and is no longer supported
by the project. Any users who are still using SDB should migrate to
at 11:04
To: users@jena.apache.org
Subject: Re: Weird sparql problem
Both your suggestions for rewriting the query worked. I'm lost with the
reasons, but for future cases, breaking problematic queries with {} is
they way to go?
On 04/11/2022 11.25, rve...@dotnetrdf.org wrote:
> So yes as suspec
t; (dc: <http://purl.org/dc/elements/1.1/>)
> (lsu: <https://www.lingsoft.fi/ns/umls/>))
> (sequence
> (table (vars ?sct_code)
> (row [?sct_code "298314008"])
> )
> (bgp
> (triple ?c skos:inScheme lsu:SNOMEDCT_US)
>
For these kind of performance issues it is useful to see the SPARQL algebra for
the whole query, not just fragments of the query. You can use the qparse
command for the version of Jena you are using to see how it is optimising your
queries e.g.
qparse --explain --query example.rq
As Lorenz
I think your problem might be your text:query string here. You have ‘*Allergy*’
as your search string which has both leading and trailing wildcards, the
leading wildcard is extremely expensive for Lucene to consider. With a leading
wildcard it must check every unique term in your index against
: cardinality estimation
HI,
I just want to see how cardinality estimation can be done
programmatically. whatever query or dataset it may be, but I want to see it
practically.
On Tue, Apr 12, 2022 at 4:33 PM rve...@dotnetrdf.org
wrote:
> Hi
>
> Could you provide more detail about what you
Hi
Could you provide more detail about what you are after? The amount of triples
that are scanned for a given SPARQL query can vary widely both based on the
query and how that query gets optimised (which can be data dependent)
I don’t think there is anything specifically exposed in the Jena
I would start by noting that:
1. Our node IDs are not hash bashed. They are 64 bit identifiers which
either represent an inlined value
(https://jena.apache.org/documentation/tdb/architecture.html#inline-values) or
an offset to the actual RDF term in the node table file.
2. We need to
