Decentralized chess game


#21

Excellent work Pieter! I wonder if anti-cheat mechanism would be harder to implement in such scenario (turn-based), in comparison to real-time games such as RTS or MOBA.
I mean, cheating in real-time games would require capturing all opponent moves, then taking the right decision through an automatized reasoning process. :thinking:


#22

Great post that provides great insight into the kind Single-Page application simplified by the application development framework that Solid provides.

BTW – I tried to lookup your Chess Ontology but its URI doesn’t resolve. What’s the reason for that? Fundamentally, you can publish your ontology via your POD i.e., it doesn’t need tp be published via purl.org. Likewise you don’t need http://example.com when you can replace that with an @prefix : <#> . declaration i.e., leverage relative HTTP URIs power :slight_smile:


#23

Good question. There are some extra things that ideally would need to be added such as a verification of a move, i.e., is this move really coming from my opponent or not.

The ontology is not mine. I found it in this paper.

Originally I had those, but to be honest for people who are not familiar with Turtle/RDF this is a bit confusing I think. Well, at least for me it was :smile:


#24

Relative HTTP URIs are at the very core of what Linked Data delivers.

See this Simple Linked Data Deployment Tutorial that demonstrates the point. For instance, a lot of the misconceptions about Linked Data Deployment are rectified by use of “#” and relative HTTP URIs :slight_smile: