One goal of Runrig is to provide support for the Solid Protocol, Linked Data Platforms (LDPs), SPARQL queries, Shape Trees and other semantic web technologies that open up pathways to smoother integration with other services and data portability by default. In order to do that, we will need to provide some kind of RDF serialization format. JSON-LD is the most common of all of these, and as a super-set of JSON, it should be possible using the serde-json library, just like we're already using for plain JSON.[^justjson]
The hardest part will be figuring out what existing ontologies to adapt and/or extend. For that, we should look to references like the NeOn Methodology.
[^justjson]: It's worth noting there are good reasons for more robust JSON-LD tooling, like justjson, whose author has provided a really helpful blog post on the pros/cons of just using serde-json. But I think for a proof-of-concept, serde-json should be fine, because there are plenty of bigger decisions to be had like settling on a long-term storage format and the best protocols for sending data over the wire in different scenarios, and I doubt we'll be writing raw JSON-LD to file forever rather than using something like oxigraph as a database and possibly running it behind a manas server or something similar when it comes to sending data across the network.
One goal of Runrig is to provide support for the Solid Protocol, Linked Data Platforms (LDPs), SPARQL queries, Shape Trees and other semantic web technologies that open up pathways to smoother integration with other services and data portability by default. In order to do that, we will need to provide some kind of RDF serialization format. JSON-LD is the most common of all of these, and as a super-set of JSON, it should be possible using the serde-json library, just like we're already using for plain JSON.[^justjson]
The hardest part will be figuring out what existing ontologies to adapt and/or extend. For that, we should look to references like the NeOn Methodology.
[^justjson]: It's worth noting there are good reasons for more robust JSON-LD tooling, like
justjson, whose author has provided a really helpful blog post on the pros/cons of just usingserde-json. But I think for a proof-of-concept,serde-jsonshould be fine, because there are plenty of bigger decisions to be had like settling on a long-term storage format and the best protocols for sending data over the wire in different scenarios, and I doubt we'll be writing raw JSON-LD to file forever rather than using something likeoxigraphas a database and possibly running it behind amanasserver or something similar when it comes to sending data across the network.