Providing conneg responses to filenames without extension, and mapping to corresponding formats

[csarven]

How can /foo be accessed with content-negotiation such that they physically map to corresponding files /foo.html , /foo.ttl etc. Is the mapping something that Solid already provides (or could provide) or is that out of scope?

If this is missing, I think it is an important enough feature to have. if for example, /foo is described like: /foo dcterms:hasFormat /foo.ttl . /foo.ttl a dcterms:MediaType ; rdfs:label "text/turtle" . and so on, Solid can silently do the rewriting and give the corresponding response. Something along these lines could give way to having cool URIs

I think one thing we need to look closer is how do we (humans) or a solid server does the mapping. One way to do it may be for solid servers to automatically respond to requests for paths which have a "well known" extension, i.e., foo.ttl, foo.html, foo.rdf exists, and so /foo will do the rewriting to one of those based on conneg.

[gobengo]

Good point and this is relevant to this test case I filed on ldnode: https://github.com/linkeddata/ldnode/pull/159

One way to do it may be for solid servers to automatically respond to requests for paths which have a "well known" extension, i.e., foo.ttl, foo.html, foo.rdf exists, and so /foo will do the rewriting to one of those based on conneg.

ldnode tries to do something like that, but is imperfect https://github.com/linkeddata/ldnode/blob/master/lib/handlers/get.js#L66

[deiu]

Yes, this feature is planned, although it is mostly covered by classic conneg patterns. One thing I can say for sure is that no conneg will be done based on logic that comes from the file itself (for many reasons). I have plans to work on this issue over the coming weeks, so I'll update the spec with a mention to how it is implemented.

[elf-pavlik]

https://www.w3.org/ns/formats/

In RDF the description of a file format may use the properties 'http://www.w3.org/ns/formats/media_type' and 'http://www.w3.org/ns/formats/preferred_suffix', if defined for that specific file format.

[csarven]

/me rubs eyes.

This feature is currently unspecified in the Protocol spec. Availability or generation of representations are typically managed by a server, and thus it would be simpler for a server to manage the mapping. The remaining consideration is whether the information about available formats should be present in the resource description. I suggest that the Protocol specification doesn't require this.