One example is the type index, which is a way to declare where you data is stored so that other apps can find it. However, it’s perfectly possible to make a Solid app that doesn’t declare its data in the type index. This means that other apps have to know the exact location where the data resides, or they won’t interoperate properly.
I consider the ‘location’ part of the schema.
Even with lenses, I’d say the chances are very low — you still have to know about the other app in order to define the translations.
This is true at the moment. I hope it’s not naive of me to imagine a future where lenses become a normal part of the development process and we begin schema design by considering existing translations, especially for common use cases like todos or notes—it’s an easier sell if it allows developers to ultimately do what works for them and ‘not worry about schemas’.
One possibility would be to rely on crowd-sourced repositories of translations.
Geoffrey Litt and I might both be inspired by the idea of ‘converters’ in Jef Raskin’s writing—this quote might have been phrased as a ‘marketplace’ of ‘transformers’ where people buy, sell, create, and maintain these bridges between apps. If I remember which book this was in I’ll share it one day. Geoffrey also has an interest in web scrapers (Wildcard might be the best current example) so I’m sure he’ll have more to add to this topic at some point.
A practice of defining lenses/converters/transformers/shapes and centralized vocabularies may have all the tradeoffs you mention, yet can still be a good foundation for automating schema-matching, which could indirectly look like interoperable serendipity.
I think this highlights the progressive nature of interoperability. It’s probably useful start with something known and achievable, limit scope, and focus solely on decoupling data from the apps. Might be easier to see solutions for interoperability in another phase of evolution.
To me this is all interchangeable: schema, file, extension, type, shape, protocol, format all encompass ‘the data and where it’s stored’, and I believe lenses should transform between all those parameters.