I love the idea of Solid and firmly believe that a user should always own and be able to access and manipulate their data in any application they are using.
However beyond syntax, semantic interoperability is always going to be hard - maybe thats why we have standards organizations! I remember the days of CORBA, and XML/SOAP/WSDL (then REST, JSON etc), there is no silver bullet. Except in specific narrow domains its hard to see how there can ever be serendipitous interoperability.
Within specific domains tho maybe theres hope. I've always been a plain text fan and am pleased to see the common usage of markdown in a lot of modern note-taking apps - there's clearly interoperability possible between Obsidian[1] and LogSeq[2] with common markdown files.
The TODO app example from the article is an interesting space. There are thousands of todo/scheduling/productivity type apps. They should be able to plug and play from a common data store. I'm personally banking on using org-mode as the data store for my BrainTool app[3]. Its thus interoperable with the emacs org ecosystem and other tools like LogSeq.
Org-mode is human readable and covers all the basics of headings, todo's, links, timestamps, tables, checkboxes etc. I'd love to see an ecosystem of serendipitously interoperable org-based productivity and PMK products!
[1] https://obsidian.md/ [2] https://logseq.com/ [3] https://braintool.org/2021/04/21/My-BrainTool-orgmode-and-em...
The crux of the problem lies in the semantic mapping (lenses / shapes in the article) and the transformations potentially required to map data that is not 1:1
Standards change / evolve, and for each "lens" you have an input and and output schema to keep track of (and potentially, the transformation logic associated with it).
This implies the existence of a transformation layer, capable of both running the logic and accessing the data - which prompts the question "where will this live".
In an adversarial interop scenario, I would expect the "adversary" (the side making the effort) to be hosting this. In a system built for interop from ground-up (yes, pipe dreams) it could be a dedicated subsystem that also enforces access control on the data.
It's definitely an interesting problem!
For those unfamiliar with the author, they're the developer of the most prolific apps created to work with Tim Berners-Lee's Solid: https://solidproject.org
I think something intermediate between his two solutions could work very nicely. Perhaps a set of competing translation repositories, and asking the user which if any to use. There's still a trust issue with the translations, but that's right the problem we already have with open source, and the downsides are probably more limited security-wise. You could still have the option for the user to supply a translation. Having common schemas that apps commonly target for bidirectional translation increases the odds that you can have serendipitous inter-app translation using only "first-party" translations by going through the common format.
Why not xml and xml schemas?
In fact you can use XML, but not barebones XML. XML does not contain semantics, which is needed to achieve interoperability. So you should use some more specialized XML, namely, RDF/XML. Which of course will increase complexity to XML. You can use also JSON-LD, which is a more complex JSON bc it adds semantics.