# Things to do instead of talking about blank nodes Feel free to contribute, this document is world-writable. 1. Do not talk about blank nodes. 2. Contribute to the SPARQL 1.2 [Community Working Group](https://www.w3.org/community/sparql-12/) * Check out the issues in [GitHub](https://github.com/w3c/sparql-12/issues). * Join the mailing list and ask how you can contribute. * If we discuss an equal amount of time into concrete proposals for SPARQL 1.2, we would actually move RDF forward. 3. Check out RDF support for the programming language(s) you work in. * Is there anything missing? * Could you contribute to it? * Could you help with documentation? * Do you have some money to spare to support those who drive it forward? 5. Help to improve developer-experience. * Write an article about something you do with RDF, document it in a way that people can reproduce it on a small pet project. * Do a screencast about topics you are good at & post it on Youtube. * Post it on your blog or on sites like [rdf.community](https://rdf.community/) and announce it in the [discussion forum](https://discuss.rdf.community/). * Remember that Medium will shut down sooner or later, do not post there. 7. Think about higher-level abstractions. * RDF is great. There are some issues but most of them can be fixed with better tooling. Think about what you had troubles with and what helped or could have helped you to solve it. * If something is missing, rise a discussion on sites like [rdf.community](https://discuss.rdf.community/). Avoid places like semantic-web@w3c.org or we get another blank node or HTTPRange-14 discussion that never leads to anything useful in the real world. * Channels with practitioners are preferred to those where all the research-oriented crowd is hanging around. Nothing wrong with research per se but we have to _just f-ing do it_. 8. Merge the benefits of REST APIs and RDF * Enterprises are adopting microservice-based architectures based on REST APIs, and not based on SQL or SPARQL endpoints. A REST API can expose resources described in RDF, in order to subsequenyly enable linking of resources from different APIs and support true Linked Data. But a REST API returning RDF can be implemented in many different ways. Several aspects of such a REST API can be standardized (e.g. data model of resources, discoverability of resources, documentation of API, description of versions of resources). Standardization efforts exist for REST APIs returning JSON such as OpenAPI/Swagger. For REST APIs returning RDF, I can think of Open Services for Lifecycle Collaboration (OSLC), which is being adopted in the engineering community but which can be applied in more domains. Post on the [OSLC forum](https://forum.open-services.net/) or the [OSLC Slack channel](https://join.slack.com/t/oslc-op/shared_invite/zt-8i27g1xx-D3Z0J0P~zvlS_YUBBrzMng) if you want to learn more about OSLC. ## Where to spend time on Feel free to add ideas here, it should be world-writable. * There is still a lot of work to do in the JavaScript stack. Check out efforts like [clownface](https://zazuko.github.io/clownface/#/) and give feedback what works for you and what does not. * Check out novel approaches for open source triplestores like [Oxigraph](https://github.com/oxigraph/oxigraph) and contribute.