Re: Async callback [was Re: SQI: Related Work to SPARQL Protocol]

On Fri, May 13, 2005 at 05:50:14PM +0200, Danny Ayers wrote:

> A possible approach that occurred to me was using the simple GET style
> of query, with an additional callback URI as an extra parameter. The
> server would respond immediately with an OK, but pass the query into a
> queue (or whatever). Once the server had the query results available,
> it would act as a client and pass the data as the content of a POST
> (or PUT) to the supplied callback URI. Whether or not it would be
> worth going to the trouble of putting a time limit on the response
> delay or even repeats, I'm not sure; I suspect that successful/don't
> know would be adequate in many circumstances.

In addition to yr reasons for needing something like this, consider
the case of very complex queries over huge datasets in the presence of
non-trivial inference (say SH(I|O)N(D))... such a query might involve
sound and complete but really *slow* reasoning, thus making the query
really slow to complete. A "we know it's gonna terminate, but you
better make a pot of coffee" kind of situation. Given the state of DL
reasoning these days, in which secondary storage touching is *just*
starting to be an active research topic, I think for the forseeable
future we'll have to think of many SemWeb/reasoning tasks in this sort
of batchish way.

Further, it may not even be the case that the answer set is especially
large, in which case streaming doesn't *really* help, since the
problem is the total amount of time one has to wait for the *first*
answer, and the utility of not holding resources (TCP/IP connections,
server resources, client buffers, etc.) open whilst you wait.

In both of these cases, I think the very simple callback mechanism you
suggest makes perfect sense. Simply include, in the protocol, a
callback slot, and the server turns into a client and conveys the
results. (One would have to add this "convey the results" thing as a
separate protocol operation, but since there's *no KB insertion
semantics* in this case, it's *relatively* trivial, at least compared
to an explicit graph modification or triples addition operation.)

But here I speak only for myself, and I'd be very very surpised to see
any of this in this version of SPARQL. But this seems like prime real
estate for a rechartering, at least IMO.

Kendall Clark

Received on Friday, 13 May 2005 16:20:44 UTC