File system to Solid mapping

On gitter @leobard expressed a use case that comes up a lot: placing a Solid server with a root directory on one's local file system, so that one can easily edit the files with tools available on one's desktop.

This is actually how we started programming the web. We could open a browser to view files on the file system and immediately, link them together and see how they worked. But as we allow content negotiation on Solid we can have a local file such as /index.html become /index if we adopt to always remove the extension, which makes a lot of sense with RDF. But then links built on the file system will always contain the extension eg. .html. This is not so troubling with html (as the Solid server should also react to the extension). But with RDF, a user would end up setting a preference for one of the encodings. So all the links would be /card.ttl#me rather than /card#me. If some of the data were then to be edited via the LDP API then the user would end up with links to the content without the extension.

One way one could get it right would be to have symbolic links on the file system that linked to the default extension. So if one has card.ttl one could have a symbolic link from card to card.ttl. This would allow a good editor to jump to the correct relative URL. (We don't have many such editors). So then should such a web server always and such symbolic links?

It seems like one could have a repo and spec just dedicated to this use case.

No files, tests, or implementation entry points are named. Start by reviewing the linked discussion and the specification repository to determine whether filesystem-to-Solid mapping belongs in the Solid specification or a separate project. Done would require a decided scope and documented behavior for extensions, content negotiation, and symbolic links.