-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File system to Solid mapping #237
Comments
It would be interesting to know how things look on different operating systems. Some support attributes on files. Is there an OS which supports attributes where Apps consistently consult those? Those OSes would then provide a particularly easy answer: add the mime type to a file to the standard attributed for it. If all apps on the OS consulted those all would be good. It would not help that much for exchanging data across OSes. There, one would need to go to the lowest common denominator or create a standard metadata associated with files in the tar). And it would probably not help for hackers that link to edit files on the FS, with Researching this a bit I found that in Java there is the User Defined File Attribute View, which allows one to set attributes across platform. The implementation of course differs between platforms as these have different Systems (see StackExchange answer). And I think for platforms that don't have the feature Java encodes these properties in a specific way. (what way?) So it would require a format to transfer files with attributes between platforms, if that is important. |
I think @timbl's answer here is a helpful one, especially as it helps avoid problems with
But I think it may not get it quite right with the other way around, where people are editing files on the FS and checking them in some browser locally, and want to create hyperlinks between representations. So for RDF the situation is that one wants to serve a foaf profile
In rww-play I had come to the conclusion that it would help to have a symbolic link Anyway, it looks like the symbolic links locally allow one to get the direct mapping answer n1. |
Hi @bblfish , I didn't think through all implications outlined above. assuming i have my files stored locally like /home/bob/documents/projects/bar/foo.html my 2c:
I have no deep knowledge of SOLID architecture, so you probably already have all that. I am noob here, so please take my input with grain of salt. |
You could have a look to solid/solid-rest which does this kind of mapping. |
@leobard I think one may be able to avoid 3 namespaces and have just one First note that a Solid server should just be a normal HTTP server. So uploading HTML, css, JS, etc should just render as it in normal browsers without needing any JS. This would allow the tradition method of publishing pages, except that content creators can upload their documents directly with LDP's HTTP read-write extension. So the server should then be able to specify transformations for various file formats such as |
@leobard
|
@bblfish you can of course jump through hoops and realize it with one URL using HTTP headers. But most developers today chose different URI schemes because they use modern application-building frameworks where you configure different paths for different ways of handling. So I decide to disagree: going for "one uri scheme to rule them all just because I can" does not help developers here. Looking at how dropbox/googledrive/onedrive do their thing, I see differnt URIs for raw/browser-render/editor and it makes life easier. I recommend keeping things as simple as possible regarding implementation ability |
Solid already provides a way of viewing and editing one resource using one URL, since it is using LDP. That simplifies a lot of state-management all over the place. The problem you bring up is just how to view non natively viewable web resources such as RDF. Solid there tends to prefer to leave that to an LDP/RDF aware client to present the data as it wishes. |
One problem I see reading @RubenVerborgh's resource-mapper.js is that it does not deal with content negotiation. This is well explained by @leobard's Cool URIs for the Semantic Web. If I read |
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 fromcard
tocard.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.
The text was updated successfully, but these errors were encountered: