Simon Helsen wrote:
Hey Paolo,
we regularly face this issue as well, e.g. we often have queries which are
"give me the most recent resources of type X", So, something like
?r rdf:type <someType>; dc:modified ?time
FILTER ( ?time > "...")
Usually, the repository has *lots* of resources of type <someType>, but
there are really only very few resources which match the time criteria.
Yes, same here.
An example is TV programs, each program has a start and end dateTime.
There are lot of programs, you typically want to select just one or
two days at the time.
Another similar situation is geo location and bounded box queries, where
you want to find all the things with a lat/long within a rectangle.
Paolo
I am not sure it is easy to handle this other than having the ability to
mark some triples as "special" (this needs to be defined somehow). E.g. in
our repo, we know all resources have a dc:modified triple and if we could
indicate that this triple is used for time comparison purposes, perhaps
TDB could store these triples in a different way. Perhaps even at a modest
insertion/replacement cost and more memory/disk space, but faster queries.
Simon
From:
Paolo Castagna <[email protected]>
To:
[email protected]
Date:
10/19/2011 04:57 PM
Subject:
On SPARQL queries with FILTER ( ?date < "..."^^xsd:dateTime )
Hi,
a query pattern I often see is filtering by some xsd:dateTime interval,
for
example:
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT * {
?s <http://purl.org/dc/elements/1.1/date> ?date .
FILTER ( ( ?date > "2011-03-03T00:00:00Z"^^xsd:dateTime ) &&
( ?date < "2011-06-06T00:00:00Z"^^xsd:dateTime ) )
}
Even with moderate size stores this query can take quite a while to
execute.
I'd like to know if there is something I could do to speedup these kind of
queries.
I understand that the xsd:dateTime value is encoded by the
NodeTableInline.
However, I am not sure this is exploited at query time or I'd llike to
understand if there is something we could do better to further improve
performances of queries similar to the one above.
Thanks,
Paolo
