This is what one guy did.

Now I'm in the process of adding this functionality to Qi4j! There are two parts to using objects/entities on the client: finding them and loading/storing them. In Qi4j there are two interfaces EntityFinder and EntityStore which respectively deal with these things.

What I have done now is to implement a REST-backend which allows you to access Entity-state through HTTP. Basically, the state of each Entity can be accessed through the URL /qi4j/entity/{type}/{id}, which will return the state as RDF/XML, along with HTTP headers like version and last-modified timestamps. I've then implemented a client-side EntityStore which accesses this REST-backend, so that for someone writing Java clients it is all transparent that the state is being accessed from some remote HTTP-server. When state has been changed it is PUT back to the server, with version checks being performed properly. The state can then be stored using whatever EntityStore is configured on the server, such as Neo4j, Amazon S3, JDBM, or even a database (for those who are so inclined).

For the finder part I have implemented a SPARQL backend, which internally delegates to Sesame2, which is the same default index/query that is used to find Entities in general. This in itself is pretty cool, because it means that you can write your domain model in Java, have it be automatically persisted in a store like Neo4j, and then with no extra effort expose it through SPARQL for AJAX webapps to consume (both RDF/XML and JSON output is supported today). Minimally writing a domain model only involves writing Java interfaces (no classes), so it's pretty easy to get started.

from: http://java.dzone.com/news/qi4j-rest-entitystore-and-spar