separate interfaces/operations for CONSTRUCT and SELECT

During yesterday's telcon there was some discussion on Dan's design
for splitting the query protocol interface into two operations [1].
I noted that Sesame's http protocol uses that same split design [2][3]
and promised to provide some background on why we made that choice.

On reflection however, it turns out that for the most part these
choices are actually not particularly relevant for SPARQL. Sesame
splits the operations because in our implementation they use different
parameter sets. For select-queries we need to specify a result data
format (RDF, XML, HTML), for construct-queries a result serialization
format (RDFXML, Turtle, etc.). None of this is relevant for SPARQL since:

a) SPARQL SELECT queries only return XML results.
b) Serialization formats are handled through content
    negotation/headers rather than a parameter.

An additional reason for us to split was that it enables the service 
to know the type of query without having to parse the query string 
first. This does apply to SPARQL but I don't really consider this a 
convincing reason for splitting in and of itself.

Just sayin' ;)

Jeen

[1] 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005AprJun/0335.html
[2] 
http://www.openrdf.org/doc/users/ch08.html#section-comm-http-table-queries
[3] 
http://www.openrdf.org/doc/users/ch08.html#section-comm-http-graph-queries
-- 
Jeen Broekstra          Aduna BV
Knowledge Engineer      Julianaplein 14b, 3817 CS Amersfoort
http://aduna.biz        The Netherlands
tel. +31 33 46599877

Received on Wednesday, 8 June 2005 08:45:07 UTC