incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: SPARQL queries and paging
Date Mon, 08 Aug 2011 14:35:42 GMT

On 08/08/11 14:35, Simon Helsen wrote:
> On this topic, I'd like to point out that we have a separate outside
> mechanism for paging which behaves like you suggest, however, the
> difference with OFFSET/LIMIT is that the next time someone makes the query
> e.g. to obtain the next page, we do expect the query to be recalculated
> since the state of the store may have changed.
> So, if you plan to change the behavior by introducing a caching model, you
> may actually alter the behavior unless you are able to determine that a
> subsequent execution of a query would not have changed results (e.g. by
> having the actions isolated in a transaction?)
> Simon

Transactions, or just Fuseki noting updates (language or grpah store 
protocol), can be used to give a version id to each state and then ETags 
can be used to drive cache invalidation.

It's a three-layer model:

   SPARQL cache
   core DB.

ETags is between SPARQL cache and code DB.

The protocol between each layer is the SPARQL protocol.

The SPARQL cache can keep whole result sets for pseudo paging using 
ORDER/OFFSET/LIMIT with different policies on

The protocol between each layer is the SPARQL protocol but it coudl also 
augment the SPARQL protocol with parameters like ?page= or 
?liveness=uselastquery for better control (in addition to trying to 
intuit from requests and version ids).

Being able to set different consistency/cache efficiency tradeoffs in 
client of cache server might be useful.


View raw message