Open tuukka opened 6 years ago
I like the idea as such.
However, this would mean that we also need representation-specific URLs, i.e., that the Turtle and JSON-LD representations receive their own URLs as well (in addition to being accessible through the canonical URL via content negotiation). I am a bit afraid to introduce that in Server.js, because the risk is that people start using such representation-representation URLs for everything (and they really shouldn't, for compatibility reasons). So maybe we should look at using an external service that works like http://example.org/resource/?format=text/turtle&url=http://fragments.dbpedia.org/2014/en
.
I see the concern. Could it also be an internal service that is accessed like that, ie. http://fragments.dbpedia.org/2014/en/resource/?format=text/turtle&url=http://fragments.dbpedia.org/2014/en
?
Now that I think of it, a URL might not be necessary at all. There's at least three aspects:
An alternative approach might be to have UI tabs for the alternative representations. On top of the representation it could tell which Accept
header / curl
command / fetch
call to use. If copying the representation to clipboard is not enough, there could also be data:
URIs for downloading. One of the tabs could even show the use of ldf-client.
Is it really that big of a benefit to have representation specific formats? Any Web developer should know what CONNEG is.
However, I do see value in your last suggestion. A UI-based solution (tabs with "view-source"-like behavior, why not?) would be more effective, since we still help developers, but does not violate best practice.
I think it would improve discoverability and lower the barrier to LDF if the HTML views of the query results would include prominent links to download the results in the various available formats (JSON-LD, Turtle etc.).