Re: Standard response to delete queries in SPARQL

Hi Justin,
>From SPARQL 1.1 Protocol W3C Recommendation:

"The response body of a successful update request is implementation
defined. Implementations may use HTTP content negotiation to provide both
human-readable and machine-processable information about the completed
update request."

The same goes also for unsuccessful update requests and unsuccessful
queries (obviously, the body of a successful query is instead defined by
the spec because it contains the result set).

Sadly, in my experience, current SPARQL endpoint implementations do not put
much effort in providing machine-processable information for these cases.

I made a small experiment looking at timeout errors (for queries) from
different endpoints. The body of the responses were all plain strings with
differing messages (sometimes hard to process even by a human) and even the
returned HTTP status codes were diverse.

I think there is much room for improvement, both for spec and for the
SPARQL endpoint implementers who could start using machine-readable
descriptions in the response bodies for these requests.

Kind regards,
Miguel

Il giorno gio 15 giu 2017 alle ore 13:25 justin mchugh <
theamazingnull@hotmail.com> ha scritto:

> Hi,
>
>
>
> I have been writing some code that abstracts the behavior of triple stores
> to make it easier for users who do not understand sparql to take advantage
> of triple stores. Mostly, I have used openlink Virtuoso as the underlying
> store and am interacting with it over http/https.
>
>
>
> I am at the point where I find the need to wrap deletions. I have looked
> but am unable to find a standardized response in the SPARQL docs that is
> returned when executing a delete query. The SPARQL docs give descriptions
> of the state of the data before and after but no expected response.
>
>
>
> Virtuoso responds with:
>
>
>
> “Delete from <graph name>, 0 triples – nothing to do”
>
>
>
> alternately, it may respond with a count. This does not seem like a
> standard message. Is there a standard I can expect to parse or will this
> differ from implementation to implementation?
>
>
>
> Thanks,
>
> Justin McHugh
>
> Computer Scientist @ GE Global Research
>