Re: new version of fed query

catching up on this discussion, but as I understand, it boils down to just that proposal, right?

>> SERVICE <service> {} -- errors propagate
>> 
>> SERVICE SILENT <service> {} -- error suppressed.


+1
That looks good to me, so you can declare when you're ok to ignore errors explicitly...

Axel

On 17 Jan 2011, at 13:07, Carlos Buil Aranda wrote:

> On 16/01/2011 11:42, Andy Seaborne wrote:
>> Carlos,
>> 
>> I like the use case (OPTIONAL+SERVICE) you present although just being OPTIONAL does not seem automatcially strong enough to make it errors always ignorable.  It is strange for queries to return one set of results on one run and a different set on another run when none of the data has changed.
>> 
>> If the right thing to do depends on the query, then surely we should design for the common case (SERVICE not being optional), and not design for this less common case.
>> 
>> There are error cases such as truncated results being returned.
> I agree in all your comments.
>> 
>> We could have:
>> 
>> SERVICE <service> {} -- errors propagate
>> 
>> SERVICE SILENT <service> {} -- error suppressed.
> This seems a good idea to me, any more comment?
> 
> Carlos
> 
>> 
>>    Andy
>> 
>> On 12/01/11 18:35, Carlos Buil Aranda wrote:
>>> Hi Andy,
>>> 
>>>> Service silent: I'm not sure it's a good idea to silently fail in the
>>>> case of a bad SERVICE request because it then looks like there were no
>>>> results. I suggest instead that we define SERVICE for the case where
>>>> it works, and state that if there is an error then something
>>>> implementation specific happens. Only a 404 from a "SERVICE ?service"
>>>> seems to me to be the same as no results. The case of endpoint
>>>> currently down or inaccessible seem rather different.
>>> 
>>> I’d like to clarify what happens when the service silent operation
>>> happens. The idea of the silent operation is to not fail the entire
>>> query when a remote SPARQL endpoint. From my point of view, it would not
>>> be good to fail an entire query if an SPARQL endpoint is down,
>>> inaccessible or returns a 404 error. Why? It depends on the query I
>>> think. For instance, in a query with an optional and SERVICE inside this
>>> optional what I want to do is to optionally get the results from a query
>>> in that service. If there are no results it would be ok for me, the
>>> important part comes from the non optional part of the query. Therefore,
>>> for me, to fail the entire query because something optional it would be
>>> an error. If I just want to join the information from a couple of
>>> endpoints using SERVICE (for instance projects and people data), the
>>> fact that the query crashed would indicate that any of the remote
>>> endpoints are down (using the appropriate error message from the system)
>>> maybe that would be not that bad. But I’m not sure if instead of query 2
>>> remote endpoints the user queries 4, 5 or more, in a complex query.
>>> 
>>> So, going back to Andy’s proposal it contained two possibilities:
>>> - in error 404 return silent operation with all variables in the service
>>> unbounded: I agree with it
>>> - error the whole query if an endpoint is unavailable : it depends on
>>> the query
>>> 
>>> Would it be possible to indicate to the system implementing the
>>> specification how to behave in this specific situation? I think this
>>> would be a good idea.
>>> 
>>> Any comments?
>>> 
>>> 
>>> Carlos
> 
>

Received on Thursday, 20 January 2011 11:53:50 UTC