Hi Andy Andy Seaborne wrote: > On 09/10/11 22:26, Paolo Castagna wrote: >> From my (and Talis) point of view: >> >> - scalability and performance (loading and querying) >> - ease of use (Fuseki did a great job in that direction) >> - better modularity and a small Jena core module >> - ability to create and keep up to date custom indexes (a la LARQ) >> - authentication and authorization (added to Fuseki?) >> - high availability (a simple master/slave replication solution >> would do) >> - a good solution for "geo" and SPARQL >> - TxTDB (ongoing) not to block reads while write transactions are in >> progress >> - a scalable inference engine(?) >> - ... > > There are three axes: time, resources and functionality. It's not a > free choice: choose two and the third is determined. Other limitations > may apply.
The roadmap isn't a definitive commitment and it does not necessarily need to explicitly include (on the HTML page) considerations on time or resources. The current page already lists a couple of desired or expected, but are not yet underway items: - OWL 2 support in ontology API - migrate package names from com.hp to org.apache "Not yet underway" does not create expectations (which is good), but it communicate that those are desired features/additions. IMHO, a couple of good examples of project roadmaps are: - https://cwiki.apache.org/confluence/display/WHIRR/RoadMap - http://code.google.com/p/google-refine/wiki/Roadmap There are plenty, I find them useful. Some projects communicate progress using roadmaps in JIRA: - https://issues.apache.org/jira/browse/WHIRR#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel I find that useful too for the projects I use/depend on. It quickly and clearly gives me a rough sense on how far off is the next release. What should I expect in it. It also gives hint to people who might want to help moving faster towards a release on where their help is needed most. Last but not least, it gives people a sense of direction. > > Making tiny incremental steps on too many fronts doesn't lead to real > progress. I agree. > > What are the priorities for Talis and how much time&resource is Talis > prepared to contribute to each priority? It's not just about Talis. It's about Apache Jena, independently from Talis. For example, a few items I mentioned in the list above are not strictly speaking needed by Talis in the short or mid-term future: - ability to create and keep up to date custom indexes (a la LARQ) - authentication and authorization (added to Fuseki?) - high availability (a simple master/slave replication solution would do) We did not found a solution for these problems out-of-the box and we needed to develop our own. However, I imagine that most of the people wanting to use Fuseki in production would need think about how to secure access to their data or how to guarantee high availability (or improve/increase availability). A first step could be to agree on a list. Then we could divide the items of that list into two groups: short/mid-terms and long/distant future. An example of item I would include in the short/mid-term is: - migrate package names from com.hp to org.apache >From a point of view of Talis: scalability (*) and performances of TDB and ARQ together with transactions (now that TxTDB became TDB) is certainly on top of the list. Something I am personally interested in and keen to do is: - ability to create and keep up to date custom indexes (a la LARQ) - a good solution for "geo" and SPARQL Paolo PS: (*) I still have 1 billion triples|quads dataset to load into TDB. > > Andy
