4 ms·

I understand data is not moving but if data structures are different there has to be some kinda merge or cloning of the data. So basically I am at Wikipedia an

I understand data is not moving but if data structures are different there has to be some kinda merge or cloning of the data. 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)

fuubi 7y ago
Correct, you are at the mercy that both Wikis are interoperable. But, each of the N actors can have its model and only agree on an abstraction, which the interoperability is based on. Let's assume an application provides a new feature, which deviates from the abstraction model. As an example, that feature could be of a "like" counter. The counter would then only be visible in a subset of application. 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.
jdsalaro 7y ago
> What is the value of having(hosting my own data) if I cannot move. 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.
- Vinnl 7y ago
  I think that is spot on. As for: > 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.)
bobwaycott 7y ago
My understanding and expectation are that it’s up to various actors to build processes/apps that use what data you have and make available to them in ways that are meaningful for their service. You then get the benefit of having YourData in services X, Y, and Z. In your example, your data has a Superwiki presence and a Wikipedia presence, which may not be identical, as its up to Superwiki and Wikipedia to present your data in their own meaningful way. 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.

fuubi 7y ago

Correct, you are at the mercy that both Wikis are interoperable. But, each of the N actors can have its model and only agree on an abstraction, which the interoperability is based on. Let's assume an application provides a new feature, which deviates from the abstraction model. As an example, that feature could be of a "like" counter. The counter would then only be visible in a subset of application. 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.

jdsalaro 7y ago

> What is the value of having(hosting my own data) if I cannot move. 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.

Vinnl 7y ago
I think that is spot on. As for: > 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.)

bobwaycott 7y ago

My understanding and expectation are that it’s up to various actors to build processes/apps that use what data you have and make available to them in ways that are meaningful for their service. You then get the benefit of having YourData in services X, Y, and Z. In your example, your data has a Superwiki presence and a Wikipedia presence, which may not be identical, as its up to Superwiki and Wikipedia to present your data in their own meaningful way. 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.