Reconsider Strict Tree layout

[damooo]

LWS specifies the layout of primary resource organization to be a hierarchy instead of strict tree, diverging from prior art like LDP, Solid. Thus it allows a resource to be in multiple containers simultaniously.

There doesn't seems many compelling UCRs for such radical departure. Where as it makes for interoperability concern, and brings ambiguity and friction in integrating with external standards and specifications.

For example:

• For servers that follow URI restrictions to integrate with relative-uri-ref affordances of the web, they cannot implement this. Such restrictions are legitimate, and ubiquitous in the ecosystem. Thus no client can model their functionality assuming interoperable multiple-simultanious-containment.

• There are servers, that provide obvious view over underlying tree layouts, like fs, obj-stores, etc. These cannot support hierarchical layout in a natural way. These servers too are ubiquitous.

• It is friction prone and non-obvious to integrate with external standards that assume single containment. For Eg: WAC and ACP has algorithms, that assume single hierarchical path for resource. It is not clear on how one should integrate with these standards with multi containment. I couldn't find any material in spec that can give clarity on this integration.

Thus, though it may cater to few niche cases, create hazard for interoperability, standard integration, etc in majority cases.

For those few niche cases, there need not be identity-level mechanism to share content between containers. Instead should better use web native content-level mechanisms like having multiple distinct resources, where clone resources redirects-to/proxies/copies main resource as per need. Fedora has some relevent mechanism

[pchampin]

With all due respect, I think you are looking at this the wrong way.
The fact that LWS allows a resource to be a member of multiple containers does not impose that all LWS servers should support this. So that makes the 2 first bullets in your examples above non-relevant.

As for WAC/ACP, you make a valid point. But until we have a clear view of how specific/open-ended LWS specifies access-control languages, this may be a premature argument to drop multiple-containment (again, considering that servers using WAC or ACP may still chose to not support multiple-containment).

[damooo]

With all due respect

Not required :-). Plz feel free to push back. I may misread, and is good to be informed.

The fact that LWS allows a resource to be a member of multiple containers does not impose that all LWS servers should support this. So that makes the 2 first bullets in your examples above non-relevant.

Hm. There lies the contention. You are looking at the servers alone, but not clients. The specified uniform interface must be minimum common affordances that client can assume and model/code their apps against. Thus, if client uses multiple-containment to model their app logic, these are not portable to large number of practical servers for the reasons mentioned above. Hence it is not quite fit to be minimum common affordance? Are there any requirements that require this identity-level sharing for modelling their apps worthy of this trade off against interoperability and integrating with external standards like WAC, ACP etc.?

[gibsonf1]

Definitely agree that multiple containment creates many problems with no clear value added. Why is this being proposed? What is the use case and value add to justify the many problems for this? Users can use types on resources to have any kind of organization they want without using containers given LWS Search and the Type Index. Containers are a terrible way to organize information (unless those containers represent actual real-world containment giving them semantic relevance, such as systems containing other systems etc)
The TwinPod implementation will never be supporting multiple containment.

[renyuneyun]

if client uses multiple-containment to model their app logic, these are not portable to large number of practical servers for the reasons mentioned above.

It appears to be a contradiction to itself? I mean, a client that models things using multi-containment will automatically support servers that only support single-containment -- the app models graphs, and trees are always graphs.

The specified uniform interface must be minimum common affordances that client can assume and model/code their apps against.

Does "minimum common affordance" mean "the least set of features (to be supported / assumed)", or "a small / minimal number of features (to be supported / assumed)"? Based on your next sentence (commented above), it appears you mean the former; but you are arguing about the latter (i.e. the latter should be true for LWS spec)?
Note: the former does not imply the latter.

I agree the problem for supporting multi-containment is the added complexity, but that is up to the use cases eventually -- either to support more use cases with a more complex schema, or to support less use cases with a more simple schema.

Multi-containment is a compromise of KG-based structure. Repeated discussions have been there for supporting different features (especially going back to early Solid discussions), which require either a KG, or a way to create multiple "views". The multi-containment is a balance between practicality and the desired features, to my mind.