- From: Mark Baker <distobj@acm.org>
- Date: Thu, 6 Oct 2005 10:13:50 -0400
- To: Leigh Dodds <leigh@ldodds.com>
- Cc: www-archive@w3.org
On Thu, Oct 06, 2005 at 02:21:37PM +0100, Leigh Dodds wrote: > >>I had questions about that design myself, but this alternative > >>never occured to me. Personally I was considering merits > >>of say: > >> > >>/graph/uri?query= > >> > >>i.e. pass the query as a parameter to the URI of the graph. > >>Initially this seemed "better" as it was clearer that I was > >>querying a graph. But obviously its limited in applicability when > >>working with multiple graphs, and perhaps when defining > >>an abstract protocol. > >> > >>Any thoughts on that? > > > >You mean that the "/graph/uri" part would be important to the client? > >If so, I don't think that's such a good idea for opacity reasons. > > > >If you don't mean that, then I'm not sure what you mean since what > >you describe is status quo with the SPARQL protocol and its use of GET. > > Hmmm let me try to clarify, and then you can still point out where > I'm wrong :) > > I read SPARQL Protocol as defining a query endpoint, a service. The > service takes parameters of the query, plus the data source URIs. > > i.e. /sparql?query=...&default-graph-uri=/uri/of/my/data > > I was musing on merits of: > > /uri/of/my/data?query=.... Ah, I hadn't noticed that part of the protocol. Yes, sure, that would make sense. You should submit that as a comment. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Thursday, 6 October 2005 14:11:47 UTC