3 ms·
I have returned RDF/N3 from my web services for years. And transformed that data into a Javascript graph of objects on the client with the library available at
by lolive 11y ago
I have returned RDF/N3 from my web services for years. And transformed that data into a Javascript graph of objects on the client with the library available at https://github.com/RubenVerborgh/N3.js https://github.com/RubenVerborgh/N3.js.
It is very flexible. Each object has a unique identifier. That identifier is dereferencable as a URL.
Each object has a type (because the Semantic Web is all about typing your data, and applying your code on data of a given type). The graph can be traversed in any way I want on the client.
Honestly, this makes things quite simple.
- purpled_haze 11y agoI like the idea behind the semantic web and if everyone had the bandwidth to commit resources to it, it would definitely add additional abilities to the web. But, in my experience, the time spent on adding RDF support wasn't worth the adoption or limited gains in site usage. What are its usage metrics in your site(s)? Does it appear that there is significant growth in its adoption? Facebook's has offered RDF for a while. I've not heard of its use outside of academic circles.
- lolive 11y agoRDF has no adoption. JSON is the winner. Let's try to understand why: Because JSON.parse() is instantly available on the client. On the contrary, RDF.parse() (or more precisely N3.parse()) is available on the client only if you use that obscure library I mentionned above. Noone knows the library, so noone uses the N3.parse(). Ok. End of discussion. Now my own feeling: RDF (and especially its N3 dialect) is the only description language I know of that serializes and deserializes graphs with no specific code, and has a good JS lib for client-side consumption. JSON (or XML, or any other tree descrption language) requires extra effort whenever you use it to serialize/deserialize/traverse a graph structure. That is why i think they suck. And that's why I prefer RDF/N3.