solid / solid-spec

Solid specification draft 0.7.0
Creative Commons Zero v1.0 Universal
1.13k stars 103 forks source link

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

Open michielbdejong opened 5 years ago

michielbdejong commented 5 years ago

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 commented 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:

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 commented 5 years ago

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.