Re: SPARQL 1.1 Protocol Conformance

(grr - pressed "send" not "save" - apologies)

On 02/08/11 13:44, Andy Seaborne wrote:
>
>
> On 02/08/11 03:08, Lee Feigenbaum wrote:
>> In SPARQL 1.0, conformance to the SPARQL Protocol required that an
>> implementation implement the abstract query interface, and that if the
>> implementation implemented the HTTP or SOAP bindings to that interface,
>> that that be done in the manner specified in the document. (See
>> http://www.w3.org/TR/rdf-sparql-protocol/#conformance)
>>
>> In the SPARQL 1.1 Protocol, we have these changes:
>>
>> * Added an update operation
>> * Removed an abstract definition of the operation
>> * Removed SOAP bindings
>> * Added the ability to directly POST a query or update, in addition to
>> via HTTP GET & POST
>>
>> So what should conformance be?
>>
>> Suggestion:
>>
>> * Implement either the query or the update operation or both
>> * For any implemented operations, implement it in at least one of the
>> ways normatively defined in the document
>>
>> This feels to me to be in the spirit of the SPARQL 1.0 Protocol... that
>> said, I'm not thrilled with it since this is a protocol and this gives
>> you 5 different things you can implement to be a conformant SPARQL 1.1
>> Protocol implementation -- that doesn't seem great to be for
>> interoperability.
>>
>> What do you think?
>
> Unless we can find 2 implementations to provide coverage for SOAP, then
> we can't pass the CR criteria anyway.
>
> So I think we should check, then if we can't get coverage, drop SOAP,
> and if we do, drop WSDL in favor of a descriptive style. This isn't a
> trivial change to the doc but it isn't huge either; we don't have the
> WSDL for update yet.
>
> Operation: query
> Parameters:
> query .... occurs once, required ...
> default-graph-uri ....
> named-grap-uri=...
> Result formats:
> ...
>
> WSDL does not help the HTTP implementer; is there an alternative, more
> widely used protocl descritption system for HTTP? Most web APIs seem to
> have description +a table and examples.
>
> Not sure where 5 comes from; there are actually two variations of query,
> implicit and explicit dataset description, +, arguably, FROM/FROM NAME
> handling.

.. as well as GET/POST isms.

Then for conformance (e.g. query), we can provide a set of query strings 
URLs, a service-supplied RDF dataset,  and a expected requests. 
Automation is nice but it's work - a pragmatic approach might be to have 
a HTML table and ask implemented to fill in the answer box:

(encoding aside:)

Query String | method | mimetype | Dataset |  expected | pass/fail

?query=ASK{}	GET      ....	  ...        filename.srx
?query=....     POST


If we include for FROM we may need to host some data.


On interoperability, I'm not so worried as there are different 
capabilities, not all different ways to do the same thing.

>
>
>
> I am planning on reporting on HTTP, query and update and HTTP graph
> protocol; on different endpoints. Query will be for both implicit
> dataset and specified dataset (this latter item is recurrent request for
> users for Fuseki which lacks the feature).
>
> I'm willing to help redraft the protocol doc if it's de-SOAPed.
>
> Andy
>
>>
>> Lee
>>
>

Received on Tuesday, 2 August 2011 12:56:08 UTC