This repository was archived by the owner on Apr 13, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 13, 2022. It is now read-only.
Does PUT /foo/bar add a containment triple for /foo/ ldp:contains /foo/bar? #185
Description
Activity
I don't think solid should mandate how applications use IRIs. If it only relies on
ldp:containsstatements 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.
- it doesn't encode folder hierarchy in IRI and all folders use simple URI Template
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/bardoes not create anldp:containstriple on/foo), though I know of some non-Solid use cases that rely on that behavior.Reacted by elf Pavlik
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/baradds 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.