- From: Carlos Buil Aranda <cbuil@fi.upm.es>
- Date: Wed, 12 Jan 2011 15:35:01 -0300
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
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