Re: new version of fed query

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.

We could have:

SERVICE <service> {} -- errors propagate

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

	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 Sunday, 16 January 2011 14:43:10 UTC