I read this article when it was published and it was very enlightening, thanks @RubenVerborgh !
There would be much to say about this subject, but here are a few comments already:
- I think we should really stop thinking of pods in analogy to Google Drive or Dropbox. End users aren’t interested in being able to move Turtle files into containers. This is well explained in this document on Solid’s interoperability problems and goals: People shouldn’t need to think about how to physically organize their data to use Solid. Unfortunately, on this same document, it says “[Users] should have as much freedom as they like to make and modify how they categorize their data”. To me, that’s not a requirement at all! We could eventually allow users to upload binaries to their Pods and move them around just like on a drive. But other solutions do it better, and IMO we shouldn’t waste time with this kind of functionality.
- In the ActivityPods project I’m working on, I use a triple store (Jena Fuseki) for data storage. When you’re working with a real knowledge graph, most of the problems Solid encounters with file hierarchies simply don’t exist. Yesterday, I reread the ShapeTree specification and simply couldn’t understand why I would need it for ActivityPods. Knowledge graphs and file hierarchies are completely different worlds, and trying to make them coincide is bound to create a lot of headaches, as Ruben’s article suggests. (Disclaimer: ActivityPods follows the Solid philosophy, but for several reasons I won’t go into here, compatibility with the entire Solid specification is not a priority for us, even though we use LDP, WAC and other Solid standards).
- To start moving away from the “Pod as Drive” philosophy, in the next version of ActivityPods, resource URIs will no longer refer to the LDP container. Instead of having pretty URIs like
https://mypod.store/alice/data/events/my-birthday-event, we’ll simply havehttps://mypod.store/alice/data/r1dsc5sd5vvfv5e8gb86wd. It’s a little less pleasant for developers, but it improves privacy (you can’t guess a resource’s content from its URL) and, above all, it makes it easy to move resources to other containers, without affecting their URI.