Re: SPARQL, philosophy n'stuff..

I'm sorry, but you seem to have misunderstood the use of a graph URI 
parameter in indirect graph addressing for GSP.

I wish all GSP actions addressed graphs directly, Queries were all GETs, 
and that Updates were all PATCH documents, but a degree of pragmatism 
has been applied.

Barry


On 22/04/13 04:07, Mark Baker wrote:
> 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 08:17:26 UTC