Re: SPARQL, philosophy n'stuff..

On Fri, Apr 19, 2013 at 9:57 AM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> The original query language you describe is what makes the Web, the
>> Web. We can't just swap it out and expect the resulting architecture
>> to still be the Web and exhibit its same desirable architectural
>> properties.
>
>
> But I don't see how the following break the model:
>
> 1. sparql-protocol
> 2. sparql-update protocol
> 3. sparql-graph-store protocol.
>
> They are all HTTP based.

Yes, but so was SOAP :P That isn't to say that there are strong
architectural similarities between the above (in general) and SOAP,
only that both misuse HTTP to the point where they're not REST, and
their relationship to the Web is tenuous at best.

sparql-update doesn't seem to have anything to do with HTTP AFAICT
(other than being tunnelled over POST), but the other two get caught
up in specifying what amounts to a profile of HTTP rather than in
using hypermedia to fit a SPARQL implementation behind an HTTP
interface. For example, GSP standardizes on the "graph" query
parameter, rather than use a GET form and a relation. Ditto for SPARQL
1.1's use of "query".

The problem here, and why SPARQL/HTTP solutions end up non-RESTful, is
that both are application protocols. How do you map FTP onto HTTP?
HTTP onto IMAP? POP onto FTP? You don't, because it makes no sense,
just as it makes no sense (to me) to map SPARQL onto HTTP. What you
*can* do, is build a pipeline (a proxy), where a client talks HTTP
(and only HTTP) to an HTTP server that is configured to talk FTP to an
FTP server. The key point there is that the client has absolutely no
idea that FTP is in use... which is as it should be with SPARQL.

I'd be repeating myself to respond to each of your subsequent points
separately, so won't ;)

Mark.

Received on Monday, 22 April 2013 03:08:09 UTC