Re: Return codes

On 07/05/2010 11:02 AM, Alexandre Passant wrote:
> 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.

+1 : no counts anywhere.

This can be very hard to implement.  Some processing may go on after the 
operation is "successful" and the later step established the count.  For 
example, the triples may not be fully added so duplicates not yet 
suppressed. It just needs to complete before the next request is processed.

Counting a graph for before-and-after can be hugely expensive.  I'd 
rather not have to scan 1e9 triples when adding one.

What does it mean?  Unique triples added or number of triples seen 
(including duplicates?) Does value equivalence affect the results?

	Andy


>
> Best,
>
> Alex.
>
>>
>> Regards,
>> Paul
>
> --
> Dr. Alexandre Passant
> Digital Enterprise Research Institute
> National University of Ireland, Galway
> :me owl:sameAs<http://apassant.net/alex>  .
>
>
>
>
>
>
>
>
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation™
>
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.

Received on Friday, 7 May 2010 18:16:05 UTC