Open michielbdejong opened 5 years ago
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:
https://drive.google.com/drive/folders/{uuid}
, this way also one can move files between folders without changing IRI of the fileWhile 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.
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.
It's clear that
POST /foo/
adds a containment triple forIt was my understanding that a Solid app can also rely on it that
PUT /foo/bar
adds a containment triple for: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.