API methods for copy/move/rename

[Otto-AA]

Are there API methods for copying or moving items in a pod?

For implementing these I currently fetch the file, POST it to the new location and optionally delete the old file. While this definitely works ok, it uses very much bandwidth (downloading and uploading again) which has several bad impacts (loading time for the user, increased bandwidth costs, higher energy consumption, unnecessary server traffic).

I think it's directly related to the WebDAV issue, but as this issue is already 4 years old and it's in there mentioned, that it shouldn't be added "at this point", maybe things have changed and it could be added again?

[elf-pavlik]

What use case would you have for move / rename? Since the way you suggest it may break links between resources, maybe your use case just needs updating some labels on resources or patching data about relationships between resources (eg. include / exclude photo from album).

[Otto-AA]

I mainly thought about using the pod as a file storage which can directly be accessed by apps. So for instance, the user could upload audio files, edit it with an app and create a visualization of them with another app. To keep his audio files organized in the pod he/she sometimes renames audio files, moves folders, etc. And because the apps are mainly used to edit or view the files, links don't get broken by renaming directories.

So in general, the usage I see would be organizing folders of data which doesn't need to have permanent links.

[acoburn]

I've implemented an LDP server (Trellis) that aims to conform to the SOLID specification. This implementation has an extension module that adds support for WebDAV at conformance levels 1 and 3 -- there is no support for locking. I found that the main use case for the COPY/MOVE methods was not so much by web applications but rather by users who wanted to mount the LDP server as a filesystem. This allows a user to move content into and out of standard LDP Containers as if they are simple directories. It is especially useful for users who want to manage NonRDFSources without dealing with RDF or HTTP semantics.

I found that WebDAV and LDP can co-exist pretty easily, though there is some mapping work that needs to happen to change the PROPPATCH/PROPFIND methods from the XML-based WebDAV world to the RDF-based Linked Data world, though TBH the code for that wasn't particularly hard to develop. In this implementation, a COPY or MOVE operation will rewrite links within the resources that are copied or moved such that any relative links are adjusted based on the resource's new location.

In terms of adding COPY/MOVE methods to the Solid specification, I wonder whether it would suffice to add a note about WebDAV (or even something like Solid servers MAY implement WebDAV) rather than requiring or re-specifying these methods within Solid. WebDAV features are entirely discoverable by clients, and so an HTTP client should have no problem determining whether these WebDAV methods are supported. Plus, if these methods are not available, one can accomplish the same things with a few additional HTTP operations (MOVE = GET + PUT + DELETE)

[kjetilk]

There is also the WebDAV precursor work that could still be helpful in https://www.w3.org/1999/04/Editing/

[elf-pavlik]

To keep his audio files organized in the pod he/she sometimes renames audio files, moves folders, etc. And because the apps are mainly used to edit or view the files, links don't get broken by renaming directories.

I still find it concerting when IRIs don't get treated as opaque. Google Drive allows changing names of 'files and folders' without changing IRIs of the resources. Since as you say apps are used to edit view files, apps could simply rely on rdfs:label and respect opacity of IRIs. Long time ago I've created related issue in solid/solid#89
IMO in most cases 'renaming' should only affect rdfs:label intended for human friendly UI (which possibly also uses i18n to respond to browser's language), none of that should in any way affect IRIs denoting those resources.

[dmitrizagidulin]

See also: solid/specification#19 (for proposed support for COPY).