SOLID ("Social Linked Data") is an emergent technology being incubated by W3C and Tim Berners-Lee's new company Inrupt.
It promises to reinvent the web in an open and decentralized fashion, where you interact with apps that store their data on infrastructure you control (a solid "pod"). This sounds good, right? Well, at the surface, it sounds good, unfortunately there are serious defects that make the viability of SOLID's adoption amongst developers unlikely.
SOLID is built on the RDF data model.
RDF is an extremely flawed data model. While the general idea of encoding relations between objects in the same way as we would use human language is enticing, the implementation is... quite lacking. The RDF data model does not even support lists (although it has sets which can act like lists if you squint hard enough).
Because of the lack of natural data types that developers expect to be present in a data model, using RDF feels unnatural, which translates directly to it being an unpleasant tool.
The original RDF specification only provided one way to represent an RDF document: the RDF/XML representation (as an aside: the Netscape/Mozilla
bookmarks.html format was built on top of RDF/XML, specifically using RDF and XHTML together).
The overhead of having to write XML to represent semantic data lead to other representation languages being developed, starting with N-Triples, which evolved into Notation3 and finally Turtle. Turtle is the preferred format for semantic web researchers today, although TriG may replace it eventually.
RDF models can also be represented in HTML, as so-called Semantic HTML. When people talk about microformats, OpenGraph or similar technology, they are talking about various takes on Semantic HTML.
Because of the requirement of RDF to be portable in some way to all of these formats, the RDF data model has suffered greatly -- it is effectively the least common denominator of all of these different formats.
(As a side note, Audacious uses RDF internally, first using XSPF as its preferred representation of library data, but later moving to a custom format which encodes the triples as a bare document.)
JSON-LD was created by Manu Sporny as an alternative to RDF, allowing for developers to make practical use of linked data.
At the same time, the RDF working group discovered that developers really like to use JSON, so they prototyped a JSON-based representation called JTriples. If you look at the examples on the wiki page, you'll understand why the developer community wasn't interested in what they had to offer: it is basically Turtle, but represented in JSON.
Eventually, the chair of the RDF Working Group decided to call up Manu Sporny and ask him to bring JSON-LD under the auspices of the RDF Working Group, and JSON-LD became the JSON representation for RDF objects.
JSON-LD also extended the RDF data model so that working with JSON-LD feels natural (it can do anything JSON can do).
Anyway, if you're interested in the unholy union of JSON-LD and RDF, Manu Sporny is more qualified to tell that tale.
Let's talk about ActivityPub
Now that the technical background concerning the various ways to represent RDF documents are out of the way, let's talk about the only remotely successful Social Web protocol the W3C has released, ActivityPub.
ActivityPub is essentially a very clever combination of ActivityStreams 2.0, Linked Data Notifications and an actor model. It has been adopted by dozens of free software projects wanting to build social graph features into their apps, the most popular being Mastodon and PeerTube.
ActivityPub is very explicitly built on JSON-LD. The examples are all JSON-LD and the specification explicitly says that JSON-LD is the only representation allowed on the wire between peers. This means that developers can work with the tooling they already know: the JSON library in their programming language, and it's guaranteed to always work.
It is because of this that ActivityPub has been successful: you can just jump in and start hacking.
The main defect of SOLID.
SOLID is not explicitly built on JSON-LD, instead JSON-LD is one of two supported representations: you can either compose your messages in JSON-LD or in Turtle.
Turtle, if you didn't already know, is depicted in the screenshot at the beginning of this post (which itself is from part of the SOLID Interoperability specification).
While it is true that some languages have high quality libraries for composing and reading Turtle documents, it is yet another thing that you have to deal with to implement a SOLID pod or a SOLID application and be conformant.
There is no stepping around it: the specification says you must support Turtle and JSON-LD.
The reality of this situation is political: W3C is unwilling to admit that almost nobody actually wants to use RDF, so they try to push alternate RDF representations like Turtle into the work they produce.
This situation means that developers will either not embrace SOLID, or they will just ignore the Turtle requirement and W3C will eventually have to concede and remove that requirement from the specification.
To be clear: ActivityPub is successful because the specification authors decisively ignored RDF and went all in on JSON-LD. If SOLID wishes to have the same success, it must reject Turtle and do the same.
If you want to build truly world-changing technology, you have to focus on the future and not the past. JSON-LD is the future and traditional RDF is the past.
February 17, 2021 [12:28:00]