I am very excited about Solid. That motivated me to write my thesis about a decentralised wiki, where Solid is its foundation. For further information, you can have a look at my work journal (https://ma.parrillo.eu).
I saw on your blog about wiki data model example. Let's say you built a Solid app around that one. Put on a website like superwiki.com, allowing users to create their wiki pages.
Now then later, wikipedia came to scene, published another data model, and made another Solid app, put on wikipedia.org.
- How will I move let's say my data from superwiki to wikipedia? - Does wikipedia then have to somehow implement some import functionality? - Or Solid has to have a protocol (standard) for wiki entries?
Your data is not on superwiki, but on your Pod. So you can connect Wikipedia to your Pod, see your data in their app, but it's still in your Pod, rather than having been moved.
> Does wikipedia then have to somehow implement some import functionality?
As follows from the previous answer: no, because the data never moves to Wikipedia. However:
> Or Solid has to have a protocol (standard) for wiki entries?
No, apps define their own data model, so Wikipedia will have to understand Superwiki's data model. Ideally, they agree on a common standard for this, using that standardisation either as a selling point or as a way to comply with future regulations. But of course, an app could also just unilaterally imitate the other's data model, just like e.g. browsers imitated each others' extension API or bookmarks data model.
(Disclosure: I also work for Inrupt, but views are my own.)
So basically I am at Wikipedia and Superwiki's mercy for interoperability.
What is the value of having(hosting my own data) if I cannot move.
"unilaterally imitate the other's data model" sounds good at the beginning, but what will happen when superwiki is constantly evolving its data structure, and wikipedia also at the same time developing features. And now imagine this with N Actors instead of 2.
Regulations maybe can help on basic data , but for extended data there will be a lot of conflict. (ex: I can move my friend list, but can't move let's say special data I assigned to them in one app)
Since the underlying data structure is a graph, every application can attach arbitrary information to an node. But the application only retrieves the necessary bits. Furthermore, I think that apps must be able to handle missing bits to some extent.
I hope this is not confusing. If it helps, one could think of Solid to be the GraphQL endpoint, where the clients send queries expressed as SPARQL and only get back the requested bits of information.
The value of having your own data is, precisely, that you have your own data; nothing more and no less.
Furthermore, and although I'm no expert in Solid's and other implementations, it's quite likely that you, or other technologists, can more easily help you achieve the interoperability you so desire if your data is not locked away behind thousand APIs and rate-limits; after all you do have your data in your pod. Think of Instagram, what if all your data was stored locally? Even if it was stored in a really messy JSON schema or whatever you can think of; it's still trivial to massage that data to import it into Wikimedia, or iterate through it and send it in batches to your email, or remove it, etc.
I'm not sure how solid plans to keep applications from stealthily generating derivatives of the data they manipulate. I can imagine some sort of separation would have to happen at the browser level where the "app" provides a scaffold and the browser replaces in your data.
> I'm not sure how solid plans to keep applications from stealthily generating derivatives of the data they manipulate. I can imagine some sort of separation would have to happen at the browser level where the "app" provides a scaffold and the browser replaces in your data.
I don't believe Solid will be able to "enforce" anything - worst case, apps can just not use Solid. I see Solid as the technology that enables apps to respect your control of the data, but the incentives for implementing that has to come from elsewhere, e.g. customer demand or legislation.
(Again, personal views, not necessarily Inrupt's.)
Assuming each service has the capability to create and store data, that new data is still yours, and other actors could request access to it.
I think this will result in various actors taking on the burden of keeping up with the Joneses—which, I think, would eventually coalesce into similar services establishing their own versions of shared data schemas with their own unique value-adds on top. Of course, these value-adds are likely still your data, and it should create somewhat of a feedback loop for similar, even competing, services. You likely would only be bothered to grant additional data access as the shape of that data changes.
(Apologies if you already posted there.)
Any chance we can get rss for that blog of yours? :)