Roadmap
On this page
This page gives an overview of the long-term goals of Comunica in order of priority, which is determined by the Comunica Association.
Interested in helping out? Find out more on how to contribute.
Improving overall performance
All performance-related issues
Comunica has been designed with modularity and flexibility as primary requirement, while performance was a lower priority. Nevertheless, experiments show that the performance Comunica of is still very similar to equivalent engines.
As Comunica is being used increasingly in more use cases, for larger datasets and more complex queries, specific performance issues are being identified. In order to resolve these, new algorithms may need to be implemented, upstream packages may need to be evaluated, or even some architectural changes may be required in some cases. Next to that, issues related to lowering the browser bundle size are also of interest.
Developer experience
Code-specific improvements are possible to make it easier for developers to work with and in Comunica. For example, errors can sometimes be too cryptic, which hinders development.
A list of all open developer experience issues can be found here.
Outreach
We intend to connect with different communities that may have overlapping interests, which we can do by lowering the barrier to entry for developers from other communities. This can for example be achieved by providing pre-packaged versions of Comunica that work out-of-the-box in other environments, such as for example rollup.js.
Future-oriented development
In addition to specification compliance, Comunica is being built with possible future specifications in mind. Comunica should become a testbed for easily testing out new query features and techniques. For instance, for efforts such as RDF*/SPARQL* and SPARQL 1.2. This also includes making Comunica ready for new technologies such as ESM and WebAssembly.
While the architecture of Comunica has been built with this flexibility in mind, some specific changes will need to be made before this is possible. For instance, testing new SPARQL 1.2 query features will require the development of a new SPARQL query parser, since our current parser (SPARQL.js) is not flexible enough in that respect.
Tangents
Below, you can find several topics that parts of the community are working on, but are not part of the general roadmap.
Different forms of query execution
Point of contact: Ruben Taelman
Comunica's current query execution model relies on defining a set of data sources to query over. While this traditional form of query execution works well in many cases, it can be too constrained in cases where data is spread over many sources across the Web, which are interlinked.
One alternative form of query execution is Link-Traversal-based Query Execution, where links are followed on the Web to find data.
A future goal of Comunica is the integration of such alternative forms of query execution.
You can learn more about this work on our experiments page.
Alternative query languages
Point of contact: Ruben Taelman
SPARQL is currently the (only) recommended way of querying knowdlege graphs that are represented in RDF. However, there is a wide range of new graph query languages emerging, such as GraphQL, Cypher and GQL, each having their own advantages. As such, being able to express queries over knowledge graphs in different languages may be valuable for different use cases.
For instance, GraphQL-LD already offers one alternative language in which queries can be expressed. Compared to SPARQL, GraphQL-LD is less complex, but also less expressive.
GeoSPARQL is another language that may be investigated in the future.