On 1 July 2016 at 15:46, A. Soroka <[email protected]> wrote: > On the other hand, a real sharp and simple (and inexpensive) approach would > be to say that Jena just doesn't maintain any non-core modules. If a non-core > module is interesting enough to a community that intersects with that of > Jena, it's on that community to find a home for it, either independently or > via some other project (Apache or no). For example, I'd be curious as to > whether the Commons RDF project could help host a Jena impl of Commons RDF. > This scheme has the advantage of minimal burden on Jena.
Hi! Glad you are picking up interest in Commons RDF and Jena :) For Commons RDF now we have dropped the earlier goal of being a "upper" interface for all the RDF frameworks. It could still very well work like that, but the problem that held us back I think was the stability issue - e.g. framework X didn't want to integrate with Commons RDF before it was "stable" (as in 1.0 and graduated from incubator?) - while Commons RDF didn't move forward without having any integrations to test it with. So now we have reconsidered our goals, and as our target is to graduate to be a component of Apache Commons, then we are now looking at the option of hosting integration modules ourselves as part of Commons RDF, similar to how Commons VFS has a set of implementations. Naturally these would then be wrappers rather than tighter integration as if you could modify the native classes of the framework - but if you do it carefully you can see it can be done without too much "translation" or cloning overhead. For instance the rdf4j module I would say is near complete now: https://github.com/apache/incubator-commonsrdf/tree/rdf4j/rdf4j (Note that this is based on the parser-with-quads branch which includes new Dataset/Quad interfaces and the RDFParserBuilder interface. Feedback very much welcome on both of these! See https://github.com/apache/incubator-commonsrdf/pulls ) I think Andy's approach is great, I have extended it with parser support in https://github.com/stain/commonsrdf-parser-jena - but I've not submitted this to Commons RDF yet; as Andy's code was not formally contributed to ASF I didn't want to do this on his behalf. I had considered to do a "clean room" approach - but of course my mind would be tainted :) Feel free to use my code though! So a similar jena module/branch would very much be welcome at Commons RDF - I would be very pleased if you would consider to contribute to it! :) Perhaps there's baked in a lot of "know-how" in the rdf4j approach that we should document - but it would be good to know your take as well, and questions that come up. There should not be a problem with the Apache Commons RDF hosting the integrations, as (on graduating to Commons) any ASF committers can update/fix them, and also a submitted pull request to update some pom.xml etc. would be easily reviewed by any of the Commons committers. If we change our mind, then it's very easy to move the integration over to jena-core with ASF - if rdf4j wanted to do the same I am willing to contribute my commits on that separately to the Eclipse foundation. -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons http://orcid.org/0000-0001-9842-9718
