Repository navigation
Support container updates #1040
Description
First off: this issue is different than creating LDPC on route to creating an LDP-RS as a member of an LDPC that doesn't exist yet. That particular case was covered in #513.
This issue is about creating or updating an LDPC (ie an LDP-BC, at the time of this writing). It will conform to LDP provided that the information in the update payload doesn't get in the way of changing the containment triples ( https://www.w3.org/TR/ldp/#h-ldpc-put-mbrprops ). So, for example, adding a label to a container (<> rdfs:label "Foo") would be fine, but PUT/PATCH that inserts or deletes ldp:contains relations should not succeed.
The use cases are generally about including additional "metadata" as part of the container description. It is partly discussed in #547 .
If this feature is implemented, #547 can be revisited, and as far as I can tell, the feature where updating a container's description through /.meta can be removed altogether (as interacting directly with the URI in question would be generally preferable.)
Edit: rel="describedBy" .meta in HTTP header can also be dropped as the interaction will only go through container URI, and that .meta will only be internal to the server.
Activity
gibsonf1 commentedon Jan 9, 2019
Is there a way to write triples to a container, such as rdfs:label or dcterms:description? I'm not able to do it yet and would really like to know how it would be done currently.
csarven commentedon Jan 9, 2019
@gibsonf1 Write to
/.meta, fetch/.elf-pavlik commentedon Jan 10, 2019
That smells bad to me.
👍 x 1000
megoth commentedon Jan 11, 2019
This could maybe be handled via LDP as an internal mechanism? So you could push triples to a container, and LDP could store these in /.meta behind the hood, and when someone gets , they'll get the content of /.meta as well as a list of children listed in the container?
Might be a bit to much auto-magic too, just thinking aloud.
csarven commentedon Jan 11, 2019
@megoth To be clear, what is currently implemented in node-solid-server (ie. how "write to /.meta, fetch /" works) can be purposed as a workaround to updating the container IRI directly. That is simply out of scope of LDP.
The write to /.meta , read from / workflow for the purpose of updating a container is implementation specific, ie. only works on node-solid-server and participating client applications (read: a form of vendor lock-in in a long enough time line.)
What's proposed in this issue is about the interface, and a closer alignment with LDP and REST.
If I understand you correctly, what you're describing is the internal mechanism, ie. splitting the LDP-centric information that node-solid-server auto-generates out-of-the-box (like containment information), from the information that user updates (excluding the containment information) in /.meta. That was the intention of .meta. What follows - to be implemented - is how updates to container IRI are handled by node-solid-server, ie. to detect and apply changes to / and /.meta respectively (provided that .meta is kept around). In any case, LDP doesn't specify the internals of how implementations handle the information, so the /.meta approach was/is a simple way to go at it as the platform tends to currently lean on file-system storage.
megoth commentedon Jan 11, 2019
Yeah, I should've been clearer in my previous comment: I wanted to suggest to make the internal mechanism I described a part of the LDP spec.
Even though it would add complexity in that the description of a folder-URI would comprise of manually and automatically generated triples, I think it could be a useful abstraction for developers, and it could be applied for all non-RDF variants of resources, e.g. images and binary files (essentially, they don't need to know about the .meta-file concept).
But this probably opens a slew of caveats I haven't considered. Just wanted to make my original thoughts (hopefully) a bit clearer.
csarven commentedon Jan 11, 2019
I don't see how it'd be or become "a part of the LDP spec", but maybe we are misunderstanding each other. LDP doesn't specify the internals of updates / recalling. Only the optional interaction with the container IRI directly, as well as suggesting to not mess around containment triples.
node-solid-server already detects .meta association for any resource. We already discussed containers, but RDFSources and NonRDFSources can also have .meta associated simply by having another resource with the same name and .meta suffix. There is a
describedByrelation in the HTTP headers for the resource in question eg. /foo.png will point to /foo.png.meta (if it exists).dmitrizagidulin commentedon Jan 21, 2019
If I'm understanding @csarven correctly, re "the interaction will only go through container URI" - that's the way it's actually implemented right now.
Meaning, you do a PATCH to the container URI, not to
.meta(although behind the scenes it gets written to.meta.)And #547 is a proposal to remove that functionality. To do away with editing the container in any way.
csarven commentedon Jan 21, 2019
I'd like to reproduce but I'm unable to PATCH container URI. I get a 500 from server:
Is there a particular ACL policy that needs to be in place in the container URI or in the parent container URI - can you specify the snippet?
I've also played with directory permissions but didn't help.
I'm basically trying following snippet:
csarven commentedon Jan 26, 2019
My reading of the error based on https://github.com/solid/node-solid-server/blob/master/lib/handlers/patch.js#L73 is that
readFilefails for directory as input as per https://nodejs.org/api/fs.html#fs_fs_readfile_path_options_callback (at least on non-FreeBSD systems). LookingpatchHandler(but not getting into debugging) it doesn't look PATCH for containers (directories on filesystem) is supported. It'd be great if anyone can confirm.csarven commentedon Jun 25, 2019
See also conversation leading up to https://gitter.im/solid/node-solid-server?at=5c3d3d3a35350772cf315ca8