I see at least RDF dumps(no resource consumption worries with this approach), if not SPARQL queries for sites.

:).

Another way to look at it is that different publishers will clearly have different resource consumption limits, and that there’s obviously going to be a lot more with low limits than there will be with high limits. So for any given query, the number of endpoints that will process it successfully will be low, thereby reducing the value of querying that data in that way. The only way to increase the number of endpoints that can process an arbitrary query is to keep the query really simple … which is the motivation behind a forms driven approach to “query”.

As for your point about search engines already having resource-consumption limits built in, I know that’s true. But it’s the same situation whether the query arrives via an HTML form submission or a SPARQL document, so I don’t think it matters for the purposes of comparing the two approaches.

1. I think that SPARQL is a lot more flexible than one thinks at first. Of course one major use is for clients to query a server. But another one that seems very appealing is as a replacement for forms, as a way for servers to query clients. I have described a sketch of how this could work here:
http://blogs.sun.com/bblfish/entry/restful_semantic_web_services
This would of course not at all be heavy on the server. Something to investigate.

2. As for clients asking servers one should not underestimate the complexity of queries sent to search engines. Search engines like AltaVista where I worked had some very long running queries. AV would let them run if there was enough CPU available. Most queries though were just one word queries (which had its own problems of course: how the hell do you know what someone is looking for when they just enter one word!) What is needed is for SPARQL endpoints to be toughened for the open world: you should be able to specify policies for how long queries can last, how much cpu they can use or how much percentage of cpu they can use, and so on. Without that kind of functionality I agree with Mark that SPARQL endpoints will not be viable (unless the engine only makes a very limited number of relations available).
Yes GET to static resources will always be the most common scenario on the web. Those resources are easy to represent, easy to cache, easy to optimise. SPARQL queries are really powerful. But one does not calculate the value of something by how many of those things there are. Without search engines the web would not be anywhere close to as interesting as it is. So SPARQL endpoints (server side) may not be numerous, but that does not mean they may not be game changers.

So from the reasoning above I see the following:
a. Every large company has a search engine, every large company will have a SPARQL endpoint
b. Every client will become a SPARQL endpoint.
c. Every application will become SPARQL conscious (and of course RESTful)
d. The above seems to point to a p2p SPARQL world

Each of these servers requires different type of SPARQL technolgies btw.

i really meant to say is that “..i see in the future public SPARQL endpoints icons right under RSS feed icons….. “

Kendall – I’m saying that SPARQL *is* useful! I look forward to using it myself, as I do a reasonable amount of work with RDF. I’m just pointing out its limitations based on my understanding of Web architecture.

You’re free to disagree of course, but it would be good if you could provide technical reasons why I’m wrong rather than an appeal to authority (as fine an authority as that is, assuming you mean DanC).

Regarding your “I know that you know it’s wrong” comment, I really truly don’t. Encoding a query into a URI is a significantly different approach than a more Web-like hypermedia based URI/form/GET interaction. Also, my position outlined here wouldn’t change had WSDL not been mentioned at all.

You and I have discussed this endlessly, so I don’t expect to convince you; but I really must flag yr incredibly tendentious claims here for others who don’t know better. SPARQL does *not* “expose a much more complex interface than GET”. That’s just *wrong*, and I know that you know it’s wrong. Bad form, Mark.

SPARQL encodes queries exactly into GETs! The first SPARQL protocol client for Python is *dozens*, not hundreds, of lines of code, most of which is XML results handling. SPARQL servers are as simple to develop.

What you are hung up on, of course, is that we used WSDL 2.0 to specify the SPARQL protocol, and you think WSDL is bad for the Web, or something. Hey, fine, ride yr REST hobby horse for all it’ll gain you. I think that’s great if it works for you.

(I’ll point out briefly that the SPARQL protocol spec merely uses WSDL to formalize the protocol; it in no way requires anyone, developers or users, to use WSDL *in any way whatsoever*. None. All of Mark’s very vague claims about “complexity” notwithstanding.)

But, in reality, SPARQL makes nice, if not very adventurous, use of HTTP, using GET to pass around queries, and POST when the query is too long to serialize in a URL.

Everything else you’ve said about its complexity, and about how it violates WebArch, is suspect and disputed by other people who also know a few things about the Web.

I expect more fairness and accuracy when summarizing views you don’t agree with, Mark! :>

My other comment to you – that SPARQL doesn’t have much to do with the Web – was premised on exactly that point, because SPARQL isn’t something that two independent agents on the Web need to agree upon.