(I’m working on a project for just this! which operates on triples natively, called m-ld. I’m going to post a message in the General Discussion about it, because I’d love some feedback.)
I agree that CRDTs are coming of age. Up to now, most collaborative editors have been implemented more-or-less from scratch, at great cost, and specialised for their document type. That’s at least partly because it’s really hard to maintain reasonable & intentional semantics when edits are concurrent.
The emergent CRDT technologies typically express multiple data structures – usually starting with an append-only log, then lists and sets and counters and so forth, each of which sustains its basic semantics (uniqueness for sets, etc.).
Most of them then wrap these up in a native API which is exposed to the application. These can be somewhat complicated by the need to surface conflicts, if the underlying CRDT is not able to resolve them automatically (ironically, since the ‘C’ is supposed to stand for ‘Conflict-free’).
Almost all of the libraries out there are on the Javascript platform. There are pure data structures (Automerge, Yjs, Gun), and local-first replicated databases (OrbitDB, DagDB, PouchDB). A recent good review article with lots more detail is here: https://www.kn8.lt/blog/building-privacy-focused-collaborative-software/
So I agree with @Vincent that an important thing to do is to relate the syntax, and also the semantics, of the JS data structures, to RDF.
Personally I’ve gone down a different road, which is to start with RDF, and then expose what I hope is a usable API on top of it with JSON-LD, trying to make things easy for non-RDF apps.
I think an advantage of this approach is what @RubenVerborgh mentioned: RDF can carry its semantics with it. One thing I’m exploring is how to ensure that the semantics are enforced (especially in closed-world models) during concurrent edits. At the moment I’m working on specific common cases. Doing it in the general case is going to take some research! Gonna need help… 