Thanks @csarven that's helpful. One of my concerns with JSON-LD is that it might lead devs astray in terms of the value and use of RDF.
Firstly, assuming RDF tools and libraries are more relevant to RDF and Semantic Web applications than JSON-LD tools and libraries (since JSON-LD was built for other purposes and with Semantic Web 'not even a consideration', at least to begin with). So RDF tools would I think lead devs towards uses, models and communities that RDF targets, and would I anticipate encourage practices that support the Semantic Web, and the application independence and interoperability that is fundamental to Solid. Whereas use of JSON-LD libraries and tooling could in turn discourage those desirable things.
Secondly, even if those concerns are not shared, I am at least as concerned if devs try to create JSON-LD with or without a 'dedicated library' and JSON-LD specific tooling. JSON-LD is not necessarily conformant if I understand correctly, whereas one hopes at least that any Turtle, n3 (or other conformant representations) generated by a 'dedicated library' would generate a conformant representation. I don't know if one can even be sure that JSON-LD tools and libraries will produce conformant JSON-LD, presumably not. And if JSON-LD is generated without tools it is even more likely to contain RDF bugs. So I see the need for a dedicated library as helping devs get things right, and a non JSON-LD library as preferable to a JSON-LD library at that, for improving outcomes including interoperability.
I can see why people familiar with JSON in the browser would be attracted to JSON-LD, but am concerned if that attraction might be a siren voice leading the unwary away from what might serve them better in the long term. Those are my thoughts in two large nutshells, but I admit I don't know enough to be confident of those positions, so any corrections and comments on this would be helpful. Thanks for reading!
@mediaprophet : What @timbl is saying is that he thinks and codes based on a realm comprising entities, entity types, entity relationships, and entity relationship types. He can even model for inferred entity relationship types (or even test their conceptual consistencies or inconsistencies) using N3 as a Rules Language.
For the rules part, you can also use SPARQL and terms from the SPIN or SHACL vocabs which enable it to function as a Rule Language too.
So the decision making boils down to using a language (or complimentary languages) that keep you rooted in a realm where entities are related to other entities in a variety of ways -- rather than being distracted by programming language symbols and the runtime objects they denote.
My rule of thumb: If you have to mention nodes, edges, and arcs in an attempt to describe an entity relationship type, the conversation is already completely broken, logically :)
@namedgraph_twitter regarding RDF-XML, the problem also became complicated by a combination of time and the general mindset around XML e.g., the notion that HTTP URIs didn't need to resolve which inadvertently lead to problems comprehending the utility of relative HTTP URIs that leverage "#" as an indexical.
In my experience, RDF-XML is a powerful notation for developing RDFizers (Transformers, Providers, Connectors) that emit 5-Star Linked Data.
Since 2007, we have developed close to 100 transformers for various APIs and Document Types using RDF-XML and XSLT. The key for us is keeping that in the box we call the Virtuoso Middleware Layer (a/k/a Sponger) i.e., users do not encounter RDF-XML at all, they simply enjoy the data wrangling and transformation benefits it provides :)