On the 6th of February I presented my proof of concept chess game Solid Chess at Solid World. It is a monthly webinar where different themes of Solid are discussed. As a matter of fact, it was the first edition of Solid World. Here is a link to the next one. In this blog post I will summarize what I explained and discussed during my presentation.
Before I started developing the app, I decided upon three features that had to be included in the app:
The three libraries that I use and that I want to highlight are comunica, query-ldflex, and semantic-chess.
Comunica is a highly modular and flexible meta query engine for the Web. I use it to execute SPARQL queries on the files which I download from the PODs. Besides SPARQL, you can also use GraphQL-LD, which is basically GraphQL for Linked Data, and you can also do federated queries. That means that you can execute a single query over multiple, different data sources, including files, SPARQL endpoints, and TPF servers. So I recommend to have a look at Comunica in case you are dealing with (complex) queries in your app.
Query-ldflex is a library that brings the LDflex language to Solid. LDflex makes is easier for developers to use Linked Data and RDF in their applications, without the need to understand all the technicalities and details of the latter two. This removes the need for SPARQL queries in certain cases. Therefore, I highly recommend to check out this library as it will save you a lot of time writing and executing error-prone SPARQL queries.
Image that two chess apps are developed by two different companies. Thus, both apps are in the same domain, i.e., the chess domain. The companies decided that their apps store data in RDF on PODs. Nice! We can share data between both apps. Just like that! After playing with app A for a week you want to have a look at app B. But, when you open up the app your previous chess games, which you played with app A, are not shown. Hmmm that is weird. You quickly open up the dev console in your browser and notice that the SPARQL query that is fetching all the game information is not returning anything. Why is that?! Considering that both apps work with RDF, shouldn’t the query provide the expected results?
The answer is no. RDF alone does not solve the data interoperability problem. Although different apps can use RDF, they can have a different data model, which can make queries from one app unreusable on the data generated by the other app. How is it possible that different data models are created? Well, two, but there are more, possible reasons are that different apps tackle different problems and that different ontologies are used to model the problem.
Different apps tackle different problems within the same domain. For example, playing a chess game vs. creating a leaderboard of chess players. The game cares about every aspect of the game: the moves, the players, the state of the board, and so on. The leaderboard might care less about the details of game, but more about the details of the players, how many games they’ve won, and which tournaments they participated in. So the data model contains different types of information, with different levels of detail, which makes the reuse of queries harder.
Different ontologies that describe the same (sub)domain are used. For example, one app uses a chess ontology, while another one uses a board game ontology. This leads to the use of different classes and properties, which makes the reuse of queries harder.
When RDF data models are not designed with the required care, it will lead to isolated apps. One app will be able to work with the PODs of the users and users own their data, but another app will have a hard time using that data, which is not what we want. Therefore, the data model is one of the most important aspects of designing a Solid app.
Here are few practical pointers for when you design your data model:
schema:Eventto a chess game, though I don’t use it. But, for example, a calendar app, which works with events, can still show the game.
And, finally, an idea to conclude: what if we define shapes, for example, via SHACL or ShEx, for our apps to express the characteristics of the data that our apps generate and consume? This way we can check how compatible different apps are with each other and different types of RDF data. This has been mentioned too on the Solid Gitter and during the monthly Solid telco. What do you think?----