On 19/03/14 18:32, Dinithi Nallaperuma wrote:
Hi Andy,
Thanks for you reply.
I guess when you say 'an Apache committer' you mean an Apache commit who's
with Jena project.
In theory, any Apache committer but it does need someone with
familiarity wit the Jena codebase which in practice means someone with
the Jena project.
Mentors have several roles:
1/ GSoC Process (so you get paid!)
2/ Technical discussion
3/ Committing to the codebase (though forking on github means that isn't
major)
Andy
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).
