There’s a considerable amount of work in flight dedicated to making interoperable ecosystems of applications and data on Solid a reality. A lot of this work is happening under the remit of the Solid Data Interoperability Panel.
Because interoperability is a fundamental value proposition of Solid, these patterns and mechanisms end up having a strong influence over how software compatible with these ecosystems gets made. Consequently, most of the work we’re doing under the umbrella of interoperability relates to solving some of the most frequent problems and questions that developers building things on solid need answered. How should data be modeled and organized?How can I ensure that another application doesn’t corrupt the data my application needs to function?How does collaborative access and sharing work?
Ultimately, we’ve realized that we need to solve machine to machine interoperability, and human to machine interoperability, in concert. This makes the work a bit harder, but (imo) a lot more fun.
So while we’ve been heads down doing what I think is some really compelling stuff on this front, we’ve not done a great job reporting on that work. We haven’t engaged the broader community enough beyond relevant panels and spec contributors. We’ll be using this category as a place to share and collaborate on related topics and work pertinent to interoperability with any of you who are interested in it.
From myself or other panel members, you should start to see weekly recaps, and updates on key interoperability-related initiatives. There’s plenty of material, so the initial posts will focus on work to date to provide context, which should help make the minutes and subsequent updates more digestible.
This is great, @justin, very happy to see this forum interaction taking shape.
I have one question about the Interoperability panel: Reading the Problems and Goals it is not clear to me if with Interoperability you mean primarily the interop within the upcoming Solid scope / ecosystem as it is evolving, or that you mean interoperability in the much broader sense: with the web at large, i.e. ensuring that Solid fits as well as possible with what is already out there, and making transitioning to Solid as easy as possible (in the latter case you would see connection to other initiatives as part of the panel’s scope).
Edit: Ah, I just see that you are probably focused on Solid 2 Solid interop, as I see that the External Interop and Outreach Panel is dedicated to the outside world.
PS. @anon36056958 the category link is working for me, but if not for you you should be able to find it in the forum structure (categories dropdown).
Thank you very much @justin, I think this is making a big difference. I knew already about panels, but somehow they always felt kind of “closed” and “far away” for some reason. Perhaps because the panel meetings fall into my working hours and it costs a lot of time skipping through all the github repos and issues. Time I prefer to spend on coding Solid apps. So having a regular recap here is very useful and appreciated.
Great point/question. Our primary focus has been interoperability within the Solid ecosystem. While not explicitly stated, having this foundation makes it a more tractable problem to establish integration patterns with other ecosystems that aren’t Solid based. Still, real world use may be likely to happen faster when we can readily bridge between ecosystems that employ different standards. Establishing these integration patterns is another dimension of interoperability, and I suspect we’ll end up tackling those under this umbrella once we get the main foundation laid down within Solid.
I was surprised to read this, because when the panel was set up I thought I was invited because of my work to provide a Solid compatible later for SAFE Network!
Other backend integrations were also being mooted and I thought due to be discussed there.
Has there been any work on the panel or elsewhere looking beyond Solid servers, and might the lack of this, and apparent change be due to Inrupt’s priorities?
I know @jeffz has been making libraries to help extend storage options for Solid apps. Has that been in isolation, or is there some coordination that’s not been apparent? I have wondered if there was some strategising around what to focus on and coordination of library design, but I haven’t seen it. So if it wasn’t happening in the panel, maybe not!
AFAIK external-interop isn’t an active panel. That’s the main reason I mentioned that it could be addressed by the data interoperability panel in time as a natural evolution (unless that panel becomes active). FWIW - inactive panels were raised in this issue and it’s something that we have to look to remedy (likely through some combination of stimulating activity, reorganizing, or consolidating).
Better answered by @jeffz, though we’d welcome his input and collaboration on any of this work
As I understand it, the primary focus of the interoperability panel is interoperations between apps supporting an ecosystem of apps that don’t interfere with each other. My work on Solid Rest approaches a different kind of interoperability - using rdflib, the databrowser, and other Solid tools on a variety of non-pod backends - the local filesystem, dropbox, etc. Are these two kinds of interoperability related? That one’s better answered by @justin :-).
If they are related, I would definitely be interested in being involved in any way that would be helpful.
“Interoperability” can mean so many things depending on what is interoperating.
multiple apps operating on the same data
an app operating on multiple backends
an ecosystem like Solid’s interacting with other ecosystems like did
…
I believe on first reading that the interoperability panel uses only the first meaning. Solid Rest uses only the second meaning. On first hearing the name of the panel, my assumption was that it was about the third meaning.
While we’ve been principally focused on solving problems related to the first point, the others are important and complementary. I do think we can benefit from closer collaboration across the broader spectrum of interoperability. Advances on one track will speed advances on another. In many cases, you can’t make real progress without nailing down the fundamentals in an adjacent track. A good way to make discussions like this actionable is to pull together some straightforward use cases and look at what’s available or needed to fulfill them.
I have begun compiling a set of use cases related to using Solid on non-pod backends. If @justin or anyone knows people who might be interested, please have them get in touch. I guess I’ll submit it as a PR to the interoperability panel? Or other suggested place?
We’re working on a standard use case document that ultimately will end up in solid/specification through the interoperability panel (history here). In a few weeks you would submit those in a pull to use cases there. Trying to figure out the best holding area in the meantime because i’ve got some as well. While we’re figuring that out - if you want to do some discussion on them in the meantime you could always create a thread in this category or make an issue on the panel repo.
