Re: no need to track WG issues in SPARQL document

On Thu, Sep 30, 2004 at 08:40:12AM -0500, Dan Connolly wrote:
> > 1/ "cascadedQueries"
> > 
> > The name implies to me one query after another, maybe with flows of
> > variables.
> 
> Yes, that's the issue, no? Hmm... I can't confirm from any
> records, but that's the issue I mean for the WG to consider.

There are protocol interactions with this issue. I've been thinking a
lot about multipart HTTP requests and responses and how (or whether)
to reflect that into the abstract protocol. It's obviously much easier
to think about, specify, and implement in the case where variables are
*not* shared across multiple queries; but the case where variables are
shared is much more powerful.

Our Urchin-Kowari integration work (position paper about this
submitted to the Life Sciences W3C Workshop if yr interested) contains
a relevant use case, if that helps. 

(In short: we query Kowari over SOAP. Before my student figured out
iTQL's nested queries, he'd do one query + one query for every match
in the first query to satisfy a user request. In other words, 1+n
queries where n is the number RSS channels a user's query matched.
That's sometimes 50 or even 100 SOAP calls. Very ugly. With nested
queries now we only do 1 query, and hence 1 SOAP call, no matter how
many matches. Very nice.)

> > How about "multpleQueriesPerRequest" which is more neutral to the
> > interactions?
> 
> That's not something I'm inclined to make an issue out of;
> that's sort of an obviously available design choice. The
> WG will either choose it or not in due course; I don't feel
> it's worth me tracking it.

I plan on including something about this in the protocol design, so
making an issue out of it does seem pointless at *this* point. But I
think Andy may have been suggesting a rename of the cascadingQueries
issue instead of suggesting another one?

Cheers,
Kendall

Received on Thursday, 30 September 2004 13:51:37 UTC