Re: new version of fed query

  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 Monday, 17 January 2011 13:08:12 UTC