...
The VIVO 1.6 development time frame is roughly November through March, although no release date has been set and that will be heavily influenced by what is added to the list of features for the release and by the availability of development effort from the VIVO community, including many VIVO installations outside the original NIH-funded VIVO grant that ended in August of 2012June with the goal of having a VIVO 1.6 out before the VIVO Conference, to be held this year in St. Louis, Missouri from August 14-16.
The list of candidate features and tasks below include both major and minor items from earlier road maps and development planning documents. Where appropriate, stages are suggested for development and implementation to reflect necessary design time or to allow for refinement of an initial design based on user feedback.
Please also note that significant changes are being made to the VIVO ontology through the CTSAconnect project and collaborations with euroCRIS and CASRAI. These changes, when stabilized, will also very likely result in a new kind of release focused almost exclusively on ontology changes and the associated data migration required to convert existing VIVO installations to the modified ontology. Most We anticipate more changes to the ontology for VIVO 1.6 than in recent releases, but most of the changes will affect the modular structure organization of the ontology or and the class and property names URIs and/or labels rather than the structure or design patterns in the ontology.
The following proposed features are not in priority or temporal order.
Please put other ideas here, even tentative suggestions
Performance
There are a number of possible routes to performance improvement for VIVO, and we seek input from the community on what the primary pain points are. Some documentation has improved, notably on MySQL configuration, tuning, and troubleshooting, but page caching has emerged as the primary performance-related improvement for 1.6.
Page caching
If you need your VIVO to display all pages with more or less equivalent, sub-second rendering times, some form of page caching at the Apache level using a tool such as Squid will likely be in your future. Apache is very fast at displaying static HTML pages, and Squid saves a copy of every page rendered in a cache from which the page can be rendered by Apache rather than generated once again by VIVO. The good news:
...
- improved server, Apache, Tomcat, and database configuration and tuning
- implementing Memcached to cache the results of commonly used SPARQL queries
- avoid issuing SPARQL queries for the same data repeatedly in the course of generating a single page
- optimizing SPARQL queries
- working around bugs in Jena's SDB that make queries other than to a single graph or the union of all graphs much less efficient
...