Paolo Castagna wrote: > You might be interested in this thread from jena-dev mailing list: > http://markmail.org/message/p5x334m7dy676oik > > In particular point 3. which I report verbatim here: > > "3/ Paging. > > The idiom of a sequence of SELECT / ORDER BY / OFFSET / LIMIT calls with > changes in OFFSET to get different slices of a result set happens in linked > data apps (and others). > > We've been optimizing these in ARQ using "top N" queries but LD-Access can > offer facilities at a different granularity. Catch that query, issue the full > SELECT / ORDER BY query, cache the results. > Then you can slice the results as pages without going back to the server. > > One side effect of this is paging without sorting, another is moving > sorting away from the origin server. > > Sorting is expensive but it's needed to guarantee stability of the result > set being sliced into pages. So issue the query as SELECT and either sort > locally (you get to choose the resources > available), to get the same sorted pageable results. Or if ordering is only > for stability, just remove the ORDER by and replace with a promise to slice > from an unchanging result set."
LD-Access - A caching layer for SPARQL endpoints https://issues.apache.org/jira/browse/JENA-140 it's classified as a "Major", "Wish". You can go on JIRA, add your comments/ideas/support... or vote|watch it. Current experiments/prototype is here: https://github.com/afs/LD-Access ... it's Scala. Now, how do we make a "Wish" come a closed "New Feature"? :-) Paolo
