first of all Andy thank you for your leadership as PMC chair of the Apache Jena project, the PMCs and the Jena community. I do believe Jena as a technical project is in a good place to be considered as the development choice for any possible RDF related effort at this point.
Over the last 20 years the semantic web community (yes 20 and the Jena project will indeed turn 20 in 2020) has seen a number of transformations that have also, in one way or another, found their technical expression in form of new modules and / or capabilities in the Jena project. I believe future versions of Jena need to be a bit bolder, this while maintaining basic API features and design choices for compatibility in a maintenance release. Jena 4 might be a good candidate for such a LTS maintenance release while Jena 5 should take a more ambitious approach and innovate where it hasn't made inroads in the technical community yet. (SPARQL 1.2, RDF 2, parallelization/concurrency, improved scripting support, web focus, UI, integration with other projects etc). I believe last time we have seen such transformative change to Jena was for releases 2.7+ and the migration of the project to the Apache software foundation almost 10 years ago. And IMO an area that needs closer attention as well is documentation, education and outreach. I am not sure where we currently stand in regards to developer adoption, downloads and deployments etc but it would be useful to gauge this type of information more systematically and more regularly for project reviews. Marco On Wed, Nov 13, 2019 at 7:18 PM Andy Seaborne <a...@apache.org> wrote: > I'd like to start a discussion on where the project might go longer term. > > This can be specific areas, overall design, about project processes, > anything. > > If we are going to do a major change, Jena4, what preparation for that > can be done? (e.g. deprecation and signalling in Jena3, before the > change happens). > > Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4 > need not be that big - we can have Jena5 etc. > > I'll put some technical points in a separate email. > > I would put on the list: > > * How has the world changed? What should the project produce? > * Target audience: for developers of Jena, while Jena3 is for users. > * Target: Java14, JPMS. > * Clear-up not easily done with perfect compatibility. > * Simpler. There are APIs and packages entangled due to history. > > To the lurkers :-) > > Feedback and specific feature requests are welcome. But before you "go > shopping", you may wish to factor in that every feature needs effort to > do it. The better place to be is that an application can get what it > needs to do, not whether the Jena system has every feature built-in. > > Andy > -- --- Marco Neumann KONA
