Alex Alishevskikh - 2014-06-04

Hi all,

There are ideas for the next major version of the library (a prototype is already commited into 3.0 branch on SVN):

  • Drop out the RDFBean classes functionality in favor of pure interface-based databinding approach. The thing is that since introducing the dynamic proxy binding in RDFBeans 2.0, I found myself modelling my stuff exclusively with RDFBean interfaces. This gives me a cleaner design, simplification and better maintainability of my code, now completely free of the aspects of objects persistence.

Thinking of future development, I realize that it would be a pain to implement new features in two versions. What's more, the dynamic nature of the interface approach opens a way for some exciting new things, either impossible or difficult to implement with the stateful beans: the examples are the virtual properties (transitive, symmetric), getter methods mapped to Sparql queries and so on.

There are some concerns about this move though - the biggest is the performance - probably, not everyone would be happy with getters and setters being the blocking IO operations. Although in the most cases, it is enough just to keep this fact in mind while writing the code, some smart caching both on proxy instance and property value levels might be helpful. Another thing is compatibility with external Beans frameworks (like Spring) - I have no idea at the moment.

  • Drop out RDF2Go dependency. OpenRDF SAIL API is an abstraction layer itself with a number of implementations for different triplestores. Also, RDF2Go seems being inactive and not maintained for a long time now.

  • Better transaction support: instead of fiddling around the "autocommit mode", there should be a clean mechanism of executing a group of setters in an atomic transaction-safe manner, that would hide the low-level calls to the underlying store API.

  • RDFBeans Generator. A very old idea of a tool to generate RDFBean interfaces from RDF Schemas and/or OWL ontologies. One can find some experimental code on SVN but it never worked properly: simple at the first glance, it exposed some conceptual issues not trivial to fix. I think I would continue this development if there is a demand for it.

Any feedback is highly appreciated!