Feature:ReturnFormatKeyword

From SPARQL Working Group
Revision as of 11:55, 30 March 2009 by KjetilK (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Feature: Return Format Keyword

Defining a standard keyword to get the results of a SPARQL query formatted with a given format.

Feature description

Provides a standard keyword / parameter to get the results of a SPARQL query formatted with a given format. Most engines support a keyword for such formatting, but there's no standardization, e.g. 'format' in Virtuoso, 'accept' in D2RQ, etc. Usually, engines also use the required content-type to provide results according a given format. Yet, the use of a common keyword eases the process of debugging query-results via a Web browser. Hence, keyword should prevail over the content-type

The list of available formats may also be standardized.

Examples

The following REST Call for a given SPARL query is based on the virtuoso implementation of such a keyword (using 'format')

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&should-sponge=&query=select+distinct+%3FConcept+where+{[]+a+%3FConcept}&format=text%2Fhtml&debug=on

Will return HTML results

While

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&should-sponge=&query=select+distinct+%3FConcept+where+{[]+a+%3FConcept}&format=json&debug=on

Returns JSON format

Might also be implemented as an extra keyword, not in the protocol, but in the language itself.

SELECT ?s ?p ?o
WHERE { 
 ?s ?p ?o . 
} 
FORMAT JSON

Existing Implementation(s)

Most engines support a keyword for such formatting, but there's no standardization.

Elsewhere, the de facto way to ask for JSON in a web service request is taken from Yahoo! and is the "output" parameter.

Existing Specification / Documentation

See existing implementations

Compatibility

Should not be an issue to ensure backwards compatibility for existing implementations.

Links to postponed Issues

None.

Related Use Cases/Extensions

I just created a jQuery script to send a SPARQL query to an endpoint. JQuery wanted JSON back, and it turned out that setting the Accept headers appropriately was hard. Thus, I first used an "accept" HTTP query parameter, then, after migration "format".

As it turns out, many HTTP implementations make it significantly harder to set HTTP headers than query parameters.

This is mostly a toolchain problem, but a data point to consider. --KjetilK 11:55, 30 March 2009 (UTC)

Champions

  • Alexandre Passant / DERI
  • OpenLink

Use Cases

  • Querying various endpoints with the same REST-ful call, i.e. independantly of the SPARQL engine implementation.
  • Debugging SPARQL queries (in various formats) simply using a Web browser.

References

(OMG, I've implemented the web service endpoint looking at some spec with format=this and format=that but I can't recall what was it. I had an illusion that the spec was from some W3C source so I overslept that the feature is missing in the protocol spec. --- iv_an_ru )