data-interoperability-panel VS rdflib.js

https://github.com/solid/data-interoperability-panel - the data interoperability panel, working on how to make sure that app developers utilize the full power of Linked Data so that end-users are able to transition between services with ease

Another possibly useful resource is https://docs.inrupt.com/developer-tools/javascript/client-libraries/, detailing the various JS tools Inrupt provides. Was thinking this could be useful to share, along with https://github.com/linkeddata/rdflib.js/, which is a powerful tool for working with Linked Data in JavaScript.

There's also rdflib.js (https://github.com/linkeddata/rdflib.js/) if you want another approach to handling linked data.

> Talking about RDF is absolutely meaningless without talking about Serialisation (and that includes ...URGH.. XML serialisation), XML Schema data-types, localisations, skolemisation, and the ongoing blank-node war.

Don't implement XML serialization. The simplest and most widely used serialization is n-quads (https://www.w3.org/TR/n-quads/). 10 pages, again with exaples, toc, and lots of non-normative content.

You don't need to handle every data type, and you can't even if you wanted to because data types are also not a fixed set. And whatever you need to know about skolemisation, localization, and blank-nodes is in the standards AFAIK.

> C'mon, rdflib is a joke. It has a ridiculous 200 issues / 1 commit a month ratio, buggy as hell, and is for all intents and purposes abandonware.

It works, not all functionality works perfectly but like I said I have used it and it worked just fine.

> rdflib.js is in memory only, so nothing you could use in production for anything beyond simple stuff. Also there's essentially ZERO documentation.

For processing RDF in browser it works pretty well, not sure what you expect but to me RDF support does not imply it should be a fully fledged tripple-store with disk backing. Also not really zero documentation: https://github.com/linkeddata/rdflib.js/#documentation

> > What are the alternatives?

> SIMPLICITY!

> But the great thing about it is that there could be dozens of equally simple systems and standards, and we could actually see which approaches are best, from usage.

Okay, so you roll your own that fits your use case. Not much use to me and it is not a standard. Lets talk again when you standardize it. Otherwise do you mind giving an alternative that I can actually take off the shelf to at least the extent that I can with RDF?

I am not going to roll my own standard, and if all the RDF data sets instead used their own standards instead of RDF it won't really improve anything.