Support container updates

[csarven]

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.

[gibsonf1]

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]

@gibsonf1 Write to /.meta , fetch /.

[elf-pavlik]

Write to /.meta , fetch /.

That smells bad to me.

(as interacting directly with the URI in question would be generally preferable.)

👍 x 1000

[megoth]

@gibsonf1 Write to /.meta , fetch /.

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]

@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]

@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.

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]

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 describedBy relation in the HTTP headers for the resource in question eg. /foo.png will point to /foo.png.meta (if it exists).

[dmitrizagidulin]

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]

I'd like to reproduce but I'm unable to PATCH container URI. I get a 500 from server:

solid:server Error page because of: { [HTTPError: Original file read error: Error: EISDIR: illegal operation on a directory, read]

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:

PATCH https://localhost:8443/test/
Content-Type: application/sparql-update

INSERT DATA {
  <> <http://www.w3.org/2000/01/rdf-schema#label> "test" .
}

[csarven]

My reading of the error based on https://github.com/solid/node-solid-server/blob/master/lib/handlers/patch.js#L73 is that readFile fails for directory as input as per https://nodejs.org/api/fs.html#fs_fs_readfile_path_options_callback (at least on non-FreeBSD systems). Looking patchHandler (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]

See also conversation leading up to https://gitter.im/solid/node-solid-server?at=5c3d3d3a35350772cf315ca8