Ok, thanks for the explanation.
> not separate partitions on disk for each graph
I wrote " 'partitions' or 'tables' " but I had the TDB files in mind
(GOSP.dat + GOSP.idn), it was a wrong analogy...
> you are reducing the number of tuples over which the filter has to
scan by narrowing its sc
No, I don't think that's what's going on. Andy can correct me if I'm going
wrong here, but TDB builds the equivalent of a quad table for named graphs, not
separate partitions on disk for each graph. The exception is the default graph.
The same is true for TIM, Jena's transactional in-memory data
> $word is provided as a value? $word looks like a variable to the
optimizer so the FILTER is after the whole of the BGP.
Sorry I should have written" :
FILTER(REGEX(?title, "some word", 'i'))
my '$word' meant 'any value to complete the query string'.
> With GRAPH, or using just the {} part,
On 17/12/2018 07:53, Vincent Ventresque wrote:
Are you sure that named graphs have better performance?
I'm not a specialist, and I'd like to know other users' opinion about
that question. I thinks it depends both on the structure of your data
and the queries you run.
My use case consisted
Le lun. 17 déc. 2018 à 13:24, Andy Seaborne a écrit :
> ...
> :spatial_dataset rdf:type spatial:SpatialDataset ;
> rdf:type text:TextDataset ;
> ...
>
> Not sure but I think the system will create this twice.
>
> It would be better to have two declarations, one for spatial, one for
>
[] ja:loadClass...
Not needed these days. Harmless.
:spatial_dataset rdf:type spatial:SpatialDataset ;
rdf:type text:TextDataset ;
...
Not sure but I think the system will create this twice.
It would be better to have two declarations, one for spatial, one for
text. I'm not su
Dear all,
We are a group of developers from Macedonia, who are currently working with
JenaDB. We are trying to implement Jena in our project and we did a lot of
research and decided that this may be the best approach for us. The requirement
for choosing of suitable database was defined to store
