Re: new version of fed query

  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 Wednesday, 12 January 2011 18:36:04 UTC