Re: Comments on the SPARQL protocol

On Tue, Feb 01, 2005 at 10:49:04AM -0500, Mark Baker wrote:
> 
> 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].

Thanks a lot for reading it so carefully.

> 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 ...

The section has been removed in the latest draft.

> 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).

HTTP and SOAP bindings will be provided, eventually.

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

I have no comment here; but thanks for the point.

> 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.

In the present and in future drafts (at present, the draft is a bit
barren of prose), the SparqlGraphRetrieval interface (which is the
descendant of "GetGraph") may or may not be implemented by service
providers as they see fit.

> 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.

This seems more pertinent directed either to the SOAP or TAG folks. At
any rate, I'm pretty confident that the SOAP binding for SPARQL will
be sensitive to the issues raised by the WebArch doc -- at least, as
sensitive as a SOAP binding *can be*.

In my personal view, not speaking for DAWG now, if there are problems
beyond that, they are SOAP, not SPARQL problems. But inquiring minds
may differ, I suppose.

> 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.

As I said above, the "abstract protocol" section of the document has
been removed. Our adopting a requirement to use WSDL moots the
abstract/concrete distinction I'd been using in prose, which was the
primary motivation for removing it.

Thanks for yr comments.

Best,
Kendall Clark

Received on Monday, 21 March 2005 20:29:44 UTC