good morning;
> On 2017-04-26, at 10:33, baran...@gmail.com wrote:
>
> […]
>
> Is it so far fetched thinking to standardise 'only' the SPARQL 'syntax' for
> text-indexing?
that would not resolve your complaint.
there are proposals which use facilities described in the recommendation to
Hello,
you generelized the problem of standardisating suggesting to standardise
first the extensions as an important step to the mean standardisation, i
think. To formulate similar things are essentially important for all users
and very stimulating. Since so many years the first eMail i
Actually, no I am not fundamentally satisfied. I was trying to explain how the
current situation came to be in reply to your assertion that “some idiocy” was
responsible and in the context of your specific complaint about to text
indexing.
In general property functions as they exist in a
On Mon, 24 Apr 2017 15:05:19 +0200, Martynas Jusevičius
wrote:
"Should have been, could have been". It is how it is, your opinion is
just
one of many and you will achieve nothing by complaining on this list. Go
create a W3C Community Group and initiate some real work
"Should have been, could have been". It is how it is, your opinion is just
one of many and you will achieve nothing by complaining on this list. Go
create a W3C Community Group and initiate some real work to achieve the
standardisation that you think is required.
On Mon, 24 Apr 2017 at 13.30,
Hello,
You seem to fundamentally misunderstand how the standardisation process
works.
The point is not whether i understand standardisation or not, the point is
your argument
At the time that SPARQL 1.1 was standardised indexing was not a
widely used extension so there was no
On 24/04/17 10:57, Rob Vesse wrote:
You seem to fundamentally misunderstand how the standardisation
process works. The intent of a standard is never to specify every
feature that exists or that could exist but rather to specify a set
of standard functionality that will be useful to end users
You seem to fundamentally misunderstand how the standardisation process works.
The intent of a standard is never to specify every feature that exists or that
could exist but rather to specify a set of standard functionality that will be
useful to end users while also being amenable to multiple
support for the
queries required.
Dick
Original message From: baran...@gmail.com Date: 22/04/2017
11:02 (GMT+00:00) To: users@jena.apache.org Subject: Re: Jena native store
indexes
On Wed, 12 Apr 2017 15:01:34 +0200, Rob Vesse <rve...@dotnetrdf.org> wrote:
> .
>
On Wed, 12 Apr 2017 15:01:34 +0200, Rob Vesse wrote:
.
In the RDF world it may still be useful to create secondary indexes as
others have noted for certain kinds of specialised search that cannot be
officially expressed in SPARQL.
Here is primarily text indexing
A RDF store is basically a four column database so and implementation can
automatically construct the necessary indexes to be able to Service any simple
scan i.e. Basic graph pattern. Efficient answering of queries can be done by
having a sufficiently smart optimiser and using precomputed
The Jena list can't really answer questions about "any RDF store", but for TDB,
you begin with basic covering indexes, so you do not need to add anything (in
fact you cannot add anything) to provide more indexing for standard SPARQL
forms.
As has been pointed out, there are _extensions_ to
But is Jena (or any RDF store for what matters) expected to perform well even
if I don't explicitly add any index?
> You 'can' create text-indexes for selected properties of your data for
> text search with a much better performance:
>
>
When writing SPARQL queries, should I be aware of any particular
index? Should I create new indexes myself (how)?
You 'can' create text-indexes for selected properties of your data for
text search with a much better performance:
With RDBMSes, indexes are a bit topic and should always be taken into
consideration when writing queries. With RDF stores instead, I barely see them
mentioned at all. So I was wondering how indexes work in Jena native store, or
other native stores in general. When writing SPARQL queries, should
15 matches
Mail list logo