Comments on the SPARQL protocol

Hi,

This comment is submitted jointly by Mark Baker and Jan Algermissen,
who discovered they had the exact same concern with the current spec[1].

That concern is with section 2, the Abstract Protocol.  We suggest that
the spec would be improved if this section were removed.  Our reasoning
is as follows ...

First, only one concrete protocol is provided (HTTP), which, in our
opinion, doesn't exercise the abstract protocol sufficiently to give
confidence that it can serve its intended purpose (see our fourth point
below too).

Second, the abstract protocol isn't required for interoperability, only
the concrete protocol is.

Third, we suggest that its inclusion may affect the interpretation of
the concrete protocol.  For example, a SPARQL protocol client may
logically invoke GetGraph via HTTP GET and interpret a successful
response to mean that GetGraph was invoked, which isn't an
interpretation licensed by HTTP, nor reflected in the message in any
way.

Forth, and related to our first and third points, we believe that
concrete protocols developed from the abstract protocol stand a good
chance of being architecturally inconsistent with the systems formed
by those protocols.  For example, the abstract protocol would seem to
suggest that a binding to SOAP would require operations called "Query",
"GetGraph", and "GetServiceDescription".  Yet, such an interpretation
would be inconsistent with Web architecture when SOAP is used over
HTTP.

In general, while we agree with the intent of the abstract protocol -
to enable multi-protocol support for SPARQL - we believe that the
approach taken with the current protocol is problematic.  We suggest
that interoperability would best be served by removing the abstract
protocol and focusing on HTTP for now.

Thanks.

 [1] http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050114/

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Tuesday, 1 February 2005 15:48:55 UTC