Hi Andy, Thanks for you reply. I guess when you say 'an Apache committer' you mean an Apache commit who's with Jena project. I would like to take this opportunity to ask whether any Apache committer subscribed here would like to mentor the project 'SPARQL Query Caching'
On Tue, Mar 18, 2014 at 7:21 PM, Andy Seaborne <[email protected]> wrote: > Hi Dinithi, > > Thank you for your interest - at the moment, no one has expressed an > interest in mentoring that project. Sorry about that - the project makes > paging results using LIMIT-OFFSET work quite nicely but unless someon step > forward (an Apache committer), the project is mentor-less. > > Andy > > > On 17/03/14 18:14, Dinithi Nallaperuma wrote: > >> Hi All, >> >> I am Dinithi Nallaperuma, a postgraduate student following MSc Advanced >> Software Engineering from University of Westminster, UK. I am fairly >> familiar with ontologies and related subject areas. >> >> I am interested in the project SPARQL Query Caching [1]. I would like to >> know whether there is any mentor who would like to mentor this project >> during the summer. >> >> I would also like to know your opinion on using JCS [2] to implement the >> proposed caching solution. I have some prior experience working with JCS >> and it can cater many of our requirements built-in. JCS supports in-memory >> caching as well as spooling to disc or database. Further it has a good api >> for managing the cache. >> >> The biggest challenge I've faced so far is cooping the modifications. One >> approach is to keep a mapping between the objects and SPARQL query results >> that referred them and invalidate the cache entry when an update to the >> object occurs. I would much appreciate any advise on how to coop with data >> modifications >> > > This is very hard in SPARQL because of negatives (parts of data that > caused results to be excluded), not just the parts of the data that lead to > a specific variable binding. > > That said, given that most use is publishing (more read than write), > dumping the cache after an update is a viable scheme in many situations if > the impact at the time of update is tolerable, such as during a quiet > period (like early morning). >
