Many thanks for the links; there’s a lot of interesting and highly usable stuff there.

I like the SQUIN approach, since it solves the data source discovery and selection issue, and also follows the ‘smart, hard-working client & dumb, data shoveling server’ approach I’ve tried to outline here.

As you’ve indicated, though, the SQUIN approach seems best suited for discovery oriented queries. For queries where you know the datasets, and just need up-to-date results, a ‘named graphs as RDF dumps’ approach seems fine to me so far. I know that’s technically a local data replication option, but it seems a lot easier, quicker and more timely (depending on the frequency of the data-dumps client side) than other local data replication methods.

Cheers!

Wilbert

A few pointers that might be interesting to you:

You may want to have a look at my slides about “Querying Linked Data with SPARQL”. These slides list different options for querying Linked Data, including the pros and cons. This slideset is from the Consuming Linked Data tutorial we gave at last year’s ISWC. At the WWW conference in April we will give a similar tutorial again.

I’m working on a novel query execution paradigm called link traversal based query execution that allows to execute SPARQL queries over the Web of Linked Data (at least over connected parts of it). The idea is to discover data relevant for answering a query by following specific RDF links during the query execution itself. All that is required from the publishers is adherence to the Linked Data principles; i.e. no requirement for SPARQL endpoints. You can read about link traversal based query execution in my ISWC’09 paper “Executing SPARQL Queries over the Web of Linked Data”. A query engine that implements the query approach is part of the Semantic Web Client Library. On top of this library I implemented SQUIN which provides the functionality of the query engine as a simple Web service that can be accessed like an ordinary SPARQL endpoint.

Greetings,
Olaf

What I’m arguing for here is that for data _providers_ should focus on nicely factored graphs and sensible URIs first, and worry about SPARQL endpoints later. From a _consumers_ point of view, though, SPARQL endpoints are the place where you start.

In that sense, there is also developer preference and experience. Tony Hirst is the grand wizard of Yahoo pipes. I don’t really get that stuff; it feels like trying to do calligraphy with boxing gloves on. And that’s before considering the fact that I’m reluctant to stick a lot of time in a proprietary platform.

On the other hand, I find it very easy and natural to think in rdf and sparql, but I guess not everyone’s brain is wired that way.

Not to fret, though: the simple meshup quickly goes from the results of a SPARQL query to formats more amenable to Tony’s mashups: CSV and Google spreadsheets. JSON and XML is just as easy.