Does PUT /foo/bar add a containment triple for /foo/ ldp:contains /foo/bar?

[michielbdejong]

It's clear that POST /foo/ adds a containment triple for

</foo/> ldp:contains <url-of-new-item>.

It was my understanding that a Solid app can also rely on it that PUT /foo/bar adds a containment triple for:

</foo/> ldp:contains </foo/bar>

But @elf-pavlik has a different interpretation, so let's discuss and pick one! :)

My stance is, if there's a rule that NSS follows, and there's no reasonable motivation for other pod server authors (like myself) to diverge from it, and it's reasonable to expect Solid apps to already be relying on it, then let's formalize that as part of the contract between Solid apps and all pod servers, and let's all build pod servers that are functionally compatible with each other, rather than functionally wildly divergent from each other.

The goal of this spec is, I think, to make the Solid app developer's life easier, by removing differences between one pod server and another, and this is another good opportunity to do so.

[elf-pavlik]

I don't think solid should mandate how applications use IRIs. If it only relies on ldp:contains statements than implementations can also support approaches like in Google Drive where:

• it doesn't encode folder hierarchy in IRI and all folders use simple URI Template https://drive.google.com/drive/folders/{uuid}, this way also one can move files between folders without changing IRI of the file
• it allows multi parent hierarchy, file of folder can have any number of parents - https://developers.google.com/drive/api/v2/reference/parents/insert

While putting some expectations on path structure of IRIs keeps them more similar to local filesystem, it still doesn't seem to support feature like symlinks.

[acoburn]

FWIW, the Trellis server allows both scenarios, and the specific behavior is controlled through configuration. I am not personally a big fan of "uncontained PUT-on-create" (where a PUT -- for creation -- on /foo/bar does not create an ldp:contains triple on /foo), though I know of some non-Solid use cases that rely on that behavior.