W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: new version of fed query

From: Carlos Buil Aranda <cbuil@fi.upm.es>
Date: Mon, 17 Jan 2011 10:07:09 -0300
Message-ID: <4D343EFD.7050006@fi.upm.es>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
  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?


>     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.
>> Id 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 Im not sure if instead of query 2
>> remote endpoints the user queries 4, 5 or more, in a complex query.
>> So, going back to Andys 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:03 UTC