W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

Re: Return codes

From: Alexandre Passant <alexandre.passant@deri.org>
Date: Fri, 7 May 2010 11:02:44 +0100
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <48126ACA-08F5-43C8-90C5-2E85590F2BDC@deri.org>
To: Paul Gearon <gearon@ieee.org>
Hi,

On 6 May 2010, at 18:43, Paul Gearon wrote:

> On Thu, May 6, 2010 at 2:09 AM, Alexandre Passant
> <alexandre.passant@deri.org> wrote:
>> Hi,
>> 
>> On 6 May 2010, at 03:55, Paul Gearon wrote:
>> 
>>> The Update document now refers to result codes for each operation.
>>> 
>>> A couple of things came up while I was doing this, and I would like
>>> some feedback:
>>> 
>>> - I have explicitly avoided stating what a result looks like, as this
>>> is a job for the interface. I'd expect some kind of representation to
>>> be used for SPARQL Protocol, HTTP operations, an API, and any other
>>> type of interface.
>> 
>> Would some HTTP codes for failure / success be defined in the protocol ?
> 
> Do you mean the SPARQL protocol? (as opposed to the HTTP protocol)
> 
> I was thinking that the SPARQL protocol would probably define
> appropriate codes in the 5xx range, since the HTTP protocol has
> already specified that those codes refer to a problem at the server
> end. As for the extra information, that could be in a header or body,
> but I'd have expected a header. (Though I've seen the note below about
> updates)

Yes, I meant using 5xx codes for errors.
BTW, by reading the current SPARQL Protocol doc, I see that 201 should be returned for new graph creation, what about 200 for other successful queries ?

> 
>>> - Most operations can fail partially or completely. To describe the
>>> mode of failure I said that a failure can contain extra information,
>>> and in most cases that will be an integer representing the number of
>>> triples that were correctly processed. DELETE/INSERT is the one
>>> exception to this, as a failure there includes a pair of tuples.
>>> Presuming everyone is OK with this  should a complete failure be a
>>> separate type again, or is a failure(0) sufficient? I have gone with
>>> failure(0).
>>> 
>>> - Going with the idea of failure data including the number of
>>> successfully processed triples, I specified the failure of "DROP
>>> GRAPH" due to partial deletion of data to include the number of
>>> triples that were deleted. This makes sense to me, since the user can
>>> always count whatever is left, but I just wanted to check that no one
>>> wanted the failure to report the number of remaining triples instead.
>> 
>> We decided (F2F3) to not indicate the number of triples added / deleted in Update [1] so we probably should stick to that.
>> Counting the number of triples that left may also be cumbersome (e.g. if it deletes entailed triples, or if you simply forgot to check number of triples in the store before the query), even from the implementation side itself I guess.
> 
> Ah yes, I'd forgotten about not counting triples in an update, but I
> recall it now. Thank you for reminding me. (personally, this will be
> easier to implement, so I'm happy)
> 
> I'm still expecting to count the number of triples processed while
> loading, right? You'll also notice that success does not carry any
> extra information. Would it be useful for a successful LOAD to return
> the number of triples loaded? It can be worked out in many cases by
> doing a count before and after, but that's not guaranteed due to
> redundant triples. On the other hand, I don't know how useful it is,
> so I thought I should ask.

IIRC, the decision of not adding information (besides the success / failure code) is for any Update query, so also for LOAD - mainly for time concerns reasons.
So I'm happy to get only this code and not go further for that round.
We could yet add that implementors MAY decide to return the number of triples in the reply body / header.

Best,

Alex.

> 
> Regards,
> Paul

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .
Received on Friday, 7 May 2010 10:03:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:42 GMT