-
Notifications
You must be signed in to change notification settings - Fork 57
Is Solid containment strictly hierarchical? #98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'll just share some of my initial thoughts around this, hope we can quickly have a discussion on this. I would normally not advocate strict hierarchies, but I have come to view this as a possibility, and something that could be a constraint on LDP that can be relaxed later that could have several simplifying effects. The cost of constraining Solid this way doesn't need to be very dramatic. Even though strict hierarchical systems have major shortcomings for knowledge organization, in my experience, we can very well build a non-hierarchical knowledge organization system on the top of a hierarchical containment hierarchy. The containment hierarchy simply does not need to play any important role in knowledge organization. It seems to me the containment hierarchy is mostly important to apps that group their writes and for the ACL system to assign common authorizations to those resources. In a hierarchical system where identifiers for parent containers can be determined simply by looking at the request URI, containment triples can very easily be computed on the fly for an incoming request, avoiding atomicity problems that might arise from more advanced structures that might need to persist information about the containment in some other form. |
I think it would be a good idea to make the container structure optional in Solid so any resource can go at any path. For example if I put a resource at Let's imagine that we are creating a web-site that we want to be Solid compatible. Essentially, our site would look the same for a user using a web browser, but when requests are sent to urls with a However, many sites have url schemes that don't follow a container structure. For example, on reddit, a url might look like Also a site might want to use the scheme Finally, allowing a resource to be at any url independent of containers would encourage containers that contain resources that are on completely different servers, which is much more in line with the decentralized nature of Solid. |
My personal vote would be in the direction of required hierarchical containers. Solid's core model so far has been - it's a web-ization of the file system, directories and files. Which are necessarily hierarchical. |
Agree completely with @kjetilk here. I think we can provide something along these lines that is simple for development, intuitive for authorization, but also leaves us with room to expand long term. We are experimenting with exactly this as part of the work in the data interoperability panel related to the intersection of discovery, validation, shapes, footprints, and authorization. |
Bi-directional linking can accommodate hierarchical linking. We have the notion of parent-to-child but not child-to-parent - that's one thing that can be formalised. Servers wishing to expose either or both of those kinds of connections between its resources should be able to do so. |
What are the reasons to prohibit non-hierarchical containment in a given system? As @jaxoncreed highlights the scenario where servers manage resources in containers which are not necessarily in the same storage / system should be recognised as within the scope of Solid. |
Just to add some context from @timbl here, he wrote in this comment, that:
So, we have a hierarchical design from the outset, the question is really whether the containment is strictly hierarchical. I.e., can anything exist outside of the hierarchy, e.g. #97 , do we have an analog to UNIX The advantage of strict hierarchy is that management of containment triples can be left entirely to the server, and the server may therefore reject any request that contains containment triples in the body of the message. It also means that we avoid atomicity issues since the containment triples can be generated from the hierarchy only, and no knowledge is needed beyond the structure of the URIs. Since the hardest problems in a decentralized architecture revolves around ACID properties, that is likely to be quite a simplifying trait. That'd be my main reason to consider a strict hierarchy. It also has a bunch of consequences for how the HTTP verbs are defined too, e.g. there is no verb that doesn't have consequences for containment, but I think this is mainly a design question that should be resolved before going too detailed. We know that both hierarchical and non-hierarchical containment can be done with LDP, and we also know that hierarchical constraint can be relaxed later. |
There's a difference between something existing at It seems like this suggestion (to enforce containment hierarchy) is simultaneously enforcing ldp:containers everywhere and ignoring them entirely. It would force every path that has "children" to be a container, and yet it would make the ldp:container vocab meaningless since the child/parent relationship is based on path not on the containment triples.
Unless I'm mistaken this is true by definition, regardless of strict hierarchy or not. Personally, I agree with @csarven here - unless there's some reason to explicitly prohibit non-hierarchical containment than it should not be done. I don't think advantages of hierarchical containment are reasons to prohibit non-hierarchical containment. It should be up to the implementer to decide if the advantage is worth it or not. In other words, the implementer should be able to decide where to put a resource when it's being added to a container. And containment should be determined based on the containment triples, not assumptions about the urls. |
I'll bring my comment over from #97 and apply it to this discussion as well. The more I think about it, I think hierarchical containment is the way to go. One very important thing that Solid must provide is the ability for the Pod owner to know and control all the data in her pod. So, if containment is not derived from hierarchy, that would imply that Solid must not support POSTing a resource directly, one would have to go through a container url to create new resources. I personally like the ability to POST a new resource directly (note that NSS currently doesn't support this though?) and think it is something Solid should support... and so I think deriving containment from hierarchy is a better solution than prohibiting POSTing a resource. |
Proposal following F2F meeting of 2019-10-29T17:17:00-01:00 There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy eg:
maps to:
Non-strictly hierarchical containment can potentially introduce non-uniform URI patterns. Hence it is generally preferable to design so that containment is strictly hierarchical. |
I think a good way to solve both this and #97 in the spec would be to say something along the lines of
Expressing it like this would still allow POSTing a resource directly, and it would implicitly be added to the container it lives under. (although, there is surely a more clear way to say the same thing as "under that container in the url hierarchy") |
How was this resolved? |
@akuckartz It was based on #98 (comment) and text committed in 717ed8a and related following 2f528f1 . It was part of PR #157 but I didn't backlink at the time. Have been backlinking on following PR. |
Another topic that @csarven and I discussed is if the Solid view of LDP is a strictly hierarchical structure.
LDP itself does not require this, and Linked Data itself does not tend towards trees, but we are talking mostly in terms of a folder hierarchy where the presence of
/
in the request URI carries significant information about the parent-child relationship.Therefore, we should clarify whether we intend the folder hierarchy to be strictly so. This has great implications for the design, and influences issues like #39 and #68 .
The text was updated successfully, but these errors were encountered: