Specification: Can one convert a non-container LDP-RS into an LDP-BC or vice versa?

[michielbdejong]

If you PUT a resource and explicitly write in there that it is a ldp:BasicContainer, does that then become a container?
And if you PATCH a container to remove its a ldp:BasicContainer predicate, does it then become a non-container LDP-RS?

I think not, but maybe since it's sometimes so easy to talk about 'LDP-RS' in general without specifying container or non-container, this should maybe be explicitly prohibited in the spec, and state that if an LDP-RS is "born a container, always a container" ;) and vice versa.

[acoburn]

This is also addressed in the Fedora specification. Effectively, a server MAY allow a client to change the interaction model of an existing resource via PUT. Doing this via PATCH is explicitly disallowed.

With Fedora, changing an interaction model can only happen in one direction (e.g. LDP-RS -> LDP-BC), which seems reasonable since an LDP-BC continues to follow the interaction pattern of an LDP-RS. One could argue that the inverse would be problematic for many reasons.

The pattern outlined by the Fedora specification is also implemented by Trellis.

[michielbdejong]

OK, so then I think our main options would be, follow NSS and prohibit it in all directions (but make that explicit at the spec-level), or follow Fedora on this and allow the non-container LDP-RS -> LDP-BC direction if it's done via PUT.

[acoburn]

Worth noting that this isn't an either-or decision. If NSS rejects requests to change the LDP interaction model, it effectively conforms to the Fedora spec on this point: changing an interaction model is purely optional, according to Fedora. The only hard requirement that Fedora introduces is that a server MUST disallow changing an interaction model via PATCH.

[michielbdejong]

You're correct in stating that in theory it's not an either-or decision, because we can always tell clients "just try and see if it works", but this is not theory. :)

Leaving things like that open could be the right way to go for some things, especially for instance performance optimisation. A good example would be HTTP/2 support. Some pod servers will have it, others may not, and we expect clients to be flexible about that. So on topics like that, I would agree with you (especially for instance when running on localhost you may not want to support all the things a production-grade pod-server would be expected to support, that's always a good situation to consider, for relaxing a MUST to a SHOULD in the spec).

But on this topic, the spec author team wouldn't be doing app developers a service if they took that approach here. So I think it should be an either-or decision. Either all pods support this, or none of them do.

[csarven]

It is possible to "convert" the interaction model by way of deleting and reinstating with a different interaction model. The LDP and AWWW recommendation for URI reuse ( https://github.com/solid/specification/issues/46 ) is that it SHOULD NOT happen unless the same resource is associated with the URI. Possible to go outside of that but, you know, don't.

So, I think this issue ultimately falls under the same recommendation about URI reuse. More specifically, it SHOULD NOT happen. If there are good use cases, what MAY happen is converting to a subtype within the same interaction model.

[michielbdejong]

@csarven ok, good answer to the question of whether we even want it, sounds like we probably don't. :)

But to linger a little bit on Aaron's remark that we can leave it up to the server, which I still think is a little bit concerning, maybe look at this at a higher level. We should note that the Fedora spec 'refines the semantics and interaction patterns of the Linked Data Platform in order to better serve the specific needs of those interested in implementing repositories for durable access to digital data', meaning it's a _protocol spec_. It prescribes a language of interaction.

However, the Solid spec is 'a set of technical documents that detail the requirements for apps, clients, servers, and intermediaries to be compatible with Solid', meaning it not only specifies the language a server should understand, and speak, but also the behaviour the server should implement. So Fedora can be happy to just define a language for a client to interact with a server, regardless of that server's feature set. But in Solid we need to be more strict! We need to make sure app pod servers implement (almost) exactly the same set of features. Only then can app developers really treat pod servers as interchangeable.

[michielbdejong]

I should probably write a blog post about the difference between protocol specs and server specs :)

[michielbdejong]

On this specific topic, I think Sarven's answer is a clear and convincing 'no', so I'll close this issue unless/until someone finds a use case that merits reopening this.

[csarven]

Issues like this reveal useful material for a Best Practices and Guidelines document that can be accompanied with The Solid Ecosystem.

[RubenVerborgh]

Proposal following F2F meeting of 2019-10-29:
The question has been answered, but it still needs to be written down in a document.

[csarven]

The spec (editor's draft) covers the semantics of slash URIs, URI persistence, and containment. It is not possible to convert.