I’m not convinced of these routes yet fellas 
JSON-LD:
I haven’t looked at how it handles triples, so I need to see how it does that because they don’t map well to key/value IMO (being three elements rather than two), though I’m ready to be corrected. I just don’t know yet.
Also, it isn’t clear to me that other RDF representations directly in the MD will be less efficient so that’s something to investigate.
This then leaves the question of using NFS and therefore IData to hold the representation. I like NFS compatibility because it exposes RDF to non Solid aware apps and devs. I expect that to start with there will be a lot of apps using SAFE NFS (including as a virtual drive) so I like the idea of exposing them to files containing RDF, especially in the early days.
WRT non generalised JSON-LD there’s a fundamental problem we create by directly supporting JSON, which is that people will create non compliant content in JSON-LD and store these without necessarily being aware that they’ve done this, or of the consequences. Whereas if we encourage use of a non generalised representation this won’t happen unless people decide to go their own way and generate something non compliant. Because of that, I think those folk are more likely to recognise the consequences and deal sensibly with them (eg converting from RDF stored by another app to JSON-LD and then save it back etc. I think they are likely to see and understand the problems of non compliant content).
The next issue here is that RDF is the way it is for reasons (which I don’t understand but think are probably important), and the tools and libraries designed for it will have features designed to exploit it and so generally be more suitable for the purposes intended for RDF. Whereas when using JSON-LD there will be some tools and libraries which are suited and some which are not - because they were designed for other purposes (eg APIs for which JSON-LD was designed in the first place). So I expect that with JSON-LD there’s increased likelihood of RDF compatibility issues. Some, perhaps most JSON-LD tools and libraries will be built by people who don’t realise this is an issue, or just don’t care because their use case is different. So I see potential for confusion and wasted time here.
Again I haven’t surveyed this, but it worries me, and if you are going to work with RDF I think there’s a benefit to learning to view it in an RDF representation designed for the purpose, rather than one which you may be familiar with but was designed for a different purpose.
Turtle is very readable IMO, but I need to look at some equivalent JSON-LD to know if there’s much at stake in this respect. So the wrestling continues
Forking RDF Libraries
I have forked rdflib.js and have proposed we do something similar with Solid-auth-client so that adding support for SAFE to an existing Solid app is as close to just dropping in the SAFE js modules as possible.
Because my changes are tiny I’m hopeful that at some point they will be merged by the Solid team and that compatibility with SAFE will become standard in any rdflib.js apps because of that. This is because those changes are literally a few lines, which is feasible because all I’m doing is enabling us to intercept calls to fetch() so we handle any requests for a SAFE URI. This route also means Solid apps which use fetch() directly will work with SAFE, and even those using XmlHttpRequest are trivial to convert. Solid apps can and do mix all these methods together, so if we don’t support at the level of fetch() porting a Solid app to SAFE is typically going to be much harder. It is also likely we would have to support many more libraries than rdflib.js. So it makes sense to start with a RESTful interface to SAFE based on intercepted fetch().
If instead we fork rdflib.js and other Solid libraries in order to bypass the RESTful API and go directly to SAFE API (with or without JSON-LD + MD) we lose a lot of this.
Simplicity v Efficiency
Unless I can be sure of the benefits, I tend to go first for simplicity, compatibility, and in our case ease of adoption by as many people in the Solid space as possible, and handle performance and efficiency later. Better get people hooked on SAFE and demanding faster, better stuff, than make them jump through hoops in order to try it out.
So we can always provide libraries that talk directly to the SAFE API as well, but I don’t think we should skip the step of providing maximum exposure and compatibility first, which is why I’m keen on supporting a Solid RESTful API via fetch() and perhaps also SAFE NFS in the first instance.
Fingers crossed that my skills have finally revived sufficiently to tackle that almost four years since David first suggested I have a go at it. Thank god I couldn’t attempt it back then lol).