Is anybody familiar with a way to add reasoning on top of an existing SPARQL endpoint ? I can think about a component called "SPARQL Endpoint Reasoning Decorator", that will have a backward chaining reasoner. The Reasoning Decorator will itself be a SPARQL endpoint. It will receive a SPARQL query, apply the backward chaining reasoner to the query, according to some ontology - rewrite the query and send the rewritten query to the original SPARQL endpoint. This way, the inferred data will not be materialized in the decorator - no additional memory/storage will be required.
Here is a diagram to illustrate the question:
A solution could be similar to using InfModel of Jena on top of an existing Jena Model (InfModel is the Reasoning Decorator in this case). Is there a way to create Jena Model on top of existing SPARQL endpoint, without materializing the triples served by the endpoint ?
OWL2 QL is very amenable to query re-writing (you can do rewriting for all the profiles, but QL is an easy place to start), so you could easily put something in front of a SPARQL endpoint, rewrite the incoming queries, and forward those onto the endpoint. As you point out, this is the decorator pattern for reasoning & an endpoint. You could even do this client side and sent the rewritten queries directly to the endpoint if you don't have the ability to edit the endpoint itself, for example, the DBPedia public endpoint.
As you illustrated in your diagram, all your rewriter really needs is the ontology. I don't know of anything out of the box you could splat on top of existing Jena models, but I think you'd want to hook in via ARQ rather than a Model (Jena folks can correct me if I'm wrong). You might be able to implement the rewriting as an optimization to ARQ's internal query algebra, which after rewriting, can be passed onto the Model for querying giving the the reasoning support you're looking for.
There's a lot of scholarly work on how to best perform rewriting, and some of the more academically inclined folks on here might be able to point you to some good papers to read to get you started.
This appears to be just the kind of processing one can do with SPARQLMotion, which is basically a RDF data processing pipeline technology. See TopBraid SPARQLMotion for more. It would be pretty easy to set up and would look a lot like your diagram when finished, with each box representing a module - read in ontology, read in rules (in addition to reasoner), process via a reasoner, and output results in SPARQL Endpoint format as XML, JSON, csv or tsv. The edges would represent the order in which the actions occurred.
Well worth consideration for this use case. Disclosure: I work for TopQuadrant.